- From: Mine Altunay <maltuna@unity.ncsu.edu>
- Date: Sat, 9 Dec 2006 18:06:31 -0500 (EST)
- To: Steve Ross-Talbot <steve@pi4tech.com>
- cc: public-ws-chor@w3.org, gbyrd@unity.ncsu.edu, debrown@unity.ncsu.edu
Dear Steve Let me also clarify one more issue related to the roles and behaviors. I realized that by tracing a relationship that is included within an interaction element, we can also determine what would be a receiving role and the receiving behavior. We can, by checking this role element, tie the receiving role behavior to a service interface. As you earlier pointed out, the operation attribute of an interaction can also give us the same information. Naturally, one hopes that they both give us the same receiving behavior and interface. My question is whether WS_CDL has any checks or restraints to ensure that there ar no inconsistencies between operation attribute and the relationship element. My other question is not directly related to roles and behaviors concept. I suppose it could be tied back to the much-debated orchestration-vs.-choregraphy issue. So let me try to summarize. Please note that I assume that each participant/or partner that joins a choreography offers its web services to the choreography, and through invocation of these web services, roles and behaviors accomplish their tasks. My question is that is it possible to obtain a complete and definite graph of interactions among web services by analyzing the choreography document? What I observe from the sample choreography documents is that a choreography document is mainly interested in the observable interactions among separate web services. What goes on inside a web service does not need to be exposed within the choreography document. (I think that this is meaningful as the inner behavior of the web service can be governed by an orchestration-language such as BPEL, and it could be much complicated.) A service may assume a certain behavior while receiving input, and after processing it, it may assume a different certain behavior to send its results, without disclosing any of the interactions that occur between its two inner behaviors. As a result, the interaction between these two behaviors may not be explicitly stated in a choreography document. Let me give you an example before I move on. Let's say our choreography consists of three services: A B and C. We have two interactions observable between parties: a request flowing from A to B and another request from B to C. Let's also assume that B has two behaviors: B1 and B2. B1 is used for receiving data flow, whereas, B2 is used for sending processed data outcome. In the resulting choreography document, one can state above example as sum of two interactions: A->B1 and B2->C, or alternatively one can state them as sum of three interactions A->B1, B1->B2, B2->C. On the one hand, the interaction between B1-B2 can very well be omitted because it can be handled by another language like BPEL. However, this results in an incomplete list of interactions. It is only implicit that B1 is connected to B2. I am very curious to learn your opinion and other members of WS-CDL mailing list on this issue. Does WS_CDL suggest one approach over the another one ? Is there any enforcement or is it totally up to the choreographer to define it any way he prefers. What would be the best way to state the interactions among behaviors in such cases? Thank you very much Regards ....Mine Altunay NC State Univ Computer Eng Dept PhD Student On Sat, 2 Dec 2006, Steve Ross-Talbot wrote: > Dear Mine, > > All interactions in WS-CDL define an operation name over a channel and > include a relationship name and the from and to roles for that interaction. > Optionally one may specify a set of exchanges (up to 3 normally, one for the > request, one for the response and one for a fault response). The operation > name may be used to tie back to a WSDL operation for the to role. If one > projects out all of the operations for a specific to role in a WS-CDL > description one would get an ordered set of of WSDL operations. The WS-CDL > defines the multi-party ordering and the end point projection provides the > specific role's ordering. > > In the definition of a role type in WS-CDL an optional interface can be > included. This may be a reference to a specific WSDL and this ties the role > to a specific service contract. > > Thus you always know which operation is invoked during an interaction because > the operation name and the to-role are defined. > > So I would say you are almost correct but that you missed the point about the > role being an abstract that has specific ordering constraints on the service > operations. Generally a role has a single behavior but that does not have to > be the case. > > If you want to find out further details carry on mailing this list but you > might want to cross post or look at the pi4soa implementation. > > Cheers > > Steve T > > On 1 Dec 2006, at 22:49, Mine Altunay wrote: > >> >> Dear list >> My understanding of current ws-cdl standard was that each role can have >> multiple behaviors and each behavior corresponds to an operation listed >> within a service's wsdl. As a result, I view a role as an abtraction that >> is a collection of service operations. Each time a different behavior is >> assumed by a role, the corresponding web service operation would be >> invoked. >> >> My confusion arises when I try to define interactions between different >> roles. An interaction consists of a relationship type and defines >> fromRoleTypes and toRoleTypes. However it does not specify which behaviors >> can be assumed during the specific interaction between two roles. >> >> My problem exacerbates when I try to tie in a choreography document with a >> run time execution environment. Since I do not know which operation is >> invoked during an interaction, determining run-time operation sequences >> between actual web service implementations is almost impossible. >> >> Can anyone enlighten me on this? am I incorrect to tie in behaviors with >> actual web services operations >> Thank you >> ....Mine >> >> >> >> Mine Altunay >> NC State Univ, Computer Eng Dept >> >> >> >> >> > > Mine Altunay NC State Univ, Computer Eng Dept
Received on Saturday, 9 December 2006 23:08:41 UTC