[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Profiles Re: [wsbpel] Issue 99 - Updated proposal for vote
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]