Profiles Re: [wsbpel] Issue 99 - Updated proposal for vote

[andrew.francis@mail.mcgill.ca]

Quoting "Yaron Y. Goland" <ygoland@bea.com>:

> My understanding of the purpose of the 'external behavior' profile
> is to describe all actions that a process will undertake that can be
> viewed externally to the process.

I always thought the specification used 'external' or publicly
visible behaviour with the premise that the only way objects communicate
is through messages. The objects themselves are blackboxes. The
only thing an external observer sees are the object interfaces and
the message passing sequence.

Given the aforementioned premise, I believe what constitutes the
external or publicly visible behaviour of process should be consistent
amongst profiles. I don't know what an 'external behaviour' profile
buys.

>The goal being to describe the order in which a process expects to send
>and receive messages. A key part of describing such a sequence is knowing
>when the sequence ends. Without the use of the <exit> activity it is
>significantly more difficult to describe end states, especially ones
>that represent an exception to the 'expected' execution path.

I think what you are describing is a protocol. I believe it is the
job of an abstract process, not its profile, to describe a protocol.
One can describe when a protocol should terminate a session without
an <exit> activity. <exit> is an internal action which one cannot
directly observe.

I think the problems revolve around lack of a conceptual model
for abstract processes and profiles. Hence issues 109 and 99. I
read stuff like "process template" and AP 1.1. However I have
not seen a concrete example.I believe it is easier to reason things
out if one has an easy to understand model, analogy, or design
principles.

I also believe developers actually have to start writing and
implementing abstract processes and profiles to understand the
issues and get it right...

~

Some analogies. If an abstract process is akin to an OOP class
then a profiles is akin to a metaclass. Profiles are factories
for abstract processes.

This is how I interpret the relationship between profiles and abstract
processes.

Now, let us pretend I have a profile called "Template Method." I
tell the implementer (i.e., a tool builder) that the purpose of my
profile is to emulate the Template Method described in the "Design
Patterns" book. The "Template Method" profile does three things:

1) Ensure the protocol is implemented without change. The protocol
   is a contract. If one correctly implements the abstract process,
   then my process can properly communicate with your implementation.

2) Allows "subclasses" to customise the template with their own
   internal business logic.

3) Place restrictions to avoid pathological behaviours.

The profile also describes use cases. For instance, the creation
of abstract processes that describe an automated business negotiation.

My profile establishes rules such as:

1) The implementer can ONLY replace opaque activities.

2) An opaque activity can be replaced with any activity EXCEPT {some list}

3) The input values MUST be assigned to the opaque variable's "input"
   attribute. The result values MUST be assigned to the opaque
   variable's "output attribute.

4) Any added activity MUST NOT use a partnerlink defined in the
   abstract process's partnerlinks (this rule and its rationale
   has been referred, by I believe Satish, in a prior post)

5) If the "subclass" or concrete executable is written in WS-BPEL,
   then the executable MUST conform to the WS-BPEL specification.
   A non WS-BPEL executable MUST implement the algorithm described
   in the abstract process.

Now the profile states how one should interpret the following
abstract process. The following abstract process defines a simple
protocol that ends when the other party sends either a 'deal' or
'no-deal' message.

<partnerlinks>
  <partnerLink name="SellerPartnerLink" ....>
. </partnerLink>