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

["Jacques R. Durand" <JDurand@us.fujitsu.com>]

Dale:

 

The problem I see with the Gateway as an endpoint that deals with internal MSHs, is that we loose all the benefit of ebms routing in that case:

We go at length defining an ebMS routing mechanism, and there we are saying that just because we want this Gateway to process some SOAP headers (security, reliability), then that's beyond the scope of multihop routing as we define it...

 

In practice, won't people still want to use the same routing mechanism already available in multihop-compliant MSHs, when this Gateway talks to other MSHs internally ? If tomorrow the company policy requires this security / reliability to be handled by ultimate endpoints instead of by Gateway (i.e. back to transparent mode) or vice-versa,  the routing remains the same.

 

I don't think we are attempting to standardize integration architectures: it just happens that this one is one of the three we list at the beginning of the section as our multihop requirements. It is just about supporting it better like we do for others, not standardize it.

 

I believe it would take little change to the spec to downgrade "transparent multihop" from the status of "core principle" down to a mutlihop mode not excluding the other mode. (After all, isn't that what the SOAP model is expecting: some headers will be processed by some nodes on the way to final destination? All this can easily be done by targeting these headers to a new intermediary role.)

 

Should we decide to "open" the definition of  multihop that way, I don't think it takes much work. Mostly 2 options:

 

- (a) a simple editorial treatment of the notion of "transparent multihop", making it a multihop mode that does not exclude the other mode that allows for QoS header preprocessing, even if we don't describe that mode in this specification.

 

- (b) specify only the wire representation of a message intended for QoS-preprocessing multihop. So far I believe it is sufficient for interoperabilty to define a SOAP role that the QoS headers need to target - (need a bit more investigation to be sure of that).

 

-jacques

---

From: Moberg Dale [mailto:dmoberg@axway.com]
Sent: Thursday, April 09, 2009 8:31 AM
To: Jacques R. Durand; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Issue about transparent multihop for "Bridged Domains"

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