OASIS ebXML Messaging Services TC

  • 1.  Section 2.4.5 Compliance with the SOAP Intermediary Model: initial questions and reservations

    Posted 06-12-2009 15:43
    
    
    
    
    
    
    
    
    
    
    

    1. Versions: Is this section intended to apply to SOAP 1.2 only?

    If so, is the first or second edition of 1.2 relevant?

    2.There is a SOAP processing model mentioned in http://www.w3.org/TR/soap12-part1/ but nothing explicitly referred to by “SOAP intermediary model”

    But consider Section 2.7 in the second edition, entitled, “Relaying SOAP Messages”:

    As mentioned earlier in this section, it is assumed that a SOAP message originates at an initial SOAP sender and is sent to an ultimate SOAP receiver via zero or more SOAP intermediaries. While SOAP does not itself define any routing or forwarding semantics, it is anticipated that such functionality can be described as one or more SOAP features (see 3. SOAP Extensibility Model). The purpose of this section is to describe how message forwarding interacts with the SOAP distributed processing model.

    ebMS does not make use of the SOAP Extensibility Model to define forwarding. Therefore, what we are doing is not what “is anticipated” So, should we really be discussing compliance? What exactly is it that we are complying with? WS-I has not released any conformance Rxxxx requirements targeted at intermediaries that I recall. We are not using the extensibility model. I think the title of our section 2.4.5 is misleading.

    3. “It is assumed that ebMS Intermediaries are also SOAP intermediaries. By default all nodes in the multi-hop path act in the “next” role (http://www.w3.org/2003/05/soap-envelope/role/next).

    Replace “by default” with “Therefore”

    4. In the SOAP processing model for intermediaries, any header that is understood and processed must be removed from the SOAP message.

    Remove “for intermediaries”

    5. “If one wants the headers to be available to further SOAP processors on the message path the headers have to be “reinserted” in the SOAP message. When a SOAP intermediary does not process a header it may relay this header to the next SOAP node, i.e. not remove the header from the message.”

    “As the routing function of the ebMS Intermediary requires processing of SOAP headers these headers are not subject to “relay” but to “reinsertion” [SOAP12]. As relaying does not apply to the ebMS headers, the @relay=”true” attribute should not be set. The ebMS routing function is then a “header reinsertion” case.

    ”NOTE: When the intermediary would reinsert header attributes by removing them first and then add them again this might break signatures. It is therefore strongly RECOMMENDED that intermediaries do not alter in any way the SOAP header of routed messages, i.e. implementations must consider the “reinsert” operation as a virtual extraction and reinsertion of header blocs. An intermediary implementation SHOULD NOT rebuild the SOAP header of routed messages by actually extracting then reinserting header blocks.”

    Please reduce this to a statement of the required functionality and do not describe how implementation should occur (IMO!) Put something like “Header processing by an intermediary MUST not break digital signatures.”

    7. NOTE: set the @role of all headers to “next”, as that does not seem to be a default in SOAP1.2 ?

    The “@role” is a 1.2 attribute. What happens for SOAP 1.1? Why do we want all headers to have that role? Why is the wss header set that way? We at most only want to set the role value to “next” for the header containing metadata consulted by the intermediary. What about mustUnderstand? For the ebMS header, we do not want a mere SOAP intermediary to throw a SOAP fault because it does not grok ebMS. And we should architecturally allow mere SOAP intermediaries. But by targeting “next” and requiring ebMS header processing, we block things. We really need to understand which header needs to be targeted and what the target value should be? We might well be better off making up our own role value here.



  • 2.  RE: [ebxml-msg] Section 2.4.5 Compliance with the SOAP Intermediary Model: initial questions and reservations

    Posted 06-12-2009 19:11
    
    
    
    
    
    
    
    >For the ebMS header, we do not want a mere SOAP intermediary to throw a SOAP fault
    >because it does not grok ebMS. And we should architecturally allow mere SOAP intermediaries.
    >But by targeting “next” and requiring ebMS header processing, we block things.
     
    Good point.
    I think the SOAP model has not given much thoughts to intermediaries that are mere "routers", and therefore we should not be too eager to make the ebms multi-hop use case "fit in" this model.
    Clearly the concept of processing SOAP headers has been defined assuming that whoever is targeted to do this processing, is the final consumer of this header, and "re-insertion" appears to be mostly a kludge, a way out some annoying corner case.
     
    If we have a rationale for NOT adding @role - and it looks like we might, given that the notion of "header processing"  falls short of supporting our case - I am all for it. 
     
    By not having this addition we also ensure that any message good for a point-to-point exchange, can also be sent to the I-Cloud, given the right routing function.
    (we should make this one of our basic principles)
    If not that introduces some embarrassing dependency to the topology.
     
    Jacques
     
     

    From: Moberg Dale [mailto:dmoberg@axway.com]
    Sent: Friday, June 12, 2009 8:42 AM
    To: ebxml-msg@lists.oasis-open.org
    Subject: [ebxml-msg] Section 2.4.5 Compliance with the SOAP Intermediary Model: initial questions and reservations

    1. Versions: Is this section intended to apply to SOAP 1.2 only?

    If so, is the first or second edition of 1.2 relevant?

    2.There is a SOAP processing model mentioned in http://www.w3.org/TR/soap12-part1/ but nothing explicitly referred to by “SOAP intermediary model”

    But consider Section 2.7 in the second edition, entitled, “Relaying SOAP Messages”:

    As mentioned earlier in this section, it is assumed that a SOAP message originates at an initial SOAP sender and is sent to an ultimate SOAP receiver via zero or more SOAP intermediaries. While SOAP does not itself define any routing or forwarding semantics, it is anticipated that such functionality can be described as one or more SOAP features (see 3. SOAP Extensibility Model). The purpose of this section is to describe how message forwarding interacts with the SOAP distributed processing model.

    ebMS does not make use of the SOAP Extensibility Model to define forwarding. Therefore, what we are doing is not what “is anticipated” So, should we really be discussing compliance? What exactly is it that we are complying with? WS-I has not released any conformance Rxxxx requirements targeted at intermediaries that I recall. We are not using the extensibility model. I think the title of our section 2.4.5 is misleading.

    3. “It is assumed that ebMS Intermediaries are also SOAP intermediaries. By default all nodes in the multi-hop path act in the “next” role (http://www.w3.org/2003/05/soap-envelope/role/next).

    Replace “by default” with “Therefore”

    4. In the SOAP processing model for intermediaries, any header that is understood and processed must be removed from the SOAP message.

    Remove “for intermediaries”

    5. “If one wants the headers to be available to further SOAP processors on the message path the headers have to be “reinserted” in the SOAP message. When a SOAP intermediary does not process a header it may relay this header to the next SOAP node, i.e. not remove the header from the message.”

    “As the routing function of the ebMS Intermediary requires processing of SOAP headers these headers are not subject to “relay” but to “reinsertion” [SOAP12]. As relaying does not apply to the ebMS headers, the @relay=”true” attribute should not be set. The ebMS routing function is then a “header reinsertion” case.

    ”NOTE: When the intermediary would reinsert header attributes by removing them first and then add them again this might break signatures. It is therefore strongly RECOMMENDED that intermediaries do not alter in any way the SOAP header of routed messages, i.e. implementations must consider the “reinsert” operation as a virtual extraction and reinsertion of header blocs. An intermediary implementation SHOULD NOT rebuild the SOAP header of routed messages by actually extracting then reinserting header blocks.”

    Please reduce this to a statement of the required functionality and do not describe how implementation should occur (IMO!) Put something like “Header processing by an intermediary MUST not break digital signatures.”

    7. NOTE: set the @role of all headers to “next”, as that does not seem to be a default in SOAP1.2 ?

    The “@role” is a 1.2 attribute. What happens for SOAP 1.1? Why do we want all headers to have that role? Why is the wss header set that way? We at most only want to set the role value to “next” for the header containing metadata consulted by the intermediary. What about mustUnderstand? For the ebMS header, we do not want a mere SOAP intermediary to throw a SOAP fault because it does not grok ebMS. And we should architecturally allow mere SOAP intermediaries. But by targeting “next” and requiring ebMS header processing, we block things. We really need to understand which header needs to be targeted and what the target value should be? We might well be better off making up our own role value here.



  • 3.  Re: [ebxml-msg] Section 2.4.5 Compliance with the SOAP IntermediaryModel: initial questions and reservations

    Posted 06-15-2009 21:46
    
    
    
    
    Surely we don’t want to block “plain” SOAP Intermediaries, i.e. SOAP nodes that don’t understand ebMS meta data, from processing SOAP messages part of an ebMS message exchange.

    The most easy way would of course be to define a new target role specific to ebMS nodes / intermediaries. This way these headers are automatically ignored and forwarded by plain SOAP intermediaries (see Table-3 in part 1 of the SOAP spec). This would impose a requirement on the endpoint to supply these target in the messages.

    Another option is not to require processing of the ebMS related SOAP headers by setting “false” as the value for the mustUnderstand attribute. This allows “plain” SOAP nodes to ignore the ebMS SOAP headers. Again according to Table-3 of the SOAP spec this would however remove these headers from the message unless the relay attribute exists with value “true”. So the requirement on the endpoint would be to supply these attributes.  
        
    The option not to supply a role attribute with a SOAP header would set the header targeted at the ultimateReceiver (see section 5.2.2 SOAP spec) and therefore prevent it from being processed at all by any intermediary SOAP node including the ebMS intermediary. This follows from the SOAP processing model defined in section 2.6 of the SOAP spec and specific from rule #4 that states that “A SOAP node MAY also choose to process non-mandatory SOAP header blocks targeted at it”. So headers not targeted at the node SHALL NOT be processed.

    Therefore in my opinion the headers that need processing by the ebMS intermediaries should have a role attribute value which targets it at the intermediary.

    Regards
    Sander

      
    On 12/06/2009 21:03, "Jacques R. Durand" <JDurand@us.fujitsu.com> wrote:

    >For the ebMS header, we do not want a mere SOAP intermediary to throw a SOAP fault
    >because it does not grok ebMS. And we should architecturally allow mere SOAP intermediaries.
    >But by targeting “next” and requiring ebMS header processing, we block things.
     
    Good point.
    I think the SOAP model has not given much thoughts to intermediaries that are mere "routers", and therefore we should not be too eager to make the ebms multi-hop use case "fit in" this model.
    Clearly the concept of processing SOAP headers has been defined assuming that whoever is targeted to do this processing, is the final consumer of this header, and "re-insertion" appears to be mostly a kludge, a way out some annoying corner case.

    If we have a rationale for NOT adding @role - and it looks like we might, given that the notion of "header processing"  falls short of supporting our case - I am all for it.

    By not having this addition we also ensure that any message good for a point-to-point exchange, can also be sent to the I-Cloud, given the right routing function.
    (we should make this one of our basic principles)
    If not that introduces some embarrassing dependency to the topology.

    Jacques

     

    From: Moberg Dale [mailto:dmoberg@axway.com]
    Sent: Friday, June 12, 2009 8:42 AM
    To: ebxml-msg@lists.oasis-open.org
    Subject: [ebxml-msg] Section 2.4.5 Compliance with the SOAP Intermediary Model: initial questions and reservations

    1. Versions: Is this section intended to apply to SOAP 1.2 only?

    If so, is the first or second edition of 1.2 relevant?

    2.There is a SOAP processing model mentioned in http://www.w3.org/TR/soap12-part1/ but nothing explicitly referred to by “SOAP intermediary model”

    But consider Section 2.7 in the second edition, entitled, “Relaying SOAP Messages”:

    As mentioned earlier in this section, it is assumed that a SOAP message originates at an initial SOAP sender and is sent to an ultimate SOAP receiver via zero or more SOAP intermediaries. While SOAP does not itself define any routing or forwarding semantics, it is anticipated that such functionality can be described as one or more SOAP features (see 3. SOAP Extensibility Model <http://www.w3.org/TR/soap12-part1/#extensibility> ). The purpose of this section is to describe how message forwarding interacts with the SOAP distributed processing model.

    ebMS does not make use of the SOAP Extensibility Model to define forwarding. Therefore, what we are doing is not what “is anticipated” So, should we really be discussing compliance? What exactly is it that we are complying with? WS-I has not released any conformance Rxxxx requirements targeted at intermediaries that I recall. We are not using the extensibility model. I think the title of our section 2.4.5 is misleading.



    3. “It is assumed that ebMS Intermediaries are also SOAP intermediaries. By default all nodes in the multi-hop path act in the “next” role (http://www.w3.org/2003/05/soap-envelope/role/next).

    Replace “by default” with “Therefore”

    4. In the SOAP processing model for intermediaries, any header that is understood and processed must be removed from the SOAP message.

    Remove “for intermediaries”

    5. “If one wants the headers to be available to further SOAP processors on the message path the headers have to be “reinserted” in the SOAP message. When a SOAP intermediary does not process a header it may relay this header to the next SOAP node, i.e. not remove the header from the message.”

    “As the routing function of the ebMS Intermediary requires processing of SOAP headers these headers are not subject to “relay” but to “reinsertion” [SOAP12]. As relaying does not apply to the ebMS headers, the @relay=”true” attribute should not be set. The ebMS routing function is then a “header reinsertion” case.

    ”NOTE: When the intermediary would reinsert header attributes by removing them first and then add them again this might break signatures. It is therefore strongly RECOMMENDED that intermediaries do not alter in any way the SOAP header of routed messages, i.e. implementations must consider the “reinsert” operation as a virtual extraction and reinsertion of header blocs. An intermediary implementation SHOULD NOT rebuild the SOAP header of routed messages by actually extracting then reinserting header blocks.”

    Please reduce this to a statement of the required functionality and do not describe how implementation should occur (IMO!) Put something like “Header processing by an intermediary MUST not break digital signatures.”



    7. NOTE: set the @role of all headers to “next”, as that does not seem to be a default in SOAP1.2 ?



    The “@role” is a 1.2 attribute. What happens for SOAP 1.1? Why do we want all headers to have that role? Why is the wss header set that way? We at most only want to set the role value to “next” for the header containing metadata consulted by the intermediary. What about mustUnderstand? For the ebMS header, we do not want a mere SOAP intermediary to throw a SOAP fault because it does not grok ebMS. And we should architecturally allow mere SOAP intermediaries. But by targeting “next” and requiring ebMS header processing, we block things. We really need to understand which header needs to be targeted and what the target value should be? We might well be better off making up our own role value here.





  • 4.  RE: [ebxml-msg] Section 2.4.5 Compliance with the SOAP Intermediary Model: initial questions and reservations

    Posted 06-24-2009 22:02
    
    
    
    
    
    An ebms role would be the most compliant solution, agree.
    But this role needs be assigned to eb:Messaging header which is also indended to the ultimate receiver.
    So end-point MSHs - not just intermediaries - need also act in this role.
    (which is good as I think message content - at least for User message - should not depend on whether it goes through the I-Cloud or not.)
     
    -jacques


    From: Sander Fieten [mailto:sander@fieten-it.com]
    Sent: Monday, June 15, 2009 2:46 PM
    To: ebxml-msg@lists.oasis-open.org
    Subject: Re: [ebxml-msg] Section 2.4.5 Compliance with the SOAP Intermediary Model: initial questions and reservations

    Surely we don’t want to block “plain” SOAP Intermediaries, i.e. SOAP nodes that don’t understand ebMS meta data, from processing SOAP messages part of an ebMS message exchange.

    The most easy way would of course be to define a new target role specific to ebMS nodes / intermediaries. This way these headers are automatically ignored and forwarded by plain SOAP intermediaries (see Table-3 in part 1 of the SOAP spec). This would impose a requirement on the endpoint to supply these target in the messages.

    Another option is not to require processing of the ebMS related SOAP headers by setting “false” as the value for the mustUnderstand attribute. This allows “plain” SOAP nodes to ignore the ebMS SOAP headers. Again according to Table-3 of the SOAP spec this would however remove these headers from the message unless the relay attribute exists with value “true”. So the requirement on the endpoint would be to supply these attributes.  
        
    The option not to supply a role attribute with a SOAP header would set the header targeted at the ultimateReceiver (see section 5.2.2 SOAP spec) and therefore prevent it from being processed at all by any intermediary SOAP node including the ebMS intermediary. This follows from the SOAP processing model defined in section 2.6 of the SOAP spec and specific from rule #4 that states that “A SOAP node MAY also choose to process non-mandatory SOAP header blocks targeted at it”. So headers not targeted at the node SHALL NOT be processed.

    Therefore in my opinion the headers that need processing by the ebMS intermediaries should have a role attribute value which targets it at the intermediary.

    Regards
    Sander

      
    On 12/06/2009 21:03, "Jacques R. Durand" <JDurand@us.fujitsu.com> wrote:

    >For the ebMS header, we do not want a mere SOAP intermediary to throw a SOAP fault
    >because it does not grok ebMS. And we should architecturally allow mere SOAP intermediaries.
    >But by targeting “next” and requiring ebMS header processing, we block things.
     
    Good point.
    I think the SOAP model has not given much thoughts to intermediaries that are mere "routers", and therefore we should not be too eager to make the ebms multi-hop use case "fit in" this model.
    Clearly the concept of processing SOAP headers has been defined assuming that whoever is targeted to do this processing, is the final consumer of this header, and "re-insertion" appears to be mostly a kludge, a way out some annoying corner case.

    If we have a rationale for NOT adding @role - and it looks like we might, given that the notion of "header processing"  falls short of supporting our case - I am all for it.

    By not having this addition we also ensure that any message good for a point-to-point exchange, can also be sent to the I-Cloud, given the right routing function.
    (we should make this one of our basic principles)
    If not that introduces some embarrassing dependency to the topology.

    Jacques

     

    From: Moberg Dale [mailto:dmoberg@axway.com]
    Sent: Friday, June 12, 2009 8:42 AM
    To: ebxml-msg@lists.oasis-open.org
    Subject: [ebxml-msg] Section 2.4.5 Compliance with the SOAP Intermediary Model: initial questions and reservations

    1. Versions: Is this section intended to apply to SOAP 1.2 only?

    If so, is the first or second edition of 1.2 relevant?

    2.There is a SOAP processing model mentioned in http://www.w3.org/TR/soap12-part1/ but nothing explicitly referred to by “SOAP intermediary model”

    But consider Section 2.7 in the second edition, entitled, “Relaying SOAP Messages”:

    As mentioned earlier in this section, it is assumed that a SOAP message originates at an initial SOAP sender and is sent to an ultimate SOAP receiver via zero or more SOAP intermediaries. While SOAP does not itself define any routing or forwarding semantics, it is anticipated that such functionality can be described as one or more SOAP features (see 3. SOAP Extensibility Model <http://www.w3.org/TR/soap12-part1/#extensibility> ). The purpose of this section is to describe how message forwarding interacts with the SOAP distributed processing model.

    ebMS does not make use of the SOAP Extensibility Model to define forwarding. Therefore, what we are doing is not what “is anticipated” So, should we really be discussing compliance? What exactly is it that we are complying with? WS-I has not released any conformance Rxxxx requirements targeted at intermediaries that I recall. We are not using the extensibility model. I think the title of our section 2.4.5 is misleading.



    3. “It is assumed that ebMS Intermediaries are also SOAP intermediaries. By default all nodes in the multi-hop path act in the “next” role (http://www.w3.org/2003/05/soap-envelope/role/next).

    Replace “by default” with “Therefore”

    4. In the SOAP processing model for intermediaries, any header that is understood and processed must be removed from the SOAP message.

    Remove “for intermediaries”

    5. “If one wants the headers to be available to further SOAP processors on the message path the headers have to be “reinserted” in the SOAP message. When a SOAP intermediary does not process a header it may relay this header to the next SOAP node, i.e. not remove the header from the message.”

    “As the routing function of the ebMS Intermediary requires processing of SOAP headers these headers are not subject to “relay” but to “reinsertion” [SOAP12]. As relaying does not apply to the ebMS headers, the @relay=”true” attribute should not be set. The ebMS routing function is then a “header reinsertion” case.

    ”NOTE: When the intermediary would reinsert header attributes by removing them first and then add them again this might break signatures. It is therefore strongly RECOMMENDED that intermediaries do not alter in any way the SOAP header of routed messages, i.e. implementations must consider the “reinsert” operation as a virtual extraction and reinsertion of header blocs. An intermediary implementation SHOULD NOT rebuild the SOAP header of routed messages by actually extracting then reinserting header blocks.”

    Please reduce this to a statement of the required functionality and do not describe how implementation should occur (IMO!) Put something like “Header processing by an intermediary MUST not break digital signatures.”



    7. NOTE: set the @role of all headers to “next”, as that does not seem to be a default in SOAP1.2 ?



    The “@role” is a 1.2 attribute. What happens for SOAP 1.1? Why do we want all headers to have that role? Why is the wss header set that way? We at most only want to set the role value to “next” for the header containing metadata consulted by the intermediary. What about mustUnderstand? For the ebMS header, we do not want a mere SOAP intermediary to throw a SOAP fault because it does not grok ebMS. And we should architecturally allow mere SOAP intermediaries. But by targeting “next” and requiring ebMS header processing, we block things. We really need to understand which header needs to be targeted and what the target value should be? We might well be better off making up our own role value here.





  • 5.  RE: [ebxml-msg] Section 2.4.5 Compliance with the SOAP Intermediary Model: initial questions and reservations

    Posted 06-24-2009 23:17
    
    
    
    
    
    
    


  • 6.  RE: [ebxml-msg] Section 2.4.5 Compliance with the SOAP Intermediary Model: initial questions and reservations

    Posted 06-17-2009 20:02
    
    
    
    
    
    
    
    Dale,
     
    The current spec references the second edition of 1.2.
     

    [SOAP12] W3C Recommendation. M. Gudgin, et al, SOAP Version 1.2 Part 1: Messaging Framework. Second Edition, April 2007.
    <http://www.w3.org/TR/soap12-part1/>


    This was based on the assumption that this is the version of the spec our ebMS spec should align with.
     
    Pim
     

    From: Moberg Dale [mailto:dmoberg@axway.com]
    Sent: 12 June 2009 17:42
    To: ebxml-msg@lists.oasis-open.org
    Subject: [ebxml-msg] Section 2.4.5 Compliance with the SOAP Intermediary Model: initial questions and reservations

    If so, is the first or second edition of 1.2 relevant?

     



  • 7.  RE: [ebxml-msg] Section 2.4.5 Compliance with the SOAP Intermediary Model: initial questions and reservations

    Posted 06-17-2009 20:08