RE: [wsrm] Does MEP belong to WSRM?

[<Szabolcs.Payrits@nokia.com>]

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