OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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



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






-----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



    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?


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)





-----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



    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.
Host - This is the process that called the sub-function.
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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]