OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [ebxml-msg] Groups - ebXML Messaging TC weekly call added


I'm not so sure whether this is an inexpensive operation. When you have a pipeline architecture this requires that the first module responsible for receiving must immediately parse the message and check the routing function. Both these operation would normally occur later on in the pipeline. So requiring this kind of support for all intermediaries requires a change in such an architecture. 

I do see the use case you mention, but I question whether we need to always require support for this option, this could also be done in conformance profiles.


On 4 nov 2009, at 09:14, Pim van der Eijk wrote:

Some comment below, also see the proposed update in separate message.

L943-945: This option requires an intermediary to execute the routing function for a message as soon as it is received on the transport level, even before it is acknowledged [on the transport level]. Otherwise the error cannot be reported back on http response.   
I would assume that an Intermediary must always support the default option, so Intermediaries are not allowed to just store and acknowledge the message on the transport level and than process it further. Do we want such a requirement? I would propose to rename this option to something like “Synchronous reporting” 
The idea is indeed that an intermediary should (default case) check whether it is actually able to route a message, by checking if the message matches a pattern in the routing table.  This is an inexpensive operation, different and separate from the more expensive operation of actually performing the action associated with the pattern (e.g. push the message forward to next hop, possibly SSL handshakes etc.).  Especially with SME endpoints connecting to an edge intermediary, getting this failure instantly on the HTTP back-channel seems to me by far the preferred option.  They may not connect the intermediary for hours or days after pushing out a message and would have no signal that anything went wrong, so instant feedback is required. See the proposed update. 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]