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

["Eckenfels. Bernd" <B.Eckenfels@seeburger.de>]

Hello Andrew,

> 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.

An abstract process could mean different things. For example it could be
"incomplete executable draft" or "template" or it could be "protocol
description". The first two are not at all directly related to ist
observable behaviour. However my understanding is that the later
"protocol description" is exactly the thing we want to define in the
"observable/external behavior"  (I actually think we should call it
"business protocol profile").

So I think it is correct to define a profile for this since it is not
everything an abstract process is (anymore) all about. Thats why we want
to profile the different flavors.

A business protocol profile does indeed only consist of port definitions
and control flow as far as needed to describe the possible message
exchanges (and I am not sure if it is actually automatically
transferable into an executable procerss which match the profile,
however thats not a question for the standard)

Greetings
Bernd

-----Original Message-----
From: andrew.francis@mail.mcgill.ca
[mailto:andrew.francis@mail.mcgill.ca] 
Sent: Sunday, May 22, 2005 9:03 PM
To: ygoland@bea.com
Cc: wsbpel@lists.oasis-open.org
Subject: [wsbpel] Profiles Re: [wsbpel] Issue 99 - Updated proposal for
vote

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.


>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>

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php