RE: [AMG] Figure 2.1 suggested revision.

Coming from a SOAP point of view, it is a crucial part of the SOAP model
that there are no modules in the "SOAP layer" (equivalent to the XMLP
layer).

The reason is that is "infrastructure" to one is "application" to
another and the the role of a block may even change as the message
passes through the message path. That is, one SOAP processor treats it
is infrastructure and the next as application.

The SOAP layer truly is only the SOAP processor. I think it is perfectly
fine to have a term for the collection of handlers (XMLP application)
but in my mind that should simply be a box around the modules and should
not in my mind stretch down into the XMLP layer.

Henrik 

>I believe that there are two types of handlers. Those that are 
>visible to the upper application layer and those that are 
>completely enclosed within the XMLP layer. The purpose of 
>those entirely within the XMLP layer is to provide additional 
>funcionality to the infrastructure services used by the 
>application. These are services that the appication can rely 
>on but does not have to interact with. An obvious candidate is 
>reliability. An application assumes that the XMLP layer will 
>handle reliable delivery but does not need to interact or have 
>visibility of how the layer does it. A handler that 
>understands retries, sequence numbers, block numbers and all 
>the other state variables associated with reliable delivery 
>can exist entirely within the XMLP layer - the application 
>should not interact with it. Other examples of handlers within 
>the XMLP layer may include those that support more complex 
>message patterns.
>
>The second type is where an application interacts directly 
>with the handler. The obvious candidate for this are handlers 
>linked to payload blocks where the contents of the message 
>have to be delivered to the application for further business 
>processing.

Received on Wednesday, 14 March 2001 11:10:47 UTC