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.
Figure 3.1 XMLP_DATA 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 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.
Figure 3.2 XMLP_Intermediary Operation
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.
Figure 3.3 Normal XMLP_UnitData operation through an Intermediary
Figure 3.4 Normal XMLP_UnitData operation through and Intermediary (alternate treatment)
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.
|