The TroubleTicket application beeing exposed as a web service, it is automatically connected to the JBI bus (NMR) thanks to the JavaEE SE. So, the service provider is in place, the first prototype can now be realized. It simply consists in connecting the two partners to the bus to have a base for enhancing this SOA system or composite application. As a result of this first stage, the web service client will not access the TroubleTicket service directly from its endpoint, but will request the service through the JBI environment.
The second part of this work is to connect the client to the bus. Here I implement a web service client, communicating through XML SOAP messages over HTTP. This client is similar to the one realized for testing alone the created web service, with the difference that it invokes another URL: the real service implementation is now unknown from it, it only see the TroubleTicket service offered by the orchestration module, which plays the role of an intermediary between consumer and provider: so, the service provider is fully transparent for the client.
This composite application involves three JBI modules:
- The HTTP/SOAP BC: acting as a connector module for the web service client to access the bus;
- The BPEL SE: managing the business process, it is in charge of the service providing;
- The JavaEE SE, acting as a bridge between the JBI bus and the application server, connecting the TroubleTicket service to the composite application environment. This module does not need to be packaged in the final JBI application accessing the TT web service it offers. The JavaEE SE is part of Sun Application Server. It is automatically plugged in the JBI bus (NMR) local instance.
Service Engines are the core a JBI composite application. Needed Binding Components just need to be started in the JBI environment. They will be automatically instanciated at deployment depending on the partners you have defined in your business process. So main step here is to developp the BPEL module. After that, the JBI application can be build and deployed, before beeing tested.
This composite application remains very basic, but it is not only a base for the road to OSS/J SOA, but it also well illustrates a SOA advantage: integration decoupling. In others words, it shows how two partners can communicate without knowing each other, and even without interact through the same protocol ! Moreover, SOA also enables to manage business processes. Each process is defined separately from the actors of the interactions building this process. Whereas classical point-to-point architectures have no global view of a process realizing a given function, SOA provides a way to globally manage the processes.