Proposal for implementing Abstract Process Template case

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

Dear Colleagues:

I have been following the discussion concerning abstract
processes. I have read Satish and Rania's Strawman. I have
also been following issues 82 and 107.

I feel a part of the problem is that to the best of
my knowledge, no one has implemented abstract processes.
I believe abstract processes are a powerful concept.
However I have not seen a clear business case showing
how abstract processes solve real life problems. I feel
it important to create abstract process prototypes to see
if the ideas actually work. I believe the Strawman, and
107 provide sufficient information to experiment.

Based on my limited experiences with WS-BPEL; reading the
specification and prototyping a toy front-end parser and a
toy runtime (still in their infancy), I have come up with
the following ideas. Hopefully others can comment and
expand on the ideas.

I know much of this is speculation, but abstract
processes are speculative. That what makes abstract
processes interesting and exciting. In the weeks to come,
I will try to prototype some of these ideas.

~~~~~~

Problem:

Imagine, I have a (BPEL) choreography that automates the
negotiation process for the on-line purchase of widgets.
My rules are simple:

1)Based on a product in my on-line catalogue, you send
  me an offer containing the product, the price, and
  the quantity.

2)In return, I will send, an acceptance, a rejection, or
  a counter-offer.

3)In turn, you will send me an acceptance, rejection, or
  counter-offer.

4)If after three rounds, an acceptance has not occurred,
  the negotiations end in failure with a REJECTION. If
  in any time an acceptance occurs, I will successfully
  terminate the negotiations with a Quote.

I embody these rules in a BPEL abstract process instance.
However I design the BPEL abstract process instance in such
a way that third parties can add their own business logic
(through use of opaque). I place the abstract process in
a public place. Third parties are free to transform
the abstract process into a form suitable for their use.
As long as third party's executable instances of my abstract
BPEL process complies with what my automated negotiation
choreography implemented by my BPEL engine expects, things
are fine. Otherwise my engine will terminate the choreography
with the non-compliant third party implementation.

My problem is that most partners who want to trade with
me do not have BPEL engines. Some partners cannot afford
the engine. Other partners do not want to make the initial
investment. Others find it too difficult to transcribe the
BPEL abstract process into a form (say a Java or Python
programme) that can implement the choreography. Since
automating the negotiation process is the best interests
of all parties (especially me since I have a BPEL engine),
how do I stimulate trade?

Solution:

Provide the tools and information to allow third parties to
turn abstract BPEL processes into some target implementation
language that will actually execute the choreography.

Part One: The Minimal Abstract BPEL programming idiom.

"Less is More" - Mies van der Rohe

I propose that the first part of the solution is to
figure out how to write an abstract BPEL process instance
with just enough constructions to allow one to implement
the choreography in question. Or in more technical terms,
just enough BPEL to allow a concrete instance to exhibit
the proper public behaviour, or in other words, a valid
execution trace.

I believe a relatively small subset of BPEL can describe
the execution traces of most BPEL choreographies. Control
flow constructs like "flow" and transaction/information
hiding constructs like "scope" are internal behaviour
and should not find their way into a minimal abstract
BPEL process. Minimal abstract BPEL process are simple.
Minimum abstract BPEL is an idiom because it is a
programming guideline, not a change to the language,
or a solution to every problem using abstract processes.

Part II: A Common Intermediate Code:

The first goal of Minimal Abstract BPEL processes is
describe the public visible behaviour of a BPEL process.
The second goal is to allow for easy translation of
minimal Abstract BPEL into a high level language.

To this end, let us pretend that there is an agreement
amongst BPEL vendors to have BPEL implementations to
produce intermediate code. To keep things simple, for
now let us assume this intermediate representation is
restricted just to the constructs needed to represent
abstract minimal BPEL.

This intermediate code is somewhere between an Abstract
Syntax Tree and an intermediate representations based on
say, three code addresses in complexity. However this
code has one fundamental characteristic: it adheres to
all the "MUST" requirements of the BPEL specification. The
intermediate representation does not preclude vendors  from
performing further optimizations on the IR insidetheir  implementations.

Now the format for this Intermediate Representation
is placed in public. Better yet the representation is
given an XML syntax. Again note, the intermediate
representation exists for the benefit of making  
translators easier to write. And allowing every Tom,Dick, Harry, and Andrew to write a translator.

Rationale:

The idea is to make it very easy for individuals and
companies to write Abstract BPEL process to
Target-language-X translators (one of my first computer
books was Kernighan and Plauger's "Software Tools" with
their Ratfor example. In the case of C#, Java one
can imagine the output being an abstract class
representing the choreography in question. Now third
parties simply use their tool of choice in filling
in business logic. I figure that having this heavily
processed intermediate representation could greatly
easy the translation process.

Now if I publish an abstract BPEL specification that
adheres to the coding guidelines, the following can
happen.

1) I can publish the Abstract BPEL process. I can also
   publish the intermediate representation as well.

2) A third party interested implementing Abstract
   BPEL processes in say, C#, Java, Python, or Perl can
   write a translator. The theory behind the intermediate
   code is to make it easier to re-target the final output.


Final comment. The output from these translators are
very simple choreographies implemented in the target
language. These provide few of the benefits one gets
implementing choreographies with WS-BPEL and a full blown
tool. The overall strategy is to lower the barrier
to entry by allowing a proliferation of simple-to-build
tools that provide rundamentary but functional
choreographies. And to start a network effect and
grow the WS-BPEL ecosystem.....