RE: [wsbpel] Question on Profile Usage Re: [wsbpel] Issue 82 - resolution]

["Green, Alastair J." <Alastair.Green@choreology.com>]

If I were to be mischievous, I would paraphrase another company's CTO (company, person to remain anonymous until they choose to break cover) who stated (evocatively, if no doubt simplistically) that BPEL was syntactic sugar plus long-running transactions. In the same light-hearted vein I would also note that the urge to escape into a spot of user code in a GPL seems to afflict many BPEL implementers (most notoriously in the form of BPEL/J), suggesting that the sugar sometimes tastes like salt. 

I think that Andrew's thoughts on the possibility of expressing many (some, lots, all?) long-running interactions in GPLs like Java or C#, and the expense and complexity of deploying BPEL engines in all sites, are very interesting.

At the same time there is a missing dimension. The real value of BP execution engines, in my view, is not so much that they provide a better or easier programming language, but that they are recoverable execution engines. It is their recoverable state that makes them capable of supporting long-running, interruptable interactions. If I am not mistaken, BPEL is normatively silent on this aspect: it is broadly assumed that a useful BPEL implementation will be recoverable, but I can create one which does not have this useful characteristic.

An extension of this point is: can we assume that both the process engine and the services that it invokes and exploits are equally well equipped? Are the services going to be recoverable? Services may be substantially less complex in terms of conversational breadth and concurrency, but still need to be long-running (recoverably stateful).

And what about those long-running transactions? Here we have a linguistic construct (nested compensatable scopes) which is a) valuable, because it provides a way of expressing relationships that are arguably harder to capture in a GPL than many other features of BPEL, and b) of questionable value, because it stops short at the very boundary which would make it truly powerful, the process boundary. If BPEL interactions were marked as, or could be deduced to be, taking place within transactional scopes, then the projection of those scopes into the interlocutor (service or processe-as-service) would enable the real work of the interaction to be tied, from initiator to executor, into a long-running transaction, which is a very useful abstraction from the details of distributed coordination. Transactional behaviour would cease to be a private matter, and become part of the externally observable behaviour, and rightly so. Defining the mapping of such projection points to the use of a distributed coordination protocol, and the making it easier to state and imply the consequent obligations upon a service or a process-as-service would add significant value to BPEL.

Bringing these two points together: perhaps the hardest problems in supporting reliable long-lived business process executions and interactions are not defining control flow, concurrency and listener-dispatcher behaviour (let alone manipulation of internal process state), but tackling recovery and distributed LRT, at both ends of a conversation, in an economical way.

Alastair

Alastair Green
CTO and Director
Choreology Ltd
68 Lombard St
London EC3V 9LJ
www.choreology.com

-----Original Message-----
From: andrew.francis@mail.mcgill.ca
[mailto:andrew.francis@mail.mcgill.ca]
Sent: 24 January 2005 20:45
To: satisht@microsoft.com
Cc: wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Question on Profile Usage Re: [wsbpel] Issue 82 -
resolution]


Hello Satish:

> I am now getting lost.

You are focusing on the aspect of my post, which is a
thought experiment. I feel the main points of my previous
post is to show how the abstract BPEL as the "template
method" design pattern works. For readers familiar with a
high level OOP, they can see how the body of an abstract
BPEL process implements an algorithm. In turn, the body
of the abstract BPEL process maps onto a public method
of an abstract class that cannot (or should not) be overridden.

The opaque is akin to a protected method that
allows the algorithm to be altered in a very
proscribed fashion. "Protected" is used to signal
that concrete subclasses must provide the necessary
implementation detail. Note in my example, I have not
introduced any new keywords into the BPEL. And as I
previously described in the original illustration,
the abstract BPEL does not care if its concrete
implementation is a BPEL process or some intermediate
high level language.

>Why would one want to translate abstract BPEL to a 3GL
>like C# or Java?

How is this so different from what a BPEL interpreter
written in C# or Java, is performing, internally?
And stops one from compiling a BPEL process into
native code?

>These languages are not designed for expressing
>long-running interactions.

However Java and C# are pretty good general purpose
languages. With the proper class libraries, general
purpose languages will be a source of WS-BPEL
competition. They may not have all the bells and
whistles of WS-BPEL, but for many, this may prove
to be a good enough solution......

>Which means that only trivial processes can be
>straightforwardly translated to them.  What is the
>goal?

I am interested in determining the idioms concerning
the design of abstract processes. I am starting off with
the assumption common to many distributed processing
models that an external observer *cannot* see what is inside
a BPEL process. The only way BPEL processes can communicate
is through message exchanges defined by a protocol. In
this context, how can one tell a "trivial" process
with rundamentary control flow, from a "complex process"
that implements scopes/compensation, atomic assigns,
and concurrency?

Assuming that the goal of my abstract BPEL process
is to provide a concrete implementation with just
enough BPEL constructs to successfully communicate
with my implementation, a question is "what is the
minimal amount of BPEL we need to include to define
a protocol that provides the proper externally observable
behaviour?" I think the subset of BPEL that does this
is small....

Small and simple enough that it seems possible to treat
the DOM of this minimal abstract BPEL as an AST. In turn
one can convert it straight to a high level language than
in turn, can be compiled..... Perhaps I am just itching
to use the Visitor pattern.....

Seriously, I admit this is handling a simple case,
assuming that synchronous exchanges are easier than
asynchronous exchanges. Besides illustrating that
abstract BPEL can be a language neutral specification,
this raises questions like:

1) Are there real world cases that these trivial
   processes solve? For instance I can see scenarios
   where one has invested in a dedicated BPEL engine.
   However most of one's trading partners are SMEs
   (small to medium enterprises) that for whatever
   reason, do not have BPEL engines. If you don't
   trade electronically, you lose on your investment
   and on lost opportunities. Why not have a translator
   or make available translators that pumps out code
   skeletons that your partners can use? This allows
   your partners to engage in a choreography. Eventually
   the partners will see the merit of having a more
   sophisticated solution and may migrate to WS-BPEL....

2) How much engineering effort would it take to
   create translations of more sophisticated BPEL
   processes (support asynchrony)? Could we say,
   adapt cookies to work with correlation sets (I
   think Edwin Khodabakchian bought this point up once)?
   Now how many real world cases get covered?

3) Also, isn't this what "profiles" are about - using
   abstract BPEL to handle a particular use case - i.e
   abstract-BPEL-as-template-method-for-translation-
   into-simple-3GL-languages-for-trading-partners-how-
   do-not-have-BPEL-engines ;-)

Cheers,
Andrew



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/leave_workgroup.php.


Choreology Anti virus scan completed