Re: Initial Usecases List

Some additional use cases, originally XMLP use cases[1], but
which seem to apply equally well here.

Jean-Jacques.

[1] http://www.w3.org/TR/2001/WD-xmlp-scenarios-20011217/

---------------
UCxxxx - 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 healthcare information. Examples of the
receiving party's responses may include order confirmations,
change control information and contractual acknowledgements.

UCyyyy - Remote Procedure Call (RPC): The sender invokes the
service by passing parameters that are serialized into a
message for transmission to the receiving server.

UCzzzz - 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: 1. The data has been
successfully delivered to the receiver, or 2. Some failure has
occurred which prevents the successful delivery to the
receiver.

UCtttt - 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 SOAP. The data reaches
the receiving application untouched, and may then be decrypted
in the agreed-upon manner.

UCuuuu - 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 signing of the payload.
The sending message handler 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 handler.

UCvvvv - Third party 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.

UCwwww - 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 handler that appends a routing
message must log the routing header information. Signed routing
headers and the message readers must be logged at the message
handler which passes the message to the ultimate receiver to
provide the evidence of non-repudiation.

UCmmmm - 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.

UCnnnn - Sending non-XML data: A digital camera wishes to
transmit image data over a wireless link using SOAP to a remote
server. The binary image data (non-XML) accompanies the
message. The digital camera represents a situation in which
connections from the receiver to the sender may not be
permitted due to device limitations or firewalls.

UCoooo - 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).

UCpppp - 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

Received on Wednesday, 20 February 2002 09:12:22 UTC