OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Does MEP belong to WSRM?


Title: Does MEP belong to WSRM?

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)? 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).

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.

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.

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]