Integrating healthcare services, Part 2: Using Apache

ServiceMix as a Healthcare Service Bus

Interconnect multiple JBI servers hosting healthcare applications

Bilal Siddiqui June 08, 2010

A Healthcare Service Bus (HSB) enables diverse healthcare applications to interconnect

and interoperate for efficient service delivery. Part 1 of this two-part article discusses the
aggregation of healthcare services using Java™ Business Integration (JBI) architecture.
This concluding installment shows how you can use an open source JBI implementation —
Apache ServiceMix — as an HSB. You'll configure an application as a ServiceMix-hosted
internal service, learn how to interconnect multiple JBI environments, and find out how you can
integrate an industry standard for healthcare interoperability into ServiceMix.

View more content in this series

By connecting various healthcare applications to a Java Business Integration (JBI) server, you can
build an enterprise service bus for healthcare: a Healthcare Service Bus (HSB). Part 1 of this two-
part article introduces JBI, explains its architecture, and discusses how it can be used as an HSB
that aggregates services such as a prescription application, a radiology-department application,
and a donor-group application.

This second part demonstrates how to configure these services so that a JBI server can
start acting as an HSB. I'll show you how to use Apache ServiceMix, a popular open source
implementation of JBI, as an HSB. I'll start by introducing ServiceMix and one of its important
components. Then I'll describe how to use that component to configure an application as an
internal service hosted on Apache ServiceMix. The third section will show how to interconnect two
JBI environments so that an application connected to one JBI environment can interconnect and
interoperate with an application connected to another JBI environment. The last section provides
some tips on how to integrate the functionality of HL7 (Healthcare Level 7, a popular healthcare
standard introduced in Part 1) into JBI.

Introducing Apache ServiceMix

Apache ServiceMix can host JBI applications, such as those shown in Figures 4, 5, 6, and 7 of
Part 1. To implement components of the JBI environment, ServiceMix uses the popular open

© Copyright IBM Corporation 2010 Trademarks

Integrating healthcare services, Part 2: Using Apache ServiceMix Page 1 of 17
as a Healthcare Service Bus
developerWorks® ibm.com/developerWorks/

source Spring framework (see Resources). You use Spring XML configuration to configure
services inside the JBI environment, which makes it straightforward to specify the Java classes
that need to be instantiated.

In addition to implementing the JBI specification, ServiceMix comes bundled with some useful
preconfigured components that you can use directly in your JBI application. Recall from the Mixing
internal and external services in JBI section of Part 1 that you need a Service Engine (SE) in
order to implement an internal service such as the Radiology Department application. ServiceMix
provides a variety of reusable SEs that you can use to build your internal services. For this article,
you'll use a ServiceMix SE called CXF Service Engine (CXFSE).

CXFSE is a wrapper for the open source Apache CXF Web services framework. It lets you use
the functionality of Apache CXF in a ServiceMix application. Apache CXF allows you to build
web service applications that are fully integrated with internal business logic. CXFSE has many
features that make it suitable for use in applications such as an HSB.

Apache CXF uses the concept of interceptors to integrate a web service front end (that is, the
interface defined in a Web Services Description Language [WSDL] file) with the web service's
business logic. CXF provides several ready-to-use interceptors and also allows you to add your
own. An interceptor does a specific job, and you can configure a chain of interceptors to do
exactly what your business logic requires. For example, you can configure the following chain of
interceptors:

1. An interceptor receives a service request from a service consumer and transforms the request
to another format.
2. Another interceptor creates Java objects from the request.
3. The third interceptor invokes the business logic and passes Java objects along with the
invocation call.
4. Another one or few interceptors can contain the actual business logic.
5. The fifth interceptor fetches new Java objects from the business-logic application.
6. The sixth interceptor transforms Java objects into XML format and sends the response back
to the service consumer.

I won't discuss the details of building or configuring CXF interceptors in this article. Instead,
I'll use a simple default combination of ready-made interceptors that can invoke the Radiology
Department application. To learn more about Apache CXF, see Resources.

CXFSE is a configurable wrapper, which means you can control the behavior of your SE by writing
an XML file. I'll demonstrate shortly how you can write the XML configuration for CXFSE for the
Radiology Department application. But first, I'll present a high-level plan for all the actions required
to host an internal application (or service) on ServiceMix.

Hosting the Radiology Department application as an internal service

The procedure for hosting an internal service on ServiceMix requires several configurations, which
I'll break down into the following five steps:

Integrating healthcare services, Part 2: Using Apache ServiceMix Page 2 of 17

as a Healthcare Service Bus
ibm.com/developerWorks/ developerWorks®

1. Write and compile the Java class containing the business logic for the Radiology Department
application, and expose the class as a web service.
2. Configure the Java classes of the Radiology Department application in the Spring framework,
so that the framework instantiates the classes and makes them available according to
application requirements.
3. Write a WSDL interface for the Radiology Department application. The JBI specification
uses WSDL 2.0 to define the interface of services exposed by internal and external service
providers.
4. Write the JBI configurations for the service provider (that is the Radiology Department
application) as well as the service consumer. (Recall the Prescription application in Figure 6 of
Part 1, which is a service consumer that sends service requests to the Radiology Department
application.)
5. Package the Radiology Department application as a JBI service assembly and copy the
package into ServiceMix.
After you perform Step 5, you'll see your HSB in action by sending messages from the Prescription
application (a service consumer) to the Radiology Department application.

Now I'll describe and demonstrate each step.

Radiology Department application as a simple Java class

Listing 1 shows a simple Java class named RadiologyDepartment, which has just one method,
named performTest():

Listing 1. The RadiologyDepartment class

package com.hsb;

import javax.jws.WebService;
import javax.xml.ws.Holder;

import com.hsb.Radiology;

@WebService(serviceName="RadiologyService",
targetNamespace="http://hsb.org/radiology-department",
endpointInterface="com.hsb.Radiology")

public class RadiologyDepartment implements Radiology {

public void performTest (Holder<String> testDetails, Holder<String> testResults)

{
System.out.println ("
RadiologyDepartment.performTest()- > TestDetails:"+testDetails.value);
System.out.println ("
RadiologyDepartment.performTest()- > TestResults:"+testResults.value);
}
}

The performTest() method takes two parameters: testDetails and testResults. As you can see,
they are of type Holder <String>. Holder is a class defined by the Java API for XML-Based Web
Services (JAX-WS). CXFSE uses JAX-WS, so it is convenient to use an instance of this class to
exchange information with your Java class. The Holder class has methods for inserting data into
and fetching data from its instance. The CXF framework internally populates data from the XML

Integrating healthcare services, Part 2: Using Apache ServiceMix Page 3 of 17

as a Healthcare Service Bus
developerWorks® ibm.com/developerWorks/

request message into the Holder object and passes the Holder object to the Java class of the
Radiology Department application.

I have left the performTest() method empty (except for a few System.out statements), strictly for
brevity. In an actual application, the performTest() method would be hooked into the Radiology
Department application's business logic.

You need to compile the RadiologyDepartment class. This article's download contains a folder
named sample1\RadiologyService, where you'll find both the code for the RadiologyDepartment
class and a compiled form of the class.

You also need to generate Java API for XML Binding (JAXB) files corresponding to the
RadiologyDepartment class. These JAXB files are used by the JAX-WS API, so Apache CXF
needs them in order to expose your RadiologyDepartment class as a web service. You can use a
handy tool named wsgen to generate all the required files from your RadiologyDepartment class.
You'll find wsgen in the ..\jdk1.6.0_12\bin folder of your JDK1.6 installation. (See Resources to learn
more about the wsgen tool.)

For this article's purposes, I've provided a ws.bat file in the download. You can just run ws.bat to
generate the required JAXB files. You can also find these files in both source and compiled form in
the sample1\RadiologyService folder.

Configuring the RadiologyDepartment class in the Spring framework

Listing 2 shows the Spring XML configuration file for the RadiologyDepartment class:

Listing 2. Spring XML configuration for the Radiology Department service

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:cxfse="http://servicemix.apache.org/cxfse/1.0">
<cxfse:endpoint>
<cxfse:pojo>
<bean class="com.hsb.RadiologyDepartment" />
</cxfse:pojo>
</cxfse:endpoint>
</beans>

Note that the root tag in Listing 2 is <beans>, which is part of Spring's XML namespace. The
<beans> tag's purpose is to hold the different Java beans (or instances of Java classes) of your
application. You configure your application-specific Java beans inside the <beans> tag. Spring
handles instantiation of Java classes and makes the classes available to the application that needs
to use them. You needn't worry about who will instantiate your Java classes and how the instances
will become available to one another. This all is Spring's headache. You just write the classes and
configure them in Spring.

The <beans> tag in Listing 2 contains the namespace declaration for a http://
servicemix.apache.org/cxfse/1.0 namespace. ServiceMix defines this namespace, the purpose
of which is to specify the behavior of CXFSE according to your application requirements. I'll refer to
this namespace as the cxfse namespace.

Integrating healthcare services, Part 2: Using Apache ServiceMix Page 4 of 17

as a Healthcare Service Bus
ibm.com/developerWorks/ developerWorks®

The cxfse namespace contains tags to specify exactly what you want to use CXFSE for.
Several options are available. You can see from Listing 2 that the root <beans> tag contains an
<endpoint> tag that belongs to the cxfse namespace. The <endpoint> tag is the start or an end of
a communication channel.

To get a full understanding of what an endpoint is, you can refer back to Figure 6 of Part 1, in
which the Prescription application sends a message to the Radiology Department application.
The Prescription application and the Radiology Department application are the endpoints. The
message originates from the Prescription application, goes through various components of the JBI
environment — such as a Binding Component (BC), the Normalized Message Router (NMR), and
an SE — and eventually ends up at the Radiology Department application.

You are configuring the Radiology Department application in Listing 2, so you use an <endpoint>
tag directly inside a <beans> tag. This tells ServiceMix that you are configuring an endpoint.

Endpoints can be of several types. For example, an endpoint can be a chain of interceptors doing
several jobs in a sequence (such as the chain of interceptors that you saw in the Introducing
Apache ServiceMix section). But for the sake of simplicity, I am using a simple Java class (the
RadiologyDepartment class) in this article. An instance of a simple Java class is commonly referred
as a Plain Old Java Object (POJO). The cxfse namespace contains a tag named <pojo>, which
sits inside an <endpoint> tag to specify that this endpoint is just an instance of a simple Java class.

Finally in Listing 2, you can see a <bean> tag, which is part of Spring's namespace and
specifies the bean (instance of a Java class) that will act as the endpoint. The <bean> tag
has an attribute named class, which specifies the fully qualified name of the class (namely,
com.hsb.RadiologyDepartment) whose instance will be the endpoint.

You'll find the Spring XML configuration file shown in Listing 2 as the xbean.xml file in the
sample1\RadiologyService\ folder of the download.

Writing the WSDL file for the radiology application

Listing 3 shows the WSDL interface for the Radiology Department application:

Listing 3. WSDL interface for the Radiology Department application

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<definitions targetNamespace="http://hsb.com/" xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="http://hsb.com/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<types>
<xsd:schema>
<xsd:import namespace="http://hsb.com/"
schemaLocation="Radiology_schema1.xsd"/>
</xsd:schema>
</types>
<message name="performTest">
<part name="parameters" element="tns:performTest"/>
</message>
<message name="performTestResponse">
<part name="parameters" element="tns:performTestResponse"/>
</message>
<portType name="Radiology">

Integrating healthcare services, Part 2: Using Apache ServiceMix Page 5 of 17

as a Healthcare Service Bus
developerWorks® ibm.com/developerWorks/

<operation name="performTest">
<input message="tns:performTest"/>
<output message="tns:performTestResponse"/>
</operation>
</portType>
</definitions>

Listing 4 shows the WSDL binding for the Radiology Department application:

Listing 4. WSDL binding for the Radiology Department application

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<definitions targetNamespace="http://hsb.org/radiology-department"
name="RadiologyService"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="http://hsb.org/radiology-department"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
<import namespace="http://hsb.com/" location="Radiology.wsdl"/>
<binding name="RadiologyDepartmentPortBinding"
type="ns1:Radiology" xmlns:ns1="http://hsb.com/">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http"
style="document"/>
<operation name="performTest">
<soap:operation soapAction=""/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="RadiologyService">
<port name="RadiologyDepartmentPort"
binding="tns:RadiologyDepartmentPortBinding">
<soap:address location="http://localhost:8092/RadiologyService/ "/>
</port>
</service>
</definitions>

You can see that the web service is simple; it just contains an operation named performTest with
a couple of parameters. WSDL interface and binding details are beyond this article's scope. See
Resources for the link to a developerWorks article that explains WSDL in detail.

In the download's sample1\RadiologyService folder, you'll find the WSDL files shown in Listing 3
and Listing 4 as Radiology.wsdl and RadiologyService.wsdl, respectively.

Packaging the Radiology Department application

You now need to package the RadiologyDepartment class and accompanying JAXB classes,
Spring's xbean.xml, and the WSDL files for the Radiology Department application into a .zip file
named RadiologyService.zip. You'll find all these files in the sample1\RadiologyService\ folder of
the download. I have already prepared the .zip file for you; it's in the sample1\ folder.

Configuring and packaging a service consumer

You have packaged your radiology application, which is a service provider. But you can't run this
application unless you have a service consumer configured in a JBI server.

Integrating healthcare services, Part 2: Using Apache ServiceMix Page 6 of 17

as a Healthcare Service Bus
ibm.com/developerWorks/ developerWorks®

Configuring a service consumer in JBI is quite similar to building the provider configuration you just
saw. You need to write the Spring XML configuration and the WSDL file for the consumer endpoint.

The Spring XML configuration for your service consumer is shown in Listing 5:

Listing 5. XML configuration for a service consumer

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:cxfbc="http://servicemix.apache.org/cxfbc/1.0"
xmlns:radiology="http://hsb.org/radiology-department">
<cxfbc:consumer wsdl="classpath:RadiologyService.wsdl"
targetService="radiology:RadiologyService" />
</beans>

You can see that Listing 5 is very similar to Listing 2. Listing 5 uses a cxfbc namespace instead
of the cxfse namespace you see in Listing 2. You use a cxfbc namespace here because the
consumer requires a BC rather than an SE. You can refer back to the six steps accompanying
Figure 6 of Part 1, in which you can see that Prescription application (a service consumer) requires
a BC, and the Radiology Department application (an internal service provider) requires an SE.
ServiceMix provides both SE and BC namespaces for CXF applications, allowing you full flexibility
in configuring your application in the way you want.

The WSDL files for the service consumer are very similar to the WSDL files in Listing 3 and Listing
4. You'll find these consumer configurations in the sample1\PrescriptionService folder in the
download.

You also need to package the Spring's XML configuration and WSDL files for the consumer
into a .zip file named PrescriptionService.zip. I have already done this for you. Look for
PrescriptionService.zip in the download's sample1\ folder.

Assembling the radiology application together with the prescription

application
You have already configured two service units, one for the Radiology Department application
(service provider) and the other for the Prescription application (service consumer). Now you'll
assemble the service units into a JBI service assembly.

To create the service assembly, you just need to write a JBI XML configuration, as shown in Listing
6:

Listing 6. JBI's XML configuration for the Radiology Department application

service assembly
<?xml version="1.0" encoding="UTF-8"?>
<jbi xmlns="http://java.sun.com/xml/ns/jbi" version="1.0">
<service-assembly>
<identification>
<name>radiology-service-assembly</name>
<description>Radiology Department Service Assembly</description>
</identification>
<service-unit>
<identification>
<name>radiology-service</name>

Integrating healthcare services, Part 2: Using Apache ServiceMix Page 7 of 17

as a Healthcare Service Bus
developerWorks® ibm.com/developerWorks/

<description>Radiology Department Service Provider</description>

</identification>
<target>
<artifacts-zip>RadiologyService.zip</artifacts-zip>
<component-name>servicemix-cxf-se</component-name>
</target>
</service-unit>
<service-unit>
<identification>
<name>prescription-service</name>
<description> Prescription Service Consumer</description>
</identification>
<target>
<artifacts-zip>PrescriptionService.zip</artifacts-zip>
<component-name>servicemix-cxf-bc</component-name>
</target>
</service-unit>
</service-assembly>
</jbi>

The root tag in Listing 6, named <jbi>, belongs to the JBI namespace (http://java.sun.com/xml/
ns/jbi). The <jbi> tag contains one child named <service-assembly>, which wraps the name and
description of the JBI service being deployed as well as the various service units in the service
assembly.

The <service-assembly> tag has two <service-unit> child tags. Each <service-unit> child
represents an individual unit of the service. You are configuring only a Radiology Department
application and a Prescription application, so your service assembly contains only two <service-
unit> tags, one for each application.

Each <service-unit> tag wraps the name of the unit, its description, and the ZIP file of the
service unit. You can see that the <artifacts-zip> tag inside each <service-unit> tag contains
the name of a ZIP file; they match the filenames for the two .zip files you created at the end of
the Packaging the Radiology Department application and Configuring and packaging a service
consumer sections. The RadiologyService.zip file is for the Radiology Department application, and
PrescriptionService.zip file is for the Prescription application.

You need to save the configuration in Listing 6 as an XML file named jbi.xml. I have done this for
you, and you can find the file in the download's META-INF\ folder. Finally, package the META-INF\
folder and the two .zip files into RadiologyAssembly.zip. I have prepared RadiologyAssembly.zip
for you; it's in the sample1\ folder of the download.

RadiologyAssembly.zip is the final ZIP file, which contains everything you have done so far.

Tips for developing ServiceMix applications

This article's download includes a Tips.txt file, which provides some useful tips on:

• Enabling the debugging trace for ServiceMix

• Clearing the ServiceMix cache
• Redeploying a ServiceMix component

You don't need these tips to run this article's sample application, but they'll be helpful for
developing your own ServiceMix applications.

Integrating healthcare services, Part 2: Using Apache ServiceMix Page 8 of 17

as a Healthcare Service Bus
ibm.com/developerWorks/ developerWorks®

Testing the Radiology Department service

Perform the following steps to test the Radiology Department application:

1. Download and install Apache ServiceMix 3.3.1 on your computer (see Resources).
2. Start ServiceMix by double-clicking on the servicemix.bat file, which you'll find in the ..
\apache-servicemix-3.3.1\bin folder of your ServiceMix installation. Wait a few moments for
the server to start its services.
3. Copy RadiologyAssembly.zip from the sample1\ folder into the ..\apache-
servicemix-3.3.1\hotdeploy folder of your ServiceMix installation. As soon as you copy the .zip
file, ServiceMix will detect that a new application is being deployed. It will start the deployment
process, which you'll see on the output console of ServiceMix. Wait for the deployment to
complete.

ServiceMix provides a simple browser-based SOAP client that you can use to test your ServiceMix
applications. This client accompanies several sample applications that come bundled with
ServiceMix. You can find it in the form of the client.html file in the ServiceMix installation's ..
\apache-servicemix-3.3.1\examples\cxf-wsdl-first folder.

Open the client.html file in your browser and type http://localhost:8092/RadiologyService in the
Target field of the HTML page. Then type the SOAP request shown in Listing 7 into the text box
just below the Target field:

Listing 7. Request SOAP message to test your radiology application

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:hsb="http://hsb.com/">
<soapenv:Header/>
<soapenv:Body>
<hsb:performTest>
<arg0>Test1</arg0>
<arg1>Test2</arg1>
</hsb:performTest>
</soapenv:Body>
</soapenv:Envelope>

I have provided this SOAP request message as SOAPRequest.txt file in the download. You can
copy the SOAP request from the SOAPRequest.txt file and paste into the text box below the Target
field. After you enter the address and the SOAP request, the client.html page will look like Figure
1:

Integrating healthcare services, Part 2: Using Apache ServiceMix Page 9 of 17

as a Healthcare Service Bus
developerWorks® ibm.com/developerWorks/

Figure 1. The client.html page

Now click the Send button at the bottom of the page and wait for a few moments. The service
consumer of the Radiology Department application receives the request, routes it to the NMR, and
then through CXFSE engine to the RadiologyDepartment class. The RadiologyDepartment class
then responds. The response travels all the way through back to the SOAP client. You can see the
response in its text box opposite the request text box, as shown in Figure 2:

Integrating healthcare services, Part 2: Using Apache ServiceMix Page 10 of 17

as a Healthcare Service Bus
ibm.com/developerWorks/ developerWorks®

Figure 2. Response shown in your SOAP client

Interconnecting JBI servers

You have seen how you can configure the Radiology Department application as an internal service
provider and invoke it from an external service consumer. Now I will demonstrate how you can
configure two JBI servers so that a service consumer connected to one JBI server can invoke the
services offered by a service provider connected to another JBI server. This situation is similar to
Figure 7 from Part 1, where I discuss the interconnection of JBI servers.

Compare Figures 4 and 7 from Part 1. Figure 4 shows a service consumer and an external service
provider connected to one JBI server. Figure 7 shows a service consumer connected to one JBI
and the provider connected to another JBI server, while the two JBI servers are interconnected to
each other.

From JBI's point of view, the two situations are the same. If a service is external to a JBI
environment, it doesn't matter whether the external service is directly connected to the JBI server
or it is connected indirectly through another JBI server. This means the JBI configuration that you
do according to Figure 7 of Part 1 will also work fine in case you want to connect your healthcare
providers according to Figure 4 of Part 1. So I'll show only the scenario of Figure 7 in this article
and leave the scenario of Figure 4 to you.

In this section, you need two JBI servers. The first server has a service consumer and an external
service provider. The second JBI server has an internal service provider. This is shown in Figure 3:

Integrating healthcare services, Part 2: Using Apache ServiceMix Page 11 of 17

as a Healthcare Service Bus
developerWorks® ibm.com/developerWorks/

Figure 3. Two JBI servers, one with an external service consumer and another
with an internal service provider

The first JBI server will think that the second JBI server is the external service. The second JBI
server will think that the first JBI server is a service consumer.

This means you can simply use the configuration of the Radiology Department application as the
second JBI server. All you need to do is to configure an external service provider and a consumer
in the first JBI server.

Configuring an external service provider simply means telling the first JBI server that the second
is a web service. You need to do just two things: write a Spring XML configuration file similar to
Listings 2 and 5, and WSDL files similar to Listing 3 and 4.

Configuring an external service provider for the first JBI server

Listing 8 contains the Spring configuration for an external service provider:

Listing 8. Spring configuration for an external service provider

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:cxfbc="http://servicemix.apache.org/cxfbc/1.0"
xmlns:radiology="http://hsb.org/radiology-department">
<cxfbc:provider
service="radiology:RadiologyService"
endpoint="RadiologyService"
locationURI="http://192.168.10.33:8092/RadiologyService/"
wsdl="classpath:RadiologyService.wsdl" />
</beans>

You can see that the <beans> tag in Listing 8 contains the same cxfbc namespace declaration
that you saw in Listing 5. That's because here in Listing 8, you are configuring an external service
provider, whereas in Listing 5 you configured an external service consumer. Whenever you
are configuring an external application (whether a provider of a consumer), you use the cxfbc
namespace.

Also notice that Listing 8 contains a <provider> tag from the cxfbc namespace (just like the
<consumer> tag of Listing 5). The <provider> tag has various attributes that specify details of the
external service:

• service: Name of the radiology service provider that is hosted on the second JBI server.
• endpoint: WSDL port of the Radiology Department application that is listening for service
requests.

Integrating healthcare services, Part 2: Using Apache ServiceMix Page 12 of 17

as a Healthcare Service Bus
ibm.com/developerWorks/ developerWorks®

• locationURI: Network address of the Radiology Department service. This network address
exists on the second JBI server. When I tried this application, my second JBI server was
running on a machine whose network address was 192.168.10.33 and the port of second JBI
server was 8092.
• wsdl: Name and location of the WSDL file. ServiceMix resolves the classpath to the root of
the ZIP file for a service. You can see from this article's download that the WSDL exists in the
sampl2\JBI1\RemoteRadiologyService folder. The contents of the RemoteRadiologyService
folder form the root of the ZIP file for this application. Therefore, I have simply written
classpath:RadiologyService.wsdl as the value of the wsdl attribute.

The WSDL file for this provider service is the same as the WSDL files shown in Listing 3 and
4. You'll find Listing 8 as xbean.xml and its accompanying WSDL as RadiologyService.wsdl in
the sample2\JBI1\RemoteRadiologyService folder of the download. You need to package all the
contents of the RemoteRadiologyService folder in a .zip file named RemoteRadiologyService.zip. I
have already prepared the .zip file for you; you'll find it in the sample2\JBI1 folder.

Configuring a service consumer for the first JBI server

Configuration for a service consumer for the first JBI server is exactly the same as the
configuration you did in Listing 5, so I won't repeat the listing here. You'll find this consumer
configuration as the xbean.xml file in the sample2\JBI1\PrescriptionService folder.

You also need a WSDL file that accompanies the consumer configuration. It is very similar to the
WSDL file in Listing 3. You'll find the WSDL file in the sample2\JBI1\PrescriptionService folder. I
have also packaged the contents of the PrescriptionService folder into PrescriptionService.zip.

Assembling the provider and consumer for the first JBI server
The two .zip files for the first JBI server are ready. The last step is to assemble the .zip files into a
service assembly. The JBI configuration file for the complete assembly is shown in Listing 9:

Listing 9. JBI configuration for the complete assembly of the first JBI server
<?xml version="1.0" encoding="UTF-8"?>
<jbi xmlns="http://java.sun.com/xml/ns/jbi" version="1.0">
<service-assembly>
<identification>
<name>remote-radiology-service-assembly</name>
<description>Radiology Department Service Assembly</description>
</identification>
<service-unit>
<identification>

<name>remote-radiology-service</name>
<description>Radiology Department Service Provider</description>
</identification>
<target>
<artifacts-zip>RemoteRadiologyService.zip</artifacts-zip>
<component-name>servicemix-cxf-bc</component-name>
</target>
</service-unit>
<service-unit>
<identification>

Integrating healthcare services, Part 2: Using Apache ServiceMix Page 13 of 17

as a Healthcare Service Bus
developerWorks® ibm.com/developerWorks/

<name>remote-prescription-service</name>
<description>Prescription Service Consumer</description>
</identification>
<target>
<artifacts-zip>PrescriptionService.zip</artifacts-zip>
<component-name>servicemix-cxf-bc</component-name>
</target>
</service-unit>
</service-assembly>
</jbi>

You can see that the JBI assembly file of Listing 9 is very similar to Listing 6. You'll find this JBI
configuration in Listing 9 as jbi.xml in the sample2\JBI1\META-INF folder of the download.

Finally, you need to package jbi.xml along with RemoteRadiologyService.zip and

PrescriptionService.zip files into another .zip file called RemoteRadiologyAssembly.zip. I have
prepared this file for you; you'll find it in the sample2\JBI1 folder.

Testing the interconnection of JBI servers

In order to test the interconnection of JBI servers, you'll run the same RadiologyAssembly
application that you saw in the Testing the Radiology Department service section. This will act as
your second JBI server.

When I tried this JBI interconnection, my second JBI server was running on a machine whose local
network address was 192.168.10.33. As you can guess, the provider of the first JBI server should
know the network address of the second JBI server. Therefore, this network address occurs at two
places in your configuration files for the provider of the first JBI server:

• The locationURI attribute in the xbean.xml file

• The address attribute of the <soap> tag in the RadiologyService.wsdl file

If you are running the second JBI server from a different address, you must make the appropriate
changes in these two places.

To run the first JBI server, perform these steps:

1. Install Apache ServiceMix 3.3.1 on a separate machine. I tried the interconnection of JBI
servers using two machines, one for the first JBI server and the other for the second JBI
server.
2. Start ServiceMix by double-clicking on the servicemix.bat file in the ..\apache-
servicemix-3.3.1\bin folder of your ServiceMix installation. Wait a few moments for the server
to start its services.
3. Copy RemoteRadiologyAssembly.zip from the sample2\JBI1 folder into the ..\apache-
servicemix-3.3.1\hotdeploy folder of your ServiceMix installation. As soon as you copy the
file, ServiceMix will detect that a new application is being deployed and start the deployment
process, which you'll see on the output console of ServiceMix. Wait for the deployment to
complete.
4. Open the same client.html file that you used earlier while testing the Radiology Department
application in your browser. Type http://localhost:8092/RadiologyService in the Target

Integrating healthcare services, Part 2: Using Apache ServiceMix Page 14 of 17

as a Healthcare Service Bus
ibm.com/developerWorks/ developerWorks®

field of the HTML page. Then type the same SOAP request from Listing 7 into the text box
below the Target field.
5. Click the Send button and wait for a few moments. The request will go to the first JBI server,
travel through its consumer BC, NMR, provider BC, and then to the second JBI server. The
consumer BC in the second JBI server will receive the request, route it through the NMR,
then to CXFSE, and eventually to the RadiologyDepartment class, which will respond. The
response will travel all the way through the two JBI servers back to your browser, which will
display the response in its text box opposite the request text box.

Integrating industry-specific standards into ServiceMix

You have seen how to integrate a variety of services into ServiceMix. The service I used as
an example in this article (the Radiology Department application service) is based on WSDL.
However, as I explained in the XML for interoperable healthcare section of Part 1, not all services
are based on WSDL. They can also be based on industry-specific standards such as HL7.
Whenever you want to integrate a service into JBI, you need a JBI component, whether the service
is WSDL-based or industry-specific.

As a general standard commonly used for defining service interfaces, WSDL can be used across
all industries. This is why you'll find many implementations based on WSDL that can be integrated
into ServiceMix, and why ServiceMix comes bundled with Apache CXF. This is not the case
with HL7. Support for HL7 is not available in ServiceMix at the time of this writing, although the
ServiceMix web site has announced that the project will integrate HL7 support into ServiceMix
sometime in the future.

You are likely to encounter the problem of integrating industry-specific standards into ServiceMix.
So here I will outline a high-level plan for building your own components that can work within
ServiceMix.

Whenever you are integrating a component into ServiceMix, you need to control the way it
responds to service requests from consumers. ServiceMix has defined interfaces that allow you to
control the behavior of an industry-specific JBI component exactly the way you want:

ServiceMix flexibility
ServiceMix provides several interfaces that you can use to implement your own components'
functionality:

• Component
• ComponentContext
• ComponentLifeCycle
• ServiceUnitManager
• InstallationContext
• Bootstrap

See Resources for a link to the official ServiceMix documentation, where you'll find details of
these interfaces.

• You can control what your component will do when it is installed. For example, you can create
database tables during installation so that the component can store application data.

Integrating healthcare services, Part 2: Using Apache ServiceMix Page 15 of 17

as a Healthcare Service Bus
developerWorks® ibm.com/developerWorks/

• Similarly, ServiceMix allows you to write the uninstallation code that undoes or cleans up the
things that your component did during installation.
• You can implement methods of ServiceMix interfaces to control the starting and stopping
of a component. Starting a component means the component becomes ready to receive
messages; stopping means the opposite.
• A ServiceMix interface enables your component to learn and interact with its environment
(that is, the JBI environment). For example, you can write code that tells which
communication objects will be used to exchange messages with your component via the
NMR.

Perhaps the most efficient strategy for integrating HL7 support into ServiceMix is to use an open
source HL7 implementation as your starting point. One such product, called HAPI (HL7 Application
Programming Interface), is already available (see Resources). You can design a lightweight
wrapper for HAPI and implement the ServiceMix interfaces in your wrapper.

Integrating healthcare services, Part 2: Using Apache ServiceMix Page 16 of 17

as a Healthcare Service Bus
ibm.com/developerWorks/ developerWorks®

Downloadable resources
Description Name Size
Sample code for this article j-hsb2.zip 232KB

© Copyright IBM Corporation 2010

(www.ibm.com/legal/copytrade.shtml)
Trademarks
(www.ibm.com/developerworks/ibm/trademarks/)

Integrating healthcare services, Part 2: Using Apache ServiceMix Page 17 of 17

as a Healthcare Service Bus