Re: Question on relation between roles and wsdl interfaces

Mine,

Addressing your second point, I think you are referring to the "scope of 
choreography", which I attempted to tackle with the ideas in my thesis 
(http://www.doc.ic.ac.uk/~hf1/phd/thesis/HTML/index.html).  A summary is 
as follows:

"...whereas Web Service Compositions describe the local process of 
service orchestration, Web Service Choreography describes the observable 
interactions between services and their users.  Choreography in general 
terms, and by dictionary definition, explores the wider aspects of 
interactions, often referenced by a similarity to arranging dance or 
ballet group sequences.  The W3C Web Services Architecture group 
describe general choreography as ..the sequence and conditions under 
which multiple cooperating independent agents exchange messages in order 
to perform a task to achieve a goal state.. Whereas compositions are 
focused from a single service viewpoint and its interactions, 
choreography of a group of related services is the interaction to 
complete a broader scenario.  Web Service Choreography is more formally 
described by the W3C Web Services Choreography Working group as; ...the 
external observable behaviour across multiple clients (which are 
generally Web Services but not exclusively so) in which external 
observable behaviour is defined as the presence or absence of messages 
that are exchanged between a Web Service and it's clients. (Austin 
2004). In a series of scenarios, the messages that flow between web 
services and clients (which may be web services, but also applications 
or even human beings) may require a specific set of interactions to 
occur and to group these interactions for transactional or 
compensational reasons.  Choreography is typically initiated by an 
external source (a client or service) and ends with a target service or 
a reply to the source.  Such interactions during this choreography poses 
questions such as; can messages be sent and received in any order?, what 
are the rules governing the sequencing of messages? And can a global 
view of the overall exchange of messages be drawn? (i.e. can we verify, 
modify and monitor the behaviour)?

As BPEL4WS is aimed at addressing the interactions from a local process 
workflow and fault tolerance perspective, it does not exhibit observable 
state by which other web service compositions can respond to for a 
global service responsibility.  The element in question is that of 
impact of state in wider composition invocations.  If the composition is 
invocated from a local .master. controller (as currently modelled by the 
BPEL4WS invocation engine) state is not transferred between composition 
engines.  The efforts necessary for effective workflow system analysis 
(Bolcer and Taylor 1998), the exploration of engineering these 
compositions is troublesome.  In addition to state, the impact of 
introducing dynamic service selection in choreography increases the 
impact on complex engineering decisions at design time.  For example, in 
a local problem domain, a dynamic discovery of an .Order Books Service. 
may be satisfied.  Yet the same service hosted globally may not take 
into account local composition behaviour, or indeed, even synchronize 
with data managed by the local service.  These are issues that should be 
recognized as a web service design compositional constraints and 
verified appropriately.  Implementations for choreography standards are 
currently in the form of the Web Service Choreography Description 
Language (WS-CDL) (Kavantzas, Burdett et al. 2004) and the Web Service 
Choreography Interface (WSCI) (Arkin, Askary et al. 2002).  Both of 
these specifications have been introduced as part of a service-oriented 
model aligned with the same W3C working groups."

In general, the "scope" of interactions is defined by the problem domain 
in question - which I believe is ultimately drawn by consensus of the 
participants.  i.e. what is important and what is not...

Thoughts?
Howard.

On Sat, 9 Dec 2006, Mine Altunay wrote:

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

-- 
Dr Howard Foster
Department of Computing
Imperial College London
www.doc.ic.ac.uk/~hf1

Received on Monday, 11 December 2006 09:11:11 UTC