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.
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
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
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.
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.
To create a Bus instance:
- Open the WebSphere Application Server admin console (the server must be running).
- In the left navigation pane, select Service Integration => Buses.
- Select Buses, then in the following dialog, select New, which starts the wizard to create a bus.
- Name the new bus,
TheBusand select OK.
- Save your changes, then see the new bus in the list (Figure 3).
Figure 3. New bus in WebSphere Application Server admin console
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:
- Select TheBus.
- In the next dialog, select Bus Members, then Add.
- Make sure that the Server radio button is selected.
- From the server selection box, select node1:server1, which will likely be selected by default.
- Click Next and Finish, then save your changes.
You now have a WebSphere Messaging Resources bus ready for use.
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.)
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:
- In a command window, change to the <WAS_HOME>/bin directory, then execute:
wsadmin -f installSdoRepository.jacl -createDb node1 server1
- 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.
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:
- 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
- You should see this message:
The resource adapter has started successfully : SIB_RA.
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:
- 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
- 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.)
- 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
- 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
- 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.
- 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:
SOAPHTTPChannel1(this specific name is required)
- WSDL Serving HTTP URL root:
- Click OK, then save your changes.
Figure 5. Endpoint Listener configuration
- Configure the new endpoint listener to connect to our bus by selecting the new Endpoint Listener, SOAPHTTPChannel1, then Connection Properties.
- Click New, and select your bus, TheBus.
- Click OK and save your changes.
- 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.
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.
- IBM Web site for Enterprise Service Bus
- BPEL articles
- WebSphere Application Server Version 6.0 Information Center
- Redpaper: WebSphere Application Server V6 Technical Overview
- Get involved in the developerWorks community by participating in
- Browse for books on these and other technical topics.
Rachel Reinitz is a Distinguished Engineer with IBM Software Services for WebSphere focusing on Web services. Rachel consults with customers and ISVs on how service oriented architecture and Web services can be used to achieve their business and technical objectives. She developed IBM's Advanced Web Services Training course and is a frequent conference presenter. Rachel is also an IBM Academy Member, and an experienced eXtreme Programming coach who has used XP practices for 4 years. She lives in the Bay Area in California, and enjoys hiking, socializing, and international travel.
Andre 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.