Integrating healthcare services, Part 2: Using Apache ServiceMix as a Healthcare Service Bus

Interconnect multiple JBI servers hosting healthcare applications

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 | PDF (413 KB) | 1

Comment

(xml4java@yahoo.co.uk), Consultant

08 June 2010

Also available in Chinese Russian Japanese Portuguese

IBM Bluemix. IBM's go-to-cloud platform. Join the beta.

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 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:

An interceptor receives a service request from a service consumer and transforms the request to another format.
Another interceptor creates Java objects from the request.
The third interceptor invokes the business logic and passes Java objects along with the invocation call.
Another one or few interceptors can contain the actual business logic.
The fifth interceptor fetches new Java objects from the business-logic application.
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:

Write and compile the Java class containing the business logic for the Radiology Department application, and expose the class as a web service.
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.
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.
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.)
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 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, theperformTest() 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.

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 (theRadiologyDepartment class) in this article. An instance of a simple Java class is commonly referred as a Plain Old Java Object (POJO). Thecxfse 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">
    <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.

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 accompanyingFigure 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>
        <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 thePackaging 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'sMETA-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.

Testing the Radiology Department service

Perform the following steps to test the Radiology Department application:

Download and install Apache ServiceMix 3.3.1 on your computer (see Resources).
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.
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:

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 RadiologyDepartmentclass 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:

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 7shows 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:

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 inListing 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.
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 thewsdl 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>
        <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:

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.
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.
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.
Open the same client.html file that you used earlier while testing the Radiology Department application in your browser. Typehttp://localhost:8092/RadiologyService in the Target field of the HTML page. Then type the same SOAP request from Listing 7 into the text box below the Target field.
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:

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.
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.

Автоматизированные Банковские Системы

четверг, 18 сентября 2014 г.