Build an SOA application from exisiting services

Put heterogeneous services together with the Petals ESB

1 2 Page 2
Page 2 of 2

When the service unit deploys, the SOAP BC activates in the JBI environment the MyAirlineCompanyEndpoint service endpoint. When a JBI component sends a message to this service endpoint, the SOAP BC transfers it to the external http://myairline.com/flightBookingService Web service, that is, the airline booking Web service.

Hotel JMS service unit

The hotel JMS service unit looks like the airline service unit. The JMS BC provides a MyHotelEndpoint service endpoint that maps to JMS message exchanges with the hotel JMS server.

XSLT service unit

The XSLT engine is used for three transformations:

  • The initial XML from the Website to the flight-request XML
  • The initial XML to the hotel-request XML
  • The flight-and-hotel-response XML to the email XML

So three service units must be provided, each one containing an XSL stylesheet for the correct transformation. The XSLT engine will provide three services through three service endpoints.

Airline and hotel connections

As seen before, we can use connections to independently link the application workflow engine to the airline and hotel services, and dynamically reconfigure this link by deploying a new service assembly.

For instance, the connection to the My Low Cost Airline Company looks like this:

<jbi version="1.0" xmlns…>
  <service-assembly>
  ... 
    <connections>
      <connection>
        <consumer service-name  ="AirLineService"
                  endpoint-name ="AirLineServiceEndpoint"/>
        <provider service-name  ="MyLowCostAirLineCompany"
                  endpoint-name ="MyLowCostAirLineCompanyEndpoint"/>
      </connection>
    </connections>
  </service-assembly>
</jbi>

This code shows that when a service consumer (the application workflow engine) consumes the AirlineService service, the MyLowCostAirLine service is really consumed.

The global service assembly

All of these service units are packaged in one service assembly. The service assembly's descriptor file contains the connections.

Figure 8. The application service assembly. Click on thumbnail to view full-sized image.

This service assembly is deployed in the Petals JBI container, and all the service units are delivered to their components.

Figure 9. Deploy the application service assembly. Click on thumbnail to view full-sized image.

The components register their related service endpoints, the container sets the connections, and the application is now ready to run.

Figure 10. The configured container. Click on thumbnail to view full-sized image.

Conclusion

The JBI specification leverages the best concepts of SOA and standardizes an approach for composing applications from existing services. JBI basically standardizes the ESB concept.

Building an SOA application with the Petals JBI container is quite simple: use some standard JBI binding or engine components, write a few XML descriptions to explain how to connect to your services, and deploy them in the Petals JBI container.

With such a container, the challenge becomes writing or using relevant services with good granularity, not assembling them.

Adrien Louis works as chief architect at EBM WebSourcing, and has six years of experience working with Java EE technologies. Currently, he is working on enterprise integration solution problems. Louis is the project manager of the Petals open source project. The goal of the Petals project is to provide a distributed JBI container packaged in various integration solutions like B2B integration or business-process-based integration.

Learn more about this topic

1 2 Page 2
Page 2 of 2