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

["Edwin Khodabakchian" <edwink@collaxa.com>]

Yaron,

We have gone back and forth on this requirement: 

Our first implementation of BPEL had an extension for allowing the
definition and execution of sub functions. We found out that people were
confused on where to use a scope, a separate process and a sub-function.
What we are seeing it that people end up using scope for grouping and
separate processes for isolation and reuse (specially given that most
engines will have internal optimization for inter-process communication
within the same engine). 

We find that people do not really care about having to redefine/partition
the declaration of port types and variables across process definitions
because this is important for increasing the level of isolation and level of
decoupling.

The part that is important and let to interpretation of implementators is
how WS-T can be used to propagate cancellation across instances and how to
align the state of the instances during a compensation/cancellation.

Anyway, this is just food for thoughts...

Edwin


> -----Original Message-----
> From: Yaron Goland [mailto:ygoland@bea.com] 
> Sent: Wednesday, October 29, 2003 3:18 PM
> To: 'Trickovic, Ivana'; wsbpel@lists.oasis-open.org
> Cc: B.Eckenfels@seeburger.de; arkin@intalio.com; 'Liu, Kevin'
> Subject: RE: [wsbpel] Issue - 2- requirements for a sub 
> function solution
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> > -----Original Message-----
> > From: Trickovic, Ivana [mailto:ivana.trickovic@sap.com]
> > Sent: Wednesday, October 29, 2003 5:22 AM
> > To: 'wsbpel@lists.oasis-open.org'
> > Cc: 'B.Eckenfels@seeburger.de'; 'arkin@intalio.com'; Liu, Kevin
> > Subject: Re: [wsbpel] Issue - 2- sub functions
> >
> >
> > We should be able to reuse pieces of BPEL code within a 
> single process 
> > or across multiple processes. The question is how these reusable 
> > pieces of BPEL code should be modeled and integrated in the calling 
> > processes.
> >
> > It seems that one idea would be to model reusable parts of 
> BPEL code 
> > (sub-processes) as BPEL processes. As Bernd suggested some 
> time ago, 
> > one way or two-way <bpel:invoke>s can be used for asynchronous and 
> > synchronous calls, respectively, and the specification 
> could also give 
> > a recommendation how to differentiate between internal and external 
> > process ports. If we take that approach, we also have to review 
> > consequences for the control flow, especially compensation 
> and error 
> > handling. Satish pointed out that the BPEL specification 
> includes as 
> > its integral part the BA protocol defined in the WS-Transaction 
> > specification. This protocol specifies the parent-child 
> relationship 
> > between scopes. But, BPEL usage of the BA protocol makes the 
> > assumption of localized behavior in a single service. If we model 
> > sub-processes as BPEL processes and use the invoke action 
> as mentioned 
> > above, we do not have localized behavior in a single 
> service anymore. 
> > So, what is missing in BPEL is the semanti!
> > cs!
> >  for compensation and error handling. It cannot be that for the 
> > sub-processes protocols such as WS-Coordination/WS-Transaction are 
> > needed. This semantics must be an integral part of the language.
> >
> > Also, sub-processes will be modeled as partners, which is 
> misleading 
> > from the modeling point of view and at the end the process 
> model will 
> > be overloaded with partner link definitions (partner links will be 
> > used extensively). I believe this is also an area where some 
> > simplifications should be made.
> >
> > Kind regards,
> >
> > Ivana
> >
> > 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.
> 
> 
> 
> 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.
> 
>