Re: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceI nfo

[Arvola Chan <arvola@tibco.com>]

Marty and David:

As I have indicated in my recent messages to Hima, there are still
issues with how the Service and Action elements ought to be
populated with values obtained from the business process specification.

http://lists.oasis-open.org/archives/ebxml-cppa/200108/msg00200.html
http://lists.oasis-open.org/archives/ebxml-cppa/200108/msg00206.html

I think we should make sure that business processes specified using
BPSS can have their messages easily transportable by the Messaging
Service.

To address the rarer scenarios, I am in favor of allowing one or more
namespace qualified extension elements at the same level as

>- From Party
>- To Party
>- Service
>- Action
>- Conversation Id
>- RefToMessageId
>- CPAId

Currently, it is possible for anyone to directly extend the SOAP header,
but I think adding extensibility to the eb:MessageHeader is preferrable.

Regards,
-Arvola

-----Original Message-----
From: Martin W Sachs <mwsachs@us.ibm.com>
To: Burdett, David <david.burdett@commerceone.com>
Cc: 'Arvola Chan' <arvola@tibco.com>; David Fischer
<david@drummondgroup.com>; ebXML Msg <ebxml-msg@lists.oasis-open.org>;
ebxml-cppa@lists.oasis-open.org <ebxml-cppa@lists.oasis-open.org>
Date: Monday, August 27, 2001 11:23 AM
Subject: RE: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceI
nfo


>
>David,
>
>I think that RosettaNet is hardly a rare case but I will wait for Arvola to
>answer this one since he brought up the inadequacy of service and action.
>
>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
>***************************************************************************
**********
>
>
>
>"Burdett, David" <david.burdett@commerceone.com> on 08/27/2001 01:08:12 PM
>
>To:   Martin W Sachs/Watson/IBM@IBMUS
>cc:   "'Arvola Chan'" <arvola@tibco.com>, David Fischer
>      <david@drummondgroup.com>, ebXML Msg
>      <ebxml-msg@lists.oasis-open.org>, ebxml-cppa@lists.oasis-open.org
>Subject:  RE: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceI
>      nfo
>
>
>
>Hi Marty ...
>
>>>>considering that there are still open questions on service and action,
>whether two levels of routing are sufficient<<<
>
>Our experience shows that you can **never** cover all cases. There is
>always
>some odd business reason that requires you, in relatively rare
>circumstances, to look into the payload to determine where to send a
>message. This makes me think that we should not try to cover every possible
>case and, instead use an approach that meets the need of most situations.
>In
>implementation terms what this means is that these "relatively rare"
>messages are first routed to an custom application that can look into the
>payload and work out what to do. The custom application then forwards the
>message to the required application.
>
>However I do think that with good business process design you can get
>around
>these propblems. So do you think that the current list of message header
>elements are sufficient:
>- From Party
>- To Party
>- Service
>- Action
>- Conversation Id
>- RefToMessageId
>- CPAId
>
>...
>
>I also completely agree with you about getting version 1.1 out as soon as
>we
>can. The timetable we agreed at our meeting in Dallas was along the
>following lines:
>1. Get comments by August 17th
>2. Prepare list of changes and review in F2F - by end September early
>October
>3. Publish draft of version 1.1 by early November
>4. Review spec following normal OASIS guidelines
>
>David
>
>
>-----Original Message-----
>From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
>Sent: Sunday, August 26, 2001 2:52 PM
>To: Burdett, David
>Cc: 'Arvola Chan'; David Fischer; ebXML Msg;
>ebxml-cppa@lists.oasis-open.org
>Subject: RE: T2 SyncReply and ReliableMessagingMethod in
>QualityOfServiceI nfo
>
>
>
>David,
>
>I was referring specifically to v 1.1.  In the long run, you are probably
>right but considering that there are still open questions on service and
>action, whether two levels of routing are sufficient, and also whether
>RefToMessageId should be specifically defined as identifying the message to
>which a response message is responding, I have to view that as post Ver.
>1.1.  Meanwhile, it works today if we admit that each delivery channel has
>a unique endpoint address although, as you point out, it can get fairly
>cumbersome.
>
>Editorial note:  It is becoming increasingly clear to me that the CPPA and
>MSG teams should focus on completing Version 1.1 as quickly as possible and
>getting it approved as an OASIS standard.  For various political and
>marketing reasons, "OASIS Standard" will sound more compelling that "ebXML
>Specification". "Completing it quickly" means triaging and moving
>everything that is more than a clarification or agreed bug fix out beyond V
>1.1.
>
>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
>***************************************************************************
*
>
>*********
>
>
>
>"Burdett, David" <david.burdett@commerceone.com> on 08/24/2001 08:18:28 PM
>
>To:   "'Arvola Chan'" <arvola@tibco.com>, David Fischer
>      <david@drummondgroup.com>, Martin W Sachs/Watson/IBM@IBMUS
>cc:   ebXML Msg <ebxml-msg@lists.oasis-open.org>
>Subject:  RE: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceI
>      nfo
>
>
>
>Folks
>
>I strongly agree with Arvola.
>
>It is unrealistic require in the ebXML Messaging spec that each delivery
>channel has a different endpoint. You should be able to use Service and
>Action to identify which application should receive a message instead and
>then route, if you want to, all messages to the same endpoint.
>
>Consider, for example, a payment service operated by a bank. This could
>potentially be included in many different collaborations and CPAs for the
>eCommerce sites that use the bank's service to do a credit card payment.
>
>I would suggest that what the bank wants to do is publish a single URL to
>which all (or many) messages from different businesses are sent rather than
>vary it for each business.
>
>... or am I missing something ...
>
>David
>
>-----Original Message-----
>From: Arvola Chan [mailto:arvola@tibco.com]
>Sent: Tuesday, August 21, 2001 8:29 AM
>To: David Fischer; Martin W Sachs
>Cc: ebXML Msg
>Subject: Re: T2 SyncReply and ReliableMessagingMethod in
>QualityOfServiceInfo
>
>
>David:
>
>Marty is saying that we need to at least require delivery channels to
>have unique endpoint addresses for 1.1.
>
>Using the ServiceBinding override mechanism, it is possible to
>specify a delivery channel with syncReplyMode for a particular
>action (for the receiver).
>
>From the CPA, both the sender and the receiver should know that the
>action in question is associated with a unique delivery channel. When a
>message arrives on the associated endpoint address, the receiver
>should have no difficulty to know that it has to respond synchronously
>because the delivery channel is a synchronous one.
>
>-Arvola
>
>-----Original Message-----
>From: David Fischer <david@drummondgroup.com>
>To: Martin W Sachs <mwsachs@us.ibm.com>
>Cc: ebXML Msg <ebxml-msg@lists.oasis-open.org>
>Date: Tuesday, August 21, 2001 8:00 AM
>Subject: RE: T2 SyncReply and ReliableMessagingMethod in
>QualityOfServiceInfo
>
>
>This is exactly the problem I see.  How do I send to the same address but
>slightly vary the parameters (change SyncReply from True to False)?  Chris
>suggested (I think) that all that was necessary was to define another
>DeliveryChannel.  I don't understand how this solves the problem since I
>can't
>figure out how to tell the receiver which DeliveryChannel to use -- maybe I
>can't by design which means this solution won't work.  This is too tightly
>coupled!
>
>Am I missing the mark?  If not, then I need to go back to my original
>premise
>that SyncReply needs to be in MessageHeader.
>
>Regards,
>
>David Fischer
>Drummond Group.
>
>-----Original Message-----
>From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
>Sent: Monday, August 20, 2001 10:20 PM
>To: Arvola Chan
>Cc: David Fischer; Christopher Ferris (E-mail); ebXML Messaging
>(E-mail); ebxml-cppa@lists.oasis-open.org
>Subject: Re: T2 SyncReply and ReliableMessagingMethod in
>QualityOfServiceInfo
>
>
>
>Arvola,
>
>It's late at night and I have just gone through 140 emails accumulated
>Friday and today so maybe I am getting a bit dull.
>
>Each party knows about its delivery channels and the other party's delivery
>channels and which one goes with each business transaction.  This is the
>information that is in the CPA and has to be installed in each party's
>system.
>
>The missing element in your posting is the endpoint address, defined for
>each delivery channel.  As long as each delivery channel has a unique
>endpoint address, the From MSH should have no ambiguity in where to send
>each message and the To MSH has no ambiguity in which delivery channel to
>use for a received message.  Service and Action should be needed only by
>the To Party's MSH and only for routing to the application entry point.
>There may be a problem if one wants to define two delivery channels with
>the same endpoint address but slight variations in some parameters.  I
>believe that we have assumed that each delivery channel has a unique
>endpoint address but I suspect that we don't say so.  Allowing two
>different delivery channels to share an endpoint address would certainly
>require an additional piece of information that the To MSH would need to
>use to identify the correct receive channel for an incoming message.
>
>I suggest that V1.1 state that every delivery channel SHALL have a unique
>endpoint address (if V1.0 doesn't say so).  For V2.0, we could consider
>permitting different delivery channls to share the same endpoint address
>and adding whatever disambiguator is required to make this work.
>
>Regards,
>Marty
>
>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
>***************************************************************************
*
>
>
>****
>*****
>
>
>
>Arvola Chan <arvola@tibco.com> on 08/20/2001 09:43:52 PM
>
>To:   David Fischer <david@drummondgroup.com>, "Christopher Ferris
>      (E-mail)" <chris.ferris@east.sun.com>
>cc:   "ebXML Messaging (E-mail)" <ebxml-msg@lists.oasis-open.org>,
>      ebxml-cppa@lists.oasis-open.org
>Subject:  Re: T2 SyncReply and ReliableMessagingMethod in
>      QualityOfServiceInfo
>
>
>
>David and Chris:
>
>I have a similar issue. It is not clear to me that a sender MSH
>can uniquely determine a delivery channel to be used to send to
>a receiver without knowing the collaboration role played by the
>receiver.
>
>The structure of the CPP/A elements is such that a Party
>may play multiple collaboration roles. For each such role,
>there can be one or more prioritized service bindings. Each
>service binding has a service element that essentially identifies
>the service provided by the party in question. Each service
>binding specifies a default delivery channel, along with zero
>or more override elements. Each override element pertains
>to a particular action and specifies the delivery channel for
>that action.
>
>If the sender knows the role played by the receiver, then it
>is straightforward to determine the delivery channel that should
>be used in order to send the message to the receiver. However,
>there is no role element in the message header. If the Message
>Service Interface is defined in such a way that the burden of
>determining the delivery channel falls on the MSH, then I am
>not sure if the MSH has sufficient information to determine
>the delivery channel. The problem I see is that the service
>name associated with a service binding is not necessarily
>unique. Is it possible to have multiple roles played by the
>same receiver with service bindings that share the same
>service name? If so, it is not clear to me which corresponding
>delivery channel should be used. For this discussion, let's assume
>that none of the service bindings in the CPA have override elements.
>Thus, it is not possible to use the Action element in the message
>header to determine the delivery channel.
>
>Regards,
>-Arvola
>
>-----Original Message-----
>From: David Fischer <david@drummondgroup.com>
>To: Christopher Ferris (E-mail) <chris.ferris@east.sun.com>
>Cc: ebXML Messaging (E-mail) <ebxml-msg@lists.oasis-open.org>
>Date: Monday, August 20, 2001 5:33 PM
>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>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>