2 Replies Latest reply on Aug 14, 2006 3:41 PM by Nicholas Capito

    Native Java Code (POJO) Invocation

    Nicholas Capito Newbie

      Is there support for invoking plain old java code vs. WebService calls? I have wsdl's designed for my java classes, but i don't want the overhead of webservice calls....?

        • 1. Re: Native Java Code (POJO) Invocation
          Alejandro Guizar Master

          Support for this feature is the goal of BPEL-135: pluggable invocation framework.

          I have reviewed Apache WSIF more than once and have concluded that, while the interfaces are compatible with the current invocation model, the implementations are not. They assume the use of Java beans at the client side, while the BPEL engine mantains variables which all are basically DOM elements. Incorporating WSIF itself is a rather straightforward task. Rewriting the WSIF providers to deal with DOM elements is not.

          Web services are moving from an RPC to a document-oriented approach. In the document world, endpoints either:
          a) process the XML document directly, or
          b) use the default XML-to-Object mapping with as few customizations as possible. Ideally, no customizations at all. You want to keep the gap between the document and the object model as narrow as possible.

          Isn't the "overhead" of webservice calls mostly associated to XML-to-Java mapping? Considering a BPEL endpoint is document-oriented in that it mantains and manipulates variables of XML types exclusively, the *real* overhead is in calling plain Java code, since they are *not* oriented to documents.

          In order to do a good job of reducing overhead here, the BPEL engine would have to mantain variables of Java types. This is not a technical issue. The BPEL engine itself already mantains a number of Java objects in the jBPM variable space such as partner link and correlation set instances, among others. The real issues are:

          Non-XML variables are out of the scope of the BPEL specification.
          The jBPM project has a clear mindset of "one process language for each purpose", where purpose is one of workflow, orchestration, pageflow, etc. as opposed to "the ultimate all-purpose process language". The language you are looking for invoking your POJOs might be jPDL, not BPEL
          I'd be really interested in knowing your thoughts here.

          • 2. Re: Native Java Code (POJO) Invocation
            Nicholas Capito Newbie

            I actually agree with everything you have said. Ironically i started of with JPDL, saw the Bpel Extension and liked the functionality so i converted. But i then found myself in a non distributed environment so i was wondering if really i should be using webservices at all....

            But idealy, my personal thoughts, I would like to have some "process services," types of utlities to mesh together the returns from other webservices and actual webservices as well. My beliefs could just be an over emphisis on the complexity/NetworkIO/etc... and quite honestly I hadn't really thought of the XML-to-Java mapping overhead on making local java calls...

            It seems that JPDL is powerful because of its interaction with java, and BPEL for its integration of Web Services.... I guess the problem is that you might want to mesh the two together without having to change process languages..... it seems like there is no real in between.

            Think of this situation....

            Which would perform better:
            A standalone system with just standard java calls,
            A standalone system using bpel with java calls being converted to local WS (endpoints) calls?

            Assuming that the BPEL is fully portable(of course with minor invoke changes) from JPDL to the extension the above situation should be an easy port.... I am going to do some testing with it so I will let you know what i find out....

            Has there been any performance comparison between JPDL and the BPEL Extension?

            I will put a little more thought into it and get back to you.