Copyright ©2000 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document is a strawman proposal for an abstract model for XP.
The challenge of crafting a protocol specification is to create a description of behaviour that is not tied to any particular approach to implementation. There is a need to abstract away from some the messy implementation details of buffer management, data representation and specific APIs. However, in order to describe the behaviour of a protocol one has to establish a set of (useful) concepts that can be used in that description. An abstract model is one way to establish a consistent set of concepts. An abstract model is a tool for the description of complex behaviour – it is not a template for an implementation... although it should not stray so far away from reality that it is impossible to recognise how the required behaviours would be implemented.
This document is a strawman proposal for an abstract model for XP. It is by no means complete or polished and at this stage the authors just like to get some sense as to whether there is an consensus that such a model is a useful contribution to the XP effort.
This document is not a W3C Technical Report. It is to be considered work in progress and does not imply endorsement by the W3C membership nor by the XML Protocol WG. It is currently under review and discussion by the XML Protocol WG.
Discussion of this document will take place on the public <xml-dist-app@w3.org> mailing list (Archives) as indicated by the email communiation rules provided in the WG charter.
@@@
An abstract model is a useful means to develop a description of a system. It abstracts away from practical details such as specific API definitions, data representation, and buffer management. It provides a way to give a precise description of the externally visible behaviour without being prescriptive of implementation architecture.
The diagram below exposes the various processing elements in an XP system: XP Clients, XP Intermediaries and XP Layer Entities.
XP clients are clients (users) of the XP layer. The XP layer provides and abstraction for the transfer of XP messages between XP clients. XP clients send and receive XP messages through the invocation of XP layer service primitives[1] at XP service access points. The exchange of service primitives occurs between XP (layer) clients and XP layer entities. XP clients are responsible for application specific processing of XP messages, including XP Module processing.
[With respect to the Axis Architecture [2] an XP client encapsulates the functionality of input and output chains and dispatcher.]
[At present it is difficult to determine whether XP module processing should be regarded as something that happens within the XP layer (which would 'fatten' the role of the XP layer entity) or whether its should be regarded as ocurring winthin the XP client. This strawman models XP module processing as occuring within the XP client. So at least for the time being they are regard as application layer entities which places them within the XP client (from an abstract POV) rather than within the layer.
The difficulty here is in abstracting some sense of service and service interface for something that is largely unspecified by XP. It would be possible to pull module processing within the XP layer IFF it could be regard solely as filtering chains that operate on inbound and outbound messages between XP layer entities and XP clients. I believe it would also be possible for such chains to be stateful in the sense that the processing of a given message may be dependent on the processing of previous messages. The external (to the processing chain) interface as seen by both the XP client and the XP layer entities must be an (abstract) XP message.
There are a great many issues wrt XP module processing: failure and recovery from a partially processed message; ordering semantics of module processing – message order, node configuration dependent...; orthogonal modules and dependencies.]
XP intermediaries are XP clients (see section 5 below) that form a processing chain between an XP client that initiates the sending of an XP message and the XP client that ultimately receives and potentially responds to that message.
XP layer entities serialize and deserialise XP messages. XP messages are composed from (and decomposed into) information passed in the parameters between the XP layer entities and XP layer clients. XP layer entities are responsible for enforcing the XP rules of procedure and for the binding of the XP layer to underlying communications protocols.
[If module processing were pulled inside the XP layer it would become part of the role of an XP layer entity which would then enforce the behavioural rules associated with the XP modules it supports]
XP Service Access Point is a conceptual point at which XP services are accessible. XP is an asymmetric protocol and the address of the initiating XP client (ie. the 'name' of its service access point) may be unavailable ie. it may not be explicitly addressible by a remote or responding XP client.
[In practical terms in XP SAP would likely be implemented as a programming language object or objects that provided an APIs for sending and receiving XP messages.
This abstraction is similar to an aggregation of the Transport Listener, deserialiser, canonicalizer and router and Transport Sender and serializer from theAxis Architecture [2]]
XP Message is the unit of exchange between peer XP layer entities. In the abstract it is a structure that represents the contents of the XP envelope and plus any attachments (whether carried within the envelope or externally in-line within the binding specific 'message wrapper' eg SOAP with attachments.
My preference is to regard an XP message as abstract. It has several concrete representations throughout its lifetime: it has a concrete representation within the memory of a device implementing XP;and it has a binding specific serialization whilst being transferred between XP layer entities. My preference would be that there is a canonical XML representation for an XP message and that some bindings may 'optimise' this such that attachments are carried in-line but outside the XP envelope.
This section focuses on the definition of the abstract services provided at the XP layer interface. Two services are modelled here, a unidirectional XML datagram service (XP_UnitData) and a bi-directional XML request/response service (XP_Data), both are assumed unreliable and capable of re-ordering and duplicating messages.
Service primitives are abstract events that cross the boundaries between protocol layers. They are a descriptive device that allow us to abstract away from practical implementation details such as buffer management and specific APIs and invocation mechanisms such as upcalls (callbacks), downcalls, queing and polling mechanisms.
It is important to note that service primitives are an abstraction. From a descriptive point-of-view they become events and actions that drive and are driven by the operation of the procedural rules of the protocol.
.request Used by initiating clients to start an operation and by intermediaries to chain an operation toward a responding client. Typically used to start the sending of a message.
.indication Used at the responding client and at intermediaties to indicate the arrival of a message on its 'outward' journey.
.response In two-way services, used by the responding client and by intermediaries to return a response or fault toward the initiating client.
.confirm
Used at intermediaries and at the initiating client to indicate the
completion of an operation started by the corresponding .request
primitive.
In the case of a two-way service (XP_Data) it may also carry a response or fault
message on its 'return' journey toward the initiating client.
These four primitives are used in two common interaction patterns to model the behaviour of two-way request/response operations and one way datagram operations as illustrated in the diagrams below.
Operation of XP_Data Service: Two-way request/response operation
Operation of XP_UnitData Service: One-way datagram operation.
From the initiators point-of-view both of types of operation start with the invocation of a .request primitive and terminate with the invocation of a .confirm primitive.
A subtle difference is that in the two-way case the .confirm primitive arises only after a .indication has been raised at the responding client, whereas in the one-way case it merely indicates that the operation is complete from the initiating end's point-of-view. In the one-way case a (silent) failure may prevent a message from being delivered as an .indication to the responding client, even though a .confirm is delivered back to the initiating client.
The XP_Data service provides an unreliable request/response service which is modelled by four service primitives. Each primitive models a transmission or reception event at interface between the XP layer and an XP client.:
XP_Data.request(
To, [OrigPath], [{ModuleList}], RequestBody, [{AttachmentList}],[BindingContext]);
XP_Data.indication(
To, From, [OrigPath], [ActualPath], [{ModuleList}], RequestBody, [{AttachmentList},
[BindingContext]]);
XP_Data.response(
[{ModuleList}], [ResponseBody|FaultBody], [{AttachmentList}], [BindingContext]]);
XP_Data.confirm(
From, [ActualPath], [{ModuleList}], [ResponseBody|FaultBody], Status, [{AttachmentList}],
[BindingContext]);
All
parameters are detailed in Section 3.4
The service is unreliable since it can fail silently through the loss of messages in transit. Immediate failures that prevent the invocation of a primitive are reported as the result of the attempted invocation.
An XP client may engage in multiple concurrent operations with the same or different recipients/paths. These concurrent operations are independent and the order in which they are processed by an intermediary or the recipient may be different from that in which they are invoked or complete at the initiator. In applications where sequencing is important an optional XP module may be used to establish the original ordering within XP layer clients
[Strawman suggestion again].
Failures that arise during message processing at XP intermediaries or at the intended recipient result in the inclusion of a FaultBody rather than a ResponseBody in the .response and .confirm primitives.
This service can be provided over HTTP, HTTPS, SSL/TCP, TCP and SMTP.
The XP_UnitData service provides an unreliable datagram service which is modelled by two service primitives that model the transmission and reception of request message as follows:
XP_UnitData.request(To,
[OrigPath], [{ModuleList}], RequestBody, [{AttachmentList}], [BindingContext]);
XP_UnitData.indication(To,
From, [OrigPath], [ActualPath], [{ModuleList}], RequestBody, [{AttachmentList]},
[BindingContext]);
XP_UnitData.confirm(
[From], Status, [BindingContext]);
All
parameters are detailed in Section 3.4
The service is unreliable since it can fail silently through the loss of messages in transit.
In general there are no ordering guarantees with respect to the delivery of messages. Intermediary and recipient processing may re-order messages. Thus, the order in which concurrent XP_UnitData operations complete is independent of the order in which they were initiated. In applications where sequencing is important an optional XP module may be used to establish the original ordering within XP layer clients.
[The one-way and unreliable nature of the interaction mean that failures during recipient XP processing should result in a message sent in a one-way message carrying a FaultBody in the reverse direction. It is also important that a failure to deliver a fault message does not give rise to further fault messages]
This service may be implemented over HTTP, HTTPS, SSL/TCP, TCP, SMTP and UDP.
This section describes the (abstract) parameters that are used in the service primitives. These parameters are abstract in the sense that no attempt is made to relate them to any concrete representation of the values they represent. They would typically relate to the parameters of an API (if the an API were closely modelled on this service definition), however, they are only given a narrative description here.
|
To |
An identifier that denotes the intended XP client that a message is being sent to. The sense of this parameter follows the direction of flow. In .indication this parameter denotes the XP client to which the message was sent in the corresponding .request primitive. This enables the identity of the originally intended recipient to be preserved despite possible redirections imposed by underlying protocols. .response primitives do not carry a To parameter because the intended recipient of the response is implicitly the initiating XP client. |
|
From |
An identifier that denotes the sending XP client in .indication and .confirm primitives. In .indication primitives this parameter makes the identity of the initiating XP client available to the XP processor. [Intermediaries may obscure this or we may require that they don't... discuss] In the XP_Data.confirm primitive this parameter conveys the identity of the responding XP client after any redirections that may have been imposed by underlying protocols. [Again possibly obscured by intermediaries...] In the XP_UnitData.confirm primitive, this parameter conveys the identity of the XP client to which an XP message was sent after any redirections imposed by underlying protocols. NB. Further redirections may occur that cannot be reported. |
|
OrigPath |
A list of identifiers that denote, in order, the path of intermediaries that the originating XP client wishes to process a message prior to delivery to the intended recipient. [We may wish to support the concepts of both strict and loose sourcerouting of XP messages as well as implicit XP message routing. The full route taken by a message may be different from that requested and not fully known to either initiating or responding clients.] The ordering of intermediaries and the ordering of module blocks in ModuleList may be semantically significant. [Depending on actual design it may not be possible to preserve the value of this parameter from .request through to .indication.] |
|
ActualPath |
A list of identifiers that denote the actual path of intermediaries used between initiating and recipient XP clients. This may differ for OrigPath due to redirections imposed by underlying protocols. [The actual path taken by a message may only be partially reported and may be entirely inaccesible.] The ordering of intermediaries and the ordering of module blocks in ModuleList may be semantically significant. |
|
ModuleList |
An optional list of XP module blocks for inclusion in (.request and .response) and included in (.indication and .confirm) XP messages. The ordering of module blocks and the ordering of intermediaries in OrigPath may be semantically significant. |
|
RequestBody |
This is the classic payload data that is passed between XP clients through the operation of the protocol. This data may be processed and extended by XP intermediary processors which may guided in their processing by the presence of XP modules in the ModuleList. |
|
AttachmentList |
This is a list of attachments that are required to accompany the message. These attachments are regarded as opaque byte arrays whose content is preserved between neighbouring XP clients. XP Intermediaries may process, add or delete attachments. Where the underlying protocol(s) natively support attachments these native facilities will be used in accordance with the appropriate binding specification. Where there is no native support for attachments in the underlying protocol, an XML friendly character based transformation will be applied to carry the attachments within the XP envelope. From the point-of-view of abstract service definition the actual mechanism used to transfer attachments is immaterial, however particular bindings may employ more efficient mechanisms than others. [NB. This places an obligation on XP protocol binding specifications to specify how attachments are to be carried.] |
|
BindingContext |
This parameter references an abstract structure that carries information pertinent to the underlying protocol binding(s). For example it may carry certificates, ids and passwords to be used by an initiating XP client to authenticate itself and/or to establish a secure channel. At the responding XP client or intermediary it may carry the authenticated id of the principal on whose behalf the operations is being conducted. If the information present in the BindingContext is inadequate for the execution of a given service primitive the invocation of that primitive will fail with a result that indicates why progress was not possible. BindingContext is optional and if not supplied the local default binding will be used. In the case of multiple bindings being available, inbound BindingContext indicates how an inbound message was received and outbound BindingContext constrains the choice of binding used for a given operation. [NB This concept places another obligation on XP protocol binding specifications in that they must enumerate what binding specific information they require in an outbound BindingContext and what binding specific information they provide in inbound BindingContexts.] It may be possible to aggregate BindingContext fields across multiple protocol bindings – eg. The usage of Realm, UserId, Password, Certificate values may not be restricted to a single protocol binding, they may be broadly applicable attributes of the principal.] |
|
FaultBody |
This carries an alternate response body in the event of an XP processing failure either at the responding XP client or at an intermediary along the path. In the event of such a failure a FaultBody is returned instead of a ResponseBody. |
|
Status |
This parmeter is present in .confirm primitives to indicate whether the operation has completed normally or not. Abnormal completion arises when the operation of an underlying protocol fails. Eg. an attempt to establish a secure channel at a lower layer may suffer an authentication failure. In such circumstances further information about the failure should be accessible in the BindingContext. |
[The service primitives and particularly their parameters are likely to evolve. In an abstract sense with the execption of BindingContext and Status, the remaining parameters are an abstraction of the message exchanged between XP clients. With a suitable definition of an XP message abstraction most of these paramters could be collapsed into fields within that abstraction. Particular bindings would be free to 'lift' fields (like To) from an outbound message and re-express them in lower-level headers or indeed leave them in place and still use them for the formation of lower-layer headers. Likewise on inbound messages, bindings could syntehsise message fields from lower-layer headers if they are not present in within the XML payload. An advantage of expressing attachments as a separate parameter is that their inclusion within the XML envelope or another wrapper (eg. MIME multipart) is deferred to the binding...there will be issues related to the formation of a manifest and internal references (URIs) for and to attachments].
Application specific processing of an XP Message occurs within XP Clients (initiating, responding and intermediary). XP Messages are delivered to XP clients in .indication and .confirm service primitives. Client processing of an XP message may then give rise to the either a response, in the case of an XP_Data.indication, or the generation of further .request primitives as governed by the application protocol operating between peer XP clients. Such application protocols are outside the scope of the XP activity.
In the case of intermediary XP clients, the response returned toward the initiator may be dependent on the outcome of processing at subsequent intermediaries and at the responding client.
The diagram below illustrates the components of an XP client within this abstract model:
Abstract Model of XP Message Processing
The XP Processor is the principle application component of an XP client. It is responsible for the application specific processing of XP messages in accordance with the intended application semantics of the message body, attachments and any optionally included module blocks. The processing of XP module blocks in accordance with the rules of procedure associated with a particular XP module is handed off to a module specific XP Module Processors.
The model of the interface between XP Module processors and an XP Processor is deliberately vague. From an XP module specifcation point-of-view, the important thing to specify with respect to an XP module are:
· the syntax and semantics of the associated XP module blocks
· the rules of procedure with respect to the generation of XP module blocks either in response to the receipt of an XP module block in an inbound message or at an initiating XP client.
[We will need to decide whether the order of module processing is semantically significant. We should have an architectural rule about this. It is probably easier and safer to assert that module processing order is semantically significant and that it is determined by the order in which module blocks arise in XP messages. XP clients initiating the transfer of an XP message may exert an influence of the module processing order by: targetting module blocks at specific intermediaries; by controlling the ordering of module blocks within the message]
An XP Processing intermediary is an XP client that processes XP messages and forwards them on to further intermediaries or the responding XP client. It may be the message path through intermediaries is allowed to fork (cf. SMTP). In the case of two-way operation it is then the responsibility of the intermediary that introduced the fork to coordinate the formation of the response that is returned toward the initiating XP client.
The processing behaviour of an XP processing intermediary is similar to that of an ordinary XP client. Inbound messages (.indication or .confirm primitives) are subject to XP Processing and XP Module Processing. Depending on the function of the intermediary suitably modified XP message body, modulelist and path parameters are formed and a revised message sent on the next leg of its journey. For the two way XP_DATA service, there are two possible interaction patterns plus hybrid derivatives.
· Fully Interlocked: The .request propagates fully through to the responding client which generates a response that propagates fully back to the initiating client
· Hop-by-Hop: where each intermediary responds locally and immediately to its neighbour. Note that with this pattern the response received by the initiating client does not originate from the responding client.
Interlocked XP_DATA operation through Intermediaries
Hop-by-Hop XP_DATA operation through Intermediaries
[Personally, I don't think this hop-by-hop pattern really works. It's here to illustrate the difference and someone else may be able to articulate circimstances where it would be of value... I am at a loss!]
The XP_UNITDATA service operating through intermediaries follows a similar pattern. However, the .confirm primitives arise through the operation of the underlying protocols between neighbouring XP layer entities.
XP_DATA operation through
Intermediaries
Bearing in mind that this is an abstract model, one of the principal roles for an XP layer entity is to provide an abstraction for a binding to an underlying protocol. In this context it is a container for the abstract rules that combine parameters taken from .indication and .response primitives (abstract) to form the outbound message and headers for the underlying protocol and vice-versa in the case of inbound messages and the .indication and .confirm primitives.
[I'd like to do a more detailed treatment of the SOAP HTTP bindings to show how using this form of model it become a non-issue whether the URI of the intended recipient is carried within the SOAP envelope or whether it is carried within the HTTP headers – the binding will dictated the mapping between underlying protocol headers, underlying protocol payload and XP service parameters. Likewise the derivation of the SOAPAction header can be explained. Also, the treatment of attachments would also be useful. I believe that we have to define a default way to carry binary attachments within the XP message envelope – possibly base64 and/or an escape mechanism for XML/text. Thus the support for attachments becomes intrinsic, however the use of more efficient underlying mechanisms for direct handling of binary become part of the binding. I'd also suggest that the construction of manifest, concrete attachment URIs and concrete attachment references be undertaken by the binding (or at least exposed for manipulation by the binding)].
[This section at present is just a place holder – I'd like to do a much more thorough job]
[1] "Simple Object Access Protocol (SOAP) v1.1"
[2]
"Axis Architecture Overview"
http://www.soap-wrc.com/axis/axis_arch_overview_v03.zip
[1] Service primitives are an abstraction of the events that cross the layer boundary between the providers of XP layer services and the client (or user) of XP layer services. They carry as parameters XP messages and other context information related to the event (primitive).