RE: [ebxml-msg] Regrets and a remark on: [ebxml-msg] RE: ebms - Multi-hop Signal Routing (ebMS-Signal-Routing.doc) uploaded

["David RR Webber \(XML\)" <david@drrw.info>]

Dale,

I tend to agree - but I think any intelligent design would make that optional - so that basic delivery can occur without the additional overhead - but if the sender needs extended delivery options - I feel its not unreasonable that additional markup is required to fulfil that - and of course the risk that somewhere in the delivery stream a system may not support all those options.

DW

> -------- Original Message --------
> Subject: [ebxml-msg] Regrets and a remark on: [ebxml-msg] RE: ebms -
> Multi-hop Signal Routing (ebMS-Signal-Routing.doc) uploaded
> From: "Moberg Dale" <dmoberg@axway.com>
> Date: Tue, March 11, 2008 6:47 am
> To: "Durand,  Jacques R." <JDurand@us.fujitsu.com>, 
> <ebxml-msg@lists.oasis-open.org>
> 
> ebBP signals have been typically handled as a business payload. The
> application can be a native BSI implementation or can be a composite
> consisting of a BSH handler communicating with a legacy application.
> 
> I think adding a header may need to be viewed as a cost of using
> intermediary routing payable by the original sender.
> 
> I have a conflict for Wednesday's meeting with a GS1 Dallas meeting.
> 
> 
> -----Original Message-----
> From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com] 
> Sent: Monday, March 10, 2008 11:30 PM
> To: ebxml-msg@lists.oasis-open.org
> Subject: [ebxml-msg] RE: ebms - Multi-hop Signal Routing
> (ebMS-Signal-Routing.doc) uploaded
> 
>  
> Inline: <JD> 
> 
> -----Original Message-----
> From: Sander Fieten [mailto:sander@fieten-it.com]
> Sent: Monday, March 10, 2008 12:01 PM
> To: Durand, Jacques R.
> Cc: ebxml-msg@lists.oasis-open.org
> Subject: Re: [ebxml-msg] Groups - Multi-hop Signal Routing
> (ebMS-Signal-Routing.doc) uploaded
> 
> All,
> 
> is it really no option to extend signal message with extra header
> information to give intermediaries the ability to route them? Jacques
> mentions, what I think, two main reasons why these message don't contain
> this kind of information. But I do have two remarks on them:
> 
> - I'm not so sure signal messages aren't intended for business delivery.
> The receipt signal for example could have value at the business level
> because it could confirm in a legally valid way that a message was
> received.
> 
> <JD> the TC decided to NOT have business headers in Receipts for a
> reason. As I remember it was that validating the digest (for
> non-repudiation of Receipt) - if ever done - is typically an operation
> that is done separately from any business process - does not need to
> surface into the application run-time that issued the User message. It
> is more of a security service. Like for any other security validation,
> the application needs be notified only in case of problem.
> Now, if one really wants to deliver this Receipt to the application,
> that is an implementation option that is still available: Since the
> original MSH is generally persisting the User message until it can
> validate the Receipt, it is easy to use this User message header to bind
> properly the Receipt to the application layer.</JD>
> 
> 
> - I agree that extra headers would be unnecessary overhead when the
> message exchange is done peer-to-peer, so there's no need for routing
> information. In a multi-hop situation however messages must include
> information which enables intermediaries to route them to their
> destination.
> 
> <JD> So because an endpoint (Core V3-compliant) MSH is not supposed to
> implement additional features, and is not even supposed to know if it is
> talking to an intermediary or just another endpoint MSH, our proposal is
> here that the first intermediary (the "Gateway") adds the necessary
> routing info. That way, the endpoint MSH behaves exactly the same in
> peer-to-peer vs. I-Cloud situations: it does not have to care.</JD>
> 
> 
> Both the Receipt and Error signal do already contain this information by
> the RefToMessageId attribute. Routing on this field would however
> require each intermediary to have an administration of received message
> ids with their related sender, otherwise the reverse path can't be
> determined. I think we can agree that this isn't a very realistic
> solution. 
> 
> <JD> And I certainly do agree because that is not at all what we
> suggested. In Option 1, the same header data as in he User message would
> be used for Signals. The only difference is, the first intermediary on
> the Signal path is adding this header, not the endpoint MSH. The only
> "administration" needed on the Gateway intermediary, is to remember
> header data from a User message until a response is obtained. No
> preliminary set-up is needed to do that.</JD>
> 
> 
> Therefor it seems reasonable to me to extend signal messages with header
> information to make it possible for intermediaries to route them to
> their destination.
> 
> <JD> I think it is not hard to find use cases where relying on "header
> data" to route a Signal back home, is not a realistic solution at all.
> An alternative like using wsa inside the I-Cloud (our Option 2) is more
> attractive, because it leverages an important fact about Signals that
> are responses to User messages: their destination is known from the
> start, unlike the destination of a User message. (and in case their
> destination had to be other than the User message origin, wsa ReplyTo
> header still handles this quite well) </JD>
> 
> -Jacques
> 
> 
> 
> Regards
> Sander
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php