RE: [ebxml-msg] MOU on intermediate support by conformance profile and other auxiliary documents for ebMS 3.0

["David RR Webber \(XML\)" <david@drrw.info>]

Dale,

 

OK perfect.  That draws everything into context well.

 

I'm familiar with the CDC use cases.  Need to revisit on that.

 

I should be finished with my current CAM upgrade work in next couple of weeks - so can spare some time then to review CDC details again.

Thanks, DW

-------- Original Message --------
Subject: RE: [ebxml-msg] MOU on intermediate support by conformance
profile and other auxiliary documents for ebMS 3.0
From: "Moberg Dale" <dmoberg@axway.com>
Date: Wed, May 07, 2008 2:01 pm
To: "David RR Webber (XML)" <david@drrw.info>
Cc: <ebxml-msg@lists.oasis-open.org>

David,

 

We need to work a bit more on CDC use cases and requirements, but we have the Northern European use cases and functionality covered, with perhaps a few of the fancier features omitted.

 

The use case that two Pull spokes can use the I-cloud to communicate needs more discussion.

 

We can possibly simplify the routing options.

 

For the return paths, we need to resolve conventions for using EPR values, especially for ReplyTo values when non-anonymous. (the question is whether to use the edge intermediary on the Internet as the EPR’s URL or to use the backchannel always or something else—maybe a special URL?)

 

So there are some details that need consensus formation.

 

That is what I had on my short list of areas for MOM, memorandum of misunderstandings.

 

Dale Moberg

 

 

 

---

From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: Wednesday, May 07, 2008 10:53 AM
To: Moberg Dale
Cc: ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] MOU on intermediate support by conformance profile and other auxiliary documents for ebMS 3.0

 

Dale,

 

Looks like a good laundry list.  Did we miss anything?

 

Also - in terms of delivery - assume the 80:20 applies to most of this - and then within that certain critical "must have" details that ensure core functionality will be guaranteed / deeply specified.

 

Then of course figuring out what we need to work on in parallel to get this all formalized.

Thanks, DW

-------- Original Message --------
Subject: [ebxml-msg] MOU on intermediate support by conformance profile
and other auxiliary documents for ebMS 3.0
From: "Moberg Dale" <dmoberg@axway.com>
Date: Wed, May 07, 2008 1:41 pm
To: <ebxml-msg@lists.oasis-open.org>

Goals

 

Transparency where feasible

 

Signature intact where feasible (important aspect of transparency)

 

WSI Conformance where feasible (especially with respect to WSI RSP policy that WS-RX Reliable Messaging headers be signed, including WS-Addressing elements where used within ReliableMessaging)

 

Spoke configuration to services within an I-Cloud should have simplicity of configuration change management.

Specifically, rerouting to services (within the I-Cloud ) can be accomplished without spoke configuration changes”)

 

Hub service destinations and spoke clients have “vanilla” ebMS 3 conformance where feasible. (Some specializations of general functionality and of extension points is allowed.)

 

Additional Implicit Constraints

 

The internal addresses within an I-Cloud can have private IP addresses and DNS names that are not publicly reachable or resolvable in the Internet.

 

Proposed

 

Rerouting by intermediaries can be based on ebMS “metadata” both in forward and return paths.

This functionality is referred to as a “table” mapping ebMS metadata to next hop URLs so that the HTTP POST (or other?) command can be rewritten.

   TBD: This map may be augmented for return paths by keeping a map involving Message-Id and Relates-To values.

 

For ebMS user messages, no special treatment is needed (so far anyway).

 

For ebMS signal messages and for WS clerical messages (such as CreateSequence, CreateSequenceResponse, etc.) several approaches are under consideration

  1. Define a ebMS Reference Parameter that allows the wsa attribute “isReferenceParameter” applied and that contains the metadata needed for routing.

  2. Allow use of WS-Addressing headers such as From or ReplyTo or FaultTo that have an EndpointReference model (and include ReferenceParameter within the EPR).

  3. For return path, if WS-Addressing Messaging-Id was present in incoming message, require use of RelatesTo in response message.

  4. For using the request connection for a response, some read-only access to ReplyTo is needed to check for the “anonymous” URL value.

     In this case, all intermediaries would be expected to hold the connection open (?) to allow the final service to use the HTTP backchannel for its response.

 

For Pull MEP-binding, allow first intermediary to handle MPC requests and let internal I-Cloud arrangements for this option be implementation specific.