David,
DeliveryChannel != service/action. I can have many service/action
pairs serviced at a given delivery channel endpoint. The distinction
between a synchronous and asynchronous endpoint has only to do with
the technical processing and this can be captured as a separate
endpoint identifier and there is nothing precluding the same service/action
serviced by each delivery channel.
Cheers,
Chris
"Burdett, David" wrote:
>
> 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:]
> 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 <>
> To: Martin W Sachs <>
> Cc: ebXML Msg <>
> 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:]
> Sent: Monday, August 20, 2001 10:20 PM
> To: Arvola Chan
> Cc: David Fischer; Christopher Ferris (E-mail); ebXML Messaging
> (E-mail);
> 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 <> on 08/20/2001 09:43:52 PM
>
> To: David Fischer <>, "Christopher Ferris
> (E-mail)" <>
> cc: "ebXML Messaging (E-mail)" <>,
>
> 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 <>
> To: Christopher Ferris (E-mail) <>
> Cc: ebXML Messaging (E-mail) <>
> 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:]
> 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:]
> Sent: Friday, August 10, 2001 6:09 AM
> To: Arvola Chan
> Cc: David Fischer; Burdett David; ebXML Messaging (E-mail);
>
> 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" <>
> > To: "Arvola Chan" <>; "Burdett David"
> > <>
> > Cc: "ebXML Messaging (E-mail)" <>
> > 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:]
> > > 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 <>
> > > To: David Fischer (E-mail) <>; 'Arvola Chan'
> > > <>
> > > Cc: ebXML Messaging (E-mail) <>
> > > 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:]
> > > >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 <>
> > > >To: ebXML Msg <>
> > > >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:
> > > >
> > > >
> > > >------------------------------------------------------------------
> > > >To unsubscribe from this elist send a message with the single word
> > > >"unsubscribe" in the body to:
> > > >
> > > >
> > >
> > >
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to:
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to:
>
> ----------------------------------------------------------------
> 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>
