Minimal Abstract Processes Re: [wsbpel] abstract process strawman

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

Hello:

[from the Strawman]

>Nick has rightly pointed out that the “tracing semantics”
>of >abstract processes is a very interesting issue that
>deserves >a thorough discussion in the group.This relates
>to >observable conformance.
I am not sure what is exactly meant by "tracing
semantics"? The strawman's language (i.e., 'visible
behaviour') implies that tracing semantics refers to
execution traces. I am using execution trace as a
history of the message exchanges between participating
processes.

Perhaps this is my interpretation, but I like the
idea that an abstract process provides just enough
information so that a concrete executable instance
can produce legal (or acceptable) execution traces.

The WS-BPEL specification begans with the notion that
an abstract process can be written so it could be
instantiated without change. It seems to me that this
approach makes certain use cases, like deriving an
executable in a different language, difficult. It
also assumes the other party has a full blown BPEL
engine.


What if one assumed the opposite: BPEL abstract processes
provided just enough information to produce legal
execution traces between participating concrete BPEL
processes?

In that case, BPEL abstract processes get much simpler.
Constructs like flows, scopes, links (and other
constructs that are outlawed in abstract processes)
that represent internal details, do not get exposed in
the abstract process. Now it should be considerable
easier for a third party to write a tool, that can
take minimal BPEL abstract processes and translate
them into a target language and executable.

Fortunately the BPEL specification does not get in
the way of programming abstract processes using this
idiom.

Just a thought.

Cheers,
Andrew