Re: [wsrm] Does MEP belong to WSRM?

["iwasa" <kiwasa@jp.fujitsu.com>]

Hi Sanjay,

There might be some different understanding and different
requirement among people, which we may want to discuss
more later. So here is my opinion in-line.

--
>I am still struggling hard to understand what it means to support the
request-response message exchange >pattern in WSRM. I am hoping that
somebody, at least the supporters of this idea will shed some light here.

>Let us first try to answer - what is the impact of supporting req-resp MEP
on the WSRM interface? Does it >mean that the WSRM provides a sendAndReceive
interface and the correlation of the response with the >request is now
handled by WSRM?
> Assuming that this is the case, will this interface also be asynchronous
(like the send interface which >allows the application layer to submit a
request and continue execution of its normal)?

<iwasa>
I think this could be synchronous. Other people may have different view for
this,
but what we want in the spec is to support synchronous request/response
message
exchange pattern like soap does. I think the typical usecase of Reliable
Messaging
is to be used in asynchronous messaging. But we do not want to prevent to
use
this spec in synchronous request/response message exchange pattern. Since it
helps
to use this RM spec for both asynchronous messaging and synchronous req/res
mep that SOAP does in reliable way. It means if we want to make exsiting
SOAP
reliable, we can use this spec, even if the SOAP is used with synchronous
req/res mep.
</iwasa>

>I personally think that the asynchronous aspect of WSRM is its primary
strength and we should strive to >retain that as much as possible. In which
case, for supporting the req-resp mep in asynchronous manner, we >also need
to define a notification mechanism between WSRM and application layer along
with clear >definition of how to pass the context, who defines the context,
etc. This may get a bit complicated (Its >arguable whether  such issues are
outside of the scope of the spec and belong to implementation designs).

<iwasa>
Thus, I don't have any use case with asynchrnous req/res mep in my mind.
And I don't expect this TC is going to define API at this point.
</iwasa>

>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 (such as purchase >order number being
common in both Order and OrderAcceptance documents), it sounds like we will
be >mixing the  application layer with the messaging layer. An alternative
to this would be to require that the >responding side to accept a context
for a request and make it available to the WSRM layer when submitting >a
response. This is again getting  complicated and burdensome.

<iwasa>
Right. This might be a kind of "Conversations" which is in out of scope
items in our charter. And I agree with you that we should not mix the
application layer and messaging layer.
</iwasa>


>Yet another issue would be - why do we want to limit ourselves to req-resp
mep only? Can we also then >consider supporting req-resp-resp pattern (a
future hypothetical mep where a request is returned with >multiple
responses). I guess, at the risk of introducing some more complexity, we
will technically be able to >support such a mep also. However, to think
about, 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).

>On the other hand, if by supporting req-resp mep, we simply meant to
support the use case where an >application can go in a blocking mode and
carry out exchange of request-response documents on the same >connection
(obviously this use case is limited to connection oriented transports only -
HTTP!). If this is all >we are saying, then I must say that I fail to see
the relevance of this use case with WSRM functionality.

<iwasa>
IMO, this is the case, as described before. And the benefit of allowing this
is to allow to use this spec to make existing SOAP synchronous req/res MEP
reliable with this spec when we want to do so.  I believe it would be
benefit
that we can say it is possible to make SOAP reliable with this spec, without
significant restriction.

Thanks,
Iwasa
</iwasa>



Thoughts??

Sanjay Patil
Distinguished Engineer
sanjay.patil@iona.com
-------------------------------------------------------
IONA Technologies
2350 Mission College Blvd. Suite 650
Santa Clara, CA 95054
Tel: (408) 350 9619
Fax: (408) 350 9501
-------------------------------------------------------
Making Software Work Together TM