Chapter 9. Broker solutions using WebSphere Business Integration Message Broker 231
Figure 9-6 Exposed Broker Runtime pattern and product mapping
The Web Services Gateway provides a standard, secure interface to external
processes. A UDDI registry is not required, but provides an additional layer of
protection against the disruptions cause by changes in the external services. A
private or public UDDI registry could be used.
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?
Source
Application
Broker
Rules
Target
Application
Partner A
Secure Zone
Demilitarized
Zone
Partner B
Inter-
enterprise
Zone
Protocol Firewall
Domain Firewall
Network
Infra-
structure
Partner
Infrastructure
Exposed
Broker
Rules
Repository
Domain QoS
Providers
App Server
Services
WebSphere Application Server -
Enterprise V5.0.2.1
+
WebSphere Application Server
Network Deployment V5.0.2.1
Private UDDI Registry
WebSphere Application Server -
Enterprise V5.0.2.1
+
WebSphere Application Server
Network Deployment V5.0.2.1
Web Services Gateway
+
WebSphere Business Integration
Message Broker V5 + CSD2
WebSphere
Application Server
V5.0.2.1
JAX-RPC
Internet
SOAP
/HTTP
SOAP
/HTTP
232 Broker Interactions for Intra- and Inter-enterprise
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.
Chapter 9. Broker solutions using WebSphere Business Integration Message Broker 233
? 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.
234 Broker Interactions for Intra- and Inter-enterprise
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).
Chapter 9. Broker solutions using WebSphere Business Integration Message Broker 235
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).
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).
MQnput
node
<in>
MQOutput
<out>
<HTTPRequest>
Client
MQ
<Broker>
Web Service
SOAP/
HTTP
HTTP Input
node
<in>
HTTP Reply
node
<out>
<message flow>
C lient
SOAP/
HTTP
<Broker>
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.