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,

Concur.

I'm excited about the possiblities here.  Clearly there is a huge opportunity to get this all right in a very elegant way.

Nothing else out there comes even close at the moment - so this is truly ours to do!

DW

> -------- Original Message --------
> Subject: RE: [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 9:41 am
> To: "David RR Webber (XML)" <david@drrw.info>
> Cc: "Durand, Jacques R." <JDurand@us.fujitsu.com>, 
> <ebxml-msg@lists.oasis-open.org>
> 
> David,
> 
> My concern is that the message metadata that ties the message into
> larger units of work needs to be supported for all messages other than
> those of use only to the MSH (these are now in v3 mainly RM acks and
> setup/takedown things)
> 
> ebXML is supposed to be usable in whole or in part. Sometimes the focus
> is more on usability in part; this focus yields a lot of optionality
> concerns.
> But it is equally important to provide support for agreements and
> contracts at higher levels, including those implicit in CPPA and ebBP
> and BIEs eventually. That is why the inclusion of the metadata "indices"
> such as To From AgreementRef Service Action Role is something that
> should be close to the default, and only omitted when clearly not needed
> (as for low level MSH concerns).
> 
> Anyway that is my point in reminding this thread of the other parts of
> ebXML. There is ongoing adoption of these other core areas of
> functionality that join existing users in still expecting and requesting
> support.
> 
> 
> 
> -----Original Message-----
> From: David RR Webber (XML) [mailto:david@drrw.info] 
> Sent: Tuesday, March 11, 2008 6:11 AM
> To: Moberg Dale
> Cc: Durand,Jacques R.; ebxml-msg@lists.oasis-open.org
> Subject: RE: [ebxml-msg] Regrets and a remark on: [ebxml-msg] RE: ebms -
> Multi-hop Signal Routing (ebMS-Signal-Routing.doc) uploaded
> 
> 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