[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Regarding where SyncReply information can and/or should reside
David Fischer wrote: > > Thanks Dale, > > No, I don't want to use Delivery Channels at all (per message or otherwise) for > changing the value of SyncReply. One Delivery Channel is all we need (per > transport). Please forget Delivery Channels were ever brought up. > > I just want to put SyncReply back in MessageHeader + QualityOfServiceInfo. > SyncReply(Mode) was in QualityOfServiceInfo in v0.93 and it got taken out > somehow. All I am asking is that it be put back in. > > Regards, > > David Fischer > Drummond Group. > <snip/> David, How is a recipient that can ONLY respond asynchronously expected to handle a request that the sender expects to be handled synchronously or vice versa? An example of the latter might be an MSH that is implemented as a servlet that could only respond via the HTTP response to an incoming request. Your use case of sending a large message and changing the processing semantics on the fly would impose on any implementation the ability to deal with any manner of response that the sender indicated. This would over-complicate the software needed at both ends. I don't see this as being a valid requirement. Further, synchReplymode in the CPA is defined as being an enumeration of the possible types of response that the parties have agreed upon: signalsOnly signalsAndResponse responseOnly none not a boolean. The boolean on the Via element is intended to inform the intermediary that it is expected to keep the channel open for the response to the sender. What seems in order to support your wish is to provide for a "whatEverSuitsMyFancy" mode that can be articulated in a CPA which would allow for a per-message reply mode that could be communicated via some header element in the message. This could ONLY be used in cases where the software at each end supported ad-hoc response modes. It should be an error if this feature were used if the recipient did not support its use. The most appropriate way I can envisage supporting this sort of thing is as a separate SOAP extension with a mustUnderstand="1". e.g. <SOAP:Envelope xmlns:SOAP="..." xmlns:eb="..."> <SOAP:Header> <eb:SynchReply mode="<value from enum above>" SOAP:mustUnderstand="1"/> <eb:MessageHeader>...</eb:MessageHeader> </SOAP:Header> <SOAP:Body>... </SOAP:Body> </SOAP:Envelope> This would provide for the feature you desire without imposing the complexity that this feature would add to a standard MSH. Implementations could chose not to support ad-hoc response modes of operation to avoid the added complexity. Cheers, Chris
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC