Java EE Service Engine: Bridging Java EE and JBI
In a typical Java EE application, MDBs are used to listen to messages from the external systems and act as integration point between two systems. Wouldnt it be good, if that MDB become part of a composite application and thus leverage full capability of JBI also? The example composite application below explains how a BPEL app is accessed from MDB. To keep the things simple (unfortunately composite applications are not simple...) the BPEL sample accesses only a Java EE webservice (SLSB). BPEL is extremely powerful and to know how more about that, read Gopalan's blogs.
Ok, enough of theory, lets get into some action. Below is the architecture diagram of an example application.
As explained in the diagram, the client application sends a message to the Queue which is picked up by the MDB. Upon receiving that message, by using the Java EE Service Engine, the MDB contacts the JBI NMR for the service endpoint exposed by the BPEL process. When MDB executes the BPEL application (hosted by BPEL service engine) BPEL app will contact JBI NMR for finding its partner services. In our BPEL example, there is only one partner service and it is a stateless session bean (JSR 109 webservice) hosted in the same appserver JVM. The JSR 109 webservice's endpoint is enabled in JBI NMR by Java EE Service Engine when the stateless session bean gets deployed. This SLSB uses new Java EE persistence apis to access the database.
In fact, Java EE SDK and Netbeans Enterprise Pack hides many complexities from the developer. Thus a developer's view of the composite application is much simple and as given below. I just hid engines and NMR and made a simpler diagram.
As explained in the diagram above, the MDB just uses JAXWS client apis to access the BPEL process. The BPEL process then invokes the Java EE webservice. The SLSB(Java EE webservice) uses persistence API to access the database. So, a developer just need to code the MDB, the stateless session bean and persistence code and design a BPEL process using these in the BPEL designer.
Now, lets see some real code. To focus on our topic, I am just concentrating on the plumbing part.
Develop a SLSB called StockWS. Annotate it with @Webservice to make it a JSR 109 webservice. See the code snippet below.
Deploy the service to the application server (Project GlassFish).
Use BPEL designer to design a BPEL app. I am not explaining how exactly this needs to be done. Take a look at this article (its a bit too long) or read gopalan for details.
Basically, you need to import the WSDL of the SLSB webservice to the BPEL application and design the BPEL process using the BPEL designer in the netbeans enterprise pack. At the end of everything, the BPEL app will expose a service as shown below in the WSDL snippet.
Create a composite application project, add the BPEL app to the composite application project and deploy it. These are few clicks in the netbeans enterprise pack.
Write the MDB. Import the WSDL of the BPEL application to the MDB as webservice client. The MDB snippet below explains everything.
The last part of the story. Normally, the above JAXWS code in MDB will try to access a service using HTTP transport. Here we want the MDB to access the BPEL app in the same JVM. So, tweak the mdb deployment descriptor to route it to JBI.
Ok, you are still reading. Let's come to the point. How does Java EE Service Engine work?
Java EE Service Engine is the glue code that is part of Sun Java System Application Server. One end of the service engine exposes JBI based contracts and is deployed into JBI runtime. The other end interact with appserver's containers, especially the webservices runtime. When the JAXWS client code executes, using a private SPI, it snatches the soap message from the JAXWS client runtime and normalizes and sends it to JBI NMR. Similarly, when the JBI NMR invokes Java EE Service Engine with an incoming JBI request, Java EE Service Engine will pass the soap message to JAXWS server runtime and get the jsr 109 webservice (slsb) invoked. With the new re-architectured JAXWS runtime (Project Tango) we should be able to change all these into a more pluggable architecture.