Portability Definition -- informal

I'll try to keep this rather informal, since I don't want develop a
formal (and thus unreadable) definition. 

    Intuitively, we can state that process portability means that using
the same process definition on two different BPEL run-time
implementations will result in the same process behaviour. Put another
way, I should be able to swap two such implementations, and the overall
behaviour of the system (including clients and services) will not
change except where, of course, nondeterminism in the process
definition allows. 

    That might suffice as an informal
definition, but I can't resist drilling in a little further. This is an
interesting topic.

    Run-time behaviour can be gauged from the "black box" perspective,
by observing message traffic in and out of an implementation. If we
have the same BPEL process definition (and associated WSDL documents)
used to configure two different BPEL run-time implementations, and the
process definition itself avoids concurrency errors, then we can
expect, given the same behaviour from clients and services used by the
process for runs using each implementation, that:

  
If we trace the message traffic, the message ordering is the same:

  

  
    
with the exception of cases where the message ordering is
non-deterministic, in which case the observed message traffic must
observe the partial-ordering imposed by the BPEL process definition.
For example, messages that are children of a <flow> may appear in
any order, but must appear together within the "lifetime" of that flow.

    

    
Message contents (payloads) should be the same, modulo
timestamps, UUIDs, unique document IDs, and other such non-repeatable
content.

  
  
Such constraints apply under ordinary "happy path" execution (no
faults), and under fault conditions.

  

    We could delve into a whole pi-calculus model here of the BPEL
run-time semantics (which would be fun) but I think I've communicated
the basic idea, and I'm not looking for thesis topics! :-)

    There are some open questions here. Potentially, when we speak of
observable message traffic, we can mean "abstract" WSDL messages, or we
can mean binding-level stuff, encoded for shipment on the wire. It
really depends on how much of the WSDL we want to pay attention to. By
worrying about binding-level issues, we are treading on the ground
covered  by interoperability, but are staying closer to the "intuitive"
definition of process portability, where we'd like to be able to swap
BPEL implementions without disturbing the rest of the system. I think
we touched on this overlap in the call today.

    An aside: perhaps someone can produce a (possibly normative) test
oracle (small Oh) for determining if a message traffic trace is legal
given a process definition? I know we want to avoid getting into the
certification business (and wisely so), but such an oracle might serve
as a poor man's reference implementation?  Just a thought.

-Ron