Introduction

With the great proliferation of standards and technologies, it's common to face the problem of integrating systems and applications across the Internet and promoting interoperability among components developed in different languages, using different protocols and technologies. In this context, it's common for synchronous applications to be implemented as Web services, having to communicate with asynchronous message-based systems. This scenario requires a connectivity infrastructure that directly manages the service interactions, freeing the application from the burden of caring for the communications between services with different protocols, implementations, and locations on the network.

This article is the first in a four-part series that explores a real case scenario with a healthcare reservation system. The system has a Service-Oriented Architecture (SOA) with WebSphere Enterprise Service Bus in place. The article series provides step-by-step instructions about how to extend it to realize a new use case based on the messaging middleware using WebSphere DataPower SOA Appliances to guarantee data confidentiality.

To help you understand these concepts, we decided to dedicate a separate article to each functional part:

• Part 1, assuming a basic understanding of both Web services and the message-oriented framework, provides a complete overview of the scenario and, thus, shows the architectural picture that has been adopted.
• Part 2 covers the security-related aspects of the system, the encryption of the data, the certificate management, and WebSphere DataPower SOA Appliances. It gives you deep insight into what happens behind the scenes and shows how to configure WebSphere DataPower SOA Appliances and its extension functions to promote a public key infrastructure (PKI).
• Part 3 provides insight into the Enterprise Service Bus (ESB) mediation module and describes the configuration steps to make the ESB aware of confidential information.
• Part 4 deals with the client side of the application receiving Java™ Message Service (JMS) messages from the Enterprise Service Bus and decrypting sensitive data to reconstruct the original message.

Back to top

Healthcare reservation system

Physician practices, healthcare systems, and hospitals usually use some sort of healthcare reservation system to improve consumer engagement, increase operational efficiency, and decrease costs. The reservation system is a unique access point for patients, helping them find a physician that's geographically close, get faster access to speciality care, schedule an appointment without a long delay, or reschedule an existing one. Patients usually interact with a reservation system over the phone or the Web.

An integrated health system can also include home health agencies, radiation therapy facilities, physical therapy facilities, long-term care services, and other health-related entities. Once registered as a healthcare service provider, each of them can take advantage of a central reservation system. They can choose to totally delegate the appointment management or still use an internal reservation system in conjunction with the new one.

A healthcare reservation system, as shown in Figure 1, includes both the central reservation system and local systems managed by individual healthcare centers. The central reservation system provides a Web service interface for adding a new health center (registerNewPartner). Each health center, in turn must implement a set of Web service interfaces to interact with the central reservation system (makeReservation, queryReservation, cancelReservation).

As you can see, we've identified two different actors interacting with the system:

• The partner performs a basic set of administrative tasks, such as registering new partners and publishing an agenda.
• The patient represents the general user of the reservation system interested in querying the system to make or reschedule appointments.

Figure 1 describes the basic flows:

Let's break down what you see in Figure 1:

1. A healthcare center that wants to leverage the advantages provided by a central reservation system can register itself as a partner and provide a list of services and available time slots that patients can reserve (in red): Partners interact with the system using the Web UI (1.1), the registerNewPartner is invoked (1.2), and data are stored in the healthcare reservation system database (1.3).
2. The patient completes the initial form with all the required information (2.1) and receives back a list of choices matching search criteria (in blue).
3. The patient submits a reservation request (3.1) using the Web UI. The central reservation system (3.2) needs to locate the partner services at run time during online transactions for the system to match patient needs with available providers. This is addressed by the WebSphere Enterprise Service Bus, which allows a higher level of abstraction hiding the details of service locations and providing mediation, dynamic lookup, routing, and logging support (3.3). The system forwards the request to the healthcare provider for approval (that is, invokes the makeReservation Web service) (3.4) and finally confirms the reservation to the patient.

This series describes how it's possible to extend the system functionality to support a new category of health center partners. These are mostly small offices that don't operate a local reservation system. They delegate an external system for managing their agenda, connecting once a day (or rarely) to get new appointments. A patient who reserves a slot with such a provider doesn't get immediate confirmation. Instead, the central reservation system sends an e-mail later when the provider connects, gets the agenda, and confirms the appointment. To support these medical offices, the central reservation system, while processing a request, updates the agenda and publishes it to the partner.

You need to consider the following:

• The medical offices aren't typically always online, so the reliable delivery of the agenda must be guaranteed even when the consumers are temporally disconnected.
• Because the medical offices might be connected to the network via a slow link, the quantity of data sent must be limited.
• The data contained in the agenda are strictly confidential, so they must be protected in some way. Confidentiality is somewhat tricky in the asynchronous scenario, because the PKI techniques used in a one-to-one interaction between a client and service provider can't be applied. For one-to-one interactions, the service public key is clearly used. But when multiple service providers come into play, the question is "whose public key will the system encrypt with?"

Back to top

Looking for a solution

Because this scenario is clearly asynchronous, it's well suited to be implemented through the messaging paradigm. Using message-oriented middleware, in fact, it's usually possible to leverage advanced features that guarantee the reliable delivery of the messages, even when the consumers (the medical offices) are temporally disconnected. These features are usually not available when using a one-way Web service-based interaction. In the light of these considerations, the ESB perfectly suits this scenario, because not only does it guarantee message-based connectivity, it also provides transparent transport protocol switching capabilities. These capabilities leverage the concept of bindings that can be defined for services within the ESB. Through these bindings, a user can provide protocol-specific settings to instrument the ESB for managing incoming and outgoing messages. An export binding describes how a client communicates with the mediation module. An import binding, instead, describes how the mediation module communicates with the defined service. These bindings make it possible to connect to the medical offices without having to put any communication logic in the application code. To implement the described scenario, we defined a mediation module and wired it to a SOAP/HTTP export binding and a JMS import binding, as displayed in Figure 2.

In this way, the mediation module is aware of receiving messages in the SOAP/HTTP protocol and of the need to transform these messages according to the JMS protocol. The import binding allows a user to specify the destination where these messages must be sent. This destination might be a topic or a queue, depending on the application's domain. Using queues has the advantage of providing a specialized communication channel between the service requester and the service provider, but at the same time it has the drawback of requiring queues to be configured on the ESB, one for each deployed service provider. Using a topic instead avoids the queue-related configuration burden, but at the same time has the disadvantage of having all the medical offices registered to the topic to listen to the messages arriving on it. In this way, a medical office might also get messages that are destined to other providers, and this could be a problem as far as confidentiality and bandwidth consumption is concerned. Later in this article, you'll see a practical solution for both of these limitations. This solution is described here from an architectural point of view, but you can find all the details concerning the technical implementation and the configuration-related aspects in the third article of this series.

Back to top

Avoid bandwidth consumption using message selectors

The JMS specifications make it possible to define some messages that can be used as filters to instrument a JMS client about which messages it should process (only those messages that are destined to it). This information can be placed in some unreserved JMS header (in the JMSType, for instance) or JMS-based additional properties before the message is forwarded to the JMS topic. In this scenario, each service provider is univocally identified through a serviceProviderId code. The central reservation system has a list containing these identification codes, one for each provider. When it's time for the reservation system to send the updated agenda to a service provider, the reservation system prepares a SOAP message (you'll see later how it's formatted), adds the right identification code to the message's body, and forwards it to the ESB. Being the ESB responsible for converting this message to a JMS payload and forwarding it to a predefined topic, it's arguable to implement some logic within the ESB to augment the JMS message header with these identification codes, thus using the serviceProviderId contained in the message body as a message selector. Fortunately the ESB provides a message element setter mediation primitive that can be used to inspect the incoming message format and add some information to the outgoing message header. This primitive has been introduced in WebSphere Enterprise Service Bus V6.0.2 and has been used in this solution to augment the JMS message header, as illustrated in Figure 3.

When the mediation module gets a request message, it uses the message setter primitive to retrieve the serviceProviderId from the SOAP body of the request and, thus, store it (through a copy action) in the output message's JMSHeader. Then the ESB forwards this message to the topic, and the medical offices get it in a reliable way. This solution requires no code to be provided on the ESB layer. On the client side, instead, it's clearly necessary to develop a JMS stand-alone application or a message-driven bean to simulate the medical office's interactions with the topic.

Back to top

Guarantee data confidentiality on the topic

As previously stated, using a topic avoids the queue-related configuration burden, but at the same time has the disadvantage of having all the medical offices registered to the topic to listen to the messages arriving on it. Even if configuring a message selector on the ESB makes it possible for a service provider to get only its own messages, this solution doesn't prevent a malicious client from registering the topic without a message selector and, therefore, listen to all the incoming messages. To overcome this limitation and make the scenario more interesting, we decided to carry out a PKI.

Each medical office is assumed to have its own certificate and to publish it to the central reservation system. You can see how it's done in Figure 5. As previously explained, each SOAP request coming to the reservation system has some information in the message's body (a serviceProviderId) that identifies the provider to whom the message must be sent. When getting a SOAP message for a specific service provider, the central reservation system parses the message, gets the serviceProviderId, and uses this information to dynamically select the service provider's published certificate and, thus, use it to encrypt the message. On the client side, of course, only the service provider identified by the serviceProviderId flag can understand the message, because it has the right private key to perform the decryption. A service provider maliciously registering the topic, however, isn't able to understand the message, because it can't decrypt it with a matching private key. In this way, data confidentiality can be ensured on the topic, even if some logic must be implemented to encrypt messages on the central reservation system. To avoid the programmatic burden of having to perform SOAP/XML marshalling and unmarshalling when encrypting the message, we decided to use an SOA appliance and, therefore, delegate a WebSphere DataPower SOA Appliances box that's responsible for performing XML standard-based encryption on the confidential part of the SOAP message's body.

The administrator of the central reservation system is responsible for getting the certificate from the medical offices and then uploading the certificates to WebSphere DataPower SOA Appliances. WebSphere DataPower SOA Appliances acts as a Web service proxy; it encrypts the incoming SOAP requests and sends the encrypted messages to the ESB (refer to the next article of this series for further details).

Back to top

Describing the solution

The complete architectural picture is presented in Figure 6.

If you look carefully at the complete architectural picture, you might notice that from a functional point of view it could be split into three different parts.

The reservation system prepares the agenda for each service provider, encrypts (through WebSphere DataPower SOA Appliances) the sensitive data, forwarding the encrypted messages to the ESB. The ESB gets the encrypted data and then performs protocol switching and mediation. The medical office then registers the topic. Each service provider owns a private key and uses it to correctly decrypt its own messages when coming to the topic. The client may be implemented as a JMS client or an EJB message-driven bean.

Back to top

Define the topic configuration properties and import the JMS binding

This section takes you through the basic steps needed to define the import JMS binding. Figure 7 shows a good graphical representation of this.

As previously explained, the ESB gets SOAP/HTTP requests and forwards these messages to the JMS topic, thus managing the protocol switching transparently. To do this, the ESB must be instrumented as far as the topic's name and connection properties, and this information must be provided when defining the import binding as JMS messaging. Clearly, providing this information requires some configuration to be previously performed through the administrative console.

Let's go through some detailed instructions of how to create and configure the following components within the ESB. Here you focus on configuring a topic space, a topic, and a topic connection factory. You also see how to import a topic space.

Configure the topic space

1. Open the WebSphere Administrative Console of the Enterprise Service Bus.
2. Enable all the events from the apposite available task filter drop down list. Figure 8 illustrates this.
   
   Figure 8. Administrative console: enable events
   
   
   
3. In the navigation pane on the left, select Service Integration and then Buses. A list of the available buses is displayed in Figure 9.
   
   Figure 9. Administrative console: bus configuration
   
   
   
4. Double-click SCA.APPLICATION.esbCell.Bus. A new window appears.
5. Select Destination Resources > Destinations. A list of the currently defined bus destinations is displayed.
6. Select New > Topic Space. A new window appears.
7. Enter TopicImportOut as the identifier. Leave all the other fields as the defaults, and click OK (see Figure 10).
   
   Figure 10. Administrative console: topic connection factory
   
   
   
8. Save the configuration when prompted to do so.

Configure the topic

Now let's address the specifics of configuring the topic itself:

9. In the navigation pane of the Administrative Console, select Resources > JMS Providers > Default Messaging.
10. In the window that appears, leave the scope as Node, the default. Scroll down the page until you see the Connection Factories and Destination sections.
11. Click the JMS topic link under the Destinations section (see Figure 11).
    
    Figure 11. Administrative console: topic
    
    
    
12. In the window that appears, click New to create a new topic. Then enter the following values:
    • Name: TopicImportOut
    • JNDI name: jms/TopicImportOut
    • Topic space: TopicImportOut
    • Bus name: SCA.APPLICATION.esbCell.Bus
13. Select OK, and save the configuration. A new topic is created under the TopicImportOut space, which is shown in Figure 12.
    
    Figure 12. Administrative console: new topic
    
    
    

Create the topic configuration factory

Now you're ready to create the topic configuration factory:

14. To make the connection factory work, you must also provide a valid setting for the Provider Endpoints field. This field contains the list of the endpoints that must be used to connect to the bootstrap engine. If you don't want to deal with undesired exceptions when connecting to the topic through some JMS clients, you should provide this setting according to the following convention: esbHostName:bootstrapPort:BootstrapBasicMessaging, where:
    • esbHostName is the name of the machine hosting the ESB.
    • bootstrapPort is the port of the bootstrap endpoint.
15. If you want to check the correct value of this port, select the Application servers link under the Server section. Then select the default server (server1) and click the ports link under the communication section in the server details page that's displayed. A new window appears along with the SIB_ENDPOINT_ADDRESS row, which contains the port-related information (see Figure 13).
    
    Figure 13. Administrative console: ports
    
    
    
16. In the navigation pane of the Administrative Console, select Resources > JMS Providers > Default Messaging.
17. Select the JMSTopicConnectionFactory link under the ConnectionFactories section. In the window that appears, select New to create a new topic connection factory (see Figure 14).
    
    Figure 14. Administrative console: new topic connection factory
    
    
    
18. Configure the topic configuration factory administration information by entering the following values (see Figure 15):
    • Name: sampleTCF
    • JNDI name: jms/sampleTCF
19. Configure the topic configuration factory connection info. After you have all the information from previous steps, select the following values from drop down list:
    • Bus name: SCA.APPLICATION.esbCell.Bus
    • Provider endpoints: esbHostName:bootstrapPort:BootstrapBasicMessaging
20. Configure the topic configuration factory durable subscription information. For this scenario, we decided to use a durable topic to guarantee the delivery of the messages even when the medical offices are temporarily disconnected. To complete this step, you should:
    • Provide a client identifier to be used on all connections created using this connection factory. This setting can also be provided in a programmatic way, but it's better to define it as a configuration step. You can type any string you like for this setting. In the sample we used ASLID as the client identifier.
    • Provide a valid durable subscription home, which is the name of the messaging engine used to store messages delivered to the durable subscription. Specify the complete name of the messaging bus that you're using for the topic. In this case it's esbNode.server1-SCA.APPLICATION.esbCell.Bus, where esbNode and server1 are respectively the names of the ESB node and the default server on the machine.
21. Configure the topic configuration factory persistent message reliability with these steps (also see Figure 15):
    • Choose the Assured persistent option from the Persistent message reliability drop-down list.
    • Select the isolation level to use for the topic connection. There are several possibilities, including Cluster, Always shared, and Never shared. You can choose one of these according to your application domain. For this scenario, we decided to use the Always shared option to make the topic sharable among several JMS subscribers.
    
    
    Figure 15. Administrative console: configuration of topic connection factory
    
    
    

Create an import topic space

After you've created a topic space, a topic, and a topic connection factory, you can define a new import JMS messaging binding and, thus, provide this information as described in Figure 16.

You'll find detailed information on how to perform this step in the third article of the series. It's important to stress that you have to select Business Object XML using JMSTextMessage as the serialization type. This way you ensure that the encrypted body of the SOAP message is passed as an XML form to the topic and then can be parsed and reconstructed using some XML security standard decryption algorithm (as described in the last article of this series).

Back to top

Conclusion

This article gave you a complete overview of a real case scenario concerning the healthcare reservation system and described the architectural picture that has been adopted. You also saw step-by-step instructions on how to configure the ESB import binding. Stay tuned for Part 2 of this series, which focuses on the other components you need to add to your solution.

Resources

Learn

• Check out the following related IBM Redbooks®:
  • Getting Started with WebSphere Enterprise Service Bus V6
  • Patterns: Implementing an SOA using an Enterprise Service Bus
  • Connecting Enterprise Applications to WebSphere Enterprise Service Bus
  • Patterns: Integrating Enterprise Service Buses in a Service-Oriented Architecture
  
  
• Get more information about IBM WebSphere DataPower SOA Appliances.
  
  
• Learn more about IBM WebSphere Enterprise Service Bus, and visit the product page on developerWorks.
  
  
• The SOA and Web services zone on IBM developerWorks hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
  
  
• Play in the IBM SOA Sandbox! Increase your SOA skills through practical, hands-on experience with the IBM SOA entry points.
  
  
• The IBM SOA Web site offers an overview of SOA and how IBM can help you get there.
  
  
• Stay current with developerWorks technical events and webcasts.
  
  
• Browse for books on these and other technical topics at the Safari bookstore.
  
  
• Check out a quick Web services on demand demo.
  
  
• Get an RSS feed for this series. (Find out more about RSS.)
  
  

Get products and technologies

• Innovate your next development project with IBM trial software, available for download or on DVD.
  
  

Discuss

• Get involved in the developerWorks community by participating in developerWorks blogs, including the following SOA and Web services-related blogs:
  • Service Oriented Architecture -- Off the Record with Sandy Carter
  • Best Practices in Service-Oriented Architecture with Ali Arsanjani
  • WebSphere SOA and J2EE in Practice with Bobby Woolf
  • Building SOA applications with patterns with Dr. Eoin Lane
  • Client Insights, Concerns and Perspectives on SOA with Kerrie Holley
  • Service-Oriented Architecture and Business-Level Tooling with Simon Johnston
  • SOA, ESB and Beyond with Sanjay Bose
  
  

About the authors

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Healthcare reservation system
• Looking for a solution
• Avoid bandwidth consumption using message selectors
• Guarantee data confidentiality on the topic
• Describing the solution
• Define the topic configuration properties and import the JMS binding
• Conclusion
• Resources
• About the authors
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers