RE: Regarding where SyncReply information can and/or should reside

[David Fischer <david@drummondgroup.com>]

Chris,

What complexity?  All MSHs which support synchronous connections will be able to
both send and receive.  The only thing happening with SyncReply=False is the
connection is dropped when transmission is complete.  Then, when the Receiver
has finished processing, the connection will be reestablished in the opposite
direction and the reply/acknowledgement/business response will be sent.

Why is reestablishing the connection a severe complexity?  I assure you it is
not.  It is done all the time.  I am not asking for a change of transport (which
is also done).  All I am asking for is MSH level support of an already existing
parameter.  It's not as if I am asking for "whatEverSuitsMyFancy".  How else is
SyncReply to be used without a CPA?  It can't be, so it must be in the
MessageHeader along with the other parameters -- which it was in v0.93.

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: Chris.Ferris@Sun.COM [mailto:Chris.Ferris@Sun.COM]On Behalf Of
christopher ferris
Sent: Tuesday, August 21, 2001 3:48 PM
To: ebXML Msg; ebxml-cppa@lists.oasis-open.org
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

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>