Usage scenarios are intended to provide representative examples of
situations where XMLP might be applicable. The purpose of usage scenarios is to
help ensure that XMLP is capable of dealing with applications and services
actually seen in the Web. Hence, usage scenario specifications should be at a
coarse-grain level of an end user's desired XML document/message interchange,
rather than at a detailed, implementation or transport specific level. Usage
scenarios often make assumptions about the specific environments in which the
use cases are described that the requirements cannot.
In other words, the requirements are explicitly targeted to the design
of XMLP; usage scenarios are targeted to systems in which XMLP is most likely
part of an overall solution. Not all requirements need to be referenced by an
example usage scenario, since, in addition to higher-level, application
specific requirements for use, there are internal, architectural requirements
independent of any specific higher-level use (e.g., using XML, schemas, and
namespaces imposes certain requirements irrespective of use).
- S1 Fire-and-forget to single receiver
-
A sender wishes to send an unacknowledged message to a single
receiver (e.g. send a stock price update every 15 minutes)
Note:
S1 Originates from splitting the
ebXML use case 1.1 into 2 scenarios (S1 and
S2).
- S2 Fire-and-forget to multiple receivers
-
A sender wishes to send unacknowledged messages to a set of
receivers (e.g. send a stock price update every 15 minutes)
Note:
S2 Originates from splitting the
ebXML use case 1.1 into 2 scenarios (S1 and
S2). Note that S2 may be decomposed into Multiple instances of S1 under the
control of some "higher-level" process such as multicast or
publish/subscribe.
- S3 Request-response
-
Two parties wish to conduct electronic business by the exchange
of business documents. The sending party packages one or more documents into a
request message which is then sent to the receiving party. The receiving party
then processes the message contents and responds to the sending party. Examples
of the sending party's documents may be purchase order requests, manufacturing
information and patient healthcase information. Examples of the receiving
party's responses may include order confirmations, change control information
and contractual acknowledgements.
- S4 Remote Procedure Call (RPC)
-
The sender invokes the service by passing parameters that are
serialised into a message for transmission to the receiving server.
- S5 Request with acknowledgement
-
A sender wishes to reliably exchange data with a receiver. It
wishes to be notified of the status of the data delivery to the receiver. The
status may take the form of:
-
The data has been successfully delivered to the receiver,
or
-
Some failure has occurred which prevents the sucessful
delivery to the receiver.
Note:
This scenario does not imply that reliable message delivery
will be supported by the XMLP core specification.
- S6 Request with encrypted payload
-
A sender wishes to exchange data with a receiver and has agreed
to encrypt the payload. The sending and receiving applications agree on the
encryption methodology. Data is encrypted by the originating application and
sent to the receiver via XMLP.The data reaches the receiving application
untouched, and may then be decrypted in the agreed-upon manner.
- S7 Third part intermediary
-
A blind auction marketplace serves as a broker between buyers
and suppliers. Buyers submit their requirements to the marketplace hub, which
broadcasts this information to multiple suppliers. Suppliers respond to the
marketplace hub where the information is logged and ultimately delivered to the
buyer.
- S8 Conversational message exchange
-
Two partners are engaged in a long-running process which
involves multiple message exchanges. Examples of such processes may be complex
supply chain management, dynamic manufacturing scheduling or information
retrieval. There may be multiple instances of the same process in progress
between the same two partners.
- S10 Message header and payload encryption
-
Two trading partners engaged in a message exchange may agree to
cryptographically sign and verify either the message header, the routing
header(s) and/ or the payload. The sender or originating application may
perform the siging of the payload. The sending message extension signs the
message header. A routing header may be appended to the message header. The
routing header may also be signed by a message service extension.
- S11 Communication via multiple intermediaries
-
An intermediary forwards a message to the ultimate receiver on
behalf of an initial sender. The initial sender wishes to enforce the
non-repudiation property of the route. Any intermediate message service
extension that appends a routing message must log the routing header
information. Signed routing headers and the message headers must be logged at
the intermediary which passes the message to the ultimate receiver to provide
the evidence of non-repudiation.
- DS17 Asynchronous messaging
-
A sender sends a message asynchronously to a receiver expecting
some response at a later time. The sender tags the request with an identifier
allowing the response to be correlated with the originating request. The sender
may also tag the message with an identifier for another service (other than the
originating sender) which will be the recipient of the response.
- S19 Sending non-XML data
-
A digital camera wishes to transmit image data over a wireless
link using XMLP to a remote server. The binary image data (non-XML) accompanies
the message. The digital camara represents a situation in which connections
from the receiver to the sender may not be permitted due to device limitations
or firewalls.
- S20 Multiple asynchronous responses
-
An application requests some information from a server, which is
returned at a later time in multiple responses. This can be because the
requested information was not available all at once (e.g., distributed web
searches). (based on [13])
- S21 Incremental parsing/processing of XMLP
messages
-
An XMLP sender generates a lengthy XMLP message that is
incrementally transmitted and received by an XMLP receiver. The XMLP receiver
processes the body as it is received (e.g., employing a SAX-style XML parser on
the body as it arrives). Note that the entire message need not be present at
one time at any point in its existence.
This would be particularly helpful for memory-limited
processors. It is also very efficient for services which are consistent with
incremental, real-time transformations of the data, direct archiving of
received data, etc. It would also be useful in scenarios in which voluminous
body data can be directly transduced into application data structures or events
by an XMLP (module) processor. In particular, there is no need for the explicit
construction of a DOM model of the data. Support for XMLP data models might
still be possible even with incremental processing if the models are
incrementally constructible (copied in its entirety from [14])
- S23 Event notification
-
An application subscribes to notifications of certain named
events from an event source. When such events occur, notifications are sent
back to the originating application (first party notification) or to another
application (third party notification). For example, an application can
subscribe to notification of various aspects of a printer's status (e.g.,
running out of paper, ink etc.). The notifications of such events could be
delivered to a management application (based on: See item 2 of
[15])
- DS24 Caching
-
Some applications may wish to make caching possible for latency,
bandwidth use or other gains in efficiency. To enable this, it should be
possible to assign cacheability in a variety of circumstances. For example,
"read" caching might be used to store messages at intermediaries for reuse in
the response phase of the request/response message exchange pattern. Such
caching might be on the scope of an entire message, an XMLP module, or scoped
to individual XMLP module elements.
Similarly, "write" caching may be useful in situations when a
request message in a request/response message exchange pattern (as well as
similar messages in other message exchange patterns) does not need to be
immediately forwarded or responded to. Such cachability might be scoped by
different methods, as outlined above.
Cacheability scoped by different elements might be associated by
an attribute to the target element, through use of XML Query or XPath to
describe the target elements in a header, or implied by the document schema,
for example.
Cacheability mechanisms applied to messages, bodies or elements
might include time-to-live (delta time), expiry (absolute time), entity
validation, temporal validation, subscription to invalidation services, and
object update/purge.
Finally, some applications may be capable of describing the
dependencies and relationships between message elements. For example, a
response element may be applicable to a wide range of requests; it would be
beneficial to describe this element's relationship with request elements, so
that it may satisfy a wide range of requests in an economical fashion.
Similarly, the presence of a particular element may be a trigger for a
cacheability mechanism to be applied to another element, such as validation or
invalidation (see also [16])
- S805 Routing
-
A developer wishes to force an explicit message path through
certain intermediaries - for instance, he might use an anonymizing intermediary
to make a call to a specified remote service without allowing the target
service to track the identity/IP of the caller. In this case, the intermediary
is responsible for calling the target service and returning the results to the
caller, using its own authentication credentials if any are required by the
target service.
- S807 Tracking
-
A service provider wishes to track incoming messages to see
exactly which processing intermediaries have touched it by the time it arrives
at its destination. It therefore requires a tracking extension to be included
by all clients, and by any processing intermediaries along the message paths
from the clients to the server.
- S809 Caching with Expiration
-
BizCo updates their online price catalog every morning at 8AM.
Therefore, when remote clients access their XMLP inventory service, clients and
intermediaries may cache the results of any price queries until 8AM the next
day.
- S810 QoS
-
An XMLP sender (not necessarily the initial XMLP sender) wants
the XMLP message to be handled with specific quality of service as it traverses
the XMLP message path to include multiple XMLP Processing intermediaries.
Information in the XMLP message is used to select appropriate QoS mechanisms
(e.g.,
RSVP,
Diffserv,
MPLS, etc.). Selection of QoS may be
constrained by
QoS policies,
Service Level Agreements (SLAs),
Service Level Specifications (SLS).