You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1582 lines
78 KiB
1582 lines
78 KiB
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<html lang="en-US"><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"><title>XML Protocol Abstract Model</title><style type="text/css">
|
|
code { font-family: monospace; }
|
|
|
|
div.constraint,
|
|
div.issue,
|
|
div.note,
|
|
div.notice { margin-left: 2em; }
|
|
|
|
dt.label { display: run-in; }
|
|
|
|
li p { margin-top: 0.3em;
|
|
margin-bottom: 0.3em; }
|
|
|
|
div.exampleInner pre { margin-left: 1em;
|
|
margin-top: 0em; margin-bottom: 0em}
|
|
div.exampleOuter {border: 4px double gray;
|
|
margin: 0em; padding: 0em}
|
|
div.exampleInner { background-color: #d5dee3;
|
|
border-top-width: 4px;
|
|
border-top-style: double;
|
|
border-top-color: #d3d3d3;
|
|
border-bottom-width: 4px;
|
|
border-bottom-style: double;
|
|
border-bottom-color: #d3d3d3;
|
|
padding: 4px; margin: 0em }
|
|
div.exampleWrapper { margin: 4px }
|
|
div.exampleHeader { font-weight: bold;
|
|
margin: 4px}
|
|
|
|
DT {
|
|
MARGIN-TOP: 0.5em; MARGIN-BOTTOM: 0.5em
|
|
}
|
|
hanging indent { text-indent: -1in; margin-left: 1in }
|
|
DD.charter {
|
|
FONT-STYLE: italic
|
|
}
|
|
LI.charter {
|
|
FONT-STYLE: italic
|
|
}
|
|
|
|
LI.change {
|
|
FONT-SIZE: smaller
|
|
}
|
|
|
|
SPAN.charter {
|
|
FONT-STYLE: italic
|
|
}
|
|
P.charter {
|
|
FONT-STYLE: italic
|
|
}
|
|
P.caption {
|
|
FONT-WEIGHT: bold
|
|
}
|
|
|
|
P.code {
|
|
MARGIN-LEFT: 36pt; TEXT-INDENT: -18pt
|
|
}
|
|
|
|
P.ednote {
|
|
BACKGROUND-POSITION: 0% 50%; BACKGROUND-ATTACHMENT: scroll; BACKGROUND-REPEAT: repeat; FONT-STYLE: italic; BACKGROUND-COLOR: yellow
|
|
}
|
|
|
|
P.prev {
|
|
FONT-SIZE: smaller
|
|
}
|
|
|
|
P.change {
|
|
FONT-SIZE: smaller
|
|
}
|
|
|
|
SPAN.ednote {
|
|
BACKGROUND-POSITION: 0% 50%; BACKGROUND-ATTACHMENT: scroll; BACKGROUND-REPEAT: repeat; FONT-STYLE: italic; BACKGROUND-COLOR: yellow
|
|
}
|
|
P.illustration {
|
|
TEXT-ALIGN: center
|
|
}
|
|
|
|
caption {
|
|
FONT-WEIGHT: bold
|
|
}
|
|
|
|
.strike {
|
|
text-decoration: line-through;
|
|
color: silver;
|
|
}
|
|
</style><link type="text/css" rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/W3C-WD"></head><body>
|
|
<div class="head">
|
|
<p>
|
|
<a href="http://www.w3.org/" title="Go to W3C Home Page">
|
|
<img width="72" height="48" alt="W3C"
|
|
src="http://www.w3.org/Icons/w3c_home">
|
|
</a>
|
|
</p>
|
|
|
|
<h1>XML Protocol Abstract Model</h1>
|
|
<h2>W3C Working Draft 20 February 2003</h2>
|
|
<dl>
|
|
<dt>This version:</dt>
|
|
<dd><a href="http://www.w3.org/TR/2003/WD-xmlp-am-20030220/">http://www.w3.org/TR/2003/WD-xmlp-am-20030220/</a></dd>
|
|
<dt>Latest version:
|
|
<dd><a href="http://www.w3.org/TR/xmlp-am/">http://www.w3.org/TR/xmlp-am/</a></dd>
|
|
<dt>Previous version:</dt>
|
|
<dd><a href="http://www.w3.org/TR/2001/WD-xmlp-am-20010709/">http://www.w3.org/TR/2001/WD-xmlp-am-20010709/</a></dd>
|
|
<dt>Editors:</dt>
|
|
<dd>Stuart Williams, Hewlett-Packard Company <a href="mailto:skw@hplb.hpl.hp.com"><skw@hplb.hpl.hp.com></a></dd>
|
|
<dd>Mark Jones, AT&T Labs <a href="mailto:jones@research.att.com"><jones@research.att.com></a></dd>
|
|
<dt>Contributors:</dt>
|
|
<dd>Mark Baker, formerly of Sun Microsystems Inc. <a href="mailto:mark.baker@canada.sun.com"><mark.baker@canada.sun.com></a></dd>
|
|
<dd>Martin Gudgin, formerly of DevelopMentor <a href="mailto:marting@develop.com"><marting@develop.com></a></dd>
|
|
<dd>Oisin Hurley, Iona <a href="mailto:ohurley@iona.com"><ohurley@iona.com></a></dd>
|
|
<dd>Marc Hadley, Sun Microsystems Inc. <a href="mailto:marc.hadley@uk.sun.com"><marc.hadley@uk.sun.com></a></dd>
|
|
<dd>John Ibbotson, IBM Corporation <a href="mailto:john_ibbotson@uk.ibm.com"><john_ibbotson@uk.ibm.com></a></dd>
|
|
<dd>Scott Isaacson, Novell Inc. <a href="mailto:SISAACSON@novell.com"><SISAACSON@novell.com></a></dd>
|
|
<dd>Yves Lafon, W3C <a href="mailto:ylafon@w3.org"><ylafon@w3.org></a></dd>
|
|
<dd>Jean-Jacques Moreau, Canon <a href="mailto:moreau@crf.canon.fr"><moreau@crf.canon.fr></a></dd>
|
|
<dd>Henrik Frystk Nielsen, Microsoft Corporation <a href="mailto:frystyk@microsoft.com"><frystyk@microsoft.com></a></dd>
|
|
<dd>Krinshna Sankar, Cisco Systems <a href="mailto:ksankar@cisco.com"><ksankar@cisco.com></a></dd>
|
|
<dd>Nick Smilonich, Unisys <a href="mailto:nick.smilonich@unisys.com"><nick.smilonich@unisys.com></a></dd>
|
|
<dd>Lynne Thompson, Unisys <a href="mailto:Lynne.Thompson@unisys.com"><Lynne.Thompson@unisys.com></a></dd>
|
|
</dl>
|
|
<p class="copyright"><a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
|
|
© 2003 <a href="http://www.w3.org/"><acronym
|
|
title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup>
|
|
(<a href="http://www.lcs.mit.edu/"><acronym
|
|
title="Massachusetts Institute of Technology">MIT</acronym></a>, <a
|
|
href="http://www.ercim.org/"><acronym
|
|
title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>,
|
|
<a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
|
|
<a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>,<a
|
|
href="http://www.w3.org/Consortium/Legal/copyright-documents">document
|
|
use</a> and <a
|
|
href="http://www.w3.org/Consortium/Legal/copyright-software">software
|
|
licensing</a> rules apply.</p></div><hr><div>
|
|
<h2><a name="abstract">Abstract</a></h2>
|
|
<p>This document describes an Abstract Model of XML Protocol.</p>
|
|
<p>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.</p>
|
|
</div><div>
|
|
<h2><a name="status">Status of this Document</a></h2>
|
|
<p>
|
|
This section describes the status of this document at the time of its
|
|
publication. Other documents may supersede this document. The latest status
|
|
of this document series is maintained at the W3C.</p>
|
|
<p>
|
|
This W3C Working Draft (WD) of the XML Protocol Abstract Model has been
|
|
produced by the XML Protocol Working Group (WG), which is part of the
|
|
<a href="http://www.w3.org/2002/ws/Activity">Web Services Activity</a>.</p>
|
|
<p>
|
|
<b>The WG has decided to discontinue work on the Abstract Model, and on
|
|
this document. The WG developed the Abstract Model to provide a framework
|
|
for evaluating candidate protocols and for reasoning about the development
|
|
of the protocol itself. The WG believes the Abstract Model has well served
|
|
its purpose in this regard, and it no longer intends to do any further work
|
|
on the model.</b></p>
|
|
<p>
|
|
This document represents the contents of the first Abstract Model WD
|
|
(http://www.w3.org/TR/2001/WD-xmlp-am-20010709/) plus some small changes.
|
|
This document contains various open questions, however the WG does not
|
|
intend to answer them directly although answers may be found in other
|
|
documents produced by the WG.</p>
|
|
<p>
|
|
This document uses the term "XML Protocol", or the short form "XMLP", to
|
|
refer to the protocol being modelled.</p>
|
|
|
|
<p>Patent disclosures relevant to this specification may be found on the
|
|
Working Group's <a rel="disclosures" href="http://www.w3.org/2000/xp/Group/2/10/16-IPR-statements.html">patent disclosure page</a>.</p>
|
|
|
|
<p>The WG has decided to discontinue work on this document and feedback can be
|
|
sent to <a href="mailto:xmlp-comments@w3.org">xmlp-comment@w3.org</a> (<a href="http://lists.w3.org/Archives/Public/xmlp-comments/">archived</a> public list); however, the WG does not intend to respond to such feedback.</p>
|
|
|
|
<p>
|
|
This is a draft document and may be updated, replaced, or obsoleted by
|
|
other documents at any time. It is inappropriate to use W3C Working Drafts
|
|
as reference material or to cite them as other than "work in progress". A
|
|
list of all W3C technical reports can be found at <a href="http://www.w3.org/TR/">http://www.w3.org/TR/</a>.</p>
|
|
|
|
</div>
|
|
<div class="toc">
|
|
<h2><a name="contents">Table of Contents</a></h2>
|
|
<p class="toc">1 <a href="#Sec1">Introduction</a><br>
|
|
1.1 <a href="#Sec1.1">Definition of Terms</a><br>
|
|
2 <a href="#Sec2">XML Protocol Abstract Model Overview</a><br>
|
|
3 <a href="#Sec3">XML Protocol Layer Service Definition</a><br>
|
|
3.1 <a href="#Sec3.1">XMLP_UnitData Operation</a><br>
|
|
3.1.1 <a href="#Sec3.1.1">Correlation at Sending and Receiving XML Protocol Applications</a><br>
|
|
3.1.2 <a href="#Sec3.1.2">XMLP_UnitData Operation through Intermediaries</a><br>
|
|
3.1.3 <a href="#Sec3.1.3">Message Correlation at Intermediary XML Protocol Applications</a><br>
|
|
3.2 <a href="#Sec3.2">Operation Parameters</a><br>
|
|
4 <a href="#Sec4">XML Protocol Applications and Modules</a><br>
|
|
4.1 <a href="#Sec4.1">XML Protocol Message Routing and Targeting (aka Naming and Addressing :-))</a><br>
|
|
4.2 <a href="#Sec4.2">XML Protocol Modules and Message Processing</a><br>5 <a href="#Sec5"> Underlying Protocol Bindings</a><br>
|
|
5.1 <a href="#Sec5.1">Binding Service Model</a><br>
|
|
5.1.1 <a href="#Sec5.1.1">Introduction</a><br>
|
|
5.1.2 <a href="#Sec5.1.2"> Service Primitives</a><br>
|
|
5.1.2.1 <a href="#Sec5.1.2.1">Message Exchange</a><br>
|
|
5.1.2.2 <a href="#Sec5.1.2.2">Message Correlation</a><br>
|
|
5.1.2.3 <a href="#Sec5.1.2.3">Errors</a><br>
|
|
5.1.3 <a href="#Sec5.1.3">Message Exchange Patterns</a><br>
|
|
5.1.3.1 <a href="#Sec5.1.3.1">One Way Message</a><br>
|
|
5.1.3.2 <a href="#Sec5.1.3.2">Request Response</a><br>
|
|
5.1.3.3 <a href="#Sec5.1.3.3">Request and n Responses</a><br>
|
|
5.1.4 <a href="#sec5.1.4">Sample Mappings</a><br>
|
|
5.1.4.1 <a href="#Sec5.1.4.1">HTTP</a><br>
|
|
5.1.4.2 <a href="#Sec5.1.4.2">SMTP</a><br>
|
|
5.1.5 <a href="#Sec5.1.5">Binding Considerations</a><br>
|
|
5.2 <a href="#Sec5.2">BindingContext</a><br>
|
|
5.3 <a href="#Sec5.3">Attachment of Arbitrary Content</a><br>
|
|
6 <a href="#Sec6">References</a><br>
|
|
7 <a href="#Acknowledgements">Acknowledgements</a><br>
|
|
</p></div>
|
|
<hr>
|
|
<div class="body">
|
|
<div class="div1">
|
|
|
|
<h2><a name="Sec1"></a>1 Introduction</h2>
|
|
<p>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.</p>
|
|
<p>This document is intended to serve as an overview and
|
|
introduction to the XML Protocol and its framework.</p>
|
|
<p>
|
|
<a href="#Sec2"><b>2 XML Protocol Abstract Model Overview</b></a> presents an overview of the abstract model</p>
|
|
<p>
|
|
<a href="#Sec3"><b>3 XML Protocol Layer Service Definition</b></a> presents a model for the services provided by the XML
|
|
protocol layer to XML protocol applications.</p>
|
|
<p>
|
|
<a href="#Sec4"><b>4 XML Protocol Applications and Modules</b></a> presents a model for the extensible processing of XML
|
|
protocol messages. </p>
|
|
<p>
|
|
<a href="#Sec5"><b>5 Underlying Protocol Bindings</b></a> presents a model for the binding of XML protocol to
|
|
underlying protocol layers.</p>
|
|
<div class="div2">
|
|
|
|
<h3><a name="Sec1.1"></a>1.1 Definition of Terms</h3>
|
|
<p>This document makes use of terms defined in the <a href="#XMLPReqs">[XMLPReqs]</a>. 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.</p>
|
|
<table cellpadding="2" cellspacing="0" width="100%" border="1"
|
|
summary="definitions of three terms not introduced in requirements document">
|
|
<colgroup span="2" valign="top"><col width="15%"><col width="85%"></colgroup>
|
|
<tr>
|
|
<td id="XMLPApp"><b>XMLP Application</b></td>
|
|
<td>
|
|
<p>A client or user of the services
|
|
provided by the <a href="#XMLPLayer">XML Protocol Layer</a>. 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.</p>
|
|
<p>
|
|
<a href="http://www.w3.org/TR/2001/WD-xmlp-reqs-20010319/#g410">XML
|
|
Protocol Handlers</a> are encapsulated within XML Protocol
|
|
Applications.</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td id="XMLPLayer"><b>XMLP Layer</b></td>
|
|
<td>
|
|
<p>The XML Protocol Layer is an
|
|
abstraction that provides services or operations that transfers
|
|
packages of <a href="http://www.w3.org/TR/2001/WD-xmlp-reqs-20010319/#g400">XML
|
|
Protocol Blocks</a> between peer <a href="#XMLPApp">XML Protocol
|
|
Applications</a> via zero or more <a href="http://www.w3.org/TR/2001/WD-xmlp-reqs-20010319/#g140">XML
|
|
Protocol Intermediaries</a>.</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td id="XMLPOperation"><b>XMLP Operation</b></td>
|
|
<td>
|
|
<p>A primitive capability or service
|
|
offered by the <a href="#XMLPLayer">XML Protocol Layer.</a> The XML
|
|
Protocol Layer supports 3 operations described in detail in <a href="#Sec3"><b>3 XML Protocol Layer Service Definition</b></a>. XMLP Operations are modelled as
|
|
sequences of events crossing the layer boundary between <a href="http://www.w3.org/TR/2001/WD-xmlp-reqs-20010319/#g300">XML
|
|
Protocol Processors</a> and <a href="#XMLPApp">XML Protocol
|
|
Applications</a>.</p>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
</div>
|
|
</div>
|
|
<div class="div1">
|
|
|
|
<h2><a name="Sec2"></a>2 XML Protocol Abstract Model Overview</h2>
|
|
<p>
|
|
<a href="#Fig2.1">Figure 2.1</a> below presents a simple case of
|
|
the XML Protocol abstract model. Hosts I and V each contain
|
|
XML protocol application components, which <em>use</em> the services
|
|
of the XML protocol layer, and XML protocol layer components
|
|
which <em>provide</em> the services of the XML protocol layer. The
|
|
services of the XML protocol layer are abstracted at the upper
|
|
layer boundary as a single operation, XMLP_UNITDATA which is
|
|
described in detail in <a href="#Sec3"><b>3 XML Protocol Layer Service Definition</b></a>.</p>
|
|
<img src="Figure2-1.png" alt="Figure 2.1 Model of Simple Case without Intermediaries." id="Fig2.1">
|
|
<p class="caption">Figure 2.1 Model of Simple Case without Intermediaries.</p>
|
|
<p>
|
|
<a href="#Fig2.2">Figure 2.2</a> below shows 5 hosts in a more
|
|
complex case of the XML Protocol abstract model. Hosts I, III
|
|
and V each contain XML protocol application components. Hosts
|
|
II and IV are intermediaries that operate within underlying
|
|
protocol layers such as HTTP proxies and SMTP message routers.</p>
|
|
<img src="Figure2-2.png" alt="Figure 2.2 XML Protocol Model Overview" id="Fig2.2">
|
|
<p class="caption">Figure 2.2 XML Protocol Model Overview</p>
|
|
<p>
|
|
<a href="#Fig2.2">Figure 2.2</a> 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 <a href="#Fig2.2">
|
|
figure 2.2</a>. 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.</p>
|
|
<p>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 intended for "XML protocol handler (e) " within the
|
|
application on Host V. Block 2 is intended for 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 intended for handlers (f) and (g).</p>
|
|
</div>
|
|
<div class="div1">
|
|
|
|
<h2><a name="Sec3"></a>3 XML Protocol Layer Service Definition</h2>
|
|
<p>This section focuses on the definition of an
|
|
abstract interface between the XML protocol applications and the
|
|
XML protocol layer. It needs to be remembered that the layer
|
|
interface described in this section is abstract - its purpose is to
|
|
enable description, not to constrain implementation.</p>
|
|
<p>The services provided by the XML protocol layer are
|
|
modeled a single operation. XMLP_UNITDATA provides services to
|
|
sending, intermediary and receiving XML protocol applications.</p>
|
|
<div class="div2">
|
|
|
|
<h3><a name="Sec3.1"></a>3.1 XMLP_UnitData Operation</h3>
|
|
<p>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.</p>
|
|
<p>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:</p>
|
|
<p class="code">
|
|
<code>XMLP_UnitData.send( To, [ImmediateDestination], Message, [Correlation], [BindingContext]);</code>
|
|
</p>
|
|
<p class="code">
|
|
<code>XMLP_UnitData.receive( [To], [From], Message, [Correlation], [BindingContext]);</code>
|
|
</p>
|
|
<p class="code">
|
|
<code>XMLP_UnitData.status( [From], Status, [BindingContext]);</code>
|
|
</p>
|
|
<p class="code">
|
|
<code>XMLP_UnitData.forward( [ImmediateDestination], Message, [BindingContext]);</code>
|
|
</p>
|
|
<p class="code">
|
|
<code>All parameters are detailed in </code>
|
|
<a href="#Sec3.2"><b>3.2 Operation Parameters</b></a>.</p>
|
|
<p>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.</p>
|
|
<p>
|
|
<a href="#Fig3.1">Figure 3.1</a> below illustrates the normal
|
|
use of these primitive at the sending and receiving XML protocol
|
|
applications.</p>
|
|
<img src="Figure3-1.png" alt="Figure 3.1 XMLP_UNITDATA Operation" id="Fig3.1">
|
|
<p class="caption">Figure 3.1 XMLP_UNITDATA Operation</p>
|
|
<p>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.</p>
|
|
<p>
|
|
<a title="XMLP_UnitData.send" name="XMLP_UnitData.send"></a>
|
|
<b>XMLP_UnitData.send</b> is invoked by the sending XML protocol
|
|
application and directed at the local sending XML protocol
|
|
processor to start a one-way transfer operation.
|
|
</p>
|
|
<p>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).</p>
|
|
<p> This primitive differs from the .<a href="#XMLP_UnitData.forward">forward</a>
|
|
primitive in that it is used by the initial sender of an XML protocol message to send a new
|
|
message.</p>
|
|
<p>
|
|
<a title="XMLP_UnitData.receive" name="XMLP_UnitData.receive"></a>
|
|
<b>XMLP_UnitData.receive</b> is invoked by the receiving XML
|
|
protocol processor and directed at a local receiving
|
|
XML protocol application to deliver a received XML protocol
|
|
message.
|
|
</p>
|
|
<p> 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).</p>
|
|
<p>
|
|
<a title="XMLP_UnitData.status" name="XMLP_UnitData.status"></a>
|
|
<b>XMLP_UnitData.status</b> 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.</p>
|
|
<p>
|
|
<a title="XMLP_UnitData.forward" name="XMLP_UnitData.forward"></a>
|
|
<b>XMLP_UnitData.forward</b> 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.
|
|
</p>
|
|
<p> 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.</p>
|
|
<p> 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.</p>
|
|
<p>This primitive differs from the <a href="#XMLP_UnitData.send">
|
|
.send</a> 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.</p>
|
|
<p>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. </p>
|
|
<div class="div3">
|
|
|
|
<h4><a name="Sec3.1.1"></a>3.1.1 Correlation at Sending and Receiving XML Protocol Applications</h4>
|
|
<p>The <a href="#Correlation">Correlation</a> 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. The mechanism by which correlation is determined
|
|
is <em>not</em> specified in this abstract model.</p>
|
|
<p>Message correlation may be determined through:</p>
|
|
<ul>
|
|
<li>
|
|
<p>the exploitation of features in the underlying protocol eg. the
|
|
request/response nature of HTTP;</p>
|
|
</li>
|
|
<li>
|
|
<p>mechanism introduced either by the XMLP processor to operate
|
|
across multiple possible underlying protocols.</p>
|
|
</li>
|
|
<li>
|
|
<p>mechanism introduced by a binding to a particular underlying
|
|
protocol within the domain of the underlying protocols own header
|
|
extension mechanism.</p>
|
|
</li>
|
|
</ul>
|
|
<p>When included in an <a href="#XMLP_UnitData.send">
|
|
XMLP_UnitData.send</a> primitive <a href="#Correlation.MessageRef">
|
|
Correlation.MessageRe</a>f 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 <a href="#Correlation.MessageRef">Correlation.MessageRef</a>.</p>
|
|
<p>Likewise, when included in an <a href="#XMLP_UnitData.receive">
|
|
XMLP_UnitData.receive</a> primitive <a href="#Correlation.MessageRef">Correlation.MessageRef</a> 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 <a href="#Correlation.MessageRef">Correlation.MessageRef</a>.</p>
|
|
<p>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 <a href="#Correlation">
|
|
Correlation</a> parameter.</p>
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="Sec3.1.2"></a>3.1.2 XMLP_UnitData Operation through Intermediaries</h4>
|
|
<p>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. </p>
|
|
<p>
|
|
<a href="#Fig3.2">Figure 3.2</a> shows the normal behaviour of
|
|
an XML_UnitData operation through an intermediary in the absence of
|
|
fatal failures. The three vertical lines represent the local XML
|
|
protocol layer boundaries and the small arrows above denote the
|
|
up/down orientation of the boundary. <a href="#Fig3.3">Figure
|
|
3.3</a> below shows an alternate representation of the same
|
|
scenario.</p>
|
|
<p>The scenario depicted in figures <a href="#Fig3.2">3.2</a>and <a href="#Fig3.3">3.3</a>. show just a single intermediary interposed
|
|
in the operation however the principle extends to an arbitrary
|
|
number of intermediaries.</p>
|
|
<img src="Figure3-2.png" alt="Figure 3.2 Normal XMLP_UnitData operation through an Intermediary" id="Fig3.2">
|
|
<p class="caption">Figure 3.2 Normal XMLP_UnitData operation through an Intermediary</p>
|
|
<img src="Figure3-3.png" alt="Figure 3.3 Normal XMLP_UnitData operation through and Intermediary (alternate treatment)" id="Fig3.3">
|
|
<p class="caption">Figure 3.3 Normal XMLP_UnitData operation through and Intermediary (alternate treatment)</p>
|
|
<p>It is worth noting that the <a href="#XMLP_UnitData.status">
|
|
XMLP_UnitData.status</a> is generated from within the XML protocol
|
|
layer. It may indicate anything from the mere fact that the message
|
|
has been sent or forwarded 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 ultimate recipient 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.</p>
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="Sec3.1.3"></a>3.1.3 Message Correlation at Intermediary XML Protocol Applications</h4>
|
|
<p>The <a href="#Correlation.MessageRef">Correlation.MessageRef</a>
|
|
sub-field of the optional <a href="#Correlation">
|
|
Correlation</a> parameter on a <a href="#XMLP_UnitData.receive">
|
|
XMLP_UnitData.receive</a> primitive carries a local abstract
|
|
reference to an XML protocol message that was previously forwarded
|
|
by this intermediary XML protocol application. The current message
|
|
is a direct consequence of the processing of that earlier forwarded
|
|
message.</p>
|
|
<p>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.</p>
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="Sec3.2"></a>3.2 Operation Parameters</h3>
|
|
<p>This section describes the operation parameters used in the
|
|
operation primitives described above.</p>
|
|
<table cellpadding="2" cellspacing="0" width="100%" border="1"
|
|
summary="descriptions of eleven operations parameters">
|
|
<colgroup span="2" valign="top"><col width="15%"><col width="85%"></colgroup>
|
|
<tr>
|
|
<td id="To"><b>To</b></td>
|
|
<td>
|
|
<p>An abstract reference that denotes the XML protocol application
|
|
that a message was originally sent to by the initiating or sending
|
|
XML protocol application.</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td id="From"><b>From</b></td>
|
|
<td>
|
|
<p>An abstract reference denotes the sending XML protocol application in
|
|
<a href="#XMLP_UnitData.receive">.receive</a> primitives.</p>
|
|
<p> In <em>.receive</em> primitives this parameter makes the
|
|
identity of the sending/initiating XML protocol application
|
|
available to the receiving/responding XML protocol
|
|
application.</p>
|
|
<span class="ednote"><b>Editorial note </b>[Intermediaries may obscure this or we may require that they don't... discuss!]</span>
|
|
<p>In the <em>XMLP_UnitData.status</em> 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.</p>
|
|
<span class="ednote"><b>Editorial note </b>[Again possibly obscured by intermediaries...]</span>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td id="ImmediateDestination"><b>ImmediateDestination</b></td>
|
|
<td>
|
|
<p>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.</p>
|
|
<p>This parameter enables sending and intermediary XML
|
|
protocol applications to address the message to the next
|
|
intermediary on route.</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td id="Message"><b>Message</b></td>
|
|
<td>
|
|
<p>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. </p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td id="Message.Faults"><b>Message.Faults</b></td>
|
|
<td>
|
|
<p>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.</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td id="Message.Blocks"><b>Message.Blocks</b></td>
|
|
<td>
|
|
<p>An abstraction of the XML
|
|
protocol blocks within an XML protocol message which are
|
|
intended to be processed by intermediaries or the ultimate
|
|
recipient.</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td id="Message.Attachments"><b>Message.Attachments</b></td>
|
|
<td>
|
|
<p>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.</p>
|
|
<p>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.</p>
|
|
<span class="ednote"><b>Editorial note </b>[NB. This places an obligation on XML protocol
|
|
binding specifications to specify how attachments are to be
|
|
carried.]</span>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td id="Correlation"><b>Correlation</b></td>
|
|
<td>
|
|
<p>An optional parameter used to express
|
|
local relationships between XML protocol messages.</p>
|
|
<p>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.</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td id="Correlation.MessageRef"><b>Correlation.MessageRef
|
|
</b></td>
|
|
<td>
|
|
<p>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. </p>
|
|
<p>In <a href="#XMLP_UnitData.send">XMLP_UnitData.send</a>
|
|
primitives, the value of this parameter references an XML protocol
|
|
message previously received by the sending XML protocol
|
|
application.</p>
|
|
<p>In <a href="#XMLP_UnitData.receive">XMLP_UnitData.receive</a>
|
|
primitives, the value of this parameter references an XML protocol
|
|
message previously sent or forwarded by the receiving
|
|
application.</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td id="BindingContext"><b>BindingContext
|
|
</b></td>
|
|
<td>
|
|
<p>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.</p>
|
|
<p>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.</p>
|
|
<p>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.</p>
|
|
<p>BindingContext is discussed further in <a href="#Sec5.2"><b>5.2 BindingContext</b></a>.</p>
|
|
<span class="ednote"><b>Editorial note </b>[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.]</span>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td id="Status.Parameter"><b>Status</b></td>
|
|
<td>
|
|
<p>In <a href="#XMLP_UnitData.status">
|
|
.status</a> primitives this parameter indicates the disposition of
|
|
the request operation which may be: <em>MessageSent,
|
|
MessageDelivered, Unknown</em> and <em>
|
|
FailedAtIntermediary</em>. The interpretation of a status value may
|
|
be augmented by information carried in the <em>BindingContext</em>. </p>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
</div>
|
|
</div>
|
|
<div class="div1">
|
|
|
|
<h2><a name="Sec4"></a>4 XML Protocol Applications and Modules</h2>
|
|
<span class="ednote"><b>Editorial note </b>There is a significant debate over terms and
|
|
concepts around Modules, Handlers, Targeting and Message routing.
|
|
At the time of this draft the discussion is still open and this
|
|
section will be updated to reflect any consensus arising from that
|
|
discussion.</span>
|
|
<p>An XML protocol application is the logic at an XML processor
|
|
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 applying the processing rules associated
|
|
with XML protocol modules. The unit of exchange between XML
|
|
protocol handlers are XML protocol blocks.</p>
|
|
<p>XML protocol blocks are aggregated into XML protocol messages
|
|
and may be targeted at particular XML processors (see <a href="#Sec4.2"><b>4.2 XML Protocol Modules and Message Processing</b></a>). XML protocol blocks are delivered
|
|
together with the rest of the XML protocol message which
|
|
encapsulates them (and its attachments if any) to the
|
|
targeted XML processor. The XML protocol application is then
|
|
responsible for identifying and dispatching the appropriate XML
|
|
protocol handlers. Generally, the dispatch to a handler will
|
|
be determined by the presence of an associated block or blocks, but
|
|
not necessarily. Handler d in <a href="#Fig2.2">Figure
|
|
2.2</a> illustrates such a case.</p>
|
|
<img src="Figure4-1.png" alt="Figure 4.1 XML Protocol Application" id="Fig4.1">
|
|
<p class="caption">Figure 4.1 XML Protocol Application</p>
|
|
<p>Each handler may succeed 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 to resolve any conflicts.</p>
|
|
<div class="div2">
|
|
|
|
<h3><a name="Sec4.1"></a>4.1 XML Protocol Message Routing and Targeting (aka Naming and Addressing :-))</h3>
|
|
<span class="ednote"><b>Editorial note </b>Needs to use some terms here that arise from the
|
|
intermediaries thread Martin started</span>
|
|
<p>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 <a href="#Fig2.2">figure 2.2,</a> the diagram in <a href="#Fig4.2">figure 4.2</a> depicts the message path of the
|
|
corresponding XML protocol message under the XML_UnitData
|
|
operation.</p>
|
|
<img src="Figure4-2.png" alt="Figure 4.2 XML Protocol Message Path" id="Fig4.2">
|
|
<p class="caption">Figure 4.2 XML Protocol Message Path</p>
|
|
<p>The path in <a href="#Fig4.2">figure 4.2</a> 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.</p>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="Sec4.2"></a>4.2 XML Protocol Modules and Message Processing</h3>
|
|
<p>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.</p>
|
|
<p>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.</p>
|
|
<p>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.</p>
|
|
<ol>
|
|
<li>
|
|
<p>An XML Protocol message consists of
|
|
a set of zero or more blocks.</p>
|
|
<span class="ednote"><b>Editorial note </b>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.</span>
|
|
</li>
|
|
<li>
|
|
<p>Each block has the following
|
|
sub-fields: <em>Block.Id</em>, <em>Block.Actor</em>, and <em>
|
|
Block.MustUnderstand</em>. 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.</p>
|
|
<span class="ednote"><b>Editorial note </b>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.</span>
|
|
</li>
|
|
<li>
|
|
<p>The fully qualified name of the top
|
|
element of a block identifies the block.</p>
|
|
<span class="ednote"><b>Editorial note </b>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.</span>
|
|
</li>
|
|
<li>
|
|
<p>The following values for Block.Actor
|
|
have special significance: <code>Next</code>, <code>Final</code>, and <code>
|
|
None</code>.; Next matches the next processor. Final
|
|
matches the final processor. None is for untargeted blocks
|
|
which may be referenced by other blocks.</p>
|
|
|
|
<p>An empty actor defaults to Final. An untargeted block
|
|
marked with <code>None</code> 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.</p>
|
|
<span class="ednote"><b>Editorial note </b>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 <code>Final </code> designates. The intended (final) processor must
|
|
recognize itself as such. <code>Next </code> has the same interpretation as
|
|
the SOAP URI, <code>http://schemas.xmlsoap.org/soap/actor/next</code> 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.</span>
|
|
</li>
|
|
<li>
|
|
<p>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.</p>
|
|
<span class="ednote"><b>Editorial note </b>SOAP: SOAP
|
|
doesn't allow body entries to be processed at intermediaries and
|
|
hence they are never removed at an intermediary.</span>
|
|
</li>
|
|
<li>
|
|
<p>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 "<code>id</code>" and "<code>href</code>" 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.</p>
|
|
<span class="ednote"><b>Editorial note </b>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.</span>
|
|
</li>
|
|
<li>
|
|
<p>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.</p>
|
|
<span class="ednote"><b>Editorial note </b>SOAP: Similar.
|
|
</span>
|
|
</li>
|
|
</ol>
|
|
</div>
|
|
</div>
|
|
<div class="div1">
|
|
|
|
<h2><a name="Sec5"></a>5 Underlying Protocol Bindings</h2>
|
|
<p>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.</p>
|
|
<div class="div2">
|
|
|
|
<h3><a name="Sec5.1"></a>5.1 Binding Service Model</h3>
|
|
<span class="ednote"><b>Editorial note </b>This entire subsection is new and has not be
|
|
subject of significant debate. It should be regarded as a work in
|
|
progress</span>
|
|
<div class="div3">
|
|
|
|
<h4><a name="Sec5.1.1"></a>5.1.1 Introduction</h4>
|
|
<p>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 choreographed 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.</p>
|
|
<p>The diagram below shows a logical layered view of the binding
|
|
model with the XML protocol processor being bound to four
|
|
underlying transports.</p>
|
|
<img src="Figure5-1.png" alt="Figure 5.1 Binding Model" id="Fig5.1">
|
|
<p class="caption">Figure 5.1 Binding Model</p>
|
|
<p>This document concerns itself with the interactions at the solid
|
|
black line between the XML protocol processor and a given
|
|
binding.</p>
|
|
<p>Note that, as shown, some bindings may be nested. e.g. a MIME
|
|
binding might be nested within a HTTP binding to allow additional
|
|
binary data to be sent along with (but outside) the XMLP
|
|
envelope.</p>
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="Sec5.1.2"></a>5.1.2 Service Primitives</h4>
|
|
<div class="div4">
|
|
|
|
<h5><a name="Sec5.1.2.1"></a>5.1.2.1 Message Exchange</h5>
|
|
<p>There are two primitives associated with message exchange: <code>MSG.req</code> and <code>
|
|
MSG.ind</code>. A <code>MSG.req</code> primitive
|
|
is sent from the XML protocol processor to the binding in order to
|
|
cause the binding to send a message. A <code>
|
|
MSG.ind</code> primitive is sent from the binding to the XML
|
|
protocol processor to indicate arrival of a message.</p>
|
|
</div>
|
|
<div class="div4">
|
|
|
|
<h5><a name="Sec5.1.2.2"></a>5.1.2.2 Message Correlation</h5>
|
|
<p>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.</p>
|
|
<p>There are four pairs of primitives associated with operation
|
|
delineation and hence message correlation:</p>
|
|
<ol>
|
|
<li>
|
|
<p>
|
|
<code>OP.start-req</code> and <code>OP.start-conf</code>
|
|
A <code>OP.start-req</code> 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 <code>OP.start-conf</code>
|
|
primitive.</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<code>OP.start-ind</code> and <code>OP.start-resp</code>
|
|
A <code>OP.start-ind</code> 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 <code>
|
|
OP.start-resp</code> primitive.</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<code>OP.end-req</code> and <code>OP.end-conf</code>
|
|
An <code>OP.end-req</code> primitive is sent
|
|
from the XML protocol processor to the binding to terminate a
|
|
correlated message exchange. The binding responds with an <code>OP.end-conf</code>primitive. Whilst the <code>OP.end-conf</code> is outstanding, the XML
|
|
protocol processor must be prepared to continue to receive <code>MSG.ind</code>s</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<code>OP.end-ind</code> and <code>OP.end-resp</code>
|
|
An <code>OP.end-ind</code> primitive is sent
|
|
from the binding to the XML protocol processor to indicate that a
|
|
correlated message exchange is to be terminated. No further <code>MSG.ind</code> will be delivered as part of the
|
|
corresponding operation, however the XML protocol processor
|
|
receiving the <code>OP.end-ind</code> primitive
|
|
may continue to issue <code>MSG.req</code>
|
|
primitives to complete operation in progress. Once all <code>MSG.req</code> primitives associate with the
|
|
operation have been issued the XML protocol processor concludes the
|
|
operation by with the invocation of an <code>
|
|
OP.end-resp</code> primitive."</p>
|
|
</li>
|
|
</ol>
|
|
<p>The actual correlation mechanism is underlying protocol and
|
|
implementation specific. e.g. A <code>
|
|
OP.start-conf</code> may carry some unique identifier that must be
|
|
provided with any subsequent <code>
|
|
MSG.req</code>(s) and is included with any subsequent <code>MSG.ind</code>(s).</p>
|
|
<p>There is no retained state within the binding between operations
|
|
although there may be during operations.</p>
|
|
</div>
|
|
<div class="div4">
|
|
|
|
<h5><a name="Sec5.1.2.3"></a>5.1.2.3 Errors</h5>
|
|
<p>The final primitive <code>ERR.ind</code> is
|
|
sent from the binding to the XML protocol processor when an error
|
|
occurs, e.g. if a <code>MSG.req</code> cannot be
|
|
honoured then an <code>ERR.ind</code> is
|
|
generated. Errors are correlated to a particular message exchange
|
|
using the mechanism described above.</p>
|
|
</div>
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="Sec5.1.3"></a>5.1.3 Message Exchange Patterns</h4>
|
|
<p>The following sections illustrate the choreography of XML
|
|
protocol binding primitives for a number of different message
|
|
exchange patterns. These are intended to be illustrative rather
|
|
than proscriptive. In particular, in many cases either sender or
|
|
receiver might initiate the OP.end-req.</p>
|
|
<div class="div4">
|
|
|
|
<h5><a name="Sec5.1.3.1"></a>5.1.3.1 One Way Message</h5>
|
|
<p class="particpant">Sender</p>
|
|
<p>
|
|
<code>OP.start-req</code>, <code>OP.start-conf</code>, <code>
|
|
MSG.req</code>, <code>OP.end-req</code>, <code>OP.end-conf</code>.</p>
|
|
<p class="participant">Receiver</p>
|
|
<p>
|
|
<code>OP.start-ind</code>, <code>OP.start-resp</code>, <code>
|
|
MSG.ind</code>, <code>OP.end-ind</code>, <code>OP.end-resp</code>.</p>
|
|
<p class="participant">Comments</p>
|
|
<p>Note that depending on the underlying protocol the primitives at
|
|
sender and receiver may not operate in lock-step. In particular,
|
|
the <code>OP.start-ind</code> may not be
|
|
delivered to the receiving XML protocol processor until the sending
|
|
XML protocol processor has issued the <code>
|
|
MSG.req</code> or even the <code>
|
|
OP.end-req</code>. 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.</p>
|
|
</div>
|
|
<div class="div4">
|
|
|
|
<h5><a name="Sec5.1.3.2"></a>5.1.3.2 Request Response</h5>
|
|
<p class="participant">Sender</p>
|
|
<p>
|
|
<code>OP.start-req</code>, <code>OP.start-conf</code>, <code>
|
|
MSG.req</code>, <code>MSG.ind</code>, <code>OP.end-req</code>, <code>
|
|
OP.end-conf</code>.</p>
|
|
<p class="participant">Receiver</p>
|
|
<p>
|
|
<code>OP.start-ind</code>, <code>OP.start-resp</code>, <code>
|
|
MSG.ind</code>, <code>MSG.req</code>, <code>OP.end-ind</code>, <code>
|
|
OP.end-resp</code>.</p>
|
|
</div>
|
|
<div class="div4">
|
|
|
|
<h5><a name="Sec5.1.3.3"></a>5.1.3.3 Request and <em>n</em> Responses</h5>
|
|
<p class="participant">Sender</p>
|
|
<p>
|
|
<code>OP.start-req</code>, <code>OP.start-conf</code>, <code>
|
|
MSG.req</code>, <code>MSG.ind</code>, <code>MSG.ind</code>, ..., <code>
|
|
OP.end-ind</code>, <code>OP.end-resp</code>.</p>
|
|
<p class="participant">Receiver</p>
|
|
<p>
|
|
<code>OP.start-ind</code>, <code>OP.start-resp</code>, <code>
|
|
MSG.ind</code>, <code>MSG.req</code>, <code>MSG.req</code>, ..., <code>
|
|
OP.end-req, OP.end-conf</code>.</p>
|
|
</div>
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="sec5.1.4"></a>5.1.4 Sample Mappings</h4>
|
|
<div class="div4">
|
|
|
|
<h5><a name="Sec5.1.4.1"></a>5.1.4.1 HTTP</h5>
|
|
<p>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.</p>
|
|
<table border="1" summary="binding primitives mapped onto HTTP protocol actions">
|
|
<caption>
|
|
Initiator
|
|
</caption>
|
|
<thead>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
Binding Primitive
|
|
</td>
|
|
<td rowspan="1" colspan="1">
|
|
Binding Action
|
|
</td>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">OP.start-req</td>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">OP.start-conf</td>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">MSG.req</td>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
<td rowspan="1" colspan="1">Send POST request</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
<td rowspan="1" colspan="1">Receive POST results</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">MSG.ind</td>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">OP.end-req</td>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">OP.end-conf</td>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<table border="1" summary="binding primitives mapped onto HTTP protocol actions">
|
|
<caption>
|
|
Responder
|
|
</caption>
|
|
<thead>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
Binding Primitive
|
|
</td>
|
|
<td rowspan="1" colspan="1">
|
|
Binding Action
|
|
</td>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
<td rowspan="1" colspan="1">Receive POST request</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">OP.start-ind</td>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">OP.start-resp</td>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">MSG.ind</td>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">MSG.req</td>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
<td rowspan="1" colspan="1">Send POST results</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">OP.end-ind</td>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">OP.end-resp</td>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<p>The above assumes use of HTTP persistent connections.</p>
|
|
</div>
|
|
<div class="div4">
|
|
|
|
<h5><a name="Sec5.1.4.2"></a>5.1.4.2 SMTP</h5>
|
|
<p>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.</p>
|
|
<table border="1" summary="binding primitives mapped onto SMTP protocol actions">
|
|
<caption>
|
|
Initiator
|
|
</caption>
|
|
<thead>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
Binding Primitive
|
|
</td>
|
|
<td rowspan="1" colspan="1">
|
|
Binding Action
|
|
</td>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">OP.start-req</td>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
<td rowspan="1" colspan="1">Open SMTP session</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">OP.start-conf</td>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">MSG.req</td>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
<td rowspan="1" colspan="1">Send mail message</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">OP.end-req</td>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
<td rowspan="1" colspan="1">Close SMTP session</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">OP.end-conf</td>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<table border="1" summary="binding primitives mapped onto SMTP protocol actions">
|
|
<caption>
|
|
Responder
|
|
</caption>
|
|
<thead>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
Binding Primitive
|
|
</td>
|
|
<td rowspan="1" colspan="1">
|
|
Binding Action
|
|
</td>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
<td rowspan="1" colspan="1">Begin SMTP transaction</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
<td rowspan="1" colspan="1">Receive mail message</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
<td rowspan="1" colspan="1">End SMTP transaction</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">OP.start-ind</td>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">OP.start-resp</td>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">MSG.ind</td>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">OP.end-ind</td>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">OP.end-resp</td>
|
|
<td rowspan="1" colspan="1"> </td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="Sec5.1.5"></a>5.1.5 Binding Considerations</h4>
|
|
<p>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:</p>
|
|
<table cellpadding="2" cellspacing="0" width="100%" border="1"
|
|
summary="binding considerations">
|
|
<colgroup span="2" valign="top"><col width="15%"><col width="85%"></colgroup>
|
|
<tr>
|
|
<td><b>Protocol</b></td>
|
|
<td>
|
|
<p>The binding should identify the exact protocol to which XML
|
|
protocol is being bound including a version. Examples might be
|
|
HTTP/1.1 or SMTP[RFC821]</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td><b>Addressing</b></td>
|
|
<td>
|
|
<p>The binding needs to show how to specify an XML protocol
|
|
processor's address with an URL.</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td><b>Message Passing</b></td>
|
|
<td>
|
|
<p>The binding needs to specify unambiguously how to use the
|
|
underlying protocol to pass a whole XML Protocol message to a node
|
|
specified by a given address. Depending on the underlying protocol
|
|
capabilities, the specification may need to detail the
|
|
following:</p>
|
|
<ol>
|
|
<li>
|
|
<p>Use of underlying protocol primitives for sending and receiving
|
|
messages.</p>
|
|
</li>
|
|
<li>
|
|
<p>Use of underlying protocol headings.</p>
|
|
</li>
|
|
<li>
|
|
<p>Underlying protocol connection management including roles of
|
|
initiator and responder, how to handle abnormal terminations, can
|
|
responder terminate connection, etc.</p>
|
|
</li>
|
|
</ol>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td><b>Message Exchange Pattern(s)</b></td>
|
|
<td>
|
|
<p>The binding needs to specify how underlying protocol sessions
|
|
are used in common message exchange patterns including one-way and
|
|
request-response.</p>
|
|
<span class="ednote"><b>Editorial note </b>[Question: what other
|
|
message exchange patterns should we specify here ?]</span>
|
|
<p>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.</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td><b>Message Ordering Characteristics</b></td>
|
|
<td>
|
|
<p>The binding needs to specify what message ordering
|
|
characteristics the underlying protocol supports. e.g. If two
|
|
messages are sent in the same direction in the same session is
|
|
their order of arrival guaranteed to be the same as the order in
|
|
which they were sent.</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td><b>Error Handling</b></td>
|
|
<td>
|
|
<p>The binding needs to specify how errors in the underlying
|
|
protocol will be handled. A non-exhaustive list of things to
|
|
consider here is: connection errors, addressing errors, message
|
|
transmission errors, abnormal termination.</p>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
<span class="ednote"><b>Editorial note </b>[Question: what other types of error do we
|
|
need to consider ?]</span>
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="Sec5.2"></a>5.2 BindingContext</h3>
|
|
<p>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.</p>
|
|
<p>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.</p>
|
|
<p>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.</p>
|
|
<p>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).</p>
|
|
<p>One would therefore expect the structure under BindingContext to
|
|
grow along the lines of:</p>
|
|
<p class="code">
|
|
<code>BindingContext.Shared //A substructure for information shared by several bindings</code>
|
|
</p>
|
|
<p class="code">
|
|
<code>BindingContext.HTTP //A substructure for information related to HTTP</code>
|
|
</p>
|
|
<p class="code">
|
|
<code>BindingContext.SMTP //....</code>
|
|
</p>
|
|
<p class="code">
|
|
<code> </code>
|
|
</p>
|
|
<p class="code">
|
|
<code>....and so on.</code>
|
|
</p>
|
|
<p>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.</p>
|
|
<span class="ednote"><b>Editorial note </b>Hopefully this captures the general idea behind
|
|
BindingContext... the details will evolve over time... indeed they
|
|
will evolve as bindings get described.</span>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="Sec5.3"></a>5.3 Attachment of Arbitrary Content</h3>
|
|
<span class="ednote"><b>Editorial note </b>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.</span>
|
|
<p>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.</p>
|
|
<p>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).</p>
|
|
<p>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.</p>
|
|
</div>
|
|
</div>
|
|
<div class="div1">
|
|
|
|
<h2><a name="Sec6"></a>6 References</h2>
|
|
<dl>
|
|
<dt class="label"><a name="XMLPReqs"></a>XMLPReqs</dt><dd>"XMLProtocol (XMLP) Requirements" (See <a href="http://www.w3.org/TR/2001/WD-xmlp-reqs-20010319/#N2082">http://www.w3.org/TR/2001/WD-xmlp-reqs-20010319/#N2082</a>.)</dd>
|
|
<dt class="label"><a name="SOAP11"></a>SOAP11</dt><dd>SOAP 1.1 Specification (See <a href="http://www.w3.org/TR/SOAP/">http://www.w3.org/TR/SOAP/</a>.)</dd>
|
|
<dt class="label"><a name="Issues"></a>Issues</dt><dd>XML Protocol WG Issues List (See <a href="http://www.w3.org/2000/xp/Group/xmlp-issues.html">http://www.w3.org/2000/xp/Group/xmlp-issues.html</a>.)</dd>
|
|
</dl>
|
|
</div>
|
|
<div class="div1">
|
|
|
|
<h2><a name="Acknowledgements"></a>7 Acknowledgements</h2>
|
|
<p>This document is the work of the W3C XML Protocol Working Group.</p>
|
|
<p>Members of the Working Group are (at the time of writing, around July 2001, and by
|
|
alphabetical order): Yasser al Safadi (Philips Research), Vidur
|
|
Apparao (Netscape), Don Box (DevelopMentor), David Burdett
|
|
(Commerce One), Charles Campbell (Informix Software), Alex Ceponkus
|
|
(Bowstreet), Michael Champion (Software AG), David Clay (Oracle),
|
|
Ugo Corda (Xerox), Paul Cotton (Microsoft Corporation), Ron Daniel
|
|
(Interwoven), Glen Daniels (Allaire), Doug Davis (IBM), Ray
|
|
Denenberg (Library of Congress), Paul Denning (MITRE Corporation),
|
|
Frank DeRose (TIBCO Software, Inc.), Brian Eisenberg (Data
|
|
Channel), David Ezell (Hewlett-Packard), James Falek (TIBCO
|
|
Software, Inc.), David Fallside (IBM), Chris Ferris (Sun
|
|
Microsystems), Daniela Florescu (Propel), Dan Frantz (BEA Systems),
|
|
Dietmar Gaertner (Software AG), Scott Golubock (Epicentric), Rich
|
|
Greenfield (Library of Congress), Martin Gudgin (Develop Mentor),
|
|
Hugo Haas (W3C), Marc Hadley (Sun Microsystems), Mark Hale
|
|
(Interwoven), Randy Hall (Intel), Gerd Hoelzing (SAP AG), Oisin
|
|
Hurley (IONA Technologies), Yin-Leng Husband (Compaq), John
|
|
Ibbotson (IBM), Ryuji Inoue (Matsushita Electric Industrial Co.,
|
|
Ltd.), Scott Isaacson (Novell, Inc.), Kazunori Iwasa (Fujitsu
|
|
Software Corporation), Murali Janakiraman (Rogue Wave), Mario
|
|
Jeckle (Daimler-Chrysler Research and Technology), Eric Jenkins
|
|
(Engenia Software), Mark Jones (AT&T), Jay Kasi (Commerce One),
|
|
Jeffrey Kay (Engenia Software), Richard Koo (Vitria Technology
|
|
Inc.), Jacek Kopecky (IDOOX s.r.o.), Alan Kropp (Epicentric), Yves
|
|
Lafon (W3C), Tony Lee (Vitria Technology Inc.), Michah Lerner
|
|
(AT&T), Richard Martin (Active Data Exchange), Noah Mendelsohn
|
|
(Lotus Development), Nilo Mitra (Ericsson Research Canada),
|
|
Jean-Jacques Moreau (Canon), Masahiko Narita (Fujitsu Software
|
|
Corporation), Mark Needleman (Data Research Associates), Eric
|
|
Newcomer (IONA Technologies), Henrik Frystyk Nielsen (Microsoft
|
|
Corporation), Mark Nottingham (Akamai Technologies), David Orchard
|
|
(JamCracker), Kevin Perkins (Compaq), Jags Ramnaryan (BEA Systems),
|
|
Andreas Riegg (Daimler-Chrysler Research and Technology),
|
|
Hervé Ruellan (Canon), Marwan Sabbouh (MITRE Corporation),
|
|
Shane Sesta (Active Data Exchange), Miroslav Simek (IDOOX s.r.o.),
|
|
Simeon Simeonov (Allaire), Nick Smilonich (Unisys), Soumitro Tagore
|
|
(Informix Software), James Tauber (Bowstreet), Lynne Thompson
|
|
(Unisys), Patrick Thompson (Rogue Wave), Randy Waldrop
|
|
(WebMethods), Ray Whitmer (Netscape), Volker Wiechers (SAP AG),
|
|
Stuart Williams (Hewlett-Packard), Amr Yassin (Philips Research)
|
|
and Dick Brooks (Group 8760).</p>
|
|
<p class="prev"> Previous Members were: Eric Fedok (Active Data Exchange) Susan
|
|
Yee (Active Data Exchange) Alex Milowski (Lexica), Bill Anderson
|
|
(Xerox), Ed Mooney (Sun Microsystems), Mary Holstege (Calico
|
|
Commerce), Rekha Nagarajan (Calico Commerce), John Evdemon (XML
|
|
Solutions), Kevin Mitchell (XML Solutions), Yan Xu (DataChannel)
|
|
Mike Dierken (DataChannel) Julian Kumar (Epicentric) Miles Chaston
|
|
(Epicentric) Bjoern Heckel (Epicentric) Dean Moses (Epicentric)
|
|
Michael Freeman (Engenia Software) Jim Hughes (Fujitsu Software
|
|
Corporation) Francisco Cubera (IBM), Murray Maloney (Commerce One),
|
|
Krishna Sankar (Cisco), Steve Hole (MessagingDirect Ltd.) John-Paul
|
|
Sicotte (MessagingDirect Ltd.) Vilhelm Rosenqvist (NCR) Lew Shannon
|
|
(NCR) Henry Lowe (OMG) Jim Trezzo (Oracle) Peter Lecuyer (Progress
|
|
Software) Andrew Eisenberg (Progress Software) David Cleary
|
|
(Progress Software) George Scott (Tradia Inc.) Erin Hoffman (Tradia
|
|
Inc.) Conleth O'Connell (Vignette) Waqar Sadiq (Vitria Technology
|
|
Inc.) Tom Breuel (Xerox) David Webber (XMLGlobal Technologies)
|
|
Matthew MacKenzie (XMLGlobal Technologies) and Mark Baker (Sun
|
|
Microsystems).
|
|
</p>
|
|
<p>We also wish to thank all the people who have contributed to
|
|
discussions on <a href="mailto:xml-dist-app@w3.org">
|
|
xml-dist-app@w3.org</a>.</p>
|
|
|
|
</div>
|
|
</div>
|
|
</body></html>
|