IBM WebSphere Developer Technical Journal: Building an Enterprise Service Bus with WebSphere Application Server V6 -- Part 2

Business requirements and the bus

This is Part 2 in a series of articles that describe how to use the new messaging engine in IBM® WebSphere® Application Server V6 to build an Enterprise Service Bus (ESB), a crucial piece of SOA infrastructure. This article describes a sample business case for building an ESB with WebSphere V6 Messaging Resources, and explains the steps for setting up an instance of the bus.

Rachel Reinitz (rreinitz@us.ibm.com), Senior Consulting IT Specialist, IBM

Rachel ReinitzRachel Reinitz is an IBM Distinguished Engineer with IBM Software Services for WebSphere and a member of the IBM Academy of Technology. She has built much of IBM’s internal and external intellectual capital and education on SOA, Enterprise Service Bus, and Web services. Rachel focuses on how to get started with SOA and ESB best practices. She consults with clients and ISVs on how SOA and ESB can be used to achieve their business and technical objectives. She is a frequent conference presenter and written many developerWorks articles on ESB and Web services. Rachel lives in the Bay Area in California, and enjoys hiking, socializing, and international travel.



Andre Tost, Senior Technical Staff Member, IBM

Andre TostAndre Tost works as a Senior Technical Staff Member in the WebSphere Business Development group, where he helps IBM's Strategic Alliance partners integrate their applications with WebSphere. His special focus is on Web services technology throughout the WebSphere product family. Before his current assignment, he spent ten years in various development and architecture roles in IBM software development, most recently for the WebSphere Business Components product. Originally from Germany, he now lives and works in Rochester, Minnesota. In his spare time, he likes to spend time with his family, and play and watch soccer whenever possible.



23 February 2005

Also available in Russian

Introduction

In Part 1 of this series, we introduced the core concepts of the WebSphere V6 Messaging Resources that can be used to build an Enterprise Service Bus (ESB). In Part 2, we present a business scenario with requirements that lead to building an ESB, and also cover the steps to create an instance of the "bus" and set it up for use with Web services. We will use this business scenario to provide a realistic context throughout this article series.


The business problem

Our fictional company, which we will call "Posts-R-US," provides package shipping services, including:

  • Consumer shipping (competing with the post office).
  • Contracted shipping for businesses.
  • OEM shipping (for example, for an online retailer).
  • Guaranteed delivery with optional acknowledgements.

Posts-R-US has grown quickly. The company recently purchased a European company, "EurPosts", and needs to integrate EurPosts systems with the Posts-R-US systems. With their direct online presence, stores, storing areas, delivery crews, airplane systems, and OEM, they have a need to serve a variety of different types of clients.

To lower costs, remain competitive, and improve their customers' experiences, Posts-R-US needs to improve the integration of their disparate systems. Currently, when a new application is developed or a new system is incorporated, extensive point-to-point integration across many technologies is required. Hence, they have decided to develop an ESB as a core component of improving their integration. Posts-R-US is also going to improve their business process automation and flexibility through the use of Business Process Execution Language (BPEL) and associated tooling (see Resources).

Figure 1 shows an overview of some of the systems that Posts-R-US needs to integrate with each other.

Figure 1. Systems requiring integration
Figure 1. Systems requiring integration

The technical environment

Key clients and systems of Posts-R-US utilize a variety of technologies including WebSphere MQ, Web services, EJB™ components, .NET® clients, publish/subscribe, CICS® legacy systems, databases, SAP®, and other third party applications. The systems shown in Figure 1 are implemented with a variety of technologies, thus adding an enterprise service bus simplifies the integration across these many technologies.

Figure 2 shows an example of the technologies used in Posts-R-US' business that need integration, and how an ESB simplifies the connections required.

Figure 2. Required connections simplified using ESB
Figure 2. Required connections simplified using ESB

The examples in subsequent installments in this article series will be based on the business systems and technologies shown in Figure 2, and will show how WebSphere Application Server V6 can be used to build an ESB that meets the integration requirements for this company. We will not cover in detail the architectural aspects of building an ESB and how it enables good integration; we will focus instead on implementation considerations.

The next section goes through the basic setup that is needed to create an enterprise service bus with Web services capability.


Basic setup

As the very first step, we will create a system integration bus (SIB or SIBus) and assign it to an instance of WebSphere Application Server. We will then enable the bus to use Web services as a protocol.

Assumptions
The instructions in this section assume a default installation of a standalone WebSphere Application Server. Your default profile will be named "default" if using WebSphere Application Server Base and "AppSrv01" if using WebSphere Application Server Network Deployment (ND). The instructions assume that the server is "server1" and node name is "node1".

To setup a command window for the profile:

  1. Change to the <WAS_HOME>/profiles/<profilename>/bin directory.
  2. Setup the command window for this profile by executing the setupCmdLine.bat.

Create a bus

To create a Bus instance:

  1. Open the WebSphere Application Server admin console (the server must be running).
  2. In the left navigation pane, select Service Integration => Buses.
  3. Select Buses, then in the following dialog, select New, which starts the wizard to create a bus.
  4. Name the new bus, TheBus and select OK.
  5. Save your changes, then see the new bus in the list (Figure 3).
Figure 3. New bus in WebSphere Application Server admin console
Figure 3. New bus in WebSphere Application Server admin console

Add a bus member

A bus needs to be assigned to run on one or more application servers and server clusters. For most development activity, you will create and assign a single bus member to the bus. When a bus member is added, a messaging engine is created in that WebSphere instance, which has its own data store for messages. For our purposes, we will have one bus with only one bus member which is a single instance of WebSphere Application Server:

  1. Select TheBus.
  2. In the next dialog, select Bus Members, then Add.
  3. Make sure that the Server radio button is selected.
  4. From the server selection box, select node1:server1, which will likely be selected by default.
  5. Click Next and Finish, then save your changes.

You now have a WebSphere Messaging Resources bus ready for use.


Setup for Web services

WebSphere Messaging Resources requires some setup to enable the bus to be able to receive Web service requests, to convert messages into SOAP messages in mediations, and to send Web service requests. The Web services feature of the Service Integration Bus is referred to as SIBWS in the WebSphere Application Server V6 Information Center (see Resources).

As we described in Part 1, WebSphere Messaging Resources convert all incoming messages into Service Data Objects (SDO). An SDO repository is used to store WSDL definitions and the SIBus uses those definitions as part of the Web services support. Therefore, the first thing you need to do is create this SDO repository.

Additionally, for the bus to receive Web service requests from clients, the bus needs to be configured with endpoint listeners; as their name implies, endpoint listeners listen on specific ports for incoming Web services messages. There are endpoint listeners provided for SOAP over HTTP and for SOAP over JMS. To enable the bus to send Web service requests, the bus must be configured with a resource adapter. (In a later article, we will explain how to configure the bus to accept incoming Web services requests, called inbound services, and send Web service requests, called outbound services.)

Install SDO repository

The SDO repository can use the IBM Cloudscape® database which is automatically installed as part of your WebSphere Application Server installation, or you can configure it to use a database of your choosing. Provide the -createDb flag as part of the setup command to use Cloudscape.

To install the SDO repository:

  1. In a command window, change to the <WAS_HOME>/bin directory, then execute:
    wsadmin -f installSdoRepository.jacl -createDb node1 server1
  2. In the WebSphere admin console, under Enterprise Applications, you should now see a new application, called SDO Repository, successfully started.

Any future configuration of Web services will now store the appropriate definitions in the SDO repository, without requiring any further setup. Typically, you will never deal with this repository directly.

Install SIbus Web services resource adapter

For the bus to act as a Web service requestor, sending Web service messages to providers, it must be configured with a resource adapter. A script included in the file sibwsInstall.jacl is provided with WebSphere Application Server for setting up the SIBWS application (described in the next section) and installing the resource adapter:

  1. In a command window, change to the <WAS_HOME>/bin directory and execute:
    wsadmin -f ../util/sibwsInstall.jacl INSTALL_RA -installRoot "C:/Program Files/IBM/WebSphere/AppServer" -nodeName node1
  2. You should see this message:
    The resource adapter has started successfully : SIB_RA.

Install and configure endpoint listeners

Endpoint listeners need to be installed and configured for each protocol you want to use to receive Web service requests into the bus. For these endpoint listeners to work, you need to install the SIBWS application as well. The same script we used to install the resource adapter, sibwsInstall.jacl, is used for installing the endpoint listeners, just with different parameters. After the installation, additional configuration in the admin console is required for each endpoint listener. Be sure to create the bus and install the resource adapter before installing the SIBWS application and endpoint listeners.

Two endpoint listeners are provided for each protocol. You can use one for requests coming from external clients into the bus, and the second one for requests coming from internal clients. You can configure security differently for each listener. If you have global security enabled, no users will be able to access any inbound service. Instructions are provided in the WebSphere Application Server V6 Information Center on how to configure the security settings to allow access.

To install the SIBWS application:

  1. In a command window, change to the <WAS_HOME>/bin directory, and execute:
    wsadmin -f ../util/sibwsInstall.jacl INSTALL -installRoot "C:/Program Files/IBM/WebSphere/AppServer" -serverName server1 -nodeName node1
  2. In the WebSphere Application Server admin console, under Enterprise Applications, you should now see a new application, called sibws.node1.server1, successfully started. For this application to start successfully, the resource adapter must have been installed first. (The name of this application may differ in your environment based on the node and server names that you picked during installation.)
  3. For each supported Web services protocol (such as, HTTP or JMS), install two endpoint listener applications using the sibwsInstall.jacl script. For example, to install the HTTP endpoint listener applications, execute:
    wsadmin -f ../util/ sibwsInstall.jacl INSTALL_HTTP -installRoot "C:/Program Files/IBM/WebSphere/AppServer" -serverName server1 -nodeName node1
  4. In the admin console, under Enterprise Applications, you should now see the two new applications listed, called sibwshttp1.node1.server1 and sibwshttp2.node1.server1. Both should be successfully started.

    Your Enterprise Applications window in the WebSphere Application Server admin console should now look like Figure 4.
    Figure 4. Enterprise Applications in admin console
    Figure 4. Enterprise Applications in admin console
  5. Now that the code for the listener is installed, we will create the specific endpoint listener. Navigate to Servers => Application Servers => server 1 => Endpoint Listeners and select New.
  6. Enter the field values listed below (and in Figure 5); these values are very specific -- the names and values must match those specified in the Endpoint listener configuration details section of the WebSphere Application Server V6 Information Center:
    • Name: SOAPHTTPChannel1 (this specific name is required)
    • URLRoot: http://localhost:9080/wsgwsoaphttp1/
    • WSDL Serving HTTP URL root: http://localhost:9080/wsgwsoaphttp1/
  7. Click OK, then save your changes.
    Figure 5. Endpoint Listener configuration
    Figure 5. Endpoint Listener configuration
  8. Configure the new endpoint listener to connect to our bus by selecting the new Endpoint Listener, SOAPHTTPChannel1, then Connection Properties.
  9. Click New, and select your bus, TheBus.
  10. Click OK and save your changes.
  11. Go to TheBus => Destinations. There should be a new destination called node1.server1. SOAPHTTPChannel1. This new destination is where all messages arriving through the defined endpoint are routed. In other words, all of the incoming SOAP/HTTP Web services requests will now go to the SOAPHTTPChannel1 destination.

Conclusion

In this article, we described a business scenario for building an Enterprise Service Bus with WebSphere Application Server V6 Messaging Resources. We created our bus and set it up for use with Web services. In Part 3, we will start developing our enterprise bus, and begin fulfilling our scenario requirements by developing a client to send a confirmation message over JMS onto the bus, and then onto a message-driven bean.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=48781
ArticleTitle=IBM WebSphere Developer Technical Journal: Building an Enterprise Service Bus with WebSphere Application Server V6 -- Part 2
publish-date=02232005