IBM Redbook User Manual

Redbooks

Paper

Chris Nott

Peter Edwards

Andrew Humphreys

Martin Keen

Using Message Sets in WebSphere Business Integration Message Broker to Implement an ESB in an SOA

Introduction

This Redpaper shows how to build an Enterprise Service Bus (ESB) using current IBM® technology. The paper is based on a simple application scenario in which Web services invocations are used to implement a simplified supply chain process for a consumer electronics retailer. We add an ESB into the scenario between the service consumers and service providers, which provides greater flexibility and loose coupling. We explore design considerations for an ESB in a service-oriented architecture (SOA) and implement the Broker design pattern for this decoupling. We use WebSphere® Business Integration Message Broker V5 to implement the ESB with services hosted on WebSphere Application Server.

This Redpaper has three sections:

򐂰 Design guidelines 򐂰 Development guidelines 򐂰 Runtime guidelines

This paper is an extension of the IBM Redbook Patterns: Implementing an SOA Using an Enterprise Service Bus, SG24-6346.

Design guidelines

This section introduces the business scenario used in this paper, describes how the Patterns for e-business apply to the solution, and discusses a design alternative for building the solution.

Business scenario

The application used in this Redpaper is based on the WS-I Supply Chain Management sample application that supports a simplified supply chain for a consumer electronics retailer business scenario. This Redpaper extends the application built in the IBM Redbook Patterns: Implementing an SOA Using an Enterprise Service Bus, SG24-6346.

We use this business scenario to show how the Patterns for e-business, SOA, and ESB approach can be used to develop solutions to real-world business requirements that are based on interoperability principles as defined in the WS-I Basic Profile.

The scenario is based on a typical business-to-customer (B2C) model. Customers may access the retailer’s Web site, review the catalog, and place orders for products such as televisions, DVD players, and video cameras. The retailer system requests fulfillment of a consumer’s order from the internal company warehouses, which respond as to whether line items from the order can be filled. If stock for any line item falls below a minimum threshold in the warehouse that stocks the item, a replenishment order is sent to an external manufacturer using the business-to-business (B2B) model. The manufacturer does not immediately fulfill replenishment orders, but completes the order at some later time (possibly after completing a manufacturing run).

2 Using Message Sets in WebSphere Business Integration Message Broker to Implement an ESB in an SOA

The company uses more than one warehouse to stock the parts that it offers to customers. However, the customer must see the order as a single transaction with the company. Therefore, aggregation of the interactions with the warehouses is required to produce a single response to a consumer request. This is shown in Figure 1.

Intranet

SCM

Application

Retail

System

Figure 1 Business scenario

Applying the Patterns for e-business

The IBM Patterns for e-business are a group of proven, reusable assets that can be used to increase the speed of developing and deploying e-business applications. The Patterns for e-business define an SOA profile for architecting SOA implementations. This profile is defined in the redbook Patterns:

Implementing an SOA Using an Enterprise Service Bus with WebSphere Application Server V6, SG24-6494.

The Patterns for e-business can be applied to this business scenario to determine the required architecture. Using the SOA profile of the Patterns for e-business we can determine that the Enterprise Service Bus runtime pattern is an ideal fit for this business scenario. In particular an Enterprise Service Bus runtime pattern using broker interactions is required to facilitate the interaction between the retail system and the warehouses.

Manufacturer

Warehouse

Business

Event Log

Manufacturer

The Broker application pattern is based on a 1-to-N topology that separates distribution rules from the applications. It enables a single interaction from the source application to be distributed to multiple target applications concurrently. This Application pattern reduces the proliferation of point-to-point connections. It is shown in Figure 2 on page 4.

Using Message Sets in WebSphere Business Integration Message Broker to Implement an ESB in an SOA 3

Target

Application

Source

Application

Broker

Rules

WIP

Broker Rules & WIP Results

Application

Target

Application

Figure 2 Application Integration::Broker pattern

An ESB is a component in an SOA that mediates interactions between service consumers and service providers so that consumers and providers are independent. It may provide additional value-added functionality within. The Broker application pattern can be applied to the Hub component of an ESB. Figure 3 shows the Enterprise Service Bus Runtime pattern.

Enterprise

App Server/

Services

App Server/

Services

ESBESB

App Server/

Services

App Server/

Services

App Server/

Services

App Server/

Services

Figure 3 Enterprise Service Bus runtime pattern - level 0

The ESB is a key enabler for an SOA as it provides the capability to route and transport service requests from the service requester to the correct service provider. The ESB controls routing within the scope of a service namespace, which is indicated symbolically by the ellipse on the ESB node representation.

The true value of the ESB concept, however, is to enable the infrastructure for SOA in a way that reflects the needs of today’s enterprise: to provide suitable service levels and manageability, and to operate and integrate in a heterogeneous environment.

4 Using Message Sets in WebSphere Business Integration Message Broker to Implement an ESB in an SOA

The ESB must be centrally managed and administered and have the ability to be physically distributed.

The Runtime pattern shown in Figure 4 represents a first-level decomposition of the major components that make up an ESB. The Broker application pattern can be applied to the Hub component of an ESB.

Enterprise

Namespace

Design alternative: SOAP message parsing

As described in the redbook Patterns: Implementing an SOA Using an Enterprise Service Bus, SG24-6346, a true SOAP intermediary carries out the validation

and processing of SOAP headers. This Redpaper shows the development of an

Using Message Sets in WebSphere Business Integration Message Broker to Implement an ESB in an SOA 7

example of parsing a SOAP message within the ESB. Parsing enables the validation of part or all of the SOAP message and can provide these advantages:

򐂰 Validation and processing of SOAP headers can be performed.

– SOAP faults are handled properly so that they correctly identify the service

that is causing the fault:

• Generation of SOAP faults

• Encoding of SOAP faults – Operations supported by the service can be validated. – The SOAP header must be properly validated and processed when the

mustUnderstand attribute is set to 1. – Decode and encode the SOAP service requests and responses. – Operation name and related namespace can be set. – Service style can be switched from document to RPC.

򐂰 Validation and processing of the SOAP bodies, representing message

content, can take place in the ESB. This includes mediation of service requests within the ESB based on the values within the SOAP body.

򐂰 Development of the intermediary logic may be eased because the message

structures are defined in the tooling up front.

The simple advantage of not validating SOAP messages and processing SOAP headers is performance, because parsing of the message is not required.

In our scenario, the ESB is required to perform aggregation logic in order to ship goods on an order. By using WebSphere Business Integration Message Broker we can define message sets to validate messages prior to executing the logic. This can occur at the beginning of message flows and also within the aggregation logic as responses are returned from service providers.

We shall also see how the Message Broker Toolkit simplifies development of logic based on the content of SOAP bodies that are defined as message sets. In our scenario we create message sets for the parts and quantities on an order.

Further information about using WebSphere Business Integration Message Broker V5 in a Web services environment can be found in SupportPac™ IA81, which is available through ibm.com® at:

http://www.ibm.com/support/docview.wss?rs=171&uid=swg24006268

In particular, this SupportPac provides a subroutine library for managing the SOAP aspects of incoming, outgoing, and fault messages.

8 Using Message Sets in WebSphere Business Integration Message Broker to Implement an ESB in an SOA

Development guidelines

This section describes how WebSphere Business Integration Message Broker V5 supports Web services within a service-oriented architecture implementation for our business scenario. It contains a step-by-step guide for building this solution.

The starting point is an application built in the redbook Patterns: Implementing an SOA Using an Enterprise Service Bus, SG24-6346. This application comprises WebSphere Business Integration Message Broker message flows and a number of WebSphere Application Server enterprise applications exchanging SOAP messages.

The existing aggregation message flow between the Retailer and Warehouses (shown in Figure 7) parses and builds SOAP messages; these SOAP messages are processed without reference to message sets. Notice that the flow performs protocol conversion from HTTP to JMS.

Figure 7 Aggregation design

This paper describes how to model a SOAP message in WebSphere Business Integration Message Broker message sets. It shows how both the envelope and the body of the message are modeled and how message models can be defined to support different SOAP bodies within the same message definition.

We then demonstrate techniques that show how this modeling benefits the development and execution of WebSphere Business Integration Message Broker message flows.

Using Message Sets in WebSphere Business Integration Message Broker to Implement an ESB in an SOA 9

Model a SOAP message in a message set

In this section you create a message set and model the SOAP messages used in the ShipGoods operation of the Warehouse service.

Overview of message sets

A message set is created inside a message set project in the Message Broker Toolkit. Note the following:

򐂰 Only one message set is allowed per message set project. 򐂰 Many message set projects can be used in a system, but only one message

set can be used by a Broker when parsing or writing a message instance.

򐂰 Message sets can be namespace-enabled. As SOAP messages always use

namespaces, any message sets used for modelling SOAP messages namespace-enabled.

򐂰 Message sets have one or more wire formats. These represent the style of

message to be input or output. Wire formats fall into three categories: Custom (mapping C or COBOL structures), XML, and Tagged/Delimited (mapping industry standards such as SWIFT). SOAP messages require an XML wire format.

򐂰 Message sets contain one or more message definition files with the suffix

.mxsd. These are valid XML schema files, annotated with WebSphere Business Integration Message Broker-specific enhancements. They can be created by importing an XML schema, DTD, C header file, or COBOL copybook. There is a customized editor in the Message Broker Toolkit to manipulate the contents of message definition files.

򐂰 Message definition files contain elements (global or local), complex types,

groups, and attributes (global or local), much as XML schemas do. Message definition files also contain messages, which are used by WebSphere Business Integration Message Broker as a unit of processing in a message flow.

must be

򐂰 It is possible to INCLUDE or IMPORT one message definition file within

another. These have similar functionality to the XML schema INCLUDE and IMPORT.

The Message Broker Toolkit contains a number of importers that enable messages to be constructed easily. However, you cannot directly import Web Services Description Language (WSDL) into the Message Broker Toolkit. To import a WSDL file, you must extract the XML schema to a separate file and import that file.

After an XML schema is imported, message definition files may require certain customizations, which can be made using the Message Broker Toolkit.

10 Using Message Sets in WebSphere Business Integration Message Broker to Implement an ESB in an SOA

Message definition files also contain extra information that XML schemas do not have. One example is a keyword of complex type known as can indicate known XML schema properties such as enables a WebSphere Business Integration Message Broker–specific property message, which means the same as choice, but the children of this complex type are messages rather than elements or attributes. This is useful when modeling business messages that are embedded within a standard envelope.

For example, a SOAP message comprises an envelope (XML tag name Envelope), which has a child element called Body. That Body element contains Web service payloads (application data), which are likely to be modeled in a WebSphere Business Integration Message Broker message set as messages. Therefore, the Body element is a likely candidate to have a composition message.

Note: WSDL files can be generated from message sets, though these may need customization prior to use by other Web services development tools. Within an MDF, messages can be grouped into categories. Message categories must be defined prior to WSDL generation. Categories are needed to enable WSDL generation from the Message Broker Toolkit.

sequence or choice. It also

composition. This

Create a message set

To create a message set:

1. Start the WebSphere Business Integration Message Broker Toolkit.

2. Ensure that you are in the Broker Application Development perspective.

Select Window from the menu.

3. Create a new Message Set Project.

a. Click File b. Enter labmsp in Project name and click Next. c. Enter labms in Message Set Name, check Use namespaces, and click

Next.

d. Check XML Wire Format Name, set the wire format name to XML (from

XML1), and click Finish.

This creates a message set within a message set project. It also creates a file called messageset.mset, which opens in the main editor of the toolkit.

Using Message Sets in WebSphere Business Integration Message Broker to Implement an ESB in an SOA 11

→ Open Perspective → Broker Application Development

→ New → Message Set Project.

4. In the main editor, select Properties → Physical properties → XML and

customize the wire format (Figure 8): a. In the Properties Hierarchy section, select Physical Properties b. Check Suppress DOCTYPE under XML document type settings. DTD

declarations are not needed, as the system is schema rather than

DTD-based.

c. Set Root Tag Name to blank by deleting the default value MRM. Web

services use SOAP messages, where the root tag name must be

Envelope. Also, the system uses embedded messages. It is not sensible to

have a hard-coded root tag name when embedded messages are used.

d. Close the messageset.mset window and save the contents.

→ XML.

Figure 8 Message set properties

Create message definition files for SOAP messages

The SOAP V1.1 XML schema must be imported into the message set so that it can be used to model SOAP messages. This schema can be found at:

http://www.w3.org/TR/2000/NOTE-SOAP-20000508/envelope-2000-04-18.xml

You also need to import the XML schemas that define the SOAP Header and SOAP Bodies of the messages we will model.

12 Using Message Sets in WebSphere Business Integration Message Broker to Implement an ESB in an SOA

Import the soap11.xsd, Configuration.xsd, Warehouse.xsd and Warehousesg.xsd files into message set project labmsp (see the additional material supplied with this redpaper for these files):

1. Select the labmsp project in the Resource Navigator.

2. Select File

→ Import from the menu.

3. Select File system and click Next.

4. Click the Browse button to the right of the Directory field and navigate to the

directory where you downloaded the additional material supplied with this redpaper. Click OK.

5. Check soap11.xsd, Configuration.xsd, Warehouse.xsd, and Warehousesg.xsd. Click Finish.

Next, create an MDF based on the soap11.xsd file you just imported:

1. Select File

→ New → Message Definition File. This starts the new message

definition file wizard.

2. In the window Select the message definition source, click XML Schema file and click Next.

3. In the window Select a schema file, select file soap11.xsd from project labmsp and click Next.

4. In the window Select a message set from the list, select labms in project labmsp and click Next.

5. In the window Select global elements from which to create messages, click Envelope and Fault and click Finish.

During this import, the global element Envelope is defined as a message. This means that message flows can nominate this message as the one to be processed. The global element Fault is also defined as a message. This is because Fault is a child of the element Body. In the following customization, the complex type of Body will be amended to be of composition message. This enables children of Body to be defined as messages.

Several warnings are generated in the task list as a result of importing this schema. These can be eliminated by measures described below, or they can be suppressed as shown in “Setting Message Broker Toolkit preferences” on page 31.

Before any further customization of the SOAP message definition file (MDF) occurs, you must create new message definitions based on the other XML schemas you have imported:

1. Select File

→ New → Message Definition File. This starts the new message

definition file wizard.

Using Message Sets in WebSphere Business Integration Message Broker to Implement an ESB in an SOA 13

2. In the window Select the message definition source, click XML Schema file and click Next.

3. In the window Select a schema file, select file Warehouse.xsd from project labmsp and click Next.

4. In the window Select a message set from the list, select labms in project labmsp and click Next.

Note: Do not select ItemListElement to be a global element because it is not an immediate child of the SOAP Body as defined in the WSDL.

5. Click Finish.

You have already copied Warehousesg.xsd into message set project labmsp. This is an XML schema which contains elements referenced in the WSDL for the Web service but are missing from the Warehouse XML schema we have imported to represent the Web service. The elements are missing because the XML schema required amendment to support a document-literal Web service. Warehousesg.xsd contains global elements ShipGoods and ShipGoodsResponse.

Perform the following:

1. Select File

2. In the window Select the message definition source, click XML Schema file and click Next.

→ New → Message Definition File.

3. In the window Select a schema file, select file Warehousesg.xsd from project labmsp and click Next.

4. In the window Select a message set from the list, select labms in project labmsp and click Next.

5. In the window Select global elements from which to create messages, click both ShipGoods and ShipGoodsResponse and click Finish. These global elements describe the SOAP Body input and output messages that we use in our scenario.

In this example, you also need to import a schema that represents the SOAP header content. Perform the following:

1. Select File definition file wizard.

2. In the window Select the message definition source, click XML Schema file and click Next.

14 Using Message Sets in WebSphere Business Integration Message Broker to Implement an ESB in an SOA

→ New → Message Definition File. This starts the new message

+ 30 hidden pages

IBM Redbook User Manual

Specifications and Main Features

Frequently Asked Questions

User Manual

Using Message Sets in WebSphere Business Integration Message Broker to Implement an ESB in an SOA

Introduction

Design guidelines

Business scenario

Applying the Patterns for e-business

Design alternative: SOAP message parsing

Development guidelines

Model a SOAP message in a message set