• No results found

An extended topology on a single queue manager

Figure 2-2 on page 16 is an extended topology on a single queue manager with two clients.

Figure 2-2 An extended topology on a single queue manager

The topology in Figure 2-2 has the following characteristics:

򐂰 Coordination queue manager resides on the intermediate queue manager

򐂰 The command queue manager and agent queue manager can both reside on the intermediate queue manager

򐂰 Each agent uses client mode to associate with the intermediate queue manager through a server connection channel

򐂰 Either client agent can be a source or destination

򐂰 Two client agents do not directly transfer files with each other but communicate through the intermediate queue manager

򐂰 The intermediate queue manager does not have any FTE code installed In the topology, you can install the WebSphere MQ File Transfer Edition plug-in or remote tools for operating, monitoring, and managing in every FTE client agent.

2.1.2 Benefits and drawbacks of this topology

In this section, we discuss the benefits and drawbacks of a single queue manager topology.

Benefits

The single queue manager topology is a light weight file transfer architecture that is simple to understand and easy to create. It makes significant use of FTE clients to transfer files between a source and destination.

SVRCONN

Chapter 2. Topologies 17 The benefits of this topology are:

򐂰 FTE client reduces system requirements

You can configure many client agents on a single queue manager topology.

These client agents require less system resources than server agents that are running on queue managers by bindings mode. Client agents support more desktop operation system versions, such as Windows 2000, Windows XP, Windows Sever 2003, Windows Vista®, and Windows Server® 2008.

򐂰 Installation and configuration are simple

WebSphere MQ File Transfer Edition client does not depend on a WebSphere MQ client, and it provides a small installation footprint.

򐂰 Minimal maintenance and management workload

There is minimal workload of management and maintenance on the FTE client because there are not any queue managers or queues.

Drawbacks

The limitations of this topology are:

򐂰 Limitation of communication between FTE client agents

As shown in Figure 2-2 on page 16, two client agents cannot directly transfer files with each other. The FTE clients must depend on an intermediate queue manager and communicate using server connection channels. We do not recommend using server connection channels across a wide area network (WAN). Therefore this topology is best suited to intra-enterprise

communications.

򐂰 Performance limitations

Client channels perform poorly in comparison to sender/receiver channels because client channels use one TCP/IP connection to complete

two-direction communication. You do not get the best transfer performance between physical nodes if you use a client channel.

Additionally, all workload must flow through a single queue manager, potentially creating a bottleneck in performance.

򐂰 No flexibility and scalability

This is a hub structure on a single queue manager. It is difficult for this structure to be extended to a multi-level structure. There is little flexibility or scalability.

򐂰 Outage problem on a single queue manager

If the single queue manager is offline in this topology, all file transfers cease;

therefore, this is a single point-of-failure.

򐂰 Security limitations

In production environments, the security level that is required for firewalls is typically high. Therefore incoming and outgoing ports on the firewall are tightly controlled and limited. The sender/receiver channels in WebSphere MQ can support this security requirement, but the server connection channels that FTE client agents use do not support setting a fixed local address port or a range of ports.

2.1.3 When to use this topology

Although the single queue manager topology is not commonplace in production environments, there are scenarios where it makes sense to use it.

One such scenario is that of a travel agency that hopes to construct a reliable, robust, and safe file transfer platform between two local offices, as shown in Figure 2-3. The travel agency has two offices in New York: the headquarters office and financial office. An intranet environment that is in good condition is between the two offices.

Figure 2-3 A travel agency scenario

The headquarter office is the business and data center. Every day the

headquarter office sends marketing information and travel sales data to the New York financial office. In the same site, there are a few IT engineers, application developers, and system administrators.

The financial office in New York is a local branch office of this travel agency. This office analyzes marketing and sales data every day and then returns the financial

NYFIN.SVRCONN

Chapter 2. Topologies 19 analysis reports to the headquarters office. There is no IT engineer for system management and maintenance in the New York office.

The single queue manager topology is a good fit for the travel agency’s requirements:

򐂰 The headquarters office hosts WebSphere MQ server V7.0 and WebSphere MQ File Transfer Edition server V7.0. A server agent using bindings mode is connected to only one queue manager that shares as coordination queue manager, command queue manager, and agent queue manager.

򐂰 In the financial office, a client agent is configured to the queue manager on the headquarter office. Files can be transferred through the

NYFIN.SVRCONN channel between the two offices. The two offices can both use the FTE eclipse plug-in tools or command lines to manage and monitor file transfers.

Another scenario is that a public agency adopts a software solution for file distribution and management instead of the high cost hardware solution of a Storage Area Network. The public agency has three business systems and one information center in a local area network. Every day three business systems upload business data files and official documents to the information center. At the same time, the systems download the updated data files from the information center on schedule. There is not a significant amount of file movement.

In Figure 2-4 on page 20, we provide a light-weight software solution to the public agency.

Figure 2-4 A public agency scenario

The information center is a file transfer hub that runs one WebSphere MQ queue manager as a coordination queue manager, command queue manager, and agent queue manager. FTE client agents run on three business systems and connect to the coordination queue manager using the SVRCONN channel in the local area network. This topology can help the public agency implement quick file movement in two-directions and reduce costs.

2.2 Multi queue manager topology

In this section, we introduce a multi queue manager topology and describe the architectural details for WebSphere MQ File Transfer Edition.

2.2.1 Topology overview

The more common WebSphere MQ File Transfer Edition network domain has multiple queue managers that are interconnected. You might have some queue managers that act as WebSphere MQ File Transfer Edition agent concentrators,

Information Center

Chapter 2. Topologies 21 while other queue mangers might only have binding mode agents. Either server agent or client agent needs a set of queues on an agent queue manager. These queues are internal queue systems to FTE and they are transparent to the end user.

You can have queue managers act as the WebSphere MQ File Transfer Edition command queue manager to provide for entry points for command lines and WebSphere MQ File Transfer Edition plug-in tools. The command queue manager can be different from the agent queue manager. It is not necessary for agents to be connected to the same command queue manager, and this queue manager can be local or remote.

Either command queue manager or agent queue manager can be from WebSphere MQ V6.0 or later.

Finally there is at least a coordination queue manager in a WebSphere MQ File Transfer Edition network domain. The coordination queue manager must be a WebSphere MQ V7.0 queue manager for its publish/subscribe feature. FTE Agents send progress and logging messages to coordination queue manager, then these messages are published to the SYSTEM.FTE topic. The FTE Explorer plug-in, when installed, is a subscriber to this topic.

If there are more than two coordination queue managers in a multi queue manager topology, one agent queue manager must only belong to one

coordination queue manager and have connectivity to the queue manager in a WebSphere MQ network.

WebSphere MQ has many ways to connect queue managers, and, by its nature, that means that there are many designs that you can use to develop a multiple queue manager topology for the WebSphere MQ File Transfer Edition network domain.

In the following sections, we introduce some common topologies on multi queue managers.