Patterns: Broker Interactions for Intra- and Inter-enterprise

240 Broker Interactions for Intra- and Inter-enterprise

Figure 9-12 Aggregation design

A gateway will be used to minimize the impact of using external services. It will

provide the mapping between the internal clients and the external services.

9.6 Developing message flows with Web services

When you design a message flow, you must consider some or all of the following

factors:

򐂰 Which nodes provide the function that you require. In many cases, you can

choose between several nodes that provide a suitable function. You might

have to consider other factors listed here to determine which node is best for

your overall needs.

򐂰 Whether it is appropriate to include more than one input node.

򐂰 Whether you can make use of subflows, for example, to define a specific

output node with common properties.

򐂰 What response times your applications expect from the message flow. This is

influenced by several aspects of how you configure your nodes and the flow.

򐂰 Whether you want to use WebSphere MQ cluster queues.

򐂰 Whether you want your messages to go through data conversion.

Message Broker

Partner

Wholesale

Partner

Wholesale

Retailer

SOAP/

HTTP

DMZ

SOAP/

HTTP

W

e

b

S

e

r

v

i

c

e

s

G

a

t

e

w

a

y

<Aggregator>

<subflow>

<subflow>

Note: A variation of this is the situation where you want to make the Broker

processes available to external clients. For an example of exposing

WebSphere Business Integration Message Broker message flows to external

clients as Web services, see Using Web Services for Business Integration,

SG24-6583.

Chapter 9. Broker solutions using WebSphere Business Integration Message Broker 241

򐂰 What steps you can take to ensure that messages are not lost.

򐂰 How errors are handled within the message flow. You can use the facilities

provided by the broker to handle any errors that are encountered during

message flow execution (for example, if the input node fails to retrieve an

input message, or if writing to a database results in an error). However, you

might prefer to design your message flow to handle errors in a specific way.

9.6.1 Development environment

The Message Brokers Toolkit is a component of the WebSphere Business

Integration Message Broker product. It is the tool used to develop message flows

and to deploy them to a broker.

WebSphere Studio Application Developer is designed for J2EE application

programming and in these scenarios would be the tool of choice for creating the

source and target applications.

Both of these tools can be used simultaneously on one system. An alternate to

this would be to install the WebSphere Studio Application Developer Integration

Edition with the Message Brokers Toolkit. This gives you J2EE programming

tools, message flow programming tools, the WebSphere Application Server test

environment, and broker management tools, all in one WebSphere Studio

workbench.

9.6.2 Development steps

Three main steps are used:

򐂰 Step 1: Create and test a Web client to access the service.

򐂰 Step 2: Create and test a simple “passthru” message flow that invokes each

Web service. This effectively tests the input to the flow, transformation

between the input and output formats, the invocation of the Web service, and

the reply.

򐂰 Step 3: Add the broker logic to the message flow and test.

9.6.3 Step 1: Access the Web service directly

The first step is to Web service enable the client and target applications. Using a

direct link between the two will allow you to ensure that the application interfaces

are working correctly before adding the broker message flows between them

(Figure 9-13).

242 Broker Interactions for Intra- and Inter-enterprise

Figure 9-13 Step 1: direct access to Web service

Web service-enable the target application

Both WebSphere Studio and WebSphere Application Server provide tools that

assist in converting an application to a Web service.

WebSphere Studio wizards

WebSphere Studio provides the Web Services wizard that creates a Web service

from an existing application. The wizard allows you to select from the following

Web service types:

򐂰 Skeleton Java bean

򐂰 Java bean

򐂰 Skeleton EJB

򐂰 URL

򐂰 DADX

򐂰 EJB

򐂰 ISD

The wizard will create all the necessary files and deployment descriptors. In

addition, you can create and test a client proxy.

WebSphere Application Server command line tools

WebSphere Application Server provides command line tools in the bin directory

to help you generate the necessary files to make an application available as a

Web service.

The steps to create a Web service from an EJB application would be:

1. Create a service endpoint interface that extends java.rmi.Remote.

2. Use the Java2WSDL command line tool to generate a WSDL file using the

service endpoint interface as input.

3. Use the WSDL2Java command line tool to generate the Web services

deployment descriptors using the WSDL file as input.

4. Use the endptEnabler command line tool to create an HTTP router.

Client

SOAP/

HTTP

Web service

target