RE: [wsrm] Does MEP belong to WSRM?

Title: Does MEP belong to WSRM?

          
Hi Sanjay,

 

 

 Thank you for 
bringing up this issue for detailed discussion. Excuse me for not 
immediately answering your mail 
question by question. I think presenting 
our way of 
thinking coherently 
may help minimalizing the change of 
misunderstandings. After this I will try to 
answer your questions at one a time.

 

We acknowledge 
the fact that Web Service became a 
success and gained a lot of acceptance. We 
believe that  "XML-based 
application protocols over HTTP"  was 
a succesful idea, and that Web Services are evolving from this 
success.

We cannot identify 
without doubt, which charasteristics made Web Services successful. It may 
be that it is a kind of synergy of its characteristics and the present 
environment. 

We are 
afraid that that this success is fragile. History shows that there were a 
lot of attempts to standardize higher layers of communication protocols and lots of them failed to be widely 
accepted although a lot of them were technically brilliant. We think that it is 
widely believed now that Web Services can be an accepted 
solution. We believe that we must treasure this hope 
and acceptance, and must not let this 
opportunity slip. 

 

Therefore we have 
concluded that we should proceed gradually in every aspect, as any dramatical 
change may - by chance - hurt a vital factor of this current 
success.

 

To be more concrete, 
we believe that we must not disregard that there is an established base of Web 
Services. We believe that we are forced to make compromises when addig a new functionality 
to the existing and accepted Web Services base. We could identify these 
principles:

 

 - 
backward compatibility:  We think it would be 
impossible to suddenly change every interfaces 
and implementations that are using Web Services. We must maintain backward 
compatibility with existing  
interfaces, 
 implementations and 
infrastructure.  (by interface 
here I mean an actual client-server interface based on SOAP, for example MM7 
interface that is the Web Service interface for sending MMS 
messages)

 - incremental change: We 
should not throw out anything that is already a functionality of Web 
Services, because of the danger of throwing the baby out with the bath 
water. The thing just thrown out may have 
been the key factor of success, as we don't know which the key factor is. 
Another aspect is that existing interfaces should be extended and 
not completely re-defined when a new functionality comes into the 
picture.

 - minimal changes:  The more 
additional work needed for changing the existing interfaces and implementations, 
the less desirable it will look to do so.

 

 When 
considering the actual SOAP Message Exchange Pattern problem, we think 
that the incremental change principle applies here. We see that 
Request-Response Message Exchange Pattern is a functionality of SOAP as it 
is now. Therefore applying the principle above, it should not be thrown 
out. We should not eliminate the Request-Response MEP support while extending 
SOAP with reliability feature.   

 

(For justification of this principle, I would also 
mention the E-mail binding defined for SOAP. It also retained the 
Request-Response functionality, see http://www.w3.org/TR/2002/NOTE-soap12-email-20020626#NE33 for 
more details)

 

--------------------------------------------------------------

 

  Now I would try to answer your 
questions: 

 

1. " 
Does it mean that the WSRM provides a 
sendAndReceive interface and the correlation of the response with the request is 
now handled by WSRM? "

 

 We think that there must be 
possible to provide something like a sendAndReceive API by an actual implementation.  As 
it is possible to provide such an  API  for existing SOAP 
implementations. (and  lot of 
them do provide  !) . 

 Of course, it doesn't mean that we have to 
define the API itself in this TC, but 
it must be possible to implement this functionality in a way that this interface 
is offered by an actual implementation. (However, I personally think that 
formally defining the interface with abstract service primitives can help the 
standardiztion work, but this is a personal 
preference). 

It must be 
emphasised anyway that 
actual API is an implementation 
question. 

 

2.  " Assuming that this is the case, will this interface also be 
asynchronous ... ? "

 

 I think 
that there is a need for an agreement on usage of terms. I think 
synchronous/asynchronous are 
programming interface (API) terms. They assume an execution flow that may be blocked when 
calling a function (synchronous) or may not 
be blocked (asynchronous). 

  Which SOAP binding  is in use is a different question. The standard HTTP SOAP binding is 
sometimes called "synchronous". I think this is unfortunate, as the API of the 
SOAP implementation can be either synchronous or asynchronous, even when 
standard ("synchronous") HTTP binding 
is is use. This can couse misunderstandings. 

 Synchronicity of API and the used SOAP 
binding are independent things. Actually 
the purpose of SOAP is partly to hide the binding and make the API 
independent from the transport protocol. 

 

3.  
"asynchronous aspect of WSRM is its primary 
strength", 

 

I would like 
to repeat that it is possible to provide an asynchronous API even for the classical HTTP binding of the SOAP specification (1.1 or 
1.2). 

So I 
concluded that you meant here something like 
"symmetric one-way messaging of WSRM is its primary strength". (Correct me 
please if I misunderstood it)

We do agree in this 
sense. We also believe that the 
possibility of symmetric 
one-way messaging is a definite strength, and we also would like to 
be sure that it will be is supported 
by the specification we will come up with.

 

However, I would like to note that symmetric one-way 
messaging has its disadvantages, too. It cannot be used in 
enviroments where the SOAP client is behind a firewall. 
However, standard SOAP with HTTP binding 
is it is asymmetric, so it is 
"firewall-compatible".

 

4. 
(comment)

I would like 
to repeat what I said during the last phone conference: I think synchronicity/asynchronicity and MEPs are two different 
things (and RPC is a third). 
Let's concentrate on the 
API and see how these terms can be 
defined:

  - Synchronous/synchronous: The API 
function blocks the execution flow or not.

  - Message Exchange Pattern: A logical 
entity consisting of one or more messages. Messages belonging to the same 
MEP are bound together by the API.  The messages have roles in the MEP and 
API calls contain the information what is the role of the message in the actual 
MEP.

 

Of course this is a very formal definition. We have 
only two possible MEP: one-way, where there is only one role: message. And SOAP 
defines the Request-Response MEP, where there are two roles: Request and 
Response. 

 

But it must be noted, that it is possible to implement 
a Request-Response MEP using asynchronous API, in this case you initiate the 
MEP

 MEPContext_id 
= InitiateRequestResponseMEP ( request, parameters 
);

and the call can return immediately (asynch). And 
somewhere may be a callback (or input queue or equivalent) 
like:

 void IncomingResponse ( 
MEPContextID_t MEPContext_id, ResponseMessage_t *response) { ... 
}

 

And it is possible to implement a synchronous API for 
the Request-Response MEP, like:

status = sendAndReceive(request, 
&response);

and the call returns after the response returns or 
error occurred. 

 

To sum it up: Synchronicity of API and MEPs are 
independent and orthogonal.

 

I would mention E-mail binding here again as an example 
for a Request-Response MEP over a binding that nobody would 
call "synchronous"

 

  5.  
"Its arguable whether  such issues are outside of 
the scope of the spec and belong to implementation designs). "

 

The distinctions in point 
4. are important here: 

 - I agree, synchronicity of API is out of the scope, it is 
implementation design question.

 - However, 
MEPs are orthogonal to synchronicity and they must be in scope as 
long as we are talking about SOAP.

 

 6. "In addition to 
solving the response notification problem, we will also have define how 
correlation is handled by the WSRM layer. If we chose to support correlation 
based on message content  "

 

Definitely not. The abstraction of 
MEPs is described very well in Section 6. of SOAP 1.2 Part 2 ( 
SOAP-Supplied Message Exchange Patterns and Features, 

http://www.w3.org/TR/soap12-part2/#soapsupmep 

 

This is the level of abstraction where the 
correlation is sensible. The only associated functionalities are to 
identify the MEP and the role of the actual message in the MEP, and this is very 
limited information: request or response. 

Message content (like Order, OrderAccept) is definitely 
out of scope here, it would be really too complicated, I would not touch it, 
either.

 

7. "Yet another 
issue would be - why do we want to limit ourselves to req-resp mep 
only? "

 

I would say: yes. I 
think the minimal change principle may be applied here. 

 

I think we should use 
the same usage scenarios that are used in the XML Protocol (SOAP 1.2) 
requirements document (see: http://www.w3.org/2000/xp/Group/xmlp-reqs-06/xmlp-reqs.html#N2690 ).

 

The following 
requirement for MEPs are in this document:

 

":XMLP should facilitate the creation of simple 
applications. Simple applications are often characterized by message exchange 
patterns such as one-way (or event), and two-way (or synchronous) request 
response interactions. The specification should make such simple exchange 
applications as easy as possible to create and to use."

 

"The specification 
will directly support One-way and Request-response patterns as part of 
permanently and intermittently connected 
scenarios..."

 

I think 
we should use the same requirements, and do not change anything on 
exiting SOAP just because of theoretical 
reasons.

 

7. "I am not quite 
convinced  yet whether support for mep is a function of WSRM or some higher 
layer (such as choreography or a dedicated coordination protocol layer, 
etc)."

 

You are 
right, it would be good to have a coordinaton layer. I also would like to see 
such a solution. We have to be sure that we encourage the evolution of such an 
architecure. 

But there 
is no such standard available, nor will there be in the foreseeable future, even 
less will it be implemented, accepted and widely used 
soon.

 

I would say 
that _at the moment_ it is better to distinguish the one-way and 
request-response MEPs as special ones and support them by the reliable SOAP 
implementation.

 

In my 
dreams we will see a slow migration to a dedicated coordinaton layer, 
and Request-Response MEP will not be needed to be built into the SOAP 
layer, and it will slowly disappear. I would like to see that. But it is hard to 
achieve. Let me finish with a little story, how hard it 
is:

  Last year, during standardization 
of the MM7 interface mentioned above, I tried to convince the working 
group to build the application message exchanges 
from one-way SOAP messages. My argument was that this way reliable 
transport may be achieved easily and it is nice and there would be no problems 
with pending HTTP transactions. I was rejected with one consent. The WG found 
that following the SOAP tradition, using standard HTTP binding is mandatory 
and defining a new HTTP binding is not even to be thought of. Nor "emulating" 
one-way messages with the request-response pattern. I can understand see their 
point now. MM7 was just one output of the WG. Others didn't want to spend 
too much time on it. They wanted to play it safe. The want to play even safer 
now, when everybody has MM7 implemented. 

 I 
think we have to take this "playing safe" tendency into account if we would like 
to see others using our output 
specification.

 

    Best 
regards,

        
Szabolcs