Using JMS and WebSphere ESB to build a powerful and reliable SOA-Part 1

Java Message Service (JMS) for J2EE
Reliable message transmission on the platform is standardized. Recently released IBM WebSphere Enterprise Service Bus (ESB)
The product provides some important functions that are at the core of any Service-Oriented Architecture (SOA) environment. This series has three articles describing how to integrate JMS and
WebSphere ESB is used in combination to form a powerful and reliable SOA.

Using JMS and WebSphere ESB to build a powerful and reliable SOA-Part 1
Using JMS and WebSphere ESB to build a powerful and reliable SOA-Part 1

Introduction

Service-Oriented Architecture (SOA) can never be built in a vacuum. In any actual environment, you must consider the existing IT
The provision of environments, functions (and data) cannot be simply achieved by providing a set of new services. Therefore, building an SOA
One of the key aspects is to break down existing applications into smaller blocks (namely, "services"). These blocks communicate through standard protocols and have well-defined interfaces. The advantage of doing so is that such environments are more flexible
There is no close coupling between all parts of the system.

The concept of loosely coupled and platform-independent services
Bus, ESB) has been further developed. The ESB acts as an "adhesive" between services that use different data and message formats, network protocols, and programming languages ". ESB
Acts as an intermediate layer between a service user and a service provider and allows the deployment of an intermediary to perform various operations, such as performing the required data conversion to the service quality of an interactive application.

In this series of articles, we will learn a specific example of an ESB acting as this intermediate layer. We will use IBM
WebSphere Enterprise Service Bus (WebSphere ESB) v6.0.1
Product to link service users and service providers, and use JMS as the message transmission mechanism. In the first article, we will take a brief look at WebSphere ESB
The product and its tool environment, that is, WebSphere integration developer v6.0.1. Section 2nd describes the actual ESB
Scenario, and describes how to build service users and service providers. In section 3rd, we will demonstrate how to build and run on WebSphere ESB
The intermediary between the user and the provider. You will learn how to deploy and run the solution. We will provide all the code components required for this operation.

Enterprise Service Bus and Java Message Service

SOA
Composed of service users and service providers that communicate with each other. They usually communicate through the Enterprise Service Bus. Each service has a service definition that describes how to receive messages from users and how to use them.
Response Message (exception when one-way service) and other items. Therefore, constructing an ESB is closely related to message transmission. For a long time, to send and receive messages in a stable, fast, and reliable manner is
An IT system's key requirement, ESB
The arrival of does not change this; it just brings additional requirements to the solution-for example, support for describing the Message format standards, inter-service transaction exchanges, and so on.

At the same time, systems based on the Java J2EE platform usually use Java Message Service (JMS) APIs to meet their message transmission requirements. Simply put, JMS describes how to send messages from one application to another, and potentially exploits the transaction quality of the service.

Taking into account that many applications are already using JMS, while SOA
The Internal Service also needs a message transmission method, so as to better understand the role of JMS in the ESB context. Each ESB must be able to use JMS
Receive a message from a service user and forward it to the corresponding service provider (through JMS or other protocols, such as HTTP), and vice versa. In addition, JMS
It also defines several different types of messages that can be sent. For example, a text message contains a string representation of a message, an object message contains a serialized Java object, and a map
The message contains key/value pair ing. Web services usually use soap as their message format, but many applications use pure XML. Therefore, the ESB
Various Network and message protocols must be supported. Figure 1 shows a series of protocol combinations that a service user and service provider may support. Note that the ESB
Acts as the intermediate layer between the two, allowing any user and provider to be connected without any protocol restrictions.

Figure 1. Example of message and network protocols in SOA

If WebSphere ESB is set to support different combinations, this is exactly what we will discuss in this series. However, let's first take a look at the product itself and its main components.

WebSphere ESB v6.0.1

WebSphere ESB is an ibm soa Foundation
. Although its version number may make people think that this product has existed for a long time, it was released for the first time at the end of 2005.
Product Series members share many components. For example, it uses the IBM WebSphere Application Server Based on J2EE
As its core runtime. WebSphere Application Server provides a JMS implementation, which is implemented by WebSphere ESB
. It also uses the service component architecture (SCA) as its basic programming model
WebSphere process server shares the SCA runtime.

Figure 2 shows the overview of Websphere ESB and its basic components.

Figure 2. Overview of Websphere ESB

WebSphere ESB supports passing basic messages through JMS.
Mqlink in Application Server communicates with WebSphere MQ. Use soap over HTTP and
The Web Service of soap over JMS is inserted into the ESB and supports many web service standards and the UDDI provided by the application server.
Registry. WebSphere ESB not only supports standard J2EE clients, but also supports C/C ++ and. Net clients. In addition, it also uses
The WebSphere adapter provides connections to various legacy environments.

Architecture of Websphere ESB and service components

We mentioned earlier that the programming model used by WebSphere ESB is based on SCA. SCA
Describes a complete service programming model, involving a large number of components (namely services) that can be described and accessed in the same way ). This type of component can be a BPEL process, business rule, or traditional Java
Components. WebSphere ESB introduces a new component type to the SCA model, that isIntermediary flow component. From the SCA perspective, the mediation flow component is no different from any other service component because the mediation component has the following features:

• Exist in the module (more accurately, exist inIntermediary Module).
• Has an interface, which is described in Java or WSDL.
• PassExportMake public to the client. The export can be bound to multiple different protocols (We will discuss this later ).
• Has dependencies on other services (throughImport).

To some extent, the mediation stream programming model is unique; it supports access and operation of binding specific information about the service message being processed (usually header type information ). For details about SCA and its programming model and how to build and deploy components through it, see the building SOA solutions with the service component architecture series. (For the rest of this series, we will assume that you already have basic SCA knowledge, so we will not repeat what has been elaborated elsewhere .)

The mediation flow component provides a new implementation of a service component, that is, the implementation of the mediation flow. Mediation flow is usually built using the visual flow Editor, Which is used through a seriesMediation primitiveDescribes the request and Response Message streams. These primitives can read and change messages, or route ("filter") messages to different target locations. Although you can build your own custom mediation primitives, this product provides a series of predefined primitives for the following purposes:

• XSLT Conversion
• Message logging
• Message Filtering
• Database Access.

Figure 3 shows the implementation of a mediation flow component that uses several mediation primitives to implement response streams.

Figure 3. Mediation flow example

By the way, we will detail the steps required to create such a stream in section 2nd.

WebSphere ESB and Service Message objects

We have not discussed how to process a message "in the bus. That is to say, how to express the data sent to the mediation flow component? The answer is that each message will be convertedService Message object. Similarly, before leaving the mediation flow component, it will be converted to any format required by the message target.

The Service Message object is service data object (SDO)
This specification describes a method for accessing data in a source-independent manner. Therefore, it does not consider whether a message passes through HTTP or JMS
Or any other protocol will not consider whether the message is a SOAP message or plain text, but will always convert it into a form that can be implemented by the actual mediation stream (such as the mediation primitive) the common format used.

Therefore, SCA provides a programming model for calling the mediation flow component, while SMO/SDO indicates the actual messages processed in this component. The two have achieved close collaboration.

SCA Export and Import binding

As mentioned above, the SCA component uses import and export to communicate with the external world (that is, to communicate with other services used by the client and component implementation of the component ). For WebSphere ESB and its mediation flow components, You can regard export as the inbound port of the ESB and import as the outbound port.

For example, assume that you have an existing service user and an existing service provider.
Communication. Now you want to insert WebSphere ESB into this connection
To record each message that passes through. You can achieve this by creating an intermediary flow component and providing it with the same interface as the target service. Then create an importWeb Service binding,
To reference the target service's WSDL (including the endpoint address) and create an import pointing to an existing web service. That is, the import has been "Bound" to the Web
Service. Similarly, create a Web Service for the export to generate a new WSDL
File, and build an endpoint pointing to the intermediary flow component. Finally, deploy the component and notify the service user to use the new endpoint address. The message is now directed to WebSphere
ESB, through a series of mediation primitives, and then forwarded to the actual target web service.

Remember we mentioned that every message will become an SMO in the bus? Web Service binding is a process that passes in soap/HTTP
The logic for converting a request message to a service message object, while binding an outbound Web Service provides its reverse logic. That is, it converts the outgoing SMO back to soap/HTTP
Message. These are all automatically performed. The runtime knows the format of the inbound message, because the message is fully described by the corresponding WSDL definition, and can be analyzed and processed accordingly during the runtime.

To ensure correctness,Custom bindingOnly the body of the message is processed. The header field is automatically processed by the infrastructure and will be converted between the JMS message and SMO without any programming.

No. What happens if the incoming message does not follow a specific message protocol such as soap? For example
If the ing message is sent to the export, the default binding cannot be used because the ing format is unknown. In this case, custom binding will be used. It must be provided in the form of a Java class from the incoming message to the SMO
To execute the corresponding analysis logic and build the correct SMO. The same processing should be performed on the outbound end (that is, the import. Custom binding implementation knows how to obtain SMO
And convert it to the correct format.

In part 2 and Part 2 of this series, we will discuss in detail examples of custom JMS binding (supporting binding of all five kinds of JMS message types ), therefore, we will discuss the topic of custom binding again and demonstrate how to deploy custom binding as part of the mediation module to the runtime.

WebSphere integration developer v6.0.1

WebSphere ESB
One of the goals is to simplify the creation of mediation and insert it into the enterprise message stream. To some extent, this goal is to use SCA
Programming Model, which allows a description and deployment mechanism to process different types of services. SCA
The specification also describes how to assemble these components into a large solution. In addition, we hope to support mediation flow components built on the basis of fine-grained mediation primitives. WebSphere
Integration developer v6.0.1 supports all these operations.

We provide a diagram of how to implement the mediation flow component using multiple primitives. The tool also allows you to visually assemble, export, and import mediation components as mediation modules for deployment and installation at runtime. For example, figure 4 demonstrates how to use the Assembly editor to build a mediation module that contains a mediation flow component.

Figure 4. Mediation module containing the mediation Flow

The previous series of articles "Building SOA solutions with the service component architecture" detail the sample scenarios for using this tool. We will also explain how to build the mediation module step by step in section 3rd.

Conclusion

This article describes how to use the WebSphere ESB product to build an enterprise service bus that supports various messaging and network protocols that can be used to connect to existing services and new services. One of the Protocols is JMS.

Based on the new service component architecture, WebSphere ESB uses service data objects as its internal message format model. SCA
Defines the concept of binding. You can use binding to provide service components to the client and allow it to communicate with other components. Using five different JMS
In the case of message types, we need to provide custom binding implementation to support any message format.

In the other two articles in this series, we will provide an example to demonstrate how to use WebSphere ESB to process JMS
Messages exchanged between the client and the (JMS-based) Message-driven bean. You will learn how to develop and deploy custom binding implementations and how to use WebSphere
As a tool environment, integration developer can build corresponding solutions.

About the author

		Andre TOSTYes A senior technician from the enterprise integration solutions organization of the software group, who helped in this department IBM customers establish a service-oriented architecture. He specializes in Web service technologies. Before assuming his current role, he worked at IBM He has worked in software development for ten years as a partner for support, development, and architecture roles (prior to his current role in Websphere Business Development Group work ). He was born in Germany and currently lives and works in the American state of Minnesota. In his spare time, he prefers to be with his family and play football or football whenever he is free.