9.4 Design guidelines

 < Day Day Up > 



9.4 Design guidelines

When using WebSphere Business Integration Message Broker as a message broker there are several things to consider to begin the design of the message flow. External factors such as the characteristics of the clients and target applications may present hard and fast restrictions. These include things such as message transports and application interfaces supported.

Quality of Service issues must also be considered. Do you need persistent messaging? Is the speed of the transaction more important than assured delivery?

Once you have determined what these are, you can look into the design of the message flows appropriate for accomplishing your task. WebSphere Business Integration Message Broker supports a wide range of transport support and message flow designs.

9.4.1 Selecting a transport

Consider the following features when selecting a transport to use for application communication with WebSphere Business Integration Message Broker:

  • WebSphere MQ Web Services Transport: Use this when you want to allow Web services clients to use non-persistent, non-transactional messaging to communicate with other applications.

  • WebSphere MQ Real-time Transport: Use this for applications and environments where you need to send large numbers of messages, or where messages are to be sent to large numbers of client applications. Use this protocol for applications that must rely on the Quality of Service provided by TCP/IP but do not need persistent delivery.

  • WebSphere MQ Enterprise Transport: Use this when you require assured delivery of messages or need to use transactional support. There are overheads involved in using the WebSphere MQ Enterprise Transport, therefore it does not offer the same levels of performance and scalability as the WebSphere MQ Real-time Transport.

9.4.2 Using real-time applications

The WebSphere MQ Real-Time transport is a protocol which allows client applications to communicate directly with the Broker via TCP/IP instead of via intermediate queues. This direct communication, and the small overhead of the TCP/IP flows used by the Real-Time Transport, offers potentially higher levels of performance than the WebSphere MQ Enterprise Transport.

The Real-Time transport does not provide any facility for persistent messages or durable subscriptions, and so is most useful for situations where data is updated very frequently, such as updating a scoreboard for a sporting event or updating a share price on a stock ticker. Applications that connect using WebSphere MQ Real-time Transport and JMS use predominantly the publish/subscribe model.

WebSphere MQ Real-time support is provided using the following message flow nodes:

  • Real-timeInput node: This node is used to receive messages from clients that connect using WebSphere MQ Real-time Transport or the WebSphere MQ Multicast Transport, and that use JMS application programming interfaces, into a message flow.

  • Real-timeOptimizedFlow node: This node is used as a complete message flow that provides a high performance publish/subscribe message flow, or, to put it another way, a multicast output node. The actions taken by this node are all internalized. Setting properties is the only way to influence its operation. Clients connect using the WebSphere MQ Real-time Transport or the WebSphere MQ Multicast Transport, and use JMS application programming interfaces. The node also supports publication to or subscription from standard WebSphere MQ applications, but with lesser performance as that achieved by JMS applications.

  • Publication node: Use the Publication node to filter output messages from a message flow and transmit them to subscribers who have registered an interest in a particular set of topics. The Publication node must always be an output node of a message flow and has no output terminals of its own.

The real-time transport is simple to configure and use in both the message flows and in JMS client applications. To send messages into a message flow using the Real-Time transport, add a Real-timeInput node or a Real-timeOptimizedFlow node to the flow. Once one of these nodes has been wired into a flow, subscribing applications can use the node to register for subscriptions over the Real-Time transport, and publishing applications can publish into the node over the Real-Time transport.

To use the Real-Time transport to publish messages out of a message flow to subscribing clients, add either the Publication node or the Real-timeOptimizedFlow node to a flow. Messages are published to subscribers using the same transport that the subscriber registered with, so the Publication node or Real-timeOptimizedFlow node will use either the WebSphere MQ Enterprise transport or the Real-Time transport to publish messages to subscribers.

When configuring either of the Real-Time input nodes, the only mandatory property is the port number that the broker uses to listen for incoming connections.

JMS clients that publish or subscribe messages using the WebSphere MQ Enterprise transport can be easily modified to use the Real-Time transport instead. JMS clients that use administered objects can be switched to use the Real-Time transport without changing any existing code, and without the application even being aware that it is using a different transport. This is accomplished by setting the TRANSPORT and PORT properties on the ConnectionFactory administered object.

9.4.3 Using Web services support

Applications that connect using WebSphere MQ Web Services Transport and HTTP use predominantly the point-to-point model.

The broker, in support of a message flow, can either act as a Web service itself, or, act as an intermediary. Input and output to the message flow is HTTP, and it is important to remember that HTTP messages are non-persistent, have no order associated with them, and not treated transactionally.

Three nodes are specific to Web services support:

  • HTTPInput node: The HTTPInput node is used to receive Web service requests for processing by a message flow. When an HTTPInput node is included in a message flow, an HTTPReply node must be included in the same flow. The HTTPInput node defines a URL selector which determines the node and path used to request this message flow.

    For example:

    • http://mbnode:7080/mymessageflow

    In this example, the client is requesting a message flow called mymessageflow, running on a broker listening on port 7080 (the default broker port) on host mbnode.

  • HTTPRequest node: When the broker acts as an intermediary between the client and a Web service, an HTTPRequest node is used in the message flow to send all or part of the message to a Web service and to coordinate the response. Its properties include the URL of the Web service.

  • HTTPReply node: The HTTPReply node constructs a SOAP-encoded reply message from the message returned by the Web service and sends it to the requestor.

Here are some examples of using Web service support within message flows:

  1. A message flow requires data provided by a Web service. To get this data, an HTTPRequest node is imbedded in the message flow (Figure 9-7).

    click to expand
    Figure 9-7: Step 2- Passthru message flow

  2. A message flow is to be made available to clients as a Web service. The input and output are handled by the HTTPInput and HTTPOutput nodes. The message is converted to an MQ message for manipulation within the existing message flow (Figure 9-8).

    click to expand
    Figure 9-8: Step 2- Passthru message flow

  3. A message flow is needed to intercept requests from clients and route it those requests to the appropriate Web service. The message is received using the HTTPInput node. The message can be manipulated first or inspected to determine routing information. It is passed to the Web service using the HTTPRequest node. The reply is sent back to the client using the HTTPReply node (Figure 9-9).

    click to expand
    Figure 9-9: Step 2- Passthru message flow

9.4.4 Using aggregation

Message flows using aggregation allow you to take an incoming message, split it into multiple messages to be sent to multiple back-end systems (fan-out), and then combine the replies into one reply (fan-in) to be sent back to the client.

The multiple fan-out requests are issued in parallel from within a message flow. This is in contrast to the standard operation of the message flow in which each node performs its processing in sequence.

Here are some examples of this:

  • ABC Electronics allows Retailers to send in order numbers to Wholesale systems to request a delivery date. More than one Wholesaler can supply the part, so the message flow simultaneously sends the request to all Wholesale systems that supply that part. When each system replies with a date, the message flow determines which Wholesaler can supply the part at the earliest date and returns that information.

  • Bank clients can request bank statements online. In reality, their accounts (mortgage, savings, stock, etc.) are held in different back-end systems. The message flow sends the request to each relevant system and returns one statement that includes the account status from each system.

The aggregation function is provided by the following three nodes:

  • The AggregateControl node marks the beginning of a fan-out of requests that are part of an aggregation. It sends a control message that is used by the AggregateReply node to match the different requests that have been made. The information propagated from the control terminal includes the broker identifier, the aggregate name property, and the timeout property.

  • The AggregateRequest node records the fact that the request messages have been sent. It also collects information that helps the AggregateReply node to construct the aggregated reply message.

  • The AggregateReply node marks the end of an aggregation fan-in. It collects replies and combines them into a single aggregated reply message.

An aggregation message flow will most likely contain Compute nodes using ESQL scripts to implement logic needed during the fan-out or fan-in process. In particular, Compute nodes are handy for manipulation of the aggregated reply before returning it to the client. Message flows can also interact with external databases to store or retrieve information needed during processing.

When determining whether to use aggregation, keep the following considerations in mind:

  1. Message flows using aggregation are generally the most complex message flows to be constructed.

  2. In production you would want the fan-out and fan-in flows to be in two different message flows. This allows the input flow to be stopped first while allowing inflight requests to complete before the fan-in flow is stopped.

  3. Good design is necessary to ensure that all fan-out and fan-in messages are captured and processed.

  4. A good knowledge of ESQL and the logical message tree is necessary to manipulate the combined messages.



 < Day Day Up > 



Patterns. Broker Interactions for Intra- and Inter-Enterprise
Patterns. Broker Interactions for Intra- and Inter-Enterprise
ISBN: N/A
EAN: N/A
Year: 2004
Pages: 102

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net