[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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. 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]