RE: [wsbpel] Issue - 2- requirements for a sub function solution

["Trickovic, Ivana" <ivana.trickovic@sap.com>]

Frank,

The initial wording of this issue defines subprocesses as outsourced pieces of BPEL codes that can be reused within a process or across multiple processes. In addition, we may consider that these outsourced pieces can be defined locally within a single bpel process and reused only within that process, or defined as a top-level bpel process and reused across multiple bpel processes. Subprocesses should be executed in the context in which they are defined and not in the context where the calling action is defined/executed. Therefore, subprocesses must also have input/output parameters in order to "pass" some information between the context in which the calling action is executed (the current context) and the subprocess. So, subprocesses certainly combine properties of bpel scopes and bpel processes. 

Taking all that into account one conclusion could be that a sub-process could be easily modeled as another bpel process with a triggering action referencing either a request-response or one-way wsdl operation. However, this would make sense only for sub-processes defined outside the calling process. But, as you emphasized, Web services are loosely coupled and I my view this is exactly the problem. Sub-processes are, by definition, tightly coupled with calling processes. By tightly coupling I mean:
(1) if calling process is terminated the sub-process must be terminated as well (at least in case of synchronous call)
(2) if sub-process fails and cannot recover from the failure, the fault must be propagated to the calling process
(3) the calling process should be able to call the compensation activity of the sub-process 

I am open to your and Satish's suggestions that we should try to keep the BPEL model simple and "stay in the realm of Web services". However, I do not believe that a "notion of "subprocesses" at the policy level enriching service definitions" could alone resolve the problem. I am wondering where requirements #1 and #3 will be specified. Shouldn't they be part of the BPEL process model? 

Kind regards,

Ivana

> -----Original Message-----
> From: Frank Leymann [mailto:LEY1@de.ibm.com]
> Sent: Freitag, 31. Oktober 2003 11:35
> To: wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue - 2- requirements for a sub function
> solution
> 
> 
> 
> We have to define very crisp what a "subprocess" is.  We are 
> all aware that
> there are many variants of this term.  The spectrum reaches from
> 
> - a granule of reuse for (BPEL) modellers
> 
> over
> 
> - a BPEL-snippet at the next lower level within a hierachy of 
> BPEL-snippets
> tightly coupled to its "including" snippet at runtime
> 
> to
> 
> - an entity that shows some BPEL-like processing behavior and that is
> loosely coupled to a BPEL process
> 
> Listing and defining these variants is an endeavor in itself as we all
> know.
> 
> BPEL is a language for specifying business processes in the 
> Web service
> space. I guess, it is important to emphasize this. It is 
> important because
> Web services are typically loosely coupled. One important 
> aspect of this
> "loose coupling" is dynamics in the sense of being able to decide for
> different service providers (on a per process instance base, 
> e.g.).  One
> service provider can be used instead of another as long both 
> satisfy the
> requirements of the requestor.  In BPEL today, these requirements are
> formulated in terms of WSDL interfaces.  What we are 
> discussing in the mail
> exchange on this subject is that "a service" that act as a 
> subprocess must
> satisfy additional requirements like, for example, being infected by
> transactional context of the invoker, being dependent on the 
> requestor in
> terms of termination etc etc. These kinds of additional 
> requirements is
> what "policies" are intended for.  Thus, I recommend to 
> define our notion
> of "subprocess" at the policy level enriching service definitions.
> 
> In doing so, we will clearly stay in the realm of Web services.
> Especially, we will comply with the "composability" 
> directions the various
> standard proposals took by relying on other general purpose proposals.
> 
> Regards,
> Frank
> 
> 
> 
> 
> 
> 
> 
> To:    "'Ron Ten-Hove'" <Ronald.Ten-Hove@Sun.COM>
> cc:    wsbpel@lists.oasis-open.org
> Subject:    RE: [wsbpel] Issue - 2- requirements for a sub function
>        solution
> 
> 
> Ron,
> 
> Personally I am eager to leave the 'readability' issue to 
> stand on its own
> merit as a separate, orthogonal issue J
> 
> I think one of the key degrees of freedom/constraint is the 
> intersection
> of:
> 
>       -          'deployability' as a separate BPEL process
>       -          'ability' to act similar to a scope
> 
> with the notion of 'easy to use as a function'. You might 
> have mentioned
> this in one of your earlier replies. Well truth be told, 
> there is nothing
> easy about transactions and compensations. If we want the unit of
> reusability to be that of a scope, then let's lose the idea 
> that it's as
> simple as a function call in a functional language.
> 
> If we agree with the above opinion (that is, suspend disbelief
> temporarily), then we can focus on how to make separately deployed
> "sub-process-like" BPEL work.
> 
> What would the characteristics be? Potentially:
>       -          structured like a scope
>       -          one entry point (like a function)
>       -          "called" similar to starting another scope 
> within the same
>       BPEL instance
>       -          which implies that correlation is automatic 
> and at the
>       invocation-layer, not the full blown correlation set, 
> which implies
>       us saying something about implementation
>       -          when the sub-BPEL returns, it has to stick 
> around until
>       the entire calling BPEL exits, to allow for proper compensation
>       -          when the calling BPEL exits, it has to 
> remember to tell
>       the called sub-BPEL that it can exit too
>       -          etc
> 
> Please let me know we are still on the same page. If we are, 
> then there is
> more to come J
> 
> Cheers,
> ++harvey
> 
> 
>       -----Original Message-----
>       From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
>       Sent: Thursday, October 30, 2003 4:50 PM
>       To: Harvey Reed
>       Cc: wsbpel@lists.oasis-open.org
>       Subject: Re: [wsbpel] Issue - 2- requirements for a sub function
>       solution
> 
>       Harvey,
> 
>           Without putting words in Yaron's mouth, I'd say 
> that is a good
>       distillation of Yaron's proposal. I would only modify 
> item 4, to add
>       that invocation of sub-functions (or whatever name you 
> want to give
>       to the reusable item) should be easily understood by a 
> human reader.
>       I (personally) think that should be a primary consideration.
> 
>           What are your thoughts on these ideas?
> 
>       -Ron
> 
>       Harvey Reed wrote:
> 
>       Interesting. I want to make sure I am still following the main
>       thread. Are we saying that:
> 
>             1.      We want to have reusable BPEL
>             2.      Since the unit of reusability needs to also follow
>             conventions of compensation, reusability is along 
> the lines of
>             "scope"
>             3.      We want to be able to deploy these reusable scopes
>             anywhere (no restrictions?)
>             4.      "invoking" these scopes should be as easy as with
>             regular scopes (no complex mapping of state, like 
> with assign)
> 
>       Close?
>       ++harvey
> 
>             -----Original Message-----
>             From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
>             Sent: Thursday, October 30, 2003 11:54 AM
>             To: ygoland@bea.com
>             Cc: wsbpel@lists.oasis-open.org
>             Subject: Re: [wsbpel] Issue - 2- requirements for a sub
>             function solution
> 
>             Yaron,
> 
>                 The first time I read the BPEL4WS 1.0 spec, one of my
>             strongest reactions was "where are the 
> subprocesses?" Over a
>             year later, one revision of the spec, and countless
>             re-readings, and my initial reaction is unchanged.
> 
>                 Modelling subprocesses as separate web services is an
>             unsatisfactory substitute. This creates 
> unreadable processes,
>             with, as you observed today, really messy 
> <assign> activities
>             used to pack and unpack requests and responses. 
> Not only are
>             the assignments ugly, cluttering the process, but 
> the dedicated
>             BPEL reader will be faced with
>                   1.      Discovering that an <invoke> isn't  "real"
>                   (involving a proper partner) -- there is no 
> clear way to
>                   distinguish such service invocations from 
> subprocesses,
>                   except by tricks like naming conventions.
>                   2.      Decoding the initial <assign> to 
> figure out what
>                   the input parameters are for the subprocess.
>                   3.      Decoding the trailing <assign> to 
> figure out what
>                   the output parameters are for the subprocess.
>             This doesn't sound like the best of modelling 
> approaches, and
>             certainly makes run-time implementations more 
> difficult. Can we
>             do better?
> 
>                 Assuming that we can agree that 
> sub-functions, as you have
>             defined them, can be used as a simple form of 
> sub-process, then
>             we may be able to converge on a satisfactory solution.
> 
>                 The rest of my comments are in-line:
> 
>             Yaron Goland wrote:
>             Here is my view on what the requirements are for 
> a solution to
>             Issue 2.
> 
>             Terminology:
> 
>             Host - This is the process that called the sub-function.
> 
>             Requirements:
> 
>             Integration into host fault/compensation model - The
>             sub-function MUST be
>             able to throw faults that will propagate to the 
> host. The host
>             MUST be able
>             to call compensation handlers defined in the sub-function.
>             I would add that sub-functions must integrate 
> into the host's
>             serializable scopes, when shared variables are passed by
>             reference to the sub-function.
> 
>             Functional Programming - One of the key concepts 
> of functional
>             programming
>             is the idea of isolation. Functions in functional 
> programming
>             systems are
>             expected to be able to run in their own context 
> and to only
>             have contact
>             with the host context through explicit value passing. The
>             sub-function
>             solution MUST enable for isolation.
> 
>             Human Usable - It MUST be reasonably easy for a 
> programmer to
>             read/write
>             sub-function definitions and calls without 
> requiring the aid of
>             a tool.
>             I believe we established this as a requirement 
> for BPEL very
>             early on, in the debate over whether <sequence> 
> was necessary.
> 
>             By Reference - Messages seem only to get larger with
>             multi-megabyte XML
>             messages now commonly seen. Therefore when 
> passing data into a
>             sub-function
>             it is critical that it be possible to hand over 
> the data by
>             reference so
>             that the data does not have to be copied on its 
> way in or out.
>             While passing by reference has good, pragmatic 
> foundations in
>             managing the impact of those ever-growing XML payloads, I
>             believe another line of argument would support 
> the need for
>             clear, controllable parameter passing to the 
> subfunction, such
>             that the process author can clearly control and 
> understand how
>             data are passed to and from the sub-function.
> 
>             Use in Expressions - It MUST be possible to call 
> a sub-function
>             anywhere one
>             could call a XPATH or other type of general/query/date
>             expression and have
>             the sub-function return the desired value.
>             That is an interesting idea. Such sub-functions 
> would need to
>             have restricted "signatures" to map to XPath 
> functions; also,
>             isn't XPath supposed to always be side-effect 
> free? That would
>             imply that all input variables of the sub-function must be
>             read-only; a single output variable would be 
> nominated as the
>             function result.
> 
>             Import - A mechanism is needed to allow 
> sub-functions to be
>             defined in stand
>             alone files which can then be referenced by multiple BPEL
>             processes.
>             Agreed.
> 
>             -Ron
> 
> 
> 
> 
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
> ave_workgroup.php.
>