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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[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.


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:
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".

	<SOAP:Envelope xmlns:SOAP="..." xmlns:eb="...">
	    <eb:SynchReply mode="<value from enum above>" SOAP:mustUnderstand="1"/>

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.



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

Powered by eList eXpress LLC