[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Groups - Multi-hop Section Draft 0.18 (ebMS3-Multihop V18-Nov07.doc) uploaded
Inline
-Jacques
-----Original Message-----
From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
Sent:
Thursday, November 13, 2008 8:26 AM
To:
ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Groups - Multi-hop
Section Draft 0.18 (ebMS3-Multihop V18-Nov07.doc)
uploaded
Hello,
Here are some comments on this draft, up
to and including section 1.5.
(Line numbers refer to "Final" view, not "Final
Showing Markup").
General:
This document is not about just any
type of multihop messaging as we focussed on a specific type of multihop
messaging: "transparent" multihop. I think we should be clearer about this, e.g.
have a more specific title (and leave open the option of future additional
profiles that may be designed for other requirements so that may not be
"transparent"). Is there any reason why section 1.4 (which roughly describes
these requirements) does not use the term
"transparent"?
added this in "Assumptions" and also mentioned in 1.4.1.
General:
The document starts at 1.1 and
ends at 1.11. I don't think there will be a second, third chapter at some
point in this profile? If not, we should reorganize the text in a smaller
number of main chapters.
Right - for next revision...
General:
People asked for some text/examples about intermediary
routing to explain the benefits of intermediaries and I provided some text some
time ago, but it was never discussed. It is illustrative, not part of the
technical specification, but could still add value as an appendix.
will look into this.
Line 30, "An Endpoint MSH can not act as an Intermediary MSH": but
some MSHs will be endpoints for some messages and intermediaries for others
(discussed in 58-60). The decision whether to forward (to next MSH) or
deliver (locally) is a kind of "routing" function in itself. Similarly, some
nodes could be "edge hops" for some messages and I-Cloud hops for others.
The
original goal for "transparency" was that an MSH does not need to know if the
next hop it is talking to is an endpoint or another intermediary, so that
networks can be reorganized without impacting the endpoints.
Right - improved on this new update.
Line 175-178, Pmodes versus routing function. I'm still not
sure this
distinction is the best terminology or the best way to
describe
configuration in a multihop network. Any message
exchange involves a huge
number of parameters, some of which are only
relevant between adjacent nodes (such as MEP Binding, URL, SSL) and others are
end-to-end parameters related to partner agreements / service contracts (such as
MEP, service, action, security, reliability etc.). With multihop, the
next-hop parameters are no longer "partner agreement" parameters. Instead,
these next-hop parameters apply to any hop, whether between end points in
point-to-point, between endpoints and edge intermediaries, or between
intermediaries not connected directly to endpoints.
Do the changes in this new update help this?
Will look into the remaining comments for the next rev. I believe several of tehse are addressed in this new update I just posted, answering comments from Sander.
-Jacques
Section 1.5.2.1
The way you've described the MEP bindings and MEP
bridging is an improvement and more similar to the way I've described this over
a year ago in the requirements document posted at:
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]