Copyright ©2001 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 XML Protocol.
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 of 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 the work of the Abstract Model Subgroup of the XML Protocol Working Group listed above. The work has benefited numerous discussions on the xml-dist-app@w3.org mailing list and from discussions with other members of the XML Protocol Working Group.
This document is not a W3C Technical Report. It is to be considered a work in progress and does not imply endorsement by the W3C membership nor by the XML Protocol WG.
As a work in progress this document represents the current state of the discussion within the Abstract Model Subgroup and should not be regarded as representing a position of full consensus amongst the membership of the subgroup. 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.
Henrik is concerned that section 3 appears to him like the definition of an API rather than as an abstract description of a wire protocol. The concern is not to as whether an abstract description should be produced or not - it certainly does bring value.
The concern is that rather than taking a "wire-protocol" approach for defining the abstract model, section 3 seems to take an approach that is more targeted a particular implementation model. An alternative description of the abstract model could be cast in terms of XML Protocol concepts such as "XML Protocol Blocks", "XML Protocol Handlers", and "XML Protocol Modules" rather than in terms of events.
In addition, Henrik has concerns that the current model seems to call out specific message exchange patterns like request/response special cases of interactions instead of providing an abstraction of how multiple message exchange patterns can be supported within the XML Protocol.
Fault Handling: Section 3 includes ideas on fault handling. These are really seeds for discussion and subject to change as the discussion matures.
The Subgroup feels that the Abstract Model should be mapped against the various scenario's presented in the requirements document. This work will not be started before the February F2F.
Fig 2.1 suggest a one-one correspondence between handlers and blocks. Are handlers allowed to process multiple blocks? (yes) Is a given block allowed to be processed by multiple handlers? (Yes).
A direct single hop interaction is not shown. This may give the impression that all operations pass through intermediaries, which is not the case.
Figure 2.1: would like the handlers to be given some concrete purposes: eg. Signature generator, Signature checker, Path handler...
The relation between the terms XMLP Module, XMLP Block and XMLP Handler may need more work.
@@@
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 intended audience for this document initially is the XML Protocol WG itself. In the longer term it is hoped that the material in this document will serve as a useful overview and introduction to the XML Protocol and its framework.
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.
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.
|
|
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.
|
|
|
A primitive capability or service offered by the XML Protocol Layer. The XML Protocol Layer supports 3 operations described in detail in Section 3. XMLP Operations are modelled as sequences of event crossing the layer boundary between XML Protocol Processors and XML Protocol Applications.
|
Figure 2.1 below presents an overview of the XML Protocol abstract model.
Figure 2.1 shows 5 hosts. Host I, III and V each contain XML protocol application components, which use the services of the XML protocol layer, and XML protocol layer components which provide the services of the XML protocol layer. The services of the XML protocol layer are abstracted at the upper layer boundary and consist of three operations which will be described in detail in Section 3.
Two of these operations, XMLP_DATA and XMLP_UNITDATA correspond to the exchange of messages using two-way request/response and one-way only message patterns respectively. These two operations are available to sending and receiving XML protocol applications, such as at Hosts I and V in figure 2.1. The third operation, XMLP_INTERMEDIARY, provides explicit support for intermediary XML protocol nodes such as Host III in figure 2.1.
Hosts II and IV are intermediaries that operate within underlying protocol layers such as HTTP proxies, SMTP message routers and arguably even IP routers and 802.1 MAC layer bridges.
Figure 2.1 can be used to discuss a number of message exchange scenarios. For example, the XML protocol Processor at Host III is bound to two, possibly different, underlying protocols. It could serve merely as a 'helper' to transition an XML protocol message from one underlying protocol to another in circumstances where the initiating processor is bound to a different underlying protocol infrastructure than the receiving or responding node, say Host V in figure 2.1. A similar scenario arises if Host III is part of an XML Protocol Firewall that controls the ingress and egress of messages from a given organisation. In both these circumstances the XML Protocol Handler(s) within the XML protocol application at Host III need not be present.
If we turn our attention to the operation of the XML protocol applications above the XML protocol layer boundary. We have a scenario in which the application at Host I has some XML protocol blocks to deliver to Host V. In addition the application at Host I needs to trigger Intermediary functionality at Host III by the inclusion of several XML Protocol Blocks. "XML Protocol Block 1" is targeted at "XML protocol handler (e) " within the application on Host V. Block 2 is targeted at handler (h) and handler (c) which replaces Block 2 with Block 3. Also, the XML protocol application at Host III inserts Block 4 into the message forwarded from Host III to Host V. Blocks 3 and 4 are targeted at handlers (f) and (g).
This section focuses on the definition of an abstract interface between the XML protocol applications and the XML protocol layer. In needs to be remembered that the layer interface described in this section is abstract - its purpose is to enable description, not to constrain implementation.
The services provided by the XML protocol layer are modelled as two operations. XMLP_UNITDATA provides services to sending and receiving XML protocol applications. XMLP_INTERMEDIARY provides explicit support for intermediary XML protocol applications to provide value added services to messages in transit.
XMLP_UnitData is a best effort one-way message transfer operation with support for message correlation.
Conceptually the XMLP_UnitData operation encapsulates the transmission of an XML protocol message from a sending XML protocol application to receiving XML protocol application. Conceptually and from the point-of-view of message correlation, each XMLP_UnitData operation causes the transmission of a different message even if the message has the same value as a previous message.
The XMLP_UnitData operation is modelled by three 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]);
All
parameters are detailed in Section 3.3
Figure 3.1 below illustrates the normal use of these primitive at the sending and receiving XML protocol applications.
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 the one or more intermediary XML protocol applications. 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. It other circumstances it may be possible to report that a message has or has not been delivered to its ultimate recipient.
XMLP_UnitData.send: 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).
XMLP_UnitData.receive: 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: 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 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.
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.
This operation may be implemented over HTTP, HTTPS, SSL/TCP, TCP and SMTP.
When included in an XMLP_UnitData.send primitive Correlation.MessageRef indicates that the XML protocol message being sent is a direct consequence of the processing of an XML protocol message previously received by the sending XML protocol application and referenced locally by Correlation.MessageRef.
Likewise, when included in an XMLP_UnitData.receive primitive Correlation.MessageRef indicates that the message being received is a direct consequence of the processing of a XML protocol message previously sent by the receiving XML protocol application and referenced locally by Correlation.MessageRef.
The Correlation parameter provides a general mechanism by which richer message exchange patterns such as request-response and request/multi-response can be derived on top of the one-way message exchange pattern of the XMLP_UnitData operation.
Failures that arise during message processing at the recipient or at intermediary XML protocol applications may result in the generation of fault messages directed toward the originator of the message whose processing gave rise to the fault. Such fault messages are a direct consequence of the faulted message and this should be indicated through the use of the Correlation parameter.
NB. No faults should be generated as a direct consequence of processing fault elements within an XML protocol messages carrying faults.
The XMLP_Intermediary operation is used to pass an XML protocol message through an XML protocol intermediary.
Conceptually an XML protocol intermediary does not generate a new XML protocol message, it operates on an XML protocol message in transit. Thus the received message and the forwarded message are regarded as the same message although the intermediary may change the value of the message.
The XMLP_Intermediary operation is modelled by two primitives (events) which model reception and forwarding of an XML protocol message at the interface between the XML protocol processor and the intermediary XML protocol application:
XMLP_Intermediary.receive( To, From, Message, [Correlation],
[BindingContext]]);
XMLP_Intermediary.forward( [ImmediateDestination], Status,
Message, [BindingContext]]);
All
parameters are detailed in Section 3.3
Figure 3.2 below illustrates the normal use of these primitives at an intermediary XML protocol application.
This operation effectively interposes the intermediary XML protocol application in the path between sending/initiating and receiving/responding XML protocol applications.
XMLP_Intermediary.receive: Invoked by an intermediary
XML protocol processor and directed at a local intermediary XML
protocol application to provide the intermediary XML protocol
application the opportunity to perform intermediary processing on a
message in transit.
This primitive is invoked as a result of the arrival of an XML
protocol message at an intermediary XML protocol processor from the
underlying protocol layers.
XMLP_Intermediary.forward: 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. The intermediary XML protocol application may
report success or failure via the Status parameter.
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.
NB. No faults should be generated as a direct consequence of
processing fault elements within an XML protocol messages
carrying faults.
Figure 3.3 shows the normal behaviour of an XML_UnitData operation through an intermediary in the absence of fatal failures. The three vertical lines at represent the local XML protocol layer boundaries and the small arrows above denote the up/down orientation of the boundary. Figure 3.4 below shows and alternate representation of the same scenario.
The scenario depicted in figures 3.3.and 3.4 show just a single intermediary interposed in the operation.
It is worth noting that the XMLP_UnitData.status is generated from within the XML protocol layer. It may indicate anything from the mere fact that the initial message has been sent by the sending node; that its has been received and/or sent from the intermediary node; or that it has indeed been delivered to the receiving node. What it means in a given circumstance will depend upon the capabilities of the underlying communications protocols used to construct the message path. The strongest thing that it can indicate is the failure to deliver an XML protocol message to its ultimate recipient.
The Correlation.MessageRef sub-field of the optional Correlation parameter on the XMLP_Intermediary.receive primitive carries a local abstract reference to an XML protocol message that previously passed through the same intermediary XML protocol application of which the current message is a direct consequence.
Typically this will arise when an application level response travels along a path that passes through one or more of the same intermediary XML protocol applications that the corresponding request passed through earlier.
This section describes the operation parameters used in the operation primitives described above.
|
An identifier that denotes the XML protocol application that a message was originally sent to by the initiating or sending XML protocol application.
|
|
An identifier that denotes the sending XML protocol application in .indication, .receive, .status and .confirm primitives. In .receive primitives this parameter makes the identity of the sending/initiating XML protocol application available to the receiving/responding XML protocol application. [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. I[Again possibly obscured by intermediaries...]
|
|
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.
|
|
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.Headers; Message.Bodies
and Message.Attachments.
|
|
An optional list of faults that may
accumulate as a message passes through multiple intermediary XML
protocol applications, a responding XML protocol application and at
further intermediary XML protocol applications on the response leg
of a two-way operation.
|
|
A container for XML protocol
blocks that are intended to be processed by intermediaries.
|
|
A container for XML protocol blocks
that are intended to be processed by the ultimate recipient.
|
|
This is a list of attachments that are
required by the XML protocol application in addition to the
XML message and that should accompany the 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. [NB. This places an obligation on XML protocol binding specifications to specify how attachments are to be carried.]
|
|
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.
|
|
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 by the receiving application. In XMLP_Intermediary.receive primitives, the value of this parameter references an XML protocol message that has previously been forwarded by this intermediary.
|
|
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. [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.]
|
|
In .confirm and .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.
In the XMLP_Intermediary.forward primitive, the Status parameter may take on the values: Success or Failure.
|
An XML protocol application is an entity that makes use of the core messaging services of the XML protocol. XML protocol applications may initiate, respond or act as intermediaries in XML protocol operations. Logically, an XML protocol application contains a number of XML protocol handlers that are responsible for the applying the processing rules associated with one or more XML protocol modules. The unit of exchange between XML protocol handlers are XML protocol blocks.
XML protocol blocks are aggregated into XML protocol messages and may be targetted at particular XML protocol handlers (see Section 4.2). Targetted XML protocol blocks are delivered together with the rest of the XML protocol message which encapsulates them (and its attachments if any) first to the XML protocol application that contains the targeted handler. The XML protocol application is then responsible for identifying and dispatching the targeted XML protocol handlers.
Each handler may succeed, fail non-fatally or fail fatally. It is the responsibility of the XML protocol application to determine the overall result of the actions of any XML protocol handlers it invokes and to augment any Faults structure carried in the ongoing message. In cases where there are multiple influences on the ImmediateDestination, it is also the responsibility of the XML protocol application resolve any conflicts.
XML protocol modules are the unit of extension within the XML protocol. Within this abstract model XML protocol modules reside as components of an XML protocol application. 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, which are realised in XML protocol application components known as XML protocol handlers.
Thus the definition of an XML protocol module requires the definition of the syntactic structure and semantics of one or more XML protocol blocks and the definition of the behavioural rules (if any) that apply to the generation and handling of those XML protocol blocks. An XML protocol handler may provided support for multiple XML protocol modules.
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 much of this understanding for a related "chunk" of processing behaviour. A given message may employ the services of many modules, both generic (e.g., security, caching, compression, transactions, etc.) and application-specific. SOAP does not define an analogous concept of a module that captures these important constraints and relationships. It remains to be seen in XMLP where the module concept will be most useful.
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.
Within the XML protocol there are two entities that need to be addressed or targeted. XML protocol applications and XML Protocol Handlers. It will be apparent from the preceding discussion that within this abstract model XML protocol handlers are deemed to reside within or operate as part of an XML protocol application. This implies that the targeting of a particular XML protocol block at a particular XML protocol handler, implicitly targets the XML protocol message at the XML protocol application that contains the targeted handler.
There are several ways in which an XML protocol block may be targeted at an XML protocol handler:
Needs to use some terms here that arise from the intermediaries thread Martin started
A XML protocol mesage 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.1, the diagram in figure 5.2 depicts the message path of the corresponding XML protocol message under the XML_UnitData operation.
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.
It is the intent that the XML protocol be capable of being bound to a variety of underlying communication protocols. The XML protocol working group will define a binding to HTTP. It is anticipated that others will create bindings to SMTP, TCP, SSL, BEEP and others.
This entire subsection is new and has not be subject of significant debate. It should be regarded as a work in progress.
This section presents an abstract service model that XML protocol bindings will supply to the upper XML protocol layer. The intent is to describe the interactions between the XML protocol processor and underlying protocol bindings and to demonstrate how these interactions are correographed to enable multiple message exchange patterns. This model is intended to provide a framework in which the development of concrete binding specifications can be discussed. This is not intended as an API specification.
The diagram below shows a logical layered view of the binding model with the XML protocol processor being bound to four underlying transports.
This document concerns itself with the interactions at the solid black line between the XML protocol processor and a given binding.
There are two primitives associated with message exchange: MSG.req and MSG.ind. A MSG.req primitive is sent from the XML protocol processor to the binding in order to cause the binding to send a message. A MSG.ind primitive is sent from the binding to the XML protocol processor to indicate arrival of a message.
[Question: do we also need a MSG.confirm to primitive sent from the binding to the XML protocol processor to indicate successful transmission or is ERR.ind sufficient for informing of failure]
In order to support message exchange patterns that are more complex than the simplest one-way exchange, some form of message correlation is required. For example, in a request-response message exchange there must be some means of correlating the request with the response. In this document a single instance of a message exchange pattern is referred to as an XML protocol processor operation or just operation for short.
There are four pairs of primitives associated with operation delineation and hence message correlation:
A OP.start-req primitive is sent from the XML protocol processor to the binding to request initialisation of a new correlated message exchange. The binding responds with a OP.start-conf primitive.
A OP.start-ind primitive is sent from the binding to the XMPL layer to indicate that a new correlated message exchange is being requested. The XML protocol processor responds with a OP.start-resp primitive.
An OP.end-req primitive is sent from the XML protocol processor to the binding to terminate a correlated message exchange. The binding responds with an OP.end-confprimitive. Whilst the OP.end-conf is outstanding, the XML protocol processor must be prepared to continue to receive MSG.inds
An OP.end-ind primitive is sent from the binding to the XML protocol processor to indicate that a correlated message exchange is to be terminated. No further MSG.ind will be delivered as part of the corresponding operation, however the XML protocol processor receiving the OP.end-ind primitive may continue to issue MSG.req primitives to complete operation in progress. Once all MSG.req primitives associate with the operation have been issued the XML protocol processor concludes the operation by with the invocation of an OP.end-resp primitive."
The actual correlation mechanism is underlying protocol and implementation specific. e.g. A OP.start-confmay carry some unique identifier that must be provided with any subsequent MSG.req(s) and is included with any subsequent MSG.ind(s).
There is no retained state within the binding between operations although there may be during operations.
The final primitve ERR.ind is sent from the binding to the XML protocol processor when an error occurs. E.g. if a MSG.req cannot be honoured then an ERR.ind is generated. Errors are correlated to a particular message exchange using the mechnanism described above.
The following sections illustrate the correography of XML protocol binding primitives for a number of different message exchange patterns.
Sender
OP.start-req, OP.start-conf, MSG.req, OP.end-req, OP.end-conf.
Receiver
OP.start-ind, OP.start-resp, MSG.ind, OP.end-ind, OP.end-resp.
Comments
Note that depending on the underlying protocol the primitives at sender and receiver may not operate in lock-step. In particular, the OP.start-ind may not be delivered to the receiving XML protocol processor until the sending XML protocol processor has issued the MSG.req or even the OP.end-req. An alternative way of saying this is that a binding may choose to delay making an underlying protocol connection until a message needs to be sent.
Sender
OP.start-req, OP.start-conf, MSG.req, MSG.ind, OP.end-req, OP.end-conf.
Receiver
OP.start-ind, OP.start-resp, MSG.ind, MSG.req, OP.end-ind, OP.end-resp.
Sender
OP.start-req, OP.start-conf, MSG.req, MSG.ind, MSG.ind, ..., OP.end-ind, OP.end-resp.
Receiver
OP.start-ind, OP.start-resp, MSG.ind, MSG.req, MSG.req, ..., OP.end-req, OP.end-conf.
The following tables show how the binding primitives might map onto the HTTP protocol actions on the initiator and responder for a request-response message exchange, time increases moving down the tables.
[These would probably be better as diagrams]
Binding Primitive | Binding Action |
OP.start-req | |
Open connection | |
OP.start-conf | |
MSG.req | |
Send POST request | |
Receive POST results | |
MSG.ind | |
OP.end-req | |
Close connection | |
OP.end-conf |
Binding Primitive | Binding Action |
Accept new connection | |
Receive POST request | |
OP.start-ind | |
OP.start-resp | |
MSG.ind | |
MSG.req | |
Send POST results | |
Receive connection close | |
OP.end-ind | |
OP.end-resp |
The above assumes use of the HTTP Connection: keep-alive header
The following tables show how the binding primitives might map onto the SMTP protocol actions on the initiator and receiver for a simple one-way message exchange, time increases moving down the tables.
[Again, these would probably be better as diagrams]
Binding Primitive | Binding Action |
OP.start-req | |
OP.start-req | |
OP.start-conf | |
MSG.req | |
Send mail message | |
OP.end-req | |
OP.end-req | |
OP.end-conf |
Binding Primitive | Binding Action |
Begin SMTP transaction | |
Receive mail message | |
End SMTP transaction | |
OP.start-ind | |
OP.start-resp | |
MSG.ind | |
OP.end-ind | |
OP.end-resp |
Underlying protocols may provide various levels of functionality to the binding. It is the responsibility of the binding to implement a mapping between XML protocol service primitives and underlying protocol primitives. The mapping should make the best use of the facilities of the underlying protocol and maximise efficiency where possible. E.g. connection setup is generally an expensive operation - bindings for connection oriented protocols should attempt to minimise the number of connections made for a given message exchange pattern. In particular, when defining a mapping the following need to be specified:
The binding needs to specify unambiguously how to use the underlying protocol to pass a whole XML Protocol message (or a MIME envelope) to a node specified by a given address. Depending on the underlying protocol capabilities, the specification may need to detail the following:
[Question: what other message exchange pattern should we specify here ?]
Here, protocol session means a unit of communication in the underlying protocol, in HTTP this maps to a single request/response, in SMTP a session only covers a single act of sending a message or a single act of receiving a message. In BEEP the session would possibly map to a channel that would be capable of many different message exchange patterns.
[Question: what other types of error do we need to consider ?]
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.
Hopefully this captures the general idea behind BindingContext... the details will evolve over time... indeed they will evolve as bindings get described.
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_Data and 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.
There is an issue as to whether something like SOAP1.1 over HTTP and SOAP 1.1 with attachments over HTTP constitute two distinct bindings or whether they should be amalgamated as a single binding over HTTP. XML protocol will likely have to face the same question. A distinction would be, in the case of a combined binding, the inbound side of the binding at least would have to support both forms, although the outbound side could make a fixed (implementation dependent) choice one way or the other. If we choose the two distinct bindings route we have two no-interoperable bindings - ie. there would need to be an interworking (helper) unit of some description in the message path translate the underlying protocol envelope between bindings. By analogy, an XMLP 1.0 over HTTP would not be capable of directly ingesting an XMLP 1.0 with Attachments envelope without help.
[XMLPReqs] "XML Protocol (XMLP) Requirements" http://www.w3.org/TR/2001/WD-xmlp-reqs-20010319/#N2082