Posts on our IBM-internal FTE newsgroup fall into a couple of categories. Some people understand the product well, and are contacting us about an obscure technical point, or advice on a complex situation, or have a suggestion about how we can make some specific part even better. I answer these posts in the same frame of mind as if I was talking to a fellow developer; the two of us are sharing the same mental model of the system. Other posts, I know as soon as I read the first sentence or two, require a completely different style of answer. These are people who are new to the product, are asking about the basics, and quite possibly have a wildly different (and inaccurate) mental model of what FTE is. A very good sign of a "type two" post is people talking about connecting their FTE clients to their FTE server.
FTE is not a client / server system. FTE is point-to-point.
The client / server networking paradigm is extremely common, and maps well to many things. Being baked into the HTTP protocol and everything built on top of it, client / server is practically ubiquitous on networks today. But it's not the only way of doing things, and FTE does not assume that you want to operate in a client / server way.
Apart from the various small control applications like fteCreateTransfer, fteListSchedules and so on, the FTE software comes in the form of the agent
. Typically you would probably have one agent on each machine that needs to send or receive files, although it's entirely possible to have more (I generally have about half a dozen on my laptop). Putting aside security considerations for the moment, any one agent can send files to any other agent, and similarly be the recipient of such files. No particular agent needs to be "the server", and there's no difference between an agent that sends files and one that receives them. Transfers can be initiated from either end or, more commonly, from somewhere else altogether. You don't log in to an "FTE server" and pull down the files you want like you would with an FTP server; the nearest thing would be to create a transfer from an agent elsewhere to an agent local to you.Some MQ background
Some relevant MQ terms for those unfamiliar with that product:
- Queue Manager - essentially, an MQ server. Other applications (of which an FTE agent is an example) connect to queue managers to send and receive MQ messages.
- Bindings Mode - a form of connection between an application and a queue manager that does not use the network. QM and application must be on the same machine. I think this is implemented using shared memory, but to be honest I've never really needed to look into it. It's fast, reliable, and provides a few more features than Client Mode.
- Client Mode - another form of connection between application and QM, more like the way other servers work. The queue manager listens on one or more network ports and applications connect to those ports. QM and application can be on the same or different machines. The application can be seen as a client of the queue manager.
So why do we sell separate "FTE Client" and "FTE Server" CDs?
Midway through the development of FTE version 18.104.22.168,¹ our friendly Marketing folks² decided that there should be a "big" and a "small" version of FTE, sold on different terms for different customer needs. The major differentiator between these versions is that the "small" one can only connect in Client Mode, to a queue manager on a different machine. The ability to connect FTE directly to its queue manager in Bindings Mode is reserved for the "big" version. Since "big" and "small" as product names aren't really IBM's style, they had to think of something to call these different versions. Given the local-vs-remote nature of the main difference between them, "Server" and "Client" seemed pretty reasonable to everyone concerned.
Unfortunately, the default client / server mindset in the world at large seems to lead many people into a misunderstanding. An "FTE Client" agent is a client in the sense that it connects to its queue manager over the network, but in its essential agent-ness it's the equal of any other. At the FTE level, ignoring the MQ plumbing beneath, it's still a point-to-point world. When you're designing and installing an FTE network you need to care how agents talk to their queue managers, but once that's done you can forget all about it. The FTE control commands don't discriminate between agents that came out of a box labelled "Server" and one with a "Client" sticker. How an agent communicates with its queue manager is its own business, indeed can be changed without anyone else noticing (you can order a "Server" agent to slum it as a Client Mode application if you want). Of the half dozen or so agents on my machine at any time, I don't generally remember which are configured for Client Mode and which for Bindings - at the FTE application level there is no functional difference.Do I want to go large?
So if a nice big FTE Server agent is actually indistinguishable apart from its plumbing, why use it? Because plumbing matters, that's why. Notice that in the last paragraph I said "no functional
difference" - I'm using the term in the sense of functional requirement
. You can do the same things, but the non-functional aspects, the "ilities", may be different. Throughput and speed of recovery spring to mind, but I have to admit to getting a little handwavey here, since when I worked in MQ this wasn't an area I had much to do with. Still, it's certainly the case that there are good reasons to opt for a bindings connection if you can, and that means an FTE Server agent.
(Incidently, on z/OS you don't have a choice. MQ client mode applications on
z/OS (as opposed to client applications connecting to
z/OS via the MQ Client Attach Facility) do not exist, and hence there is no FTE Client option on the mainframe. You always get an MQ Bindings connection.)But I WANT a client / server topology!
That's no problem - you can have one. FTE is point-to-point, but when Points B to Z all connect to Point A, then Point A starts to look an awful lot like a server. Since Point A is now quite important and maybe handling a lot of traffic, it probably also makes sense to use an FTE Server agent in this role to get the benefits of MQ Bindings mode. Just understand that the two aspects of server-ness (1, topologically, being everybody's go-to guy / 2, FTE-license-ologically, having a fat pipe to MQ) are largely independent. Sometimes they'll coincide, sometimes they won't. Summary - two levels
When you're contemplating performance, queue manager locations, licensing costs, etc, you're at the plumbing level, and you should be thinking about which agents in your network will be FTE Server and which FTE Client. When you're designing transfers and flows between agents you're at the application topology level, and you can design whatever topology makes sense.If it makes sense for your scenario,
there's no problem with having a dozen client machines
running FTE Server, getting files from a central server machine that
runs FTE Client.
If you understand that sentence then you understand this post.
1. Our first version, but our numbers have to line up with MQ's
2. I'm not being facetious. One of the things I noticed when I joined the FTE Development team is how much more closely we work with our people in Marketing, Tech Sales, and so on - I like it.