1 Reply Latest reply on Jun 10, 2006 5:27 PM by aguizar

    Webservice in front of the BPEL process realized by a sessio

    zauberlehrling

      Hello everyone,

      I've some questions concerning the "Hello World Example" included in the
      BPEL extension.

      In this example we have one webservice , which is realized by the
      web archive "hello-web.war". This webservice is the frontend to the
      bpel process "hello.bpel". By calling the webservice at

      http://localhost:8080/hello/caller

      you can start the bpel process. There is a queue involved in the communication
      between the webservice and the BPEL engine. My questions are:

      1) Is it possible to replace hello-web.war by a session bean which realizes a webservice.

      2) If yes, how to establish the communication between the session bean and
      the BPEL engine? Is there an example or a description how to do this?

      3) What are the reasons for the queue ? Is it possible to have a webservice in front
      of the BPEL engine without a queue?

      Many thanks in advance

      Frank

        • 1. Re: Webservice in front of the BPEL process realized by a se
          aguizar

          Frank,

          The WSEE server programming model allows handlers on Java as well as EJB endpoints, so this is just a matter of including the handler in your session bean configuration.
          Once you install the handler, it will do the rest for you. I do not provide an example of this because I do not see much value here. You are not supposed to write the EJB method bodies anyway. The only good use that comes to mind is declarative transaction demarcation. Is that what you are looking for?

          For information on EJB endpoints, refer to the JBossWS wiki.
          jBPM BPEL depends on JMS to control the delivery of incoming requests to the process. There are three requirements to message delivery:

          The process instance arrives at an inbound message activity, but the corresponding message has not arrived yet. The activity must wait for it.
          BPEL effectively makes a web service stateful. The runtime must deliver incoming messages to the right service instance (read: process instance). Upon enactment, an inbound message activity specifies the correlation properties an incoming message must match for the activity to accept it.
          A message arrives but no activity is waiting for it. The BPEL runtime must store it until an activity becomes available.
          JMS fits the previous requirements remarkably well:

          The inbound message activity sets up a listener on the queue. JMS delivers the message asynchronously when it comes.
          The activity sets a message selector which specifies the properties of the desired message
          The endpoint handler puts the message in the queue and lets JMS take care of it.
          In sum, it is not possible to have a service without queue.