OASIS ebXML Messaging Services TC

  • 1.  RE: [ebxml-msg] About intermediaries

    Posted 10-22-2007 18:18 
    Jacques,

Good catch and summary.

I suspect CDC and from my experience NIH - both have "burst" type needs.  In NIH case its submission deadlines - in CDC - in response to real world events.

This is different from "normal" B2B weekly / monthly peaks.

Certainly NIH receives 90% of traffic in a month over 1 or 2 days!

Also - the push/pull model is very important - ultimately both use cases want an initial tiny notification message to queue up later an asynchronous transfer when bandwidth permits / priorities require.

Not sure if this helps at all?!  My sense here is we want simple mechanisms that are self-adaptive to a wide range of anticipated use patterns without requiring any intervention.

Maybe a combination of some synchronous - and other asynchronous channels available for both uses?

Cheers, DW

"The way to be is to do" - Confucius (551-472 B.C.)


>


  • 2.  RE: [ebxml-msg] About intermediaries

    Posted 10-22-2007 18:35 
    Will the asynchronous intermediary effectively "terminate" the HTTP
request and reply interaction? So it would issue its own SOAP faults,
any other protocol error messages, HTTP status codes, and SOAP header
responses as needed? Or would intermediaries be restricted to OneWay
meps only? (with any SOAP faults simply generated downstream from the
intermediary, and not transmitted back (unless the downstream nodes
started a new connection back either through the intermediary or
bypassing the intermediary to the origin directly)) I think once we
enter into soap paths with node count higher than 2, the existing mep
vocabulary becomes incomplete and basically inadequate for the job.

I don't see how intermediaries can participate in other meps (beyond one
way non-robust) without going into the synchronous mode? However, even
then the issue whether the next hops on the soap path must be
synchronous with respect to the intermediary is another matter, right?

There is a much more complex set of combinations that need to be
addressed.



    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 3.  RE: [ebxml-msg] About intermediaries

    Posted 10-22-2007 23:24 
     inline


  • 4.  Re: [ebxml-msg] About intermediaries

    Posted 10-23-2007 23:42 
    Jacques you said something in your response that confuses me a bit.

> E.g., all an intermdiary may need to do for enabling any of  these
> combinations, is to put "any message received on MPC 123, right into the
> sending MPC 234"

The MPC of an ebMS Message is included in the
eb:Messaging/eb:UserMessage/@mpc attribute. If the MPC value needs to be
changed at the intermediary wouldn't that necessitate the ebMS Message
header being modified? I didn't think we were contemplating modification of
the values within the ebMS Message header.


On 10/22/07 4:23 PM, "Durand, Jacques R."


  • 5.  RE: [ebxml-msg] About intermediaries

    Posted 10-24-2007 04:54 
    Ric:

You caught me writing things a little too quickly here. 
You are right: the ebMS header should not - must not - be altered by
intermediaries.  
So this seems to imply that multi-hop routing always requires each
message to use the same MPC all along, the MPC becoming de-facto an
end-to-end channel.

In this case multi-hop forwarding would fall into one of these 2
categories:

- either the MPC is used as routing function, by associating each
routing path unambiguously with a single MPC end-to-end. 
- or the MPC is not sufficient to determine the routing, which makes use
of additional routing functions. But even in that case, each message
must still use the same MPC end-to-end.

In both cases, the "forward" intermediary operation will need to comply
with this MPC invariant (the P-modes configuring the intermediaries must
reflect this).

All this is to be distinguished from routing uniquely based on other
headers, say WS-addressing, in which case the intermediary does NOT need
be an ebMS intermediary in the sense it does not need to understand the
ebMS header - and is out of scope of this MPC invariant.

Jacques  


    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


Related Content