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

[<andrew.francis@mail.mcgill.ca>]

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