RE: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceInfo

[Martin W Sachs <mwsachs@us.ibm.com>]

David,

Take a look at the definitions of the ServiceBinding and Override elements
on the CPA spec.  The ServiceBinding element identifies the delivery
channel that is to be used for all received messages under the Process
Specification document except as follows.  The Override element defines
exceptions to the previous sentence.  It identifies a different delivery
channel to be used for a specific business transaction. If you want to
support SyncReply for certain business transactions, you define Override
elements for those business transactions.

At runtime, the sender does not tell the receiver which delivery channels
to use for what.  That's a negotiation matter during composition of the
CPA.  The receiver decides which delivery channels it will use where and
puts this into the CPP.  Delivery channels are uniquely identified within
the CPP (ID attributes) and it doesn't matter whether two or more will have
the same transport.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



David Fischer <david@drummondgroup.com> on 08/20/2001 08:32:35 PM

To:   "Christopher Ferris (E-mail)" <chris.ferris@east.sun.com>
cc:   "ebXML Messaging (E-mail)" <ebxml-msg@lists.oasis-open.org>
Subject:  RE: T2 SyncReply and ReliableMessagingMethod in
      QualityOfServiceInfo



Maybe I acceded to quickly?  I am trying to understand how to use another
delivery channel to support SyncReply.  I see CPAid in the MessageHeader so
the
receiving end knows which CPA to use.  I guess the DeliveryChannel is
chosen
based upon which transport is involved.

What if there are two DeliveryChannels with the same transport.  One HTTP
w/
SyncReply=True and one HTTP w/ SyncReply=False, how does the receiver know
which
one to use?  The CPAid would be the same.  Do we need to append the
DeliveryChannel ID on the end?

     <eb:CPAid>CompanyA-003</eb:CPAid>

Where CPAid is "CompanyA" and the DeliveryChannel ID is "003"?  I'm not
sure how
the sender tells the receiver which DeliveryChannel to use.  Please forgive
my
ignorance but, how does this work?

David Fischer
Drummond Group.

-----Original Message-----
From: David Fischer [mailto:david@drummondgroup.com]
Sent: Friday, August 10, 2001 10:37 AM
To: Arvola Chan
Cc: ebXML Messaging (E-mail)
Subject: RE: T2 SyncReply and ReliableMessagingMethod in
QualityOfServiceInfo


Arvola, I agree with you but I don't think this is a significant enough
Requirement to fight for.  I will accede to the majority as long as it
seems
like a workable solution.

My personal opinion is that everything in the Via (CPA message related
parameters) should also be represented in MessageHeader -- again I don't
feel
strongly enough about this to fight for it very much.

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: christopher ferris [mailto:chris.ferris@east.sun.com]
Sent: Friday, August 10, 2001 6:09 AM
To: Arvola Chan
Cc: David Fischer; Burdett David; ebXML Messaging (E-mail);
ebxml-cppa@lists.oasis-open.org
Subject: Re: T2 SyncReply and ReliableMessagingMethod in
QualityOfServiceInfo


Arvola,

It was not the intent to require use of the syncReplyMode
attribute (and hence the Via). The two parties exchanging
messages point-to-point are assumed to "know" by virtue of
their CPA (or the virtual equivalent of one) what their
syncReplyMode is. The Via element needs this because the
intermediaries don't have access to this information.

Cheers,

Chris

Arvola Chan wrote:
>
> David:
>
> I don't think using a second DeliveryChannel will work. The following is
an
> excerpt from the CPP/A spec:
>
> The ebXML Message Service's syncReply attribute is set to a value of
"true"
> whenever the 1190
> syncReplyMode attribute has a value other than "none". 1191
>
> Even if you have a channel that calls for the use of synchronous reply
mode,
> the syncReply attribute still has to be set. In other words, it is still
> necessary to use the Via element if the syncReply attribute is present
only
> there, but this constradicts the assumption that the Via element is only
> used when intermediaries are involved.
>
> -Arvola
>
> ----- Original Message -----
> From: "David Fischer" <david@drummondgroup.com>
> To: "Arvola Chan" <arvola@tibco.com>; "Burdett David"
> <david.burdett@commerceone.com>
> Cc: "ebXML Messaging (E-mail)" <ebxml-msg@lists.oasis-open.org>
> Sent: Thursday, August 09, 2001 7:45 PM
> Subject: RE: T2 SyncReply and ReliableMessagingMethod in
> QualityOfServiceInfo
>
> > This was my original proposal, syncReply in both.  However, I was told
> this
> > could be accomplished using a second DeliveryChannel.  While this is
not
> my
> > first preference, it would work...  <shrug>
> >
> > David Fischer
> > Drummond Group
> >
> > -----Original Message-----
> > From: Arvola Chan [mailto:arvola@tibco.com]
> > Sent: Thursday, August 09, 2001 12:24 PM
> > To: Burdett David; David Fischer (E-mail)
> > Cc: ebXML Messaging (E-mail)
> > Subject: Re: T2 SyncReply and ReliableMessagingMethod in
> > QualityOfServiceInfo
> >
> >
> > David:
> >
> > I was mostly concerned with how to obtain synchronous replies in the
> single
> > hop case, assuming the Via element is to be used exclusively for
multi-hop
> > scenarios. I didn't realize there is a need to have syncReply vary hop
by
> > hop.
> >
> > I think it is reasonable to have syncReply both in the QOS and in the
Via
> > elements, and to say that the information in the Via element overrides
the
> > information in the QOS element. I don't have any particular preference
> > between the names Via versus RoutingHeader.
> >
> > Thanks,
> > -Arvola
> >
> > -----Original Message-----
> > From: Burdett, David <david.burdett@commerceone.com>
> > To: David Fischer (E-mail) <david@drummondgroup.com>; 'Arvola Chan'
> > <arvola@tibco.com>
> > Cc: ebXML Messaging (E-mail) <ebxml-msg@lists.oasis-open.org>
> > Date: Thursday, August 09, 2001 9:57 AM
> > Subject: RE: T2 SyncReply and ReliableMessagingMethod in
> > QualityOfServiceInfo
> >
> >
> > >Arvola
> > >
> > >I disagree. You need syncReply in the Via. The attached PDF file
titled
> > "Why
> > >you need syncReply in the Via" contains a diagram which illustrates
the
> use
> > >case. Where the first hop is synchronous and the second not.
> > >
> > >If we want Via to be used only when intermediaries are being used then
> you
> > >would need ackRequested held elsewhere, e.g. in the Quality of
Service.
> > >However since syncReply can vary from hop to hop (see previous
example),
> > you
> > >would then need to also have it in the Via and a rule that the Via
> > >over-rides the QoS.
> > >
> > >There is also the issue that the sender of a message may not know that
it
> > is
> > >multiple hop as the PDF file titled "Using ebXML RM behind the
firewall"
> > >illustrates. In this case external communications are done
synchronously,
> > >but the messaging to an application within the company is done
> > >asynchronously.
> > >
> > >I think we need to keep ackRequested and syncReply in the Via, but
rename
> > it
> > >... to "Routing Header" perhaps, although I have no strong preference
...
> > ;)
> > >
> > >I'd appreciate your thoughts on these use cases.
> > >
> > >David
> > >PS Slides very similar to these two were posted ages ago and discussed
in
> > >Tokyo last November I think.
> > >
> > >
> > >-----Original Message-----
> > >From: Arvola Chan [mailto:arvola@tibco.com]
> > >Sent: Wednesday, August 08, 2001 6:59 PM
> > >To: David Fischer; ebXML Msg
> > >Subject: Re: T2 SyncReply and ReliableMessagingMethod in
> > >QualityOfServiceInfo
> > >
> > >
> > >David:
> > >
> > >Sorry for the delayed response. I agree with you that the Via element
> > should
> > >be used exclusively for those cases where intermediaries are involved.
> > >Therefore, it makes sense to move the syncReply and ackRequested
> attributes
> > >to be under the QualityOfServiceInfo element.
> > >
> > >Since there already is a deliverySemantics attribute under the
> > >QualityOfServiceInfo element, and the reliableMessagingMethod
attribute
> can
> > >vary from one hop to another, I think reliableMessagingMethod should
stay
> > in
> > >the Via element.
> > >
> > >Regards,
> > >-Arvola
> > >
> > >-----Original Message-----
> > >From: David Fischer <david@drummondgroup.com>
> > >To: ebXML Msg <ebxml-msg@lists.oasis-open.org>
> > >Date: Monday, August 06, 2001 8:51 PM
> > >Subject: T2 SyncReply and ReliableMessagingMethod in
QualityOfServiceInfo
> > >
> > >
> > >There should be nothing in the Via which is not also in other headers.
> Via
> > >should only be used for multi-hop intermediaries.  In the case of
> > SyncReply,
> > >there is no single-hop way of requesting SyncReply=true.
> > >
> > >Attributes SyncReply and ReliableMessagingMethod should also be in
> > >QualityOfServiceInfo.  They should retain their current defaults.
> > >
> > >Regards,
> > >
> > >David Fischer
> > >Drummond Group.
> > >
> > >
> > >------------------------------------------------------------------
> > >To unsubscribe from this elist send a message with the single word
> > >"unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
> > >
> > >
> > >------------------------------------------------------------------
> > >To unsubscribe from this elist send a message with the single word
> > >"unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
> > >
> > >
> >
> >
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org


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