Re: Clarifying exchange type

I think this is an interesting discussion from my viewpoint.  I can see 
the concern, but before touching
it, I wish to point out the following.

As I once noted, there is no need, intrinsically, to specify request, 
reply etc.

The important thing is a sequence of conversations grouped into one.  
For example you specify first
the book is named "Hard Times", and then in the second request "hard 
cover", and then we reply
that the book is available, which is semantically an answer to the 
previous two requests.

CDL is for me very interesting since it is not based on one-way message 
passing or request-reply.
In fact, request-reply is easily described and validated using a 
so-called co-relation identity:

Alice --> Bob:  <ch(s), request, "C Programming Laguage", x>,
Bob --> Alice: <s, reply, "yes we have it it is 100 pounds", y>.

Here s indicates a co-relation identity. For this co-relation identity, 
its interaction type is:

             Out( Request ); In (Reply)

for Alice, and for Bob,
 
              In (Request); Out (Reply).

Note that, by using coreation, we can insert arbitrary interactions 
between them, and the correspondence
is never lost.

So we can capture request-reply. I have no objection that we name this 
and its variants with special
names, since they are useful. In fact, I rather read Gary's proposals in 
this context.  Anyway the point
is the above idea can cover two requests and reply to both: three 
requests and two replies etc. etc.

In fact, this is what we call "session types" --- in essence, a session 
type says that we need a primary,
and obligatory, co-relation identity for each interaction: and we can 
realise micro-protocol specification
as above by having an additional identity.

 From this viewpoint, my question is: are there any these 
"request-reply" and its variants, including
notifications, which cannot be captured as a pattern of interaction, 
which can be made explicit by the
use of  co-relation identity?

Even if we do not have any, it does not mean we should throw away 
request-reply, since they may
be useful for documentation and monitoring. They are micro-sessions 
inside a session. Anyway this
does tell us: if things get complicated, why not use sub-identities and 
name the protocol?

This naming can be used for validation.

To be sure: I am not against new proposals which can be put into the 
current CDL very easily and is
useful. I am doing a theory, where things can be as general as possible. 
Nevertheless it is good to try
to position what is being discussed in a general context.

kohei


Gary Brown wrote:
>
> Hi Monica
>
> Definitely a subject for debate at the next conf call.
>
> I think the issue is that the spec is ambiguous in terms of usage of 
> the request and respond actions related to an exchange. The only 
> constraint at the moment is that there can only be a single non-fault 
> exchange, with action=Respond, in the same interaction activity as an 
> associated request exchange.
>
> It does not however indicate whether two or more interaction 
> activities could each have an exchange (with action=respond and no 
> fault name), which would imply a request has more than one normal 
> response.
>
> Therefore the change I am proposing is designed to clarify the 
> situations and enable more stringent validation to be applied. I think 
> if we take the other route, which would be to constrain CDL only to 
> deal with the request-only and request/response MEPs, this would be a 
> big mistake. However, if this route was taken, it would still require 
> clarifications in the spec to prevent the situation I have outlined.
>
> The benefits of CDL are more widely applicable than just the current 
> limited world of web services. Whether or not WSDL2, WS-Notifications 
> etc will take off, they show that distributed systems require more, 
> and they are trying to meet those requirements. I think it is 
> therefore important for us to address those requirements in CDL, and 
> at a tool level deal with runtime limitations, depending upon the 
> runtime environment within which the choreography is being applied.
>
> Regards
> Gary
>
>
> Monica J. Martin wrote:
>>
>> Gary Brown wrote:
>>
>>>
>>> Hi Monica,
>>>
>>> The ability to define notifications has been in the spec from day 
>>> one. It is simply a case of defining an interaction that has just a 
>>> 'Respond' exchange in it with no preceding 'Request' exchange (in 
>>> the same or any other interaction activity).
>>>
>>> The new 'Notify' exchange type that I am suggesting would not 
>>> require any new semantics, as it is so similar to the 'Respond' 
>>> exchange, although it does enable us to tighten up the semantics 
>>> around the 'Respond' exchange, to enable static validation to ensure 
>>> that there is a matching 'Request' exchange, which is currently not 
>>> possible,
>>
>> mm1: I agree we have a Respond exchange; however we may differ on 
>> whether or not this is a Notify.  Granted it may be similar to 
>> Respond; it may be Respond or, in other cases, its meaning may be 
>> very different from Respond. Perhaps this is a case to consider 
>> whether a Respond exchange is capable of specifying a Request match 
>> rather than differentiating with a Notify. I have opted not to 
>> explain the business level differences of a response or notify, as 
>> this has historically been outside of this WG scope.
>>
>>> So basically, at the moment it is possible to define notifications 
>>> as well as responses, but a CDL description may define these so they 
>>> are ambiguous and there is no way to statically validate whether 
>>> they are correct. This change would also be advantageous in a Web 
>>> Services deployment, as it clearly indicates whether WS 
>>> notifications is required, and if not available would enable an 
>>> organisation to understand that the CDL could not be implemented.
>>
>> mm1: It appears that what you are asking for are more functions 
>> around what Respond may be. Thanks.
>>
>>
>>
>>
>>
>
>

Received on Sunday, 29 October 2006 22:36:53 UTC