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

[christopher ferris <chris.ferris@east.sun.com>]

David,

What is the respondant to do with the response in this
case if the software is configured/written to provide ONLY a
synchronous response? You're making all manner of false assumptions
here. Re-establish the connection in the other direction?
Take my previous example of a servlet-based MSH. What provision
has it for establishing a connection?

Just because the ebMS spec is written to provide for
transport over a variety of different transports and to provide
for the possibility of synchronous vs asynchronous transfer
of messages between peers does not mean that every MSH 
implementation MUST support all manner of exchange.

It is perfectly reasonable that one design an MSH that
only supports synchronous request/response via HTTP from
the server perspective. You can't change a leopard's spots.

The whole point of a CPA is to describe how parties will
exchange messages so that both parties can exchange
messages interoperably. If one party can only respond
synchronously, that may limit their ability to do
business with parties that cannot process synchronous
responses, but it may also be a perfectly valid use
for some processes.

Conversly, you cannot expect that a party that can only
respond asynchronously to respond synchronously. 

Cheers,

Chris



David Fischer wrote:
> 
> 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>