 | Level: Intermediate Antonio Gallo (agallo73@yahoo.it), IT Specialist, Banca d'Italia
Maria Gallo (maria.gallo@it.ibm.com), Software Developer, IBM
Michele Crudele (michele.crudele@it.ibm.com), Software Architect, IBM
31 Jan 2008 Looking for a way to manage the interoperability among applications
using different protocols that need to exchange confidential data? Consider
combining the functionality of IBM® WebSphere® Enterprise Service Bus
and IBM WebSphere DataPower® SOA Appliances. Find out how you can get a secure,
agile, and extendible solution with a little effort in terms of code.
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.
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:
Figure 1. Healthcare reservation
system
Let's break down what you see in Figure 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).
- 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).
- 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?"
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.
Figure 2. Mediation module
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.
 |
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.
Figure 3. Message selectors
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.
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.
Figure 4. Public key
infrastructure
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.
Figure 5. Certificate management
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).
Describing the solution
The complete architectural picture is presented in Figure 6.
Figure 6. Architecture
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.
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.
Figure 7. Import binding
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
- Open the WebSphere Administrative Console of the Enterprise Service Bus.
- Enable all the events from the apposite available task filter drop down list.
Figure 8 illustrates this.
Figure 8. Administrative
console: enable events
- 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
- Double-click SCA.APPLICATION.esbCell.Bus. A new window appears.
- Select Destination Resources > Destinations. A list of the currently
defined bus destinations is displayed.
- Select New > Topic Space. A new window appears.
- 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
- Save the configuration when prompted to do so.
Configure the topic
Now let's address the specifics of configuring the topic itself:
- In the navigation pane of the Administrative Console, select Resources >
JMS Providers > Default Messaging.
- 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.
- Click the JMS topic link under the Destinations section (see Figure
11).
Figure 11. Administrative
console: topic
- 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
- 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:
- 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.
- 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
- In the navigation pane of the Administrative Console, select
Resources > JMS Providers > Default Messaging.
- 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
- Configure the topic configuration factory administration information by
entering the following values (see Figure 15):
- Name:
sampleTCF
- JNDI name:
jms/sampleTCF
- 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
- 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.
- 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.
Figure 16. Administrative console: JMS import binding
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).
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
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:
About the authors | | | Antonio Gallo works as IT specialist at Banca d'Italia. As a member of the Tivoli Lab in Rome since 2000, Antonio was involved in different initiatives with the briefing center, providing customers consultancy on how SOA and Web services can be used to achieve their business and technical objectives and realizing first prototypes. He's a Sun Certified J2EE Enterprise Architect, and his interests include software design patterns, Enterprise Service Bus, and SOAs. |
| | | Maria Gallo is a software developer in the IBM Software Group's Tivoli Lab in Rome. She has 10 years of IT experience in the change and configuration management arena in different roles: customer support, product support, and development. Her primary interests are in security and J2EE architecture. She's also a Sun Certified J2EE Enterprise Architect. |
| | | Michele Crudele is a software architect working in the IBM Software Group's Tivoli Lab in Rome. He has 15 years of IT experience, mostly focusing on the development of systems management products and solutions. Michele has broad technical experience from working on different disciplines, such as change configuration management, monitoring and availability management, IBM autonomic computing technologies, and digital asset management for the publishing industry sector. |
Rate this page
| |
