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

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:] 

Sent: Thursday, April 09, 2009 8:31 AM
To: Jacques R. 
Durand; 
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