OASIS ebXML Messaging Services TC

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.

 
We agreed to add ebMS metadata also to signals and 
helper messages. And we also looked in some detail at one 
option for adding this metadata, by adding it to a WSA header.  Imo we did not fully compare 
this option to using a an eb:Messaging header (containing an eb:UserMessage but 
one that has no eb:PayloadInfo) to 
convey the ebMS metadata. I want to fully 
understand both options and compare their pros and 
cons.  Unfortunately, due to travel I 
will not be able to attend next week's meeting.
 
Pim
 




From: Moberg Dale [mailto:dmoberg@axway.com]
Sent: 07 May 2008 19:42
To: 
ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] MOU on 
intermediate support by conformance profile and other auxiliary documents for 
ebMS 3.0




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.

Yes, I agee that adding metadata  to
ebMS signals or to other messages used in WS protocols is what is agreed upon
as a MOU item.



The way or ways to do this is apparently
TBD J



I think that since we have several ways to
attach the metadata, we probably want to prune these down into a simple
convention to do it in a standard way.



(Incidentally, would we then provide CPPA
support for these messages? Would they be treated as msh level messages from
the default packaging and delivery channel standpoint?)











From: Pim van der Eijk
[mailto:pvde@sonnenglanz.net]

Sent: Wednesday, May 07, 2008 1:04
PM

To: Moberg Dale;
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





 

We agreed to add ebMS metadata also to signals and
helper messages. And we also looked in some detail at one option for
adding this metadata, by adding it to a WSA header.  Imo we did not fully
compare this option to using a an eb:Messaging header (containing an
eb:UserMessage but one that has no eb:PayloadInfo) to convey the ebMS
metadata. I want to fully understand both options and compare their
pros and cons.  Unfortunately, due to travel I will not be able to
attend next week's meeting.

 

Pim

 









From: Moberg
Dale [mailto:dmoberg@axway.com]

Sent: 07 May 2008 19:42

To: ebxml-msg@lists.oasis-open.org

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

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.

Here are some reasons why I would 
prefer to use ebMS headers for routing rather than WS-Addressing Reference 
Parameters:

Conformance to v3.0 Core
The ebMS 3.0 Part 1 Core does not specify the use of WS-Addressing. 


Avoid yet another standard to 
support
Requiring support for WS-Addressing in a multihop context adds a burden 
to implement ebMS 3.0 in general and the multihop profile in particular.It is 
also true that the counterproposal requires adding ebMS headers in some 
situations where v3.0 Core does not require them, but any ebMS 3.0 
implementation needs to know how to construct or handle ebMS 3.0 headers anyway, 
so this is just a reuse of that general functionality. 

Inconsistency
If we start using WS-Addressing reference parameters in the multihop 
context, the question comes up why we did not use them in ebMS 3.0 Core. There 
are already elements in the ebMS header that are also in WS-Addressing, such as 
MessageId. Nevertheless, v3.0 Core does not use WS-Addressing even for these 
header fields, let alone use reference parameters for the information types that 
are in an ebMS 3.0 header but are not regular WS-Addressing field. I think the 
ebMS 3.0 header is richer than WS-Addressing header, so that this decision was 
right at the time. But even if it were not, I think a multihop profile should 
stick to the approach taken in v3.0 Core.  

Limited reuse
It might look as if using WS-Addressing is an instance of reusing a more 
general specification instead of defining ebMS specific mechanisms. But unlike 
the reuse of WS-Security or WS-Reliability/WS-ReliableMessaging, this reuse is 
only a syntactic issue. We would just be adding information to some defined 
extension points in the schema. Any processing of that information would require 
ebMS-specific processing, rather than using generic WS-Addressing functionality. 
Any intermediary that provides WS-Addressing functionality and wants to conform 
to this profile would still need to have ebMS-specific 
functionality.

Duplication in message 
structure
Having to store or retrieve the same type of information in two different 
locations usually smells of missed generalizations, and I think that is true 
here too. We looked at putting the equivalent of an ebMS header in a URL (the 
earlier HTTP URL query parameters), I don’t find putting it in WS-Addressing 
parameters a lot more elegant. It also raises issue like how to handle any 
inconsistencies in situations where there is both a WS-Addressing structure and 
an ebMS header. Also, the WS-Addressing specification says that using reference 
parameters to store information that would otherwise be in other SOAP headers 
could 
cause “unintended or erroneous semantics in the resultant SOAP message". 

Generalized routing
This is related to duplication. When using just ebMS 
headers,  assuming routing is done 
on destination PartyId, any 
message (user, signal, WS-* helper, bundles, piggy backs) can be routed based on 
the single following XPath expression:
S:Envelope/S:Header/eb3:Messaging/eb3:UserMessage[1]/eb3:PartyInfo/eb3:To/eb3:PartyId




From: Moberg Dale [mailto:dmoberg@axway.com]
Sent: 07 May 2008 23:14
To: Pim van der Eijk; 
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




Yes, I agee that adding 
metadata  to ebMS signals or to other messages used in WS protocols is what 
is agreed upon as a MOU item.

The way or ways to do 
this is apparently TBD J

I think that since we 
have several ways to attach the metadata, we probably want to prune these down 
into a simple convention to do it in a standard 
way.

(Incidentally, would we 
then provide CPPA support for these messages? Would they be treated as msh level 
messages from the default packaging and delivery channel 
standpoint?)





From: Pim van 
der Eijk [mailto:pvde@sonnenglanz.net]
Sent: Wednesday, May 07, 2008 1:04 
PM
To: Moberg Dale; 
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

 
We agreed to add ebMS 
metadata also to signals and helper messages. And we also looked in some 
detail at one option for adding this metadata, by adding it to a WSA 
header.  Imo we did not fully compare this option to using a an 
eb:Messaging header (containing an eb:UserMessage but one that has 
no eb:PayloadInfo) to convey the ebMS metadata. I want to fully 
understand both options and compare their pros and 
cons.  Unfortunately, due to travel I will not be able to attend next 
week's meeting.
 
Pim
 




From: Moberg 
Dale [mailto:dmoberg@axway.com]
Sent: 07 May 2008 19:42
To: 
ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] MOU on intermediate 
support by conformance profile and other auxiliary documents for ebMS 
3.0
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.

Pim:
 
as discussed today, we have two solutions to pick from, 
none of them being a clear win...
Let me just try to alleviate some of the drawbacks you see 
to WS-addressing:




From: Pim van der Eijk 
[mailto:pvde@sonnenglanz.net]
Sent: Wednesday, May 28, 2008 2:02 
PM
To: 'Moberg Dale'; 
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




Here are some reasons why I would 
prefer to use ebMS headers for routing rather than WS-Addressing Reference 
Parameters:

Conformance to v3.0 Core
The ebMS 3.0 Part 1 Core does not specify the use of WS-Addressing. 



 
Avoid yet another standard to 
support
Requiring support for WS-Addressing in a multihop context adds a burden 
to implement ebMS 3.0 in general and the multihop profile in particular.It is 
also true that the counterproposal requires adding ebMS headers in some 
situations where v3.0 Core does not require them, but any ebMS 3.0 
implementation needs to know how to construct or handle ebMS 3.0 headers anyway, 
so this is just a reuse of that general functionality. 







Inconsistency
If we start using WS-Addressing reference parameters in the multihop 
context, the question comes up why we did not use them in ebMS 3.0 Core. There 
are already elements in the ebMS header that are also in WS-Addressing, such as 
MessageId. Nevertheless, v3.0 Core does not use WS-Addressing even for these 
header fields, let alone use reference parameters for the information types that 
are in an ebMS 3.0 header but are not regular WS-Addressing field. I think the 
ebMS 3.0 header is richer than WS-Addressing header, so that this decision was 
right at the time. But even if it were not, I think a multihop profile should 
stick to the approach taken in v3.0 Core.  

 
Limited reuse
It might look as if using WS-Addressing is an instance 
of reusing a more general specification instead of defining ebMS specific 
mechanisms. But unlike the reuse of WS-Security or 
WS-Reliability/WS-ReliableMessaging, this reuse is only a syntactic issue. We 
would just be adding information to some defined extension points in the schema. 
Any processing of that information would require ebMS-specific processing, 
rather than using generic WS-Addressing functionality. Any intermediary that 
provides WS-Addressing functionality and wants to conform to this profile would 
still need to have ebMS-specific functionality. 
<JD> But we could say as well 
that it is in the nature of wsa to be a "syntactic specification", i.e. unlike 
WS-RM or WSS it does not define precise mechanisms: only some mappings between 
EPR construct and header content, as well as some limited control of the HTTP 
binding and some cross-message correlation features. Now, besides the 
header aspect,  the notion of EPR appears to be a convenient modeling construct that can be reused 
in PModes, and is able to wrap up all data needed for routing, with ref 
parameters. 

Duplication in message 
structure
Having to store or retrieve the same type of information in two different 
locations usually smells of missed generalizations, and I think that is true 
here too. We looked at putting the equivalent of an ebMS header in a URL (the 
earlier HTTP URL query parameters), I don’t find putting it in WS-Addressing 
parameters a lot more elegant. It also raises issue like how to handle any 
inconsistencies in situations where there is both a WS-Addressing structure and 
an ebMS header. Also, the WS-Addressing specification says that using reference 
parameters to store information that would otherwise be in other SOAP headers 
could 
cause “unintended or erroneous semantics in the resultant SOAP message". 

 
Generalized routing
This is related to duplication. When using just ebMS 
headers,  assuming routing is done 
on destination PartyId, any 
message (user, signal, WS-* helper, bundles, piggy backs) can be routed based on 
the single following XPath expression:
S:Envelope/S:Header/eb3:Messaging/eb3:UserMessage[1]/eb3:PartyInfo/eb3:To/eb3:PartyId




From: Moberg Dale [mailto:dmoberg@axway.com]
Sent: 07 May 2008 23:14
To: Pim van der Eijk; 
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




Yes, I agee that adding 
metadata  to ebMS signals or to other messages used in WS protocols is what 
is agreed upon as a MOU item.

The way or ways to do 
this is apparently TBD J

I think that since we 
have several ways to attach the metadata, we probably want to prune these down 
into a simple convention to do it in a standard 
way.

(Incidentally, would we 
then provide CPPA support for these messages? Would they be treated as msh level 
messages from the default packaging and delivery channel 
standpoint?)





From: Pim van 
der Eijk [mailto:pvde@sonnenglanz.net]
Sent: Wednesday, May 07, 2008 1:04 
PM
To: Moberg Dale; 
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

 
We agreed to add ebMS 
metadata also to signals and helper messages. And we also looked in some 
detail at one option for adding this metadata, by adding it to a WSA 
header.  Imo we did not fully compare this option to using a an 
eb:Messaging header (containing an eb:UserMessage but one that has 
no eb:PayloadInfo) to convey the ebMS metadata. I want to fully 
understand both options and compare their pros and 
cons.  Unfortunately, due to travel I will not be able to attend next 
week's meeting.
 
Pim
 




From: Moberg 
Dale [mailto:dmoberg@axway.com]
Sent: 07 May 2008 19:42
To: 
ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] MOU on intermediate 
support by conformance profile and other auxiliary documents for ebMS 
3.0
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.

 
Some comments in bold 
green.
 
Pim




From: Durand, Jacques R. 
[mailto:JDurand@us.fujitsu.com]
Sent: 29 May 2008 04:48
To: 
Pim van der Eijk; Moberg Dale; 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



Pim:
 
as discussed today, we have two solutions to pick from, 
none of them being a clear win...
Let me just try to alleviate some of the drawbacks you see 
to WS-addressing:




From: Pim van der Eijk 
[mailto:pvde@sonnenglanz.net]
Sent: Wednesday, May 28, 2008 2:02 
PM
To: 'Moberg Dale'; 
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




Here are some reasons why I would 
prefer to use ebMS headers for routing rather than WS-Addressing Reference 
Parameters:

Conformance to v3.0 Core
The ebMS 3.0 Part 1 Core does not specify the use of WS-Addressing. 



 
Avoid yet another standard to 
support
Requiring support for WS-Addressing in a multihop context adds a burden 
to implement ebMS 3.0 in general and the multihop profile in particular.It is 
also true that the counterproposal requires adding ebMS headers in some 
situations where v3.0 Core does not require them, but any ebMS 3.0 
implementation needs to know how to construct or handle ebMS 3.0 headers anyway, 
so this is just a reuse of that general functionality. 





From: Moberg Dale [mailto:dmoberg@axway.com]
Sent: 07 May 2008 23:14
To: Pim van der Eijk; 
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




Yes, I agee that adding 
metadata  to ebMS signals or to other messages used in WS protocols is what 
is agreed upon as a MOU item.

The way or ways to do 
this is apparently TBD J

I think that since we 
have several ways to attach the metadata, we probably want to prune these down 
into a simple convention to do it in a standard 
way.

(Incidentally, would we 
then provide CPPA support for these messages? Would they be treated as msh level 
messages from the default packaging and delivery channel 
standpoint?)





From: Pim van 
der Eijk [mailto:pvde@sonnenglanz.net]
Sent: Wednesday, May 07, 2008 1:04 
PM
To: Moberg Dale; 
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

 
We agreed to add ebMS 
metadata also to signals and helper messages. And we also looked in some 
detail at one option for adding this metadata, by adding it to a WSA 
header.  Imo we did not fully compare this option to using a an 
eb:Messaging header (containing an eb:UserMessage but one that has 
no eb:PayloadInfo) to convey the ebMS metadata. I want to fully 
understand both options and compare their pros and 
cons.  Unfortunately, due to travel I will not be able to attend next 
week's meeting.
 
Pim
 




From: Moberg 
Dale [mailto:dmoberg@axway.com]
Sent: 07 May 2008 19:42
To: 
ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] MOU on intermediate 
support by conformance profile and other auxiliary documents for ebMS 
3.0
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.