[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Does MEP belong to WSRM?
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]