OASIS ebXML Messaging Services TC

 View Only
  • 1.  Groups - Multi-hop Section Draft 0.5 (ebMS3-Multihop V05.doc) uploaded

    Posted 06-25-2008 03:20
    V0,5:
    - section 1.5 updated based on feedback and extended for response messages.
    
     -- Mr Jacques Durand
    
    The document revision named Multi-hop Section Draft 0.5 (ebMS3-Multihop
    V05.doc) has been submitted by Mr Jacques Durand to the OASIS ebXML
    Messaging Services TC document repository.  This document is revision #3 of
    ebMS3-Multihop.doc.
    
    Document Description:
    Draft of the multi-hop section.
    V0.3:
    - a few updates in the definition section (editorial)
    - added a commented Flow diagram (section 1.7.1) on RM sequence
    establishment. To review.
    V0.4:
    - section 1.5 (Intermediary Role) rewritten, though not complete yet.
    (diff with 0.3 visible)
    V0,5:
    - section 1.5 updated based on feedback and extended for response messages.
    
    View Document Details:
    http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/document.php?document_id=28652
    
    Download Document:  
    http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/download.php/28652/ebMS3-Multihop%20V05.doc
    
    Revision:
    This document is revision #3 of ebMS3-Multihop.doc.  The document details
    page referenced above will show the complete revision history.
    
    
    PLEASE NOTE:  If the above links do not work for you, your email application
    may be breaking the link into two pieces.  You may be able to copy and paste
    the entire link address into the address field of your web browser.
    
    -OASIS Open Administration
    


  • 2.  RE: [ebxml-msg] Groups - Multi-hop Section Draft 0.5 (ebMS3-Multihop V05.doc) uploaded

    Posted 06-28-2008 14:34
    
    Jacques,
    
    Lines 110-114, "PModes governing message exchanges should only be known from
    Endpoint MSHs. The I-Cloud should not have to be aware of PModes, with an
    exception: when an Intermediary has to support message pulling, it must know
    which ones of the messages it receives must be pushed and which ones must be
    pulled. This requires partial knowledge of PModes associated with message
    pulling."
    
    An intermediary needs to know a much larger subset of "nextMSH"
    configuration parameters. Here is a list (mostly from
    http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/document.php?document
    _id=28269):
    
    - MEP Binding
    - Protocol (though we could profile this to always be HTTP 1.1)
    - Protocol.Address
    - Transport security protocol (none, SSL/TLS, version)
    - Transport security protocol client certificate
    - Transport security protocol server certificate
    - MPC (see below [1])
    - Maxsize
    - Report.SenderError.AddressTo
    - Report.ReceiverErrorsTo
    - ErrorHandling.Report.AsResponse 
    - Report.ProcessErrorNotifyConsumer
    - Report.ProcessErrorNotifyProducer
    - Report.ProcessErrorDeliveryFailuresNotifyProducer
    - AtLeastOnce.ReplyPattern 
    - Transport retries (see below [2])
    - "Streaming" [3]
    
    Notes:
    
    [1] MPC:  
    This is an intermediary configuration if MPC "remapping" is allowed, see May
    2008 message thread "Multihop and Pull".
    http://lists.oasis-open.org/archives/ebxml-msg/200805/msg00013.html
    
    [2] Transport retries:
    Some messaging products support not only ebMS retries but also separately a
    lower-level HTTP retries.  EbMS retries are business process related and a
    contract among From Party and To Party MSH, with (Retries*RetryInterval)
    typically hours or even days. HTTP retries are a generic transport retry
    mechanism (also usable with AS2) with retry intervals of seconds or minutes.
    It makes sense for ebMS intermediaries to support (and be configurable for)
    HTTP retries even if they do not support WS-* related retries, in particular
    with store-and-forward intermediaries. This is the case for one product that
    supports ebMS 2.0 multihop. 
    
    [3] "Streaming"
    Perhaps "streaming" behaviour should be a configuration parameters. I'll
    comment later in a separate message for easier tracking.
    
    Related comment for lines 163-167, 
    
    "a routing rule can be construed as a pair: (Boolean expression over the
    routing input, URL) where [the] URL identifies the next MSH."
    
    This only covers the case where the forwarding is a Push (to this next URL),
    not when the next node retrieves the message from the intermediary a Pull
    request.  It is also incomplete:  A routing rule should map this expression
    to settings for this larger set of "nextMSH" parameters mentioned above.
    
    Pim
    
    
    


  • 3.  Streaming versus Store-and-Forward

    Posted 07-02-2008 20:48
     
    
    Streaming versus store-and-forward
    
    The decision to "stream" or to "store-and-forward" can be considered
    an implementation aspect that doesn't need to be standardized, as
    Jacques noted in
    http://lists.oasis-open.org/archives/ebxml-msg/200802/msg00047.html in
    response to Ian's message on node types in
    http://lists.oasis-open.org/archives/ebxml-msg/200802/msg00043.html
    Here is some discussion on the relevant advantages of "streaming"
    versus "store-and-forward".  
    
    Here's an attempt to compare the two:
    
    Advantages of streaming (compared to store-and-forward):
    - The intermediary only needs to provide a routing function, it does
    not need to provide temporary storage for messages. The more data
    flows through the intermediary, the leaner the system that provides
    the ebMS intermediary function can be. 
    - The intermediary can start forwarding the message immediately after
    having scanned the SOAP header for ebMS routing data. If the message
    is very large (and not "chunked" using some to be defined message
    chunking protocol) and/or there are multiple cascaded
    intermediaries, this reduces end-to-end latency.  
    - The intermediary can act as a "synchronous" intermediary, using the
    back-channel on the incoming HTTP connection to relay incoming content
    on the outgoing HTTP connection.  This content can include SOAP
    faults, any other protocol error messages, HTTP status codes, SOAP
    header responses, and even response business messages. Note that 
    streaming does not imply, but enables synchronous (see separate note).
    
    Advantages of store-and-forward (compared to streaming):
    - The intermediary can act as a buffer.  When there is much less
    bandwidth for the outcoming connection than there is for the incoming
    connection, the intermediary can temporarily queue the incoming
    messages. In the extreme case where the outgoing connection can not be
    established or is dropped, the intermediary can act as a temporary
    buffer and provide transport-level retries to forward the incoming
    message as and when the next MSH becomes accessible. 
    - Disaster recovery: assume a disaster happens to an ebMS 3.0 endpoint
    that receives incoming messages via an intermediary. Its reliable
    messaging component may have acknowledged some messages that it has
    not yet delivered to its backend applications.  Suppose a stand-by MSH
    takes over within some SLA-defined interval. It can notify the
    intermediary to adapt its routing tables and request it to resubmit
    all recent messages to ensure they are all processed.  (Alternatively, the
    Receiver could ask all its trading partners to resubmit messages, but
    if the failed MSH receives messages from hundreds or thousands of
    other message handlers, reloading them from the last intermediary is
    more convenient). 
    
    Note that "MEP Bridge" from push (from sender to intermediary) to pull
    (by receiver from intermediary) requires "store-and-collect"
    functionality. So I assume most ebMS 3.0 intermediaries to implement
    and support temporary storage at the intermediary, and if they need to
    support if for store-and-collect they might as well support it for
    store-and-forward. The "streaming" mode seems to be an optimization
    in general but is a pre-requisite for synchronous intermediaries.
    
    
    


  • 4.  Synchronous Intermediaries

    Posted 07-02-2008 20:51
    
    Synchronous intermediaries
    
    We've focussed on asynchronous ebMS messaging across intermediaries
    for good reasons, one being that in cases where the last MSH pulls
    from the intermediary it is the only option and we still need a way to
    reverse route Receipts, WS-* reverse messages and business responses. 
    
    Do we still need to support synchronous intermediaries for messages
    that are "pushed all the way"? Synchronous intermediaries are 
    intermediaries that keep the requestor connection open to forward the
    back-channel response. To limit the options, it seems preferable to
    assume that either all intermediaries are waiting or none of them are
    (see earlier discussion).
    
    A disadvantage of synchronous intermediaries is that having all
    intermediaries wait before their HTTP reply is made does not scale
    well, is brittle and utilizes lots of resources. This is why it is not
    supported in some production ebMS 2.0 intermediary deployments.
    
    However, some ebMS-like messaging protocols that support
    intermediaries have support for synchronous intermediaries. Sometimes
    this is restricted to "idempotent" operations that do not require
    reliability, such as looking up data in a remote databases.  Support
    for synchronous intermediaries could provide an upgrade path for these
    communities and extend the adoption of ebMS 3.0.
    
    In point-to-point Web Services messaging synchronous SOAP
    request/response interactions are also very widely used. It would be a
    benefit for an intermediary to be able to support this model without
    modifications to the behaviour of the server and/or the client.
    
    The cost of supporting a synchronous Receiver seems to be quite
    limited. The last intermediary can receive a synchronous response, and
    forward it back to the initial sender asynchronously. The reverse path
    could use a different path through the I-Cloud, as long as it ends at
    the original sending MSH. 
    
    What about the cost of supporting a Sender that assumes Two Way Sync?
    I.e. the sending MSH sends a message to an intermediary and expect a
    synchronous response. This first intermediary would send the request
    to the intermediary and expect to be able to receive the response on
    the HTTP back-channel. This first intermediary could send the request
    asynchronously but remember which open incoming HTTP connection the
    eb:MessageId is associated with. Assuming a response arrives in time
    through the intermediary (correlated based on eb:RefToMessageId), the
    intermediary could reply on the back-channel of the open incoming HTTP
    connection. Despite its obvious limitations, there is very strong
    interest in this kind of synchronous/asynchronous bridging for
    clients.
    
    
    


  • 5.  RE: [ebxml-msg] Groups - Multi-hop Section Draft 0.5 (ebMS3-Multihop V05.doc) uploaded

    Posted 09-04-2008 19:13
    Pim:
    
    Looking again at this message, for the next iteration of the multihop
    draft: comemnts 


  • 6.  RE: [ebxml-msg] Groups - Multi-hop Section Draft 0.5 (ebMS3-Multihop V05.doc) uploaded

    Posted 09-10-2008 20:36
    Hello Jacques,
    
    Unfortunately I can't make tonight's call. A couple of comments:
    
    - I was only referring to Pmodes in a loose sense of "bunch of configuration
    parameters relevant to building or sending/forwarding a message".   Due to
    assumptions of transparency and end-to-end security and reliability our
    intermediaries need less configuration parameters than regular endpoints, by
    intention, but still some.
    
    - Transport security details (SSL) are part of any intermediary
    configuration. Whether or not they are out of scope for ebMS is debatable.
    In some products/deployments transport security is not handled not by the
    ebMS MSH but in others it is. An option to configure transport security has
    been part of ebXML CPP/CPA OASIS standard ("Transport" element) since the
    beginning.  I think the absence of transport security Pmode parameters in
    ebMS 3.0 Core is an oversight.
    
    - MEP Binding is a configuration parameter for all intermediaries, not just
    for the last. The next MSH node may be an endpoint for some messages, or yet
    another intermediary for others (see last assumption in 1.3.1).  So any
    intermediary should be able to push or be pulled from based on conditions.  
    
    - We discussed some contrained support for synchronous, and there is some
    text on synchronous streaming already.  This could be part of the routing
    function: configuration linked to message patterns in rules, of the
    intermediaries and the endpoints that connect to them.
    
    Pim