wsrm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [wsrm] Does MEP belong to WSRM?
- From: <Szabolcs.Payrits@nokia.com>
- To: <sanjay.patil@iona.com>, <wsrm@lists.oasis-open.org>
- Date: Fri, 11 Apr 2003 21:27:24 +0200
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.
--------------------------------------------------------------
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,
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.
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]