Inline
<JD>
Original Message-----
From: Sander Fieten
[mailto:sander@fieten-it.com]
Sent:
Wednesday, June 18, 2008 1:10 PM
To: Durand, Jacques R.
Cc:
ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Groups - Multi-hop
Section Draft 0.4 (ebMS3-Multihop V04.doc) uploaded
Jacques,
below
are my comments on the new text.
Sander
Line 138-143:
In
this paragraph you define the forwarding function in terms of MSH roles as
defined in the core spec and state that an intermediary acts both as a sending
and as a receiving MSH. The core spec states that an MSH acting in the sending
role supports the abstract operations Submit, Send and Notify and the receiving
role the operations Receive, Notify and Deliver. Because the intermediary isn't
bound to a Consumer, like endpoint MSH's, there seems to be no need to support
all these abstract operations. The only operations an intermediary will support
are Receive, Notify and Send. So I would think we should define the intermediary
as a separate role with support for these three abstract
operations.
<JD> Right.
Is it an
idea to define MEP bridging, i.e. using different MEP for the Receive and Send
operation, as a separate function of an intermediary?
<JD> OK.
Line 145-148:
As I wrote before I
would favor the label "address information" for the information contained in the
message that defines the destination of the message and use "routing
information" as the information that is configured in the intermediary and that
defines a mapping from an address to a next hop.
<JD> how about:
- information contained in the message =
"routing input" (since it is what will be fed to the routing
function configured in the Intermediary)
- information that is configured in
the intermediary = "routing rules" (a set of these
defines the routing function. This name allows to break it up in
smaller parts - the rules, that may need to be updated independently. Also
subparts of the Input - Service, Action, ToParty... - will be used by different
rules.)
Otherwise address information is confusing: the routing input
might be very remotely related to an address, e.g. in some Intermediary,
could just be "Service/Action" value. Hardly address
information (the address information is actually what
teh routing function is generating).
I feel that the difference
between these two types of information is made clearer, but it's more a matter
of personal taste.
On line 146 however it is stated that different parts of the ebms header
are used by intermediaries. Shouldn't that be different part of the ebms message
as routing information can be in the ebms header but also in WS-A headers?
<JD> not necessarily: you could have Intermediary X
that uses ToParty info, then Intermediary Y that uses Service/Action (for
the same party). Both are present in eb:UserMessage element, regardless if this
element is in eb:Messaging or in a wsa ref parameter header.
Line
155-213 Details of the Routing Function:
I still think that using the same
(named) element in both the ebMS message and the WS-A header is confusing,
certainly because the WS-A header will be attached to non ebMS user messages.
Using eb:UserMessage leads to non ebMS user messages and even non ebMS messages
containing an eb:UserMessage element.
<JD> this
is mostly for parsing convenience: ideally the routing function (routing rules)
should use the same element as "routing input" regardless how it is
packaged in the message (as an wsa ref parameter or as an eb:Messaging child). I
think in our case its OK that non-ebMS messages use such an element: after all,
these non-ebms messages are still candidate for "ebMS routing": the presence of
an ebms-namespaced element is what qualifies them for ebms (intermediary)
processing. It is actually expected that some
app-dependent namespaces be found in ref parameters. See example in http://www.w3.org/TR/ws-addr-soap
:
<wsa:EndpointReference
... xmlns:fabrikam="http://example.com/fabrikam"
>
<wsa:Address>http://example.com/fabrikam/acct</wsa:Address>
<wsa:Metadata>
<wsaw:InterfaceName>fabrikam:Inventory</wsaw:InterfaceName>
</wsa:Metadata>
<wsa:ReferenceParameters>
<fabrikam:CustomerKey>123456789</fabrikam:CustomerKey>
<fabrikam:ShoppingCart>ABCDEFG</fabrikam:ShoppingCart>
</wsa:ReferenceParameters>
</wsa:EndpointReference>
On 17 jun 2008, at 09:01,
jdurand@us.fujitsu.com wrote:
> V0.4: incremental update from
V0.3.
> - section 1.5 (Intermediary Role) rewritten, though not complete
yet.
> (diff
> with 0.3 visible). For
review.
>
>
> -- Mr Jacques Durand
>
> The
document revision named Multi-hop Section Draft 0.4 (ebMS3-
>
Multihop
> V04.doc) has been submitted by Mr Jacques Durand to the OASIS
ebXML
> Messaging Services TC document repository. This document is
revision
> #2 of ebMS3-Multihop.doc.
>
> Document
Description:
> Draft of the multi-hop section.
> V0.3:
> - a
few updates in the definition section (editorial)
> - added a commented
Flow diagram (section 1.7.1) on RM sequence
> establishment. To
review.
> V0.4:
> - section 1.5 (Intermediary Role) rewritten,
though not complete yet.
> (diff with 0.3 visible)
>
> View
Document Details:
> http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/document.php?do
> cument_id=28566
>
> Download Document:
>
http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/download.php/28
> 566/ebMS3-Multihop%20V04.doc
>
> Revision:
>
This document is revision #2 of ebMS3-Multihop.doc. The document
>
details page referenced above will show the complete revision
history.
>
>
> PLEASE NOTE: If the above links do not
work for you, your email
> application may be breaking the link into two
pieces. You may be able
> to copy and paste the entire link address
into the address field of
> your web browser.
>
> -OASIS Open
Administration