1 Reply Latest reply on Mar 24, 2007 7:29 PM by aguizar

    added a bit more bpel process structure ideas

    tom.baeyens

      hi,

      i just added a bit more indication of how i would model a bpel process (only the top level structure) in sync with the pvm:

      a bpel process inherits from pvm Process. the scope attributes and collections are stored in an aggregated scope member field. Both the pvm process initial node member field and the scope activity field, point to the same node, which represents the top level activity for the bpel process.

      a bpel lexecution inherits from pvm Execution.

        • 1. Re: added a bit more bpel process structure ideas
          aguizar

           

          a bpel process inherits from pvm Process. the scope attributes and collections are stored in an aggregated scope member field. Both the pvm process initial node member field and the scope activity field, point to the same node, which represents the top level activity for the bpel process.

          This is a nice design and actually matches what exists in jbpm bpel 1.1.x. The process has a single child of type Scope which takes variables, partner links, correlation sets, fault handlers and event handlers at the process level.

          Apart from the global scope, the BpelProcess itself contains the targetNamespace, the default expression and query languages and a collection of imported documents. Neither of these properties belong to a scope.

          a bpel lexecution inherits from pvm Execution.

          Is this really needed? I found out that a subclass of Execution (Token in jbpm 3.x) was neither needed nor desirable. If you do introduce a subclass, then you have to downcast everywhere, which turns out to be quite annoying.