ebXML multi-hop messaging -- some additional thoughts

[Philippe DeSmedt <PDeSmedt@viquity.com>]

All,

Please allow me to contribute some thoughts to the e-mail exchanges that
have taken place regarding the provisions for intermediaries in the ebXML
Messaging specification. Having participated in ebXML TR&P for over year,
I've seen the specification develop to where it is today. My apologies if
some of what I am saying below is repetitive of some of the earlier e-mails
on this topic. Also, as Chris Ferris has pointed out, the appropriateness of
multi-hop messaging within the context of ebXML has been discussed at length
in earlier meetings. My purpose here is to summarize my viewpoint, and
identify future directions for the ebXML specifications.

Intermediaries ('hubs') may serve a wide range of purposes. In some cases,
the 'hub' is not a 'trading partner' in the strict sense, but rather a
simple mechanism that assists in the execution of business processes among
trading partners, mostly through message forwarding [case 1]. At the other
end of the spectrum, the 'hub' could be a true participant performing a
service such as, for instance, an auction or a bokering service. In the
latter case, the 'hub' can be considered a true trading partner, as it is a
direct participant in the message/process exchange [case 2]. Somewhere in
the middle is the case where the message exchange is still between 'real'
trading partners, but the 'hub' acts as an intelligent, trusted intermediary
between trading partners, i.e., it is not just a simple router or forwarder,
but rather an infrastructure that assist in or enables the reliable and
secure transmission of the messages, and may offer additional collaborative
services [case 3].

I believe that the ebXML Messaging specification intends to address cases 1
and 3 (as case 2 can be divided up in separate point-to-point exchanges
between the 'hub' and each trading partner respectively).

In case 1, the role of the 'hub' is pretty much to look at the destination
information in the header, and forward the message on to the next link
(either the end destination or another intermediate node). This is similar
to the way e-mail messages travel between sender and recipient. Even in this
conceptually simple case, issues arise as to which path acknowledgements or
error messages should take (i.e., do they travel back to the originator of
the message via the route taken, or directly); a related issue is whether at
any node along the path between source and destination, it can be assumed
that once the message is known to be delivered to the next node, that the
responsibility for delivering the message has now shifted to that next node
(and that the latter node is responsible for 'recovery' of the message, if
necessary). David Burdett's excellent write-up (referenced in some of the
earlier e-mails on this thread) covers a lot of interesting scenarios. Some
of these issues were uncovered during the ebXML proof-of-concept activities.
The current version of the ebXML Messaging specification covers the use of
routing headers for this type of intermediated routing, and discusses the
various acknowledgement scenarios).

Note also that the notion of an intermediary in RosettaNet's RNIF2
specification corresponds to case 1: an unencryptable delivery header has
been separated out from the service header to enable an intermediate node to
determine where to send the message to next. My assumption is that over time
the RNIF specification will evolve to cover more sophisticated uses of a
'hub' as well. Intermediaries were explicitly discussed in the RNIF2
meetings, and what is currently in that specification is what was considered
adequate for now. 

Case 3 is  very different. As in case 1, the business process being executed
is between two partners. Topology-wise, both cases 1 and 3 can be drawn as a
typical hub-and-spoke model. However, there is now also an 'agreement'
between each of the partners and the 'hub'. This agreement is at the
quality-of-service (QoS) level, covering, for instance, reliability and
security: the 'hub' may implement the reliability protocol that is currently
under discussion in the ebXML Messaging working group, and possibly also act
as a 'trusted intermediary'. In that case, a trading partner may trade
securely with the hub using the key-pair for that particular partner-hub
combination, and on the next leg, the hub will deliver the message securely
using the keys for the other partner-hub combination. Hubs may also assist
in protocol conversions in those cases where interoperability between the
ebXML and other protocols is desired, assist in the tracking of business
process execution, etc. These are just some examples of how using a 'hub'
(or hubs) in the middle can be more than just routing messages. The key
point is that, in order to support these 'intelligent hubs', the current
ebXML specifications need to be augmented to account for the fact that
different levels of 'agreement' may exist: TPAs (or whatever the current
accurate term is) cover agreements between trading partners -- they do not
cover case 3. Should TPAs be augmented to account for multiple hops? Do we
need a different form of TPAs to account for intelligent hubs? What in the
messaging specification needs to be changed or augmented? 

In summary, I believe that there is a new breed of intermediaries or hubs
out there, with powerful capabilities that extend beyond mere routing of
messages. In order to support them, we need to ensure that the
specifications that come out of ebXML and other bodies address some of the
issues that I highlighted above. With that in mind, I'm glad to see that
ebXML Messaging is moving in the right direction, though obviously more work
is required.
_______________________________
Philippe De Smedt
Architect
Viquity Corporation (www.viquity.com)
1161 N. Fair Oaks Avenue
Sunnyvale, CA 94089-2102
(408) 548-9722
(408) 747-5586 (fax)
pdesmedt@viquity.com