RE: [ebxml-msg] Issue about transparent multihop for "Bridged Domains"

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

Hi Jacques,

 

Is it necessary to handle the case of the private domain as a protocol continuation? That is, would it not be possible to view the communication of endpoint with gateway as a distinct communication unit of work, and subsequent “hops” as simply a new messaging connection?

 

In fact, when talking to a domain gateway, the gateway will typically integrate with further internal components in some integration architecture (WS, SOA, ESB, EAI, JMS, MQ, J2EE, Spring, SCA, etc etc.) ebMS could, of course, be used as a collaboration protocol between gateway and internal components, but no special provisions need to be made for that case. It is just a chain of distinct messaging protocols. No state has to be aligned between the external protocol state and the internal protocol state (though in practice such alignment may be enforced at an application level and by various rules, SLAs and the like, within the domain).

 

So I would summarize by saying that we should not enter into standardizing integration architectures. There are more than enough available (some would say too many!)

 

Dale Moberg

 

Subject: [ebxml-msg] Issue about transparent multihop for "Bridged Domains"

 

 

Issue: the assumption that "transparent multihop" applies to bridged domains (in the same way as it applies to Hub-and-spoke and Interconnected-Hubs topologies) is overly restrictive:

- In many applications, a B2B Gateway is where security and reliability are expected to be handled, as what is beyond the gateway is a private domain with QoS needs (and contractual needs) different from the public side.

 

Proposal:

- Make the principle of "transparent multihop" just one mode of multihop supported by ebMS part 2.

In another mode - "serviceable multihop" , intermediaries (typically edge-intermediaries) could modify the SOAP envelope before forwarding - add/remove security or reliability headers, even bundle/unbundle. In both modes, intermediaries never modify User Message units or Signal Message units.

- Keep the current draft focused on "transparent multihop", but make sure that it does not preclude "serviceable multihop" which could be described in a future conformance profile (e.g. transparent and serviceable correspond to two levels of conformance for intermediaries)

 

-jacques