The Source for Java Technology Collaboration
User: Password:



 Binod

Binod's Blog

Java EE Service Engine: Bridging Java EE and JBI

Posted by binod on July 10, 2006 at 02:20 AM | Comments (10)

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.

javaeese.png

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.

javaeese-app.png

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.

Step-1

Develop a SLSB called StockWS. Annotate it with @Webservice to make it a JSR 109 webservice. See the code snippet below.

slsb-ws.png

Deploy the service to the application server (Project GlassFish).

Step-2

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.

bpel-wsdl.png

Step-3>

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.

Step-4
Write the MDB. Import the WSDL of the BPEL application to the MDB as webservice client. The MDB snippet below explains everything.

mdb-code.png

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

mdb-dd.png

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.


Bookmark blog post: del.icio.us del.icio.us Digg Digg DZone DZone Furl Furl Reddit Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment

  • According to the DTD for sun-ejb-jar.xml for EJB 3, the stub property should be defined as

    ...
    < stub-property >
    < name > jbi-enabled < /name >
    < value > true < /value >
    < /stub-property >
    ...


    Am I correct? Ludo asked me to put this property into the pre-defined property list for this field and make the property name field editable so you can add custom properties in the GUI.

    Posted by: peterwx on August 03, 2006 at 04:49 PM

  • Very good article and it really shows the Power of Java EE service engine!

    Posted by: ss144236 on September 20, 2006 at 01:59 AM

  • Great article indeed but there is something I don't get. What's the point to annotate to session bean and make it a web service ? If it's deployed in the JEE SE, whether it is as an EJB or a web service is transparent for other jbi components, isn't it ? The only reason I see is that these annotations avoid you to write the WSDL manually.

    Btw, aren't the annotations part of the JSR 181 and not JSR 109 ?

    Posted by: mvbv on September 20, 2006 at 08:48 AM

  • Yes, how the webservice is created is transparent for JBI components. The blog shows one example, where an EJB exposed as a webservice is accessed from JBI using Java EE Service Engine.

    Posted by: binod on September 20, 2006 at 09:41 AM

  • Excellent article with actual code implementation. Java EE is really simple and powerful.

    Posted by: ramagopal on October 02, 2006 at 02:20 PM

  • All code references I haver seen always go through the BPEL engine, but what if there is no requirement to go to BPEL? What if I need to go directly from MDB to the SLSB? how would the code look like? Instead of referencing the BPEL service I only have to reference the SLSB? I know maybe this seems pointless but what if there is some logic encapsulated in a Java EE app (EJB maybe) that is faster than BPEL and even may determine if there is a need to go to a BPEL.

    Posted by: hj2633 on October 31, 2006 at 09:49 AM

  • Very good example. I have one negative comment though:
    as I understand, this particular example is not portable because it uses GlassFish Java EE service engine to
    1) expose StockWS as a JBI end point.
    2) enable StockProcessListenerMDB to send message to JBI end point representing the BPEL service.
    What if I change my application server to something else?

    Posted by: ss141213 on December 28, 2006 at 08:58 AM

  • Internal access to web or EJB container is undefined by Java EE specifications. So, it is hard to write a portable and performant Java EE Service Engine. However any Java EE appserver can write their own Java EE Service Engine and expose their Java EE containers.

    On the other hand, any JBI implementation that can run on top of appserver can use the Java EE Service Engine. i.e Java EE Service Engine is portable across JBI implementations.

    Until Java EE application servers expose their Java EE containers as JBI components, you can always route the JBI messages using HTTP/SOAP BC. It will incur the cost of a network overhead. Note that Java EE Service Engine hasnt introduced any new APIs/artifacts or packaging mechanism. It uses JAXWS almost everywhere. So, you can overcome the portability of your application to a great extend.

    Posted by: binod on January 01, 2007 at 08:01 PM

  • Hi, I hope you don't mind me asking a couple "newbie" questions. I'm trying to implement a BPEL module (deployed in GlassFish) that is very similar to the first part of this example application, i.e. a client placing a message on a queue that invokes a BPEL process. In my case I'm dealing with a remote ActiveMQ queue that the client places messages on. Is there a JBI component for Active MQ? What is the best approach for communicating with ActiveMQ? Are there alternatives to writing MDBs to initiate a BPEL process?

    Posted by: rbiresch on February 16, 2007 at 12:40 PM

  • good,thank you

    Posted by: jljf_hh on April 22, 2008 at 07:50 PM



Only logged in users may post comments. Login Here.


Powered by
Movable Type 3.01D
 Feed java.net RSS Feeds