XMLP Node acting as initial sender XMLP Node

XMLP Node acting as initial sender XMLP Node acting as intermediary XMLP Sender XMLP Application 1 Handler a Handler b XMLP Block 1 XMLP Block 2 XML Node acting as ultimate receiver XMLP Sender & Receiver XMLP Application 2 XMLP Application 3 Handler e Handler c Handler d XMLP Block 3 XMLP Block 4 Handler f Handler g Handler h XMLP Message Path XMLP Layer XMLP Processor Underlying Protocol Layer XMLP Message XMLP Processor Underlying Protocol Message Path Underlying Protocol intermediary e. g. HTTP proxy SMTP relay Host III Host IV Host V

XMLP Node acting as initial sender XML Node acting as ultimate receiver XMLP Sender XMLP Receiver XMLP Application 1 XMLP Application 2 S 1 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) Assumptions No intermediaries, XMLP or otherwise. XMLP Message Path XMLP Layer XMLP Processor Underlying Protocol Layer Host I XMLP Message Comments Implements XMLP_UNITDATA primitive. XMLP Processor Underlying Protocol Message Path Host II

XML Nodes acting as ultimate receivers XMLP Node acting as initial sender XMLP Receiver Application 2 XMLP Sender XMLP Application 1 S 2 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) Assumptions No intermediaries, XMLP or otherwise. XMLP Message Path XMLP Layer XMLP Processor Underlying Protocol Layer Host I XMLP Message XMLP Processor Underlying Protocol Message Path Host II Comments 1. Implements XMLP_UNITDATA primitive. 2. Multicast handler may implement different distribution mechanisms depending on underlying protocol. For example, a distribution list of target receivers. 3. Multicast is a feature of the message and 4. is a mechanism to send a single message to multiple receivers 5. 4. Don’t use the term multicast – too overloaded !!

XMLP Node acting as initial sender XML Node acting as ultimate receiver XMLP Sender XMLP Receiver XMLP Application 1 XMLP Application 2 XMLP Message Path XMLP Layer XMLP Processor Underlying Protocol Layer Host I XMLP Message S 3 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. Assumptions No intermediaries, XMLP or otherwise. XMLP Processor Underlying Protocol Message Path Host II Comments 1. Implements XMLP_DATA primitive. 2. Underlying protocol(s) may not implement message correlation. 3. Sending handler inserts message identifier. 4. Receiving handler adds correlation identifier when creating response message. 5. Sending handler correlates request and response messages for return to sending application. 6. Request/response Feature. Multiple ways of implementing depending on the underlying protocol. 7. 7. If underlying transport supports req/resp, then this diagram, otherwise next

XMLP Node acting as initial sender XML Node acting as ultimate receiver XMLP Sender XMLP Receiver XMLP Application 1 XMLP Block 1 Message Identifier Handler XMLP Layer XMLP Processor Underlying Protocol Layer Host I XMLP Application 2 Message Identifier Handler XMLP Application 2 Message correlation XMLP Block 1 Message Correlation Handler XMLP Message Path XMLP Message XMLP Processor Underlying Protocol Message Path XMLP Layer XMLP Processor Underlying Protocol Layer Host II XMLP Application 1 XMLP Processor Underlying Protocol Message Path Host I

XMLP Node acting as initial sender XML Node acting as ultimate receiver XMLP Sender XMLP Receiver XMLP Application 1 RPC Handler XMLP Application 2 XMLP Block 1 RPC Handler XMLP Message Path XMLP Layer XMLP Processor Underlying Protocol Layer Host I XMLP Message XMLP Processor Underlying Protocol Message Path Host II S 4 Remote Procedure Call (RPC) The sender invokes the service by passing parameters that are serialised into a message for transmission to the receiving server. Assumptions 1. No intermediaries, XMLP or otherwise. 2. Note that this scenario will be influenced by the XMLP WG RPC sub-group conclusions. Therefore this is only one possible configuration and assumes an RPC handler. Comments 1. Implements XMLP_DATA primitive. 2. Underlying protocol(s) may not implement message correlation. 3. Sending handler inserts message identifier and encodes calling arguments. 4. Receiving handler adds correlation identifier when creating response message and adds encoding of response data. 5. Sending handler correlates request and response messages for return to sending application via language bindings that reflect the encoding scheme. 6. An alternative may to build an encoding handler which works with a Request/Response handler o provide the same functionality.

XMLP Node acting as initial sender XML Node acting as ultimate receiver XMLP Sender XMLP Receiver XMLP Application 1 Message Identifier Handler RPC Request Handler XMLP Layer XMLP Processor Underlying Protocol Layer Host I XMLP Application 2 XMLP Block 1 XMLP Block 2 Message Identifier Handler RPC Request Handler XMLP Application 2 Message Correlation Handler RPC with request/response message correlation RPC Response Handler XMLP Block 2 Message Correlation Handler XMLP Block 2 XMLP Message Path XMLP Message XMLP Processor Underlying Protocol Message Path XMLP Layer XMLP Processor Underlying Protocol Layer Host II XMLP Application 1 RPC Response Handler XMLP Processor Underlying Protocol Message Path Host I

XMLProtocol Initiator/Sender XMLP Layer XML Protocol Responder/Receiver XMLP_DATA Status Handler Request/ Response Handler Status Block Request/Response Block Sending XMLP Processor XMLP_DATA Status Handler Request/ Response Handler Receiving XMLP Processor Underlying Protocol Layers Node II S 5 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. 3. 4. 5. Assumptions No intermediaries, XMLP or otherwise. The receiver is the application ultimately receiving the message. Comments 1. Implements XMLP_DATA primitive. 2. Request/Response handlers manage the correlation of messages 3. Status handler at receiver inserts status block into response message providing information for sender.

Encryption Agreements XMLProtocol Initiator/Sender XMLP Layer XMLP_UNITDATA XMLP_DATA Sending XMLP Processor XML Protocol Responder/Receiver XMLP_UNITDATA XMLP_DATA Receiving XMLP Processor Underlying Protocol Layers Node II S 6 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. Assumptions 1. No intermediaries, XMLP or otherwise. 2. Scenario states that encryption/decryption is at the application layer. Comments 1. Implements either XMLP_DATA or XMLP_UNITDATA primitives. The scenario does not specify which. 2. All relationships and agreements for encryption are at the application layer so there is no impact on the XMLP layer.

S 7 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. Assumptions Comments

S 8 Conversational message exchange Two partners are engaged in a longrunning 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. Assumptions Comments

S 10 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 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. Assumptions Comments

S 11 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 headers must be logged at the message handler which passes the message to the ultimate receiver to

DS 17 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. Assumptions Comments

S 19 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. Assumptions Comments

S 20 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). Assumptions Comments

S 21 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 employs an XMLP handler that can incrementally process 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 memorylimited 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

S 23 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

DS 24 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

S 805 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

S 807 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. Assumptions Comments

S 809 Caching with Expiration Biz. Co updates their online price catalog every morning at 8 AM. Therefore, when remote clients access their XP inventory service, clients and intermediaries may cache the results of any price queries until 8 AM the next day. Assumptions Comments

S 810 Qo. S An XP sender (not necessarily the initial XP sender) wants the XP message to be handled with specific quality of service as it traverses the XP message path to include multiple XP Processing intermediaries. Information in the XP message is used to select appropriate Qo. S mechanisms (e. g. , RSVP, Diffserv, MPLS, etc. ). Selection of Qo. S may be constrained by Qo. S policies, Service Level Agreements (SLAs), Service Level