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

["Pim van der Eijk" <pvde@sonnenglanz.net>]

Hello,

Thanks for a detailed proposal. A couple of comments:

Line 91-99 and below:  when the TC considered (1) and (2) I was not a
member, but I indicated via TC comment that this would cause routing issues
in multi-hop. The response at the time was that multi hop was not in scope.
Now it is, and now we see why it is an issue ..  

Line 91-100. I think adding more business header information in Signals is a
serious option, especially if it results in intermediaries having to
implement only one routing mechanism instead of two separate ones.  Those
elements could be optional, and a single-hop profile could constrain them to
not be used or to ignore them if used. It could then qualify as an erratum.
We've already seen that achieving end-to-end security may require different
behaviour from endpoints, and there certainly is no eb:RoutingElements
element in the v3.0 Core XSD, so we will need to publish an updated schema
anyway.

Like your option 1, business header routing would require a "reverse
routing" function. For ebMS 2.0 this reverse routing is limited to reversing
eb:From and eb:To. An intermediary that forwards user messages with <From,
To, {other parameters like Service..}> should be configured to reverse route
Signal messages <To, From, {some other parameter values}>.  For most
practical use cases (B2B, G2G, SOA), that seems quite acceptable (see
separate message).

Line 188-192:  I see why you propose that the final MSH sends any Signals
synchronously.  Assuming we want the configuration for MSH B to be the same
(or as similar as possible) whether or not intermediaries are present, the
result is that an MSH A will get Signals synchronously when sending directly
(not via intermediary) and asynchronously when connecting indirectly (via an
intermediary).  OK, but a maximally transparent approach (in my
interpretation of "transparent") would allow an MSH to only change the next
hop URL and possibly TLS security to send via an intermediary instead of
directly. 

Line 255-368:  this proposal has two major advantages: minimal configuration
for Router intermediaries, and it can even support dynamic routing (as
opposed to static routing tables at intermediaries).   But it seems to break
a clean distribution of routing at various levels:
Level 1:  HTTP clients and servers, routing based on next hop URLs.
Level 2:  SOAP nodes (ebMS and non-ebMS), routing based on WS-A headers.  
Level 3:  ebMS nodes, routing based on ebMS headers.
For Signal messages, this proposal is somehow "in between" levels 2 and 3.

Line 359-363:  This is about using a wsa IRI not used as next hop URL but as
a key for a lookup to find a next WSA hop.  Is this standard WS-A
functionality?    Isn't the ultimate consequence of this that all
intermediaries must know about each other and having
intermediary-to-intermediary routing tables?

Reading this section somehow made me think of the "Via" and message trace
elements in version 1.0 ..

Pim

-----Original Message-----
From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com] 
Sent: 12 March 2008 00:31
To: Moberg Dale; David RR Webber (XML)
Cc: 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:

No-one denies the need to bind some ebms signals to the application layer.

I think in the past we looked at two models, concerning "response signals"
(eb:Errors or Receipts responding to other messages):

(1) provide all these signals with a full set of metadata headers as found
in User messages. So these are (can be) bound to the Consumer app the same
way as User messages.  

(2) Do not add business-level metadata in signals, and rely instead on their
association (RefToMessageID) with the related User message and its metadata
- which normally should be persisted long enough in order to make sense of
this signal. 

In both cases, application delivery of these signals (along with related
metadata) is always an option - yet just an option. 

So far I have not heard much of a concern at the time the TC decided to go
along with (2).

In our implementation, Errors are not delivered to the application, but
logged. The application can access this log via an API, or the MSH can be
configured for notification to the app. We treat Receipts the same (logged
after validation). Yet it would be easy for us to add a Receipt delivery
option similar to User messages delivery: we do not need additional headers
for this. 
In solution (1) it is not clear to me what kind of business metadata would
go in an eb:Error message (the same as in the User message in
error?)

We also need to have a closer look at routing options and their cost in the
I-cloud, before evaluating (1) or (2) based on their multi-hop friendliness.

Jacques

-----Original Message-----
From: Moberg Dale [mailto:dmoberg@axway.com]
Sent: Tuesday, March 11, 2008 6:41 AM
To: David RR Webber (XML)
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

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

---------------------------------------------------------------------
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