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

["Moberg Dale" <dmoberg@axway.com>]

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