OASIS ebXML Messaging Services TC

  • 1.  issue 077

    Posted 09-26-2006 01:46
    
    
    
    
    
    
    
    
    
    
    

    Pete:

    Here is a proposal for addition in the intro (propose to insert just after 1.2 section, before current 1.3 ), as we discussed the need for a little explanation on relationship with Web services specs.

    I think it is addressing [part of] isue077.

    -Jacques

    1.3 Reusing Web services specifications, their role in a messaging middleware

    A major design choice in V3 is the reuse of Web services specifications that concern the protocol level. The message security and reliability features are reusing WS standards and their implementations.

    The message SOAP body has been freed for business payload. The ebMS header is just a SOAP extension among others. As a result, V3 is significantly more compliant than V2 with the SOAP processing model, and apt at composing Web services standards that are defined as SOAP extensions. Compliance of V3 with future WS-I profiles - in particular BP 1.2, BP 2.0 and RSP profiles - will be an objective in subsequent releases, as it is expected that these profiles will be natively supported by most SOAP platforms.

    Compliance with Web services standards does not remove the rationale behind an internet-based messaging middleware. Often, document-centric eBusiness and eGovernment exchanges need to clearly dissociate messaging functions from the way these messages are consumed on the back-end. Such consumption may take place according to various models, as mentioned in 1.1. The use of [SOAP] message header elements that represent standard business metadata (user or company ID, business conversation, business service and action, etc.), is a key feature for supporting a decoupled binding with back-end business processes. At the same time, past experience has demonstrated that the messaging layer must be more supportive of business transactions: messages are parts of basic choreographies that map to higher-level business exchanges between partners. Monitoring and enforcing properties of such multi-message exchanges (timing, error handling, quality of service, binding to underlying transport, etc.) requires explicit support by the messaging layer, allowing a flexible, contract-based control by the message producer and consumer layers.



  • 2.  Re: issue 077

    Posted 09-26-2006 19:11
    Thus spoke Jacques Durand (JDurand@us.fujitsu.com) on Mon, Sep 25, 2006 at 06:45:09PM -0700:
    > Here is a proposal for addition in the intro (propose to insert just
    > after 1.2 section, before current 1.3 ), as we discussed the need for a
    > little explanation on relationship with Web services specs.
    > I think it is addressing [part of] isue077.
    
    > 1.3 Reusing Web services specifications, their role in a messaging
    > middleware
    > 
    > A major design choice in V3 is the reuse of Web services specifications
    > that concern the protocol level. The message security and reliability
    > features are reusing WS standards and their implementations.
    
    This is a good addition, but I would propose replacing the title and
    first paragraph with something like this instead, to emphasize that
    ebMS is itself a Web Service (removing any semblance of an "us versus
    them" mentality):
    
    1.3 Web Services and Their Role in an eBusiness Messaging Framework
    
    A major design choice in V3, is the specification of the MSH and its
    associated processing rules as a Web Service.  The intent is to make
    use of other relevant Web Services specifications that fulfill certain
    messaging requirements, and build upon that base by adding what is
    necessary for a complete eBusiness messaging service.  For example,
    the message security and reliability requirements are met through the
    use of other Web Services standards and their implementations; and
    [something about what eb:Messaging adds in terms of business value].
    ebMS 3 brings this all together into a single, coherent framework.
    
    The remainder looks fine, subject to the corrections you already
    provided in your subsequent message.
    
    > The message SOAP body has been freed for business payload. The ebMS
    > header is just a SOAP extension among others. As a result, V3 is
    > significantly more compliant than V2 with the SOAP processing model, and
    > apt at composing Web services standards that are defined as SOAP
    > extensions. Compliance of V3 with future WS-I profiles - in particular
    > BP 1.2, BP 2.0 and RSP profiles - will be an objective in subsequent
    > releases, as it is expected that these profiles will be natively
    > supported by most SOAP platforms.
    > 
    > Compliance with Web services standards does not remove the rationale
    > behind an internet-based messaging middleware. Often, document-centric
    > eBusiness and eGovernment exchanges need to clearly dissociate messaging
    > functions from the way these messages are consumed on the back-end. Such
    > consumption may take place according to various models, as mentioned in
    > 1.1. The use of [SOAP] message header elements that represent standard
    > business metadata (user or company ID, business conversation, business
    > service and action, etc.), is a key feature for supporting a decoupled
    > binding with back-end business processes. At the same time, past
    > experience has demonstrated that the messaging layer must be more
    > supportive of business transactions: messages are parts of basic
    > choreographies that map to higher-level business exchanges between
    > partners. Monitoring and enforcing properties of such multi-message
    > exchanges (timing, error handling, quality of service, binding to
    > underlying transport, etc.) requires explicit support by the messaging
    > layer, allowing a flexible, contract-based control by the message
    > producer and consumer layers. 
    
    --Pete
    Pete Wenzel