Portability Definition -- informal

[Ron Ten-Hove <Ronald.Ten-Hove@Sun.COM>]

    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