XML Protocol Abstract Model

1.1 Definition of Terms

This document makes use of terms defined in the [XMLPReqs]. Additional terms introduced in this document are defined locally in this section, however, in the long term we anticipate that they will be incorporated into a single glossary for all documents produced by the WG.

XMLP Application	A client or user of the services provided by the XML Protocol Layer. An XML Protocol Application may act in the initiating or responding role with respect to two-way request response operations and in the sending or receiving roles with respect to one-way operations. XML Protocol Applications may also act in an intermediary role with respect to both two-way and one-way operations. XML Protocol Handlers are encapsulated within XML Protocol Applications.
XMLP Layer	The XML Protocol Layer is an abstraction that provides services or operations that transfers packages of XML Protocol Blocks between peer XML Protocol Applications via zero or more XML Protocol Intermediaries.
XMLP Operation	A primitive capability or service offered by the XML Protocol Layer. The XML Protocol Layer supports 3 operations described in detail in 3 XML Protocol Layer Service Definition. XMLP Operations are modelled as sequences of events crossing the layer boundary between XML Protocol Processors and XML Protocol Applications.

3.1 XMLP_UnitData Operation

XMLP_UnitData is a best effort one-way message transfer operation with message correlation. Multiple message transfer operations can be correlated in various ways to form message exchange patterns like request/response, and long-lived dialogs.

The XMLP_UnitData operation is modeled by four primitives (events). Each primitive models a transmission, reception or status event at interface between an  XML protocol application and an XML protocol processor:

XMLP_UnitData.send( To, [ImmediateDestination], Message, [Correlation], [BindingContext]);

XMLP_UnitData.receive( [To], [From], Message, [Correlation], [BindingContext]);

XMLP_UnitData.status( [From], Status, [BindingContext]);

XMLP_UnitData.forward( [ImmediateDestination], Message, [BindingContext]);

All parameters are detailed in 3.2 Operation Parameters.

Conceptually the XMLP_UnitData operation encapsulates the transmission of an XML protocol message from a sending XML protocol application to a receiving XML protocol application. The principal conceptual difference between sending and forwarding an  XML protocol message is that, from a message correlation point of view, sending generates a new message whereas forwarding passes on an existing message. Conceptually the forwarded message is the same message as previously received although the action of intermediary processing may have changed the value of the message.

Figure 3.1 below illustrates the normal use of these primitive at the sending and receiving XML protocol applications.

Figure 3.1 XMLP_UNITDATA Operation

The operation is best effort which means that it can fail silently with the loss of the message in transit. A lost  message may have been partially processed at an intermediary XML protocol application. The success or failure of the operation is reported via the XMLP_UnitData.status primitive. In some circumstances it may only be possible to report that a message has been sent. In other circumstances it may be possible to report that a message has or has not been delivered to its ultimate recipient.

XMLP_UnitData.send is invoked by the sending XML protocol application and directed at the local sending XML protocol processor to start a one-way transfer operation.

Upon receipt of this primitive by the sending XML protocol processor an XML protocol message is transferred from the sending XML protocol processor toward the receiving XML protocol processor (possibly via intermediary XML protocol processors).

This primitive differs from the .forward primitive in that it is used by the initial sender of an XML protocol message to send a new message.

XMLP_UnitData.receive is invoked by the receiving XML protocol processor and directed at  a local receiving  XML protocol application to deliver a received XML protocol message. 

This primitive is invoked as a result of the arrival of an XML protocol message from the sending XML protocol processor (via the underlying protocol layers).

XMLP_UnitData.status is used to report on the delivery status of the operation to the sending XML protocol application. This primitive may be used to report to the sending XML protocol application on the success or failure to send and deliver a message to the receiving XML protocol application. In general, it is not possible to assert that a message has been delivered to the receiving XML protocol application without engaging in further interactions. With care it is possible to assert definite failure to deliver provided that circumstances are such that there is no possibility of subsequent delivery. From the point-of-view of the initiating XML application the operation has completed once this primitive has been invoked.

XMLP_UnitData.forward is invoked by an intermediary XML protocol application once it has completed intermediary processing of a message in transit and directed at the local intermediary XML protocol processor.

In the event of success the message is forwarded to its next destination, as designated by the ImmediateDestination parameter if given. Alternatively an implementation or configuration dependent method may be used to select the next recipient of the message along a path.

In the event of failure, the message in transit is discarded. A correlated fault message may be generated by the intermediary XML protocol application and sent toward the originator of the failed message.

This primitive differs from the .send primitive in that it is used by an intermediary XML protocol application to forward an existing XML protocol message received by the intermediary XML protocol application.

An XML protocol application may engage in multiple concurrent operations with the same or different intermediary and/or receiving XML protocol applications. These concurrent operations are independent and the order in which they are processed by the receiving and intermediary applications may be different from the order in which they are invoked or complete at the sending XML protocol application. 

3.2 Operation Parameters

This section describes the operation parameters used in the operation primitives described above.

To	An abstract reference that denotes the XML protocol application that a message was originally sent to by the initiating or sending XML protocol application.
From	An abstract reference denotes the sending XML protocol application in .receive primitives. In  .receive primitives this parameter makes the identity of the sending/initiating XML protocol application available to the receiving/responding XML protocol application. Editorial note [Intermediaries may obscure this or we may require that they don't... discuss!] In the XMLP_UnitData.status primitive, this parameter conveys the identity of the XML protocol application to which an XML protocol message was sent after any redirections imposed by underlying protocols. NB. Further redirections may occur that cannot be reported. Editorial note [Again possibly obscured by intermediaries...]
ImmediateDestination	An identifier that denotes the immediate destination of an XML protocol message. If this parameter is unspecified, the default value is implementation and configuration dependent. This parameter enables sending and intermediary XML protocol applications to address the message to the next intermediary on route.
Message	An abstraction of an XML protocol message exchanged between sending and receiving XML protocol applications. An XML protocol message has the following sub-fields:  Message.Faults; Message.Blocks; and Message.Attachments.
Message.Faults	An abstraction of a collection of XML protocol faults carried in an XML protocol message that is correlated with the XML protocol message whose processing gave rise to one or more faults. Such a message may arise at an intermediary or at the ultimate recipient.
Message.Blocks	An abstraction of the XML protocol  blocks within an XML protocol message which are intended to be processed by intermediaries or the ultimate recipient.
Message.Attachments	An abstraction of the a collection of arbitrary attachments being transferred as part of an XML protocol message. These attachments are opaque bytes as far as XML protocol processing elements are concerned. 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. Editorial note [NB. This places an obligation on XML protocol binding specifications to specify how attachments are to be carried.]
Correlation	An optional parameter used to express local relationships between XML protocol messages. At present only a single subfield, Correlation.MessageRef is defined, however it is conceivable that other subfields may be defined in future, eg. Correlation.MsgSequence to distinguish between and potentially order n multiple messages that arise from the same source as a direct consequence of  the current message.
Correlation.MessageRef	An abstraction of a local reference to the local abstraction of an XML protocol message the processing of which the current XML protocol message is a direct consequence. In XMLP_UnitData.send primitives, the value of this parameter references an XML protocol message previously received by the sending XML protocol application. In XMLP_UnitData.receive primitives, the value of this parameter references an XML protocol message previously sent or forwarded by the receiving application.
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 the sending/initiating XML protocol application to authenticate itself and/or to establish a secure channel. At the responding XML protocol application it may carry the authenticated id of the principal on whose behalf the operation 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. BindingContext is discussed further in 5.2 BindingContext. Editorial note [NB This concept places another obligation on XML 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.]
Status	In .status primitives this parameter indicates the disposition of the request operation which may be: MessageSent, MessageDelivered, Unknown and FailedAtIntermediary. The interpretation of a status value may be augmented by information carried in the BindingContext.

4.1 XML Protocol Message Routing and Targeting (aka Naming and Addressing :-))

Editorial note Needs to use some terms here that arise from the intermediaries thread Martin started

An XML protocol message path can be viewed as the sequence of handlers that an XML protocol message passes through between initiating/sending XML protocol application and receiving responding XML protocol application. With reference to figure 2.2, the diagram in  figure 4.2 depicts the message path of the corresponding XML protocol message under the XML_UnitData operation.

Figure 4.2 XML Protocol Message Path

The path in figure 4.2 shows sequential handler processing at the sending node, Node I, while the handler processing at Nodes III and V is concurrent (at least logically). Combinations of handlers that can be invoked concurrently from within an XML protocol application are said to be mutually orthogonal.

4.2 XML Protocol Modules and Message Processing

XML protocol modules are the unit of extension within the XML protocol.  An XML protocol module encapsulates the syntactic constructs of an extension, known as XML protocol blocks, and the behavioural rules associated with the generation and processing of an XML protocol block.  The abstraction for the processing and/or logic defined by an XML protocol module is called an XML protocol handler.

The SOAP 1.1 specification (section 2) states:  "Processing a message or a part of a message requires that the SOAP processor understands, among other things, the exchange pattern being used (one way, request-response, multicast, etc.), the role of the recipient in that pattern, the employment (if any) of RPC mechanisms such as the one documented in section 7, the representation or encoding of data, as well as other semantics necessary for correct processing."  An XML protocol module is the locus for understanding blocks associated with that module.  A given message may employ the services of many modules, both generic (e.g., security, caching, compression, transactions, etc.) and application-specific.

The following list provides an initial set of concepts which capture and slightly refine the SOAP message processing model.  A comparison of each concept with SOAP is also provided for reference.

1. An XML Protocol message consists of a set of zero or more blocks.

   Editorial note SOAP: Similar. Blocks correspond to header or body entries. SOAP groups header entries into an optional Header element and body entries into an obligatory Body element.

2. Each block has the following sub-fields: Block.Id, Block.Actor, and Block.MustUnderstand. Block.Id is an optional identifier that identifies the block for the purposes of reference by other blocks. Block.Actor identifies the XMLP processor that is intended to process the block. Block.MustUnderstand specifies whether the intended semantics of the block must be carried out.

   Editorial note SOAP: SOAP does not specify whether an actor URI is to be interpreted extensionally (naming a particular node) or intensionally (describing a node or group of nodes that satisfy some property). Special reserved URI's describe nodes which are encountered next or last.  Beyond the reserved URI's, there is no particular semantics associated with an actor URI.  Semantically, the URI's can signify a processor that supports a given application, module or capability, or it can describe a destination, node or location.  This flexibility is preserved in XMLP.

3. The fully qualified name of the top element of a block identifies the block.

   Editorial note SOAP: SOAP identifies blocks by the fully qualified element name.  The block can (but need not) be mapped to some appropriate handler.  Other schemes have also been suggested.  For example, an attribute could name a module which would take responsibility for selecting the handler to invoke.

4. The following values for Block.Actor have special significance: Next, Final, and None.; Next matches the next processor. Final matches the final processor. None is for untargeted blocks which may be referenced by other blocks.

   An empty actor defaults to Final.   An untargeted block marked with None is useful for declarative information that is referenced by another block or blocks. It is guaranteed not to be removed and can even be referenced by blocks which are targeted at different processors.

   Editorial note SOAP: An empty SOAP actor in a header "indicates that the recipient is the ultimate destination of the SOAP message," and a "body entry is semantically equivalent to a header entry intended for the default actor." This is what Final designates. The intended (final) processor must recognize itself as such. Next has the same interpretation as the SOAP URI, http://schemas.xmlsoap.org/soap/actor/next SOAP forces the actor for body entries to be the final processor. SOAP permits the inclusion of blocks for which there do not turn out to be any actors that match along the message path; and even if an actor URI matches a given processor, the processor may determine that no behaviour is associated with the block. The value None, on the other hand, is a stronger statement on the part of the sender that signifies that no processor will qualify as a matching actor.

5. When a block is selected for processing at an intermediary, the block is removed from the envelope.  A handler may add zero or more blocks. Blocks which are merely referenced are not removed.

   Editorial note SOAP: SOAP doesn't allow body entries to be processed at intermediaries and hence they are never removed at an intermediary.

6. The XML Protocol blocks are ordered within the envelope. This order is followed by each processor as it selects and processes blocks, yielding a limited facility for specifying sequential constraints. Two alternatives are available for more complex orderings and constraints.   Hierarchical constraints can be achieved by syntactically scoping blocks inside one another. Finally, blocks can be incorporated by reference using the "id" and "href" attribute mechanism.; Using these techniques, more elaborate "manifest" blocks which direct the processing of other blocks can be designed. From the processor's point of view, only the outermost element of the block is seen.

   Editorial note SOAP: Header entries can be referenced via links from other headers. If they have no actor (targeted at the final destination), they will not be removed by any intermediaries. Using that mechanism, headers can be effectively shared among modules, even at different nodes. The actor-less headers are interpreted as relevant to the final processor, even though they may not be. The body can only be targeted at the final procesor.

7. The processing of a block by a handler may result in a fault or a successful evaluation.  A fault terminates processing of the block and message and causes a return message containing the fault to be generated if a return path is available.  Rather than fatally faulting, it is also possible for a handler to insert a block targeted to another destination e.g., the final destination).  This block can contain status information, non-fatal errors, or other results that can be further processed, incorporated into a return value, etc.

   Editorial note SOAP:  Similar.

5.1 Binding Service Model

Editorial note This entire subsection is new and has not be subject of significant debate. It should be regarded as a work in progress

5.2 BindingContext

Each of these underlying protocols supports different features and capabilities and it is not plausible or desirable to provide a detailed abstraction that captures the full range of diversity. The core of XML protocol in respect of the exchange of XML protocol messages takes a lowest common denominator approach by regarding the underlying channel as potential lossy and capable of mis-ordering and duplication. Underlying protocols may offer better assurances of delivery probability, delivery ordering and at-most once delivery behaviour.

In the service abstraction provided above, an abstract parameter known as BindingContext is introduced. The primary purpose of BindingContext is to act as a collecting 'bucket' for parameters that control the functionality of the particular set of underlying protocols available at any given node.

It is expected that the authors of XML Protocol binding specifications will add structure beneath BindingContext to cover the features and capabilities of the underlying protocol being bound. This may also include a descriptor of the ordering, loss and duplication properties of the underlying protocol, although this should be treated with caution in multi-hop scenarios.

Some BindingContext extensions may be of more general applicability than just a single binding. For example, the references to user ids, private keys and public certificates necessary for SSL and HTTPS could be shared between both bindings (were they to exist).

One would therefore expect the structure under BindingContext to grow along the lines of:

BindingContext.Shared    //A substructure for information shared by several bindings

BindingContext.HTTP      //A substructure for information related to HTTP

BindingContext.SMTP     //....

 

....and so on.

The manipulation of fields within the BindingContext may be driven from within, for example, an intermediary XML protocol application on the basis of constructs carried as XML protocol message blocks within the message being carried.

Editorial note Hopefully this captures the general idea behind BindingContext... the details will evolve over time... indeed they will evolve as bindings get described.

5.3 Attachment of Arbitrary Content

Editorial note This topic is subject to active discussion and the view presented here is *very* preliminary. There is likely be considerable diversity of viewpoints that are not captured let alone resolved here.

Another role of an XML protocol binding is to invoke the services of underlying protocols and to introduce any mechanism required to map between the semantics of the underlying protocol and those of the XML protocol core message delivery operations  XMLP_UnitData. The attachment of arbitrary content to an XML protocol message is one facet of this mapping.

The core XML protocol messaging services intrinsically handle arbitrary attachments through the use of the Attachments parameter. The expectation is that the design of XML protocol WILL specify a means for encoding arbitrary content and carrying it within an XML protocol envelope. This mechanism will leverage any pre-existing work within XML Schema, and will also provide mechanisms for embedding complete, arbitrary, XML documents within the outer XML protocol message envelope (itself an XML construct).

Some underlying protocols will support more efficient ways of carrying arbitrary content and or multiple XML documents. The normative bindings to an underlying protocol MUST define the mechanism used by that binding to carry attachments containing arbitrary content. In the absence of any statement to the contrary in the definition of a particular protocol binding, the default XML based encoding for arbitrary content attachments will be taken as having been specified. Any other scheme specified for a particular binding must have functional capabilities at least as capable as the default XML based encoding scheme, in particular it must be possible to reference the individual attachments from within the XML protocol message envelope.