Integrating Healthcare Services, Part 1:: Using An Enterprise Service Bus For Healthcare

Integrating healthcare services, Part 1: Using an
Enterprise Service Bus for healthcare

Configure a Java Business Integration server to make diverse
applications interconnect and interoperate
Skill Level: Intermediate
Bilal Siddiqui (xml4java@yahoo.co.uk)

Consultant
18 May 2010
Ideally, the diverse services that medical patients need should interconnect and
interoperate to enhance healthcare quality and efficiency. This article, the first of two
parts, discusses the aggregation of healthcare services using Java™ Business
Integration (JBI) architecture. Such an aggregation platform — a Healthcare Service
Bus (HSB) — can be readily adapted to other industries.
This two-part article demonstrates the aggregation of various healthcare-related
services over a service bus, which I call (aptly enough) a Healthcare Service Bus
(HSB). Here in Part 1, I'll start with a use-case scenario in which various applications
that serve patient needs are connected to an HSB, and I'll explain the features the
HSB should provide. Next, I'll introduce Java Business Integration (JBI) architecture,
used for building the HSB. By following the sequence of events that occur inside a
JBI server, you'll see how JBI works internally for business integration and how its
components coordinate with external applications. The last section of Part 1
provides configuration examples that demonstrate how you can control the behavior
of JBI components so that they work for healthcare. In Part 2, you'll learn how to
integrate healthcare services using the existing functionality of an open source JBI
implementation (Apache ServiceMix) and by implementing new ServiceMix
functionality.
A service bus for healthcare
Using an Enterprise Service Bus for healthcare Trademarks

© Copyright IBM Corporation 2010. All rights reserved. Page 1 of 18
developerWorks® ibm.com/developerWorks
An HSB integrates a variety of healthcare-related services. Imagine the needs of an

emergency patient who requires life-saving care, including services such as blood
transfusion, emergency prescriptions, and radiology tests.
When the patient arrives at a medical facility, the doctor in charge uses the service
bus to check the patient's allergy history from an application running on the patient's
cell phone. The doctor also enters initial observations about the patient's condition
into a medical prescription application connected to the bus. The doctor's
observations travel over the service bus into a Web server hosting the portal of the
insurance company that covers the patient.
The doctor then prescribes a blood transfusion for the patient into the same
prescription application. The prescription is automatically sent over the service bus
not only to a few blood banks, but also to a donor-group application, which sends
SMS messages to donors whose blood samples have been prematched with the
patient's. The blood requirement to the donor-group application also travels over the
service bus.
The doctor also writes a prescription for emergency drugs and a radiology test,
which are fed into the same prescription application. The prescription application
sends these prescriptions over the bus to the medical facility's in-house pharmacy
and radiology department.
Aggregation of services
You can see from this use-case story that the HSB allows diverse applications to
interconnect and interoperate, thereby enabling aggregation of services. Two main
types of applications — service consumers and service providers — connect to the
HSB. The prescription application that sent the blood transfusion requirement to the
HSB acted as a service consumer (an application that requests or consumes a
service). The donor-group application that sent SMS messages to potential blood
donors acted as a service provider (an application that provides the requested
service). Interconnection and interoperation are different requirements that together
provide aggregation of services. Interconnection means that service providers and
service consumers have a common way of connecting to (reaching) one another, so
that they can interoperate with one another (exchange information and messages).
The HSB uses the popular XML format for interoperable exchange of messages.
HSB as SOA
An architecture such as the HSB's that relies heavily on "services"
is called Service Oriented Architecture (SOA). SOA simply means
that everything is a service. The donor-group application is a service
that sends out SMS messages. The radiology department is also a
service, one that performs radiology tests on demand. In an SOA,
any application that exposes the service is a service provider and
the application that demands, requests, or uses a service is a
service consumer.

ibm.com/developerWorks developerWorks®
Figure 1 shows service providers and service consumers connected to the HSB:
Figure 1. Service providers and consumers connected to an HSB
Note that Figure 1 shows three service providers connected to the HSB: the
Insurance Company Portal, Donor Group, and Radiology Department applications.
An HSB should be able to interconnect service consumers to both in-house and
external service providers, so that they can interoperate with one another. In Figure
1, the Radiology Department application exists within the medical facility; the Donor
Group and the Insurance Company Portal applications are outside the medical
facility.
Required HSB features
To enable interconnection, the HSB must:
• Keep a log of all service providers connected to it, so that it can route a
service-consumption request from a service consumer to the appropriate
service provider.
• Provide a standard mechanism that lets service providers and service
consumers talk to one another through the service bus.
• Allow other HSBs to interconnect with it.
Interconnection of HSBs
Interconnection of HSBs is an interesting application, the architecture of which is

shown in Figure 2:
Figure 2. Interconnection of HSBs

Figure 2 shows two HSBs for different medical facilities. One facility has a Blood
Bank application, which the Prescription application can invoke through
interconnection of the two HSBs.
XML for interoperable healthcare
XML can be used in two ways to enable interoperability of healthcare services:
• Web services: Web services based on Web Services Description

Language (WSDL) and Simple Object Access Protocol (SOAP) are
frequently used in many industries, including healthcare. WSDL uses
XML to define the service; that is, define the interface that the service
provides. SOAP is an XML-based protocol used for actual messaging
between service providers and consumers. (See Resources for more
information about WSDL and SOAP.) The HSB should be able to
interconnect any healthcare application that uses WSDL and SOAP for
interoperability.
• Health Level 7: Health Level 7 (HL7) is a set of popular healthcare
standards that define many data structures used to specify healthcare
information, such as medical records, prescriptions, and patient
discharges summaries. (Older HL7 versions 1 and 2 were based on
ASCII. The recent HL7 version 3.X uses XML as its data format for
defining message structures.)
Generalizing the HSB to other industries

The interconnection and interoperability requirements discussed
here are applicable to industries other than healthcare. For
example, the diverse services in the tourism industry — hotels,
airlines, car rentals, and tour operators — must interconnect and
interoperate to serve their customers. The HSB's three
interconnection features are applicable to the tourism industry as
well. Different service providers such as hotels and car rentals can

easily use WSDL and SOAP to interoperate. And industry-specific

XML-based standards like HL7 can exist in any industry.
The HSB that I'll demonstrate can interconnect healthcare applications that use the
WSDL, SOAP, and HL7 standards.
ESB: A general architecture for interoperability and interconnection
Such a generalized interoperable and interconnected architecture is typically

referred to as Enterprise Service Bus (ESB), which can:
• Be based on SOA.
• Allow service providers and consumers to use WSDL and SOAP.
• Be extensible and flexible in the sense that it allows service providers and
consumers to use industry-specific XML-based standards such as HL7.
The idea of an ESB is not new. Several ESB implementations exist today. (See
Resources for links to some popular open source ESBs.) This means that there's no
need to build an HSB from scratch. You can configure an existing ESB to work for
healthcare.
Using JBI as an HSB

The JBI specification defines a standardized Java business-integration environment.
JBI provides all the features of an ESB that I have discussed, so I'll use it to build an
HSB.
Several JBI implementations are available, including a popular open source

implementation from Apache called ServiceMix. The rest of this series is all about
using JBI and configuring ServiceMix to build an HSB.
JBI components working together for healthcare
Figure 3 shows how JBI can be used as an HSB:
Figure 3. JBI working as an HSB

You can see in Figure 3 that the three main components of JBI are Binding
Components (BCs), Service Engines (SEs), and a Normalized Message Router
(NMR).
I'll explain the working of JBI components with the help of the sequence of events
(shown in Figure 4) that happens when the Prescription application (a service
consumer) connects to the Donor Group application (a service provider):
Figure 4. Service consumer connecting to a service provider though JBI

The following sequence occurs in Figure 4:
Step 1: The Prescription application (a service consumer) connects to JBI and asks
for the service offered by the Donor Group application (a service provider that sits
outside the JBI environment).
Step 2: The JBI environment forwards the service request to an appropriate BC —

the one that receives all service requests from the Prescription application. Each
service consumer or provider that works with JBI has a particular dedicated BC
inside the JBI environment.
Step 3: The BC transforms the service invocation request into a normalized format
defined by the JBI specification. The purpose of defining the normalized format is to
enable interoperation between BCs. All JBI BCs understand the normalized format.
Each BC also understands the format of the service provider or consumer to which
the BC is attached. In other words, JBI's normalizing feature is a common format into
which all BCs transform messages received from their respective service consumers
or producers.
Step 4: The Prescription application's BC hands over the normalized message to the
NMR shown in Figure 4. The entire JBI environment includes a single NMR.
Step 5: The NMR's job is to receive normalized messages from one BC, identify the
target service provider, and forward (or route) the normalized message to another

BC of the target service. In this step, the NMR forwards the normalized message to
the BC connected with the Donor Group application.
Step 6: The BC of the Donor Group application denormalizes the normalized

message, thereby transforming it into the format understood by the Donor Group
application.
Step 7: The BC hands over the denormalized message to the Donor Group
application.
This sequence of events reveals two simple points about JBI:
• JBI works on the idea of normalized message routing. Each message is

normalized by a BC and handed over to NMR. NMR routes the message
to another BC, which denormalizes it into the format understood by the
intended service provider.
• The normalized-message-routing mechanism provides a decoupled
architecture. Decoupling means the service providers and consumers
interact with one another only through the NMR mechanism. They don't
interact directly with one another.
The main advantage of this decoupled architecture is that you implement a particular
data format or standard only once, in the form of a BC. Later, all service providers
that provide services according to the particular data format simply use an instance
of the BC to become integrated into the JBI environment.
For example, if you must integrate HL7 into JBI, you need a BC that understands
HL7. If you have the HL7 BC, you can integrate any HL7 service into JBI, thereby
forming an HSB.
Part 2 of this series will give you practical steps for building an HL7-based BC and
integrating HL7 into JBI. But for the moment, there's more to learn about JBI.
Mixing internal and external services in JBI
The discussion accompanying Figure 4 shows the communication between a service

consumer and a service provider that resides outside the JBI environment.
Recall from the use-case story at the beginning of this article that the Prescription
application also sent a message to an in-house radiology department. This means
that your JBI environment should be able to host the Radiology Department
application as an internal service. Internal services in JBI are hosted as SEs.
SEs are just like BCs with one additional feature: An SE also contains the business
logic of the internal service (for example, of the Radiology Department application).
BCs and SEs are both connected to JBI's NMR, as you saw in Figure 3, which I've

modified in Figure 5 to show the Radiology Department application as an SE:
Figure 5. Radiology Department application shown as an SE
The sequence of events to access an internal service (that is, an SE) is shown in
Figure 6:
Figure 6. A service consumer accessing an internal service provider

The sequence of events shown in Figure 6 represents what happens when a service
consumer such as the Prescription application sends a message to the Radiology
Department application (an internal service provider):
Step 1: The Prescription application (a service consumer) connects to JBI and asks
for the service offered by the Radiology Department application.
Step 2: The JBI environment forwards the service request to the BC of the
Prescription application.
Step 3: The BC transforms the service invocation request into a normalized

message.
Step 4: The BC hands over the normalized message to NMR.
Step 5: The NMR forwards the normalized message to the Radiology Department
application (an SE).
Step 6: The SE internally denormalizes the message and invokes the required
business logic.
This sequence of events — which is quite similar to the sequence of events shown
Figure 4 — shows that an SE contains the functionality of a BC and also the
business logic of the service-provider application.
It may appear that an SE unnecessarily mixes two separate things (the functionality
of a BC and the business logic). In Part 2, I will show you how to build the business
logic of your internal service on top of an existing BC, without any unnecessary
mixing.
Interconnecting JBI-based ESBs

Refer back Figure 2, in which I show the interconnection of HSBs. This

interconnection can be achieved through JBI, as shown in Figure 7:
Figure 7. Two interconnected JBI environments
Note that Figure 7 shows different applications connected to two separate JBI
environments. The following sequence of events happens when the Prescription
application (shown connected to the first JBI in Figure 7) sends a message to the
Blood Bank application (a service provider that resides inside the second JBI
environment):
Step 1: The Prescription application (a service consumer) connects to the first JBI
and asks for the service offered by the Blood Bank application.
Step 2: The first JBI environment forwards the request to the BC of the Prescription
application.

Step 3: The BC of the Prescription application transforms the service invocation

request into a normalized message.
Step 4: The BC of the Prescription application hands over the normalized message
to the NMR.
Step 5: The NMR forwards the normalized message to the BC connected with the
second JBI environment.
Step 6: The BC connected with the second JBI environment denormalizes the
message.
Step 7: The BC connected with the second JBI environment hands over the
denormalized message to the second JBI environment.
Step 8: The second JBI environment receives the request and forwards it to the BC
connected with the first JBI environment. This means the two JBI environments
connect to each other through appropriate BCs.
Step 9: The BC connected with the first JBI environment transforms the service
invocation request into a normalized message.
Step 10: The BC connected with the first JBI environment hands over the
normalized message to the NMR.
Step 11: The NMR forwards the normalized message to the Blood Bank application
(an SE).
Step 12: The SE internally denormalizes the message and invokes the required
business logic.
Message-exchange patterns in JBI
The discussions accompanying Figures 4, 5, 6, and 7 show one-way communication

— sending a message from a service consumer to a service provider. The service
provider (such as the Donor Group application) does not send a return message. JBI
documentation refers to this type of messaging as in-only message exchange. The
in-only message-exchange pattern is suitable for services like the Donor Group
application, which only needs a one-way message to the group. No information is
required to travel back to the requesting Prescription application.
Some other service (such as the Insurance Company Portal application) may be
required to send a response. Such a request-response messaging pattern is also
allowed in JBI and referred to as in-out. As you might guess, the response also
travels in the same manner from the service provider through the JBI environment —
BCs, SEs, and NMR — and ultimately to the service consumer. So I won't include
another sequence of events to describe in-out messaging.

Configuring and bootstrapping your JBI environment

The JBI specification provides a detailed XML schema for defining the behavior of all
BCs and SEs that you wish to host on JBI. Now I will describe how you can use the
JBI schema to configure a JBI implementation as an HSB.
I won't discuss the entire JBI schema in this article. I'll focus here on one important
JBI tag called <component>. Part 2 will demonstrate the use of more JBI schema
tags.
The <component> tag defines a JBI component. A component can be a BC or an

SE. Listing 1 shows what the XML configuration of the BC for the Prescription
application looks like:
Listing 1. XML configuration for the prescription application's BC
<?xml version="1.0" encoding="UTF-8"?>

<jbi xmlns="http://java.sun.com/xml/ns/jbi" version="1.0">
<component type="binding-component"
component-class-loader-delegation="parent-first"
bootstrap-class-loader-delegation="parent-first">
<identification>
<name>Prescription-Application</name>
<description>Binding Component for the prescription application</description>
</identification>
<component-class-name>
org.apache.servicemix.cxfbc.CxfBcComponent
</component-class-
<component-class-path>
<path-element>lib/servicemix-cxf-bc-2009.01.jar</path-element>
<path-element>lib/geronimo-annotation_1.0_spec-1.1.1.jar</path-element>

</component-class-path>
<bootstrap-class-name>
org.apache.servicemix.common.DefaultBootstrap
</bootstrap-class-name>
<bootstrap-class-path>
</bootstrap-class-path>
</component>
</jbi>
You can see that Listing 1 contains a <component> tag with a type attribute and
five child tags named <identification>, <component-class-name>,
<component-class-path>, <bootstrap-class-name>, and
<bootstrap-class-path>.
The type attribute specifies whether the component is a BC or an SE. Listing 1

configures the BC for the Prescription application, so the value of the type attribute
should be binding-component.

The <identification> tag in Listing 1 provides a name and description for the BC.
The <component-class-name> tag specifies the Java class that implements the
logic required by the BC. The JBI specification has a standard interface named
javax.jbi.component.Component, which all BCs should implement. I am going
to use Apache ServiceMix in this series to demonstrate the working of an HSB.
ServiceMix provides a BC that can be used to work with service consumers that
consume SOAP-based Web services. The class that implements the logic of this BC
is named org.apache.servicemix.cxfbc.CxfBcComponent. In Part 2, I'll use
this class to demonstrate how the Prescription application works with JBI. That's why
Listing 1 includes org.apache.servicemix.cxfbc.CxfBcComponent as the
name of the component class wrapped inside the <component-class-name> tag.
Now look at the <component-class-path> tag in Listing 1. It has two child tags
named <path-element>. These tags specify the path to all JAR files that the
component class needs in order to execute. This means the
<component-class-name> and <component-class-path> tags form a pair
that specifies the name of the BC's Java class as well as the complete class path
required to execute the Java class.
You will find another pair of tags named <bootstrap-class-name> and

<bootstrap-class-path> in Listing 1. This pair is similar to the previous pair of
<component-class-name> and <component-class-path> tags. The
bootstrap pair specifies the name and class path of the Java class that implements
the logic of bootstrapping the BC.
Bootstrapping means putting the BC into service. Bootstrapping occurs when you
start your JBI server (ServiceMix). The bootstrapping class contains all the logic to
bring the BC to life and get it up and running.
Now look at the <component> tag in Listing 2, which represents an external service
provider such as the Donor Group application. Listing 2 has exactly the same
structure as Listing 1, so it does not need any explanation.
Listing 2. XML configuration of an external service provider

<component type="binding-component"
<identification>
<name>Donor-Group-Application</name>
<description>Binding Component for the Donor Group application</description>
</identification>
org.apache.servicemix.cxfbc.CxfBcComponent
</component-class-

</component>
</jbi>
Listing 3 shows another <component> tag that tells how to configure an SE — an

internal service provider (such as the Radiology Department application):
Listing 3. XML configuration of an internal service provider

<component type="service-engine"
<identification>
<name>Radiology-Department-Application</name>
<description>Radiology Department Service Application</description>
</identification>
org.hsb.radiology.RadiologyBean</component-class-name>
<path-element>lib/radiology-bean.jar</path-element>
<path-element>lib/ radiology-bean.jar</path-element>
</component>
</jbi>
If you compare Listing 3 with Listing 2, you'll see only one major difference: The
type attribute value in Listing 2 is binding-component (because it is a BC
representing an external service provider), whereas the value of the type attribute
shown in bold in Listing 3 is service-engine because it is an SE representing an
internal service.
Coming up next
You have seen how to use JBI's <component> tag to configure your BCs and SEs.
JBI also provides a reusability mechanism for building general-purpose BCs that can

be used in various scenarios.
JBI implementations such as ServiceMix provide prebuilt BCs that come bundled
with the implementation. You don't even need to configure the <component> tag for
such BCs. The implementation will already know the classes and other details of
such BCs.
Part 2 will put the pieces together and demonstrate how you can use the existing
functionality of ServiceMix as well as build and configure new functionality — that is,
implement and configure a BC or an SE — to integrate healthcare services.

Resources
Learn
• JBI: Get the Java Business Integration specification from the Java Community
Process site.
• Open source ESBs:
• Apache ServiceMix
• Mule ESB
• OpenESB
• Fuse ESB
• PetalESB
• WSDL: Visit the World Wide Web Consortium (W3C) site to learn more about
Web Service Description Language.
• "Deploying Web services with WSDL: Part 1" (Bilal Siddiqui, developerWorks,
November 2001:) Learn about authoring WSDL for your Web service.
• SOAP: Visit the W3C site to learn more about SOAP.
• "Deploying Web services with WSDL, Part 2: Simple Object Access Protocol
(SOAP)" (Bilal Siddiqui, developerWorks, March 2002): Read a thorough
discussion on the SOAP protocol and its syntax.
• HL7: Learn about standards for interoperability of health information.
• Browse the technology bookstore for books on these and other technical topics.
• developerWorks Java technology zone: Find hundreds of articles about every
aspect of Java programming.
Discuss
• Get involved in the My developerWorks community.
About the author

Bilal Siddiqui
Bilal Siddiqui is an electronics engineer, an XML consultant, and the
co-founder of WaxSys, a company focused on simplifying e-business.
After graduating in 1995 with a degree in electronics engineering from
the University of Engineering and Technology, Lahore, Pakistan, he

began designing software solutions for industrial control systems. Later,

he turned to XML and used his experience programming in C++ to build
Web- and WAP-based XML processing tools, server-side parsing
solutions, and service applications. Bilal is a technology evangelist and
a frequently published technical author.
Trademarks
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the
United States, other countries, or both.

Integrating Healthcare Services, Part 1:: Using An Enterprise Service Bus For Healthcare

Uploaded by

Document Informationclick to expand document information

Copyright:

Available Formats

Integrating Healthcare Services, Part 1:: Using An Enterprise Service Bus For Healthcare

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Integrating Healthcare Services, Part 1:: Using An Enterprise Service Bus For Healthcare

Uploaded by

Copyright:

Available Formats

Integrating healthcare services, Part 1: Using an

Enterprise Service Bus for healthcare

Skill Level: Intermediate

Bilal Siddiqui (xml4java@yahoo.co.uk)

A service bus for healthcare

Using an Enterprise Service Bus for healthcare Trademarks

An HSB integrates a variety of healthcare-related services. Imagine the needs of an

Using an Enterprise Service Bus for healthcare Trademarks

Figure 1. Service providers and consumers connected to an HSB

Required HSB features

To enable interconnection, the HSB must:

Interconnection of HSBs is an interesting application, the architecture of which is

Figure 2. Interconnection of HSBs

Using an Enterprise Service Bus for healthcare Trademarks

XML for interoperable healthcare

XML can be used in two ways to enable interoperability of healthcare services:

• Web services: Web services based on Web Services Description

Generalizing the HSB to other industries

Using an Enterprise Service Bus for healthcare Trademarks

easily use WSDL and SOAP to interoperate. And industry-specific

ESB: A general architecture for interoperability and interconnection

Such a generalized interoperable and interconnected architecture is typically

Using JBI as an HSB

Several JBI implementations are available, including a popular open source

JBI components working together for healthcare

Figure 3 shows how JBI can be used as an HSB:

Figure 3. JBI working as an HSB

Using an Enterprise Service Bus for healthcare Trademarks

Figure 4. Service consumer connecting to a service provider though JBI

Using an Enterprise Service Bus for healthcare Trademarks

The following sequence occurs in Figure 4:

Step 2: The JBI environment forwards the service request to an appropriate BC —

Using an Enterprise Service Bus for healthcare Trademarks

Step 6: The BC of the Donor Group application denormalizes the normalized

This sequence of events reveals two simple points about JBI:

• JBI works on the idea of normalized message routing. Each message is

Mixing internal and external services in JBI

The discussion accompanying Figure 4 shows the communication between a service

Using an Enterprise Service Bus for healthcare Trademarks

modified in Figure 5 to show the Radiology Department application as an SE:

Figure 5. Radiology Department application shown as an SE

Figure 6. A service consumer accessing an internal service provider

Using an Enterprise Service Bus for healthcare Trademarks

Step 3: The BC transforms the service invocation request into a normalized

Step 4: The BC hands over the normalized message to NMR.

Interconnecting JBI-based ESBs

Using an Enterprise Service Bus for healthcare Trademarks

Refer back Figure 2, in which I show the interconnection of HSBs. This

Figure 7. Two interconnected JBI environments

Using an Enterprise Service Bus for healthcare Trademarks

Step 3: The BC of the Prescription application transforms the service invocation

Message-exchange patterns in JBI

The discussions accompanying Figures 4, 5, 6, and 7 show one-way communication

Using an Enterprise Service Bus for healthcare Trademarks

Configuring and bootstrapping your JBI environment

The <component> tag defines a JBI component. A component can be a BC or an

Listing 1. XML configuration for the prescription application's BC

<?xml version="1.0" encoding="UTF-8"?>