Tentative Hold Protocol Part 2: Technical Specification

Abstract

The objective of Tentative Hold Protocol is to facilitate automated coordination of multi-business transactions. Tentative Hold Protocol is an open, loosely coupled, messaging-based framework for the exchange of information between businesses prior to the actual transaction itself. Tentative Hold Protocol defines an architecture that allows tentative, non-blocking holds or reservations to be requested for a business' resource (e.g., the items for sale from an online retailer).

Status of this document

This document is a submission to the World Wide Web Consortium (see Submission Request, W3C Staff Comment). For a full list of all acknowledged Submissions, please see Acknowledged Submissions to W3C.

This document is a NOTE made available by the W3C for discussion only. Publication of this Note by W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members. No W3C resources were or are allocated to the issues addressed by the NOTE. W3C has had no editorial control over the preparation of this NOTE.

A list of current W3C technical documents can be found at the Technical Reports page.

Table of Contents

1. Motivation

2. Overview

2.1 Relationship to Other XML Specifications

3. Tentative Hold Protocol Architecture

3.1 State Diagram

3.2 Tentative Hold Schema

3.3 Sample Hold Request Message

3.4 WSDL and Tentative Hold Messaging

4. Component Requirements

4.1 Notational Conventions

4.2 General Tentative Hold Protocol Requirements

4.3 Client Coordinator Requirements

4.4 Client-side Persistent Store Requirements

4.5 Resource Coordinator Requirements

4.6 Resource Persistent Store Requirements

4.7 Rules Integration Module Requirements

5. References

Appendix A - Requesting a Tentative Hold

Appendix B - Sample Messages

1. Motivation

Current supply chain automation technologies provide automation of one-to-one business interactions. However, in the real-world supply lattice ecology, businesses interact with numerous other businesses to complete many business transactions. These transactions involve multiple businesses and require careful orchestration due to their strong interdependence. Tentative Hold Protocol facilitates automation of such transactions. This document provides technical details for Tentative Hold Protocol, including Schema and Web Services Description Language mapping. The operations involved in Tentative Hold Protocol, as well as their inputs and outputs, are described using WSDL syntax. The Tentative Hold Protocol White Paper, included in this W3C submission, provides various business scenarios as well as an overview of how this technology can be useful.

Tentative Hold Protocol is an open, loosely coupled, messaging-based framework for the exchange of information between businesses prior to the actual transaction itself. Tentative Hold Protocol defines an architecture that allows tentative, non-blocking holds or reservations to be requested for a business' resource (e.g., the items for sale from an online retailer). In the paradigm of online purchasing, these tentative reservations are placed prior to the sale, allowing multiple clients to place these tentative holds on the same item. Whenever one client completes the purchase of the item, the other clients receive notifications that their holds are no longer valid.

This protocol provides flexibility for both ends of the transaction. The clients have the ability to request tentative reservations on the resources that they want to acquire as a single coordinated purchase, verifying price and availability before completing the transactions. If one item becomes unavailable (purchased by some other client), the first client has the ability to replace it with another item without losing any holds on other items already reserved. The vendors grant non-blocking reservations on their products, retaining control of their resources, while allowing many potential customers greater flexibility in coordinating their purchases. 

2. Overview

Tentative Hold Protocol uses existing and evolving open standards and technologies wherever possible to ensure the interoperability across heterogeneous remote enterprises. For example, the Client Coordinator and Resource Coordinator can be represented as web services using WSDL, and can communicate using SOAP over HTTP/HTTPS (however, such bindings are not mandated; the communication could happen using the BizTalk Framework, the XML Protocol under development at W3C or other communication protocols).

The major components involved are displayed in Figure 1. There will be a Tentative Hold Protocol coordinator on both the client (Client Coordinator - CC) and resource owner side (Resource Coordinator - RC), responsible for communicating various messages including hold requests and cancellations. There will also be persistent stores on both ends, responsible for maintaining information such as current holds and activity logs.

Figure 1. Tentative Hold Protocol Overview 

A client application will interact with its Client Coordinator by requesting new tentative holds, requesting information about existing holds, canceling holds, and retrieving archived information from the Client-side Persistent Store (CPS). The client application will receive hold request responses and cancellation notifications from the CC. Refer to Appendix A for a more in-depth diagram and description of the sequence of events involved with the request for a tentative hold and cancellation. 

The Client Coordinator will interact with remote Resource Coordinators, sending requests from the client application for new tentative holds, cancellations, and current status, as well as forwarding any responses from the Resource Coordinators to the client application. The Client Coordinator will store the following information in a Client-side Persistent Store:

• Tentative holds and their status (e.g., requested, granted and so on); and
• Activity logs.

As noted previously, the Resource Coordinator resides on the resource owner's system. It will receive and respond to requests for tentative holds, as well as passing any needed cancellation notifications. The RC will interact with the Rules Integration Module to determine whether a requested tentative hold should be granted and for how long. The RC will also be responsible for tracking all currently active holds, canceling them when their timeouts expire and sending notifications to the affected Client Coordinators.

The resource owner will be responsible for providing a rules engine entity (Rules Integration Module or RIM). This will be the main interaction point between the Resource Coordinator and the resource owner's systems. The RIM will be responsible for handling any business-rule-specific actions in response to requests for tentative holds. This allows the resource owner great flexibility in providing targeted customer service in the granting of holds, specifying greater or lesser hold expirations for a given hold request, as well as the potential for notifying valued clients when some resource is being reserved by another client - allowing the preferred client the opportunity to lock in their purchase first.

The RIM will be responsible for determining whether a new Tentative Hold Protocol request is valid, whether it should be granted, and its duration. This implies that the RIM must be able to determine whether the requested resource is available. Once a hold request has been determined to be valid, the RIM is responsible for inserting a trigger on the application managing the resource (e.g., database management system, ERP, and so on); this trigger will notify the Resource Coordinator about any change in the status of the resource for which the hold is being granted. This allows the RC to notify any affected clients that their holds are no longer valid.

2.1 Relationship to Other XML Specifications

The headers of the tentative hold protocol communications are specified and validated using XML Schemas. These communications take advantage of XML-based communication protocols though they are not tied to any particular protocol. Hence, it is possible to exchange tentative hold protocol communications using an existing protocol such as Simple Object Access Protocol, BizTalk Framework, ebXML Transport, Routing and Packaging, or the W3C XML Protocol that is currently under development. 

The services offered by the Client Coordinator and Resource Coordinator and the communications across them can be modeled using Web Services Description Language (WSDL). Refer to Section 2 of this submission for a WSDL representation of the interaction between the  Tentative Hold Protocol Client and Resource Coordinators listed in Figure 1. Tentative Hold Protocol could be modeled using other process modeling specifications or graphical modeling tools.

The services that are used in a coordinated manner using Tentative Hold Protocol could be discovered using a discovery service such as Universal Description, Discovery and Integration (UDDI). 

Tentative Hold Protocol facilitates coordination of multi-business transactions. However, it is totally decoupled from the business information that is exchanged as a part of the request and responses. These request and responses could conform to any of the vertical industry XML document standards (e.g., RosettaNet dictionary).

As mentioned before, Tentative Hold Protocol facilitates automated coordination of multi-business transactions, but does not ensure it. Tentative Hold Protocol could complement protocols such as Transaction Internet Protocol (TIP) and Business Transaction Protocol (BTP) by preceding transactions that use one of these protocols.

3. Tentative Hold Protocol Architecture

3.1 State Diagram

The following state diagram displays the states and transitions involved in the lifespan of a single tentative hold. Note that a given hold's state will be known to the Resource and Client Coordinators associated with that hold. 

Figure 2. Tentative Hold Protocol State Diagram 

As noted in the diagram, the following four states are associated with a hold:

• Responding - This initial state is reached when some application sends a Hold Request message.
  
• In Process - This intermediate state indicates that the hold request has been received and an acknowledgement of the request has been returned to the hold requester. 
  
• Active - This state is reached from the In Process state when the requested hold has been granted - a Hold Granted message has been sent by the resource owner. Note that in this state the hold requester may attempt to modify the specifics of this hold by sending a Modify Hold message.
  
• Inactive - This state is reached from the Active state when the tentative hold is no longer valid - e.g., a Hold Cancellation message has been sent by the client or the resource owner, or the hold has expired.

It is also possible to perform a Status Query at any of these states; however, this type of message does not result in a state change.

3.2 Tentative Hold Schema

Namespace

Implementations of this specification MUST use the following XML namespace URI:

http://www.w3.org/2001/08/thp/schemas

The namespace prefix "holdSchema" used in this specification is associated with this URI.

Schema

The following schema is provided to define Tentative Hold Protocol message headers.

<?xml version="1.0"?>
<schema xmlns="http://www.w3.org/2000/10/XMLSchema"
          targetNamespace="http://www.w3.org/2001/08/thp/schemas"
          xmlns:holdSchema="http://www.w3.org/2001/08/thp/schemas">
<!-- =================================================================== -->
<!-- Item - holdHeader -->
<!-- Note - This information is required in all the Tentative Hold Protocol communications. -->
<!-- Fields- holdID - UUID. -->
<!--             customerID - account number or other identifier -->
<!--             replyTo - could be a unique locator such as a URI or an email address depending on the communication protocol to be used. -->
<!-- comment - space for trading partner defined info. -->
<!-- =================================================================== -->
<complexType name="holdHeader">
  <sequence>
    <element name="holdID" type="int"/>
    <element name="customerID" type="string"/>
    <element name="replyTo" type="string"/>
    <element name="comment" type="string"/>
  </sequence>
</complexType>

<!-- =================================================================== -->
<!-- Item - userDefinedBody -->
<!-- Note - This will carry any domain-specific information  (e.g., product ID and quantity). An implementation shall probably have many different userDefinedBody's (one for holdRequest, holdRequestAck, ...). This body is used in all messages. -->
<!-- Fields - Trading partner to trading partner specific or an agreed standard (e.g., RosettaNet PIP). -->
<!-- =================================================================== -->
<complexType name="userDefinedBody">
  <!-- user defined line item structure -->
</complexType>

<!-- =================================================================== -->
<!-- Item - holdRequestHdr -->
<!-- Note - Specifies the Tentative Hold Protocol header for messages requesting a tentative hold. -->
<!-- Fields - Same as holdHeader -->
<!-- =================================================================== -->
<complexType name="holdRequestHdr">
  <sequence>
    <element name="baseHeader" type="holdSchema:holdHeader"/>
  </sequence>
</complexType>

<!-- =================================================================== -->
<!-- Item - holdRequestAckHdr -->
<!-- Note - -->
<!-- Fields - holdHeader + timeUntilResponse - a indication of the time it will take the resource provider to process the request. -->
<!-- =================================================================== -->
<complexType name="holdRequestAckHdr">
  <sequence>
    <element name="baseHeader" type="holdSchema:holdHeader"/>
    <element name="timeUntilResponse" type="timeDuration"/>
  </sequence>
</complexType>

<!-- =================================================================== -->
<!-- Item - holdGrantHdr -->
<!-- Note - -->
<!-- Fields - holdHeader + holdDuration - the agreed to length of the hold on the resource requested. -->
<!-- =================================================================== -->
<complexType name="holdGrantHdr">
  <sequence>
    <element name="baseHeader" type="holdSchema:holdHeader"/>
    <element name="holdDuration" type="timeDuration"/>
  </sequence>
</complexType>

<!-- =================================================================== -->
<!-- Item - holdDenialHdr -->
<!-- Note - -->
<!-- Fields - holdHeader + reason - a description of the reason for the denial. The implementation may choose to use reason codes or just textual descriptions. -->
<!-- =================================================================== -->
<complexType name="holdDenialHdr">
  <sequence>
    <element name="baseHeader" type="holdSchema:holdHeader"/>
    <element name="reason" type="string"/>
  </sequence>
</complexType>

<!-- =================================================================== -->
<!-- Item - holdModifyRequestHdr -->
<!-- Note - -->
<!-- Fields - holdHeader -->
<!-- =================================================================== -->
<complexType name="holdModifyRequestHdr">
  <sequence>
    <element name="modifiedHoldRequest" type="holdSchema:holdHeader"/>
  </sequence>
</complexType>

<!-- =================================================================== -->
<!-- Item - holdModifyGrantHdr -->
<!-- Note - -->
<!-- Fields - holdHeader + holdDuration - the agreed to length of the hold on the resource requested. -->
<!-- =================================================================== -->
<complexType name="holdModifyGrantHdr">
  <sequence>
    <element name="modifiedHoldRequest" type="holdSchema:holdGrantHdr"/>
  </sequence>
</complexType>

<!-- =================================================================== -->
<!-- Item - holdModifyDenialHdr -->
<!-- Note - -->
<!-- Fields - holdHeader + reason - a description of the reason for the denial.The implementation may choose to use reason codes or just textual descriptions.-->
<!-- =================================================================== -->
<complexType name="holdModifyDenialHdr">
  <sequence>
    <element name="modifiedHoldRequest" type="holdSchema:holdDenialHdr"/>
  </sequence>
</complexType>

<!-- =================================================================== -->
<!-- Item - holdModifyResponseChoiceHdr -->
<!-- Note - The use of a single type for this response was to facilitate a synchronous request/response for the modify request without preventing asynchronous.-->
<!-- Fields - Either holdModifyGrantHdr or holdModifyDenialHdr -->
<!-- =================================================================== -->
<complexType name="holdModifyResponseChoiceHdr">
  <choice>
    <element name="grant" type="holdSchema:holdModifyGrantHdr"/>
    <element name="deny" type="holdSchema:holdModifyDenialHdr"/>
  </choice>
</complexType>

<!-- =================================================================== -->
<!-- Item - holdCancellationRequestHdr -->
<!-- Note - -->
<!-- Fields - holdHeader + customerReason - a description of or a code for the reason why the hold is being cancelled. -->
<!-- =================================================================== -->
<complexType name="holdCancellationRequestHdr">
  <sequence>
    <element name="customerHold" type="holdSchema:holdHeader"/>
    <element name="customerReason" type="string"/>
  </sequence>
</complexType>

<!-- =================================================================== -->
<!-- Item - holdCancellationResponseHdr -->
<!-- Note - -->
<!-- Fields - holdHeader -->
<!-- =================================================================== -->
<complexType name="holdCancellationResponseHdr">
  <sequence>
    <element name="customerHold" type="holdSchema:holdHeader"/>
  </sequence>
</complexType>

<!-- =================================================================== -->
<!-- Item - holdCancellationNotificationHdr -->
<!-- Note - -->
<!-- Fields - holdHeader + cancellationReason - a description of or a code for the reason the vendor is cancelling the hold. -->
<!-- =================================================================== -->
<complexType name="holdCancellationNotificationHdr">
  <sequence>
    <element name="customerHold" type="holdSchema:holdHeader"/>
    <element name="cancellationReason" type="string"/>
  </sequence>
</complexType>

<!-- =================================================================== -->
<!-- Item - holdStatusQueryHdr -->
<!-- Note - -->
<!-- Fields - holdHeader -->
<!-- =================================================================== -->
<complexType name="holdStatusQueryHdr">
  <sequence>
    <element name="customerHold" type="holdSchema:holdHeader"/>
  </sequence>
</complexType>

<!-- =================================================================== -->
<!-- Item - holdStatusResponseHdr -->
<!-- Note - -->
<!-- Fields - holdHeader -->
<!-- =================================================================== -->
<complexType name="holdStatusResponseHdr">
  <sequence>
    <element name="baseHeader" type="holdSchema:holdHeader"/>
  </sequence>
</complexType>

<!-- =================================================================== -->
<!-- Item - statusStructure -->
<!-- Note - -->
<!-- Fields - holdHeader + holdState - a description of the state of the hold. Possible values currently defined are: responding, in process, active, and inactive. The definition is left open (not restricted) for future or user refinement of the useful values. -->
<!-- =================================================================== -->
<complexType name="statusStructure">
  <sequence>
    <element name="itemHeader" type="holdSchema:holdHeader" />
    <element name="holdState" type="string"/> 
  </sequence>
</complexType>

<!-- =================================================================== -->
<!-- Item - holdStatusResponseBody -->
<!-- Note - -->
<!-- Fields - holdItemsCount - the number of holds matching the holdStatusQuery. -->
<!--             itemList - The header and state of the holds that match the query. -->
<!-- =================================================================== -->
<complexType name="holdStatusResponseBody">
  <sequence>
    <element name="holdItemsCount" type="int"/>
    <element name="itemList" type="statusStructure" minOccurs="0" maxOccurs="unbounded"/>
  </sequence>
</complexType>

<!-- =================================================================== -->
<!-- Item - holdErrorHdr -->
<!-- Note - -->
<!-- Fields - holdHeader -->
<!-- =================================================================== -->
<complexType name="holdErrorHdr">
  <sequence>
    <element name="baseHeader" type="holdSchema:holdHeader"/>
  </sequence>
</complexType>

<!-- =================================================================== -->
<!-- Item - holdErrorBody -->
<!-- Note - -->
<!-- Fields - holdErrorType - some code for the type -->
<!--             holdErrorDesc - a description of the error, possibly to include the erroneous message. -->
<!-- =================================================================== -->
<complexType name="holdErrorBody">
  <sequence>
    <element name="holdErrorType" type="int"/>
    <element name="holdErrorDesc" type="string"/>
  </sequence>
</complexType>
</schema>

3.3 Sample Hold Request Message

The following sample Hold Request message is based on a published BizTalk schema (located at http://schemas.biztalk.org/nxtrend_com/syuwc1l2.xml). It is provided as an example of how a Tentative Hold Protocol message might appear. Refer to Appendix B for a comprehensive set of sample messages dealing with other Tentative Hold Protocol messages and acknowledgements.

<SOAP-ENV:Envelope 
        xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
        xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema">

  <SOAP-ENV:Body>
    <header>
      <holdSchema:holdRequestHdr xmlns: holdSchema = "http://www.w3.org/2001/08/thp/schemas"
            xsi:schemaLocation=
                             "http://www.w3.org/2001/08/thp/schemas/HoldRequest.xsd">
        <holdSchema:baseHeader> 
          <holdSchema:holdHeader>
            <holdID>2B7367E7-6913-4E89-8792-90F1D80EDDDF</holdID>
            <customerID>ABC105</customerID>
            <replyTo>[email protected]</replyTo>
            <comment>consider this urgent</comment>
          </holdSchema:holdHeader>
        </holdSchema:baseHeader>
      </holdSchema:holdRequestHdr>
    </header>
    <body>
      <holdSchema:userDefinedBody>
        <RequestForQuote RequestType="FORMAL" ResponseType="STATUS">
          <QuoteRequestHeader>
            <Currency>USD</Currency>
            <QuoteDate>2001-10-10</QuoteDate>
            <QuoteParty PartyID="XYZ123"> 
              <NameAddress>
                <name>XYZ Company</name>
                <street>123 Maple Street</street>
                <city>Mill Valley</city>
                <state>CA</state>
                <zip>90952</zip>
                <country>US </country>
              </NameAddress>
            </QuoteParty>
            <ShipToParty PartyID="ABC123"> 
              <NameAddress>
                <name>ABC Company</name>
                <street>8 Oak Avenue </street>
                <city> Old Town </city>
                <state> PA </state>
                <zip>95819</zip>
                <country>US </country>
              </NameAddress>
            </ShipToParty>
          </QuoteRequestHeader>
          <ListofBaseItemDetail>
            <BaseItemDetail>
              <ItemName>Bulbs</ItemName>
              <ItemQuantity>100</ItemQuantity>
              <ItemDescription>lamp bulbs</ItemDescription>
            </BaseItemDetail>
          </ListofBaseItemDetail >
        </RequestForQuote >
      </holdSchema:userDefinedBody>
    </body>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

3.4 WSDL and Tentative Hold Messaging

From the Web Services Description Language (WSDL) W3C Note Abstract: 

WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services).

The Tentative Hold Protocol messaging has been mapped into this representation, based on the current revision (W3C Note 15 March 2001, version 1.1). The operations involved in Tentative Hold Protocol, as well as their inputs and outputs, are described using the following WSDL syntax. 

<?xml version="1.0" encoding="UTF-8"?>
<definitions name ="TentativeHold"
          targetNamespace="http://www.w3.org/2001/08/thp/definitions"
          xmlns:tns="http://www.w3.org/2001/08/thp/definitions"
          xmlns:holdSchema="http://www.w3.org/2001/08/thp/schemas"
          xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
          xmlns="http://schemas.xmlsoap.org/wsdl/">

  <message name="HoldRequest">
    <part name="header" type="holdSchema:holdRequestHdr"/>
    <part name="body" type="holdSchema:userDefinedBody"/>
  </message>

  <message name="HoldRequestAck">
    <part name="header" type="holdSchema:holdRequestAckHdr"/>
    <part name="body" type="holdSchema:userDefinedBody"/>
  </message>

  <message name="HoldGrantResponse">
    <part name="header" type="holdSchema:holdGrantHdr"/>
    <part name="body" type="holdSchema:userDefinedBody"/>
 </message>

  <message name="HoldDenialResponse">
    <part name="header" type="holdSchema:holdDenialHdr"/>
    <part name="body" type="holdSchema:userDefinedBody"/>
  </message>

  <message name="HoldModifyRequest">
    <part name="header" type="holdSchema:holdModifyRequestHdr"/>
    <part name="body" type="holdSchema:UserDefinedBody"/> 
  </message>

  <message name="HoldModifyResponse">
    <part name="header" type="holdSchema:holdModifyResponseChoiceHdr"/>
    <part name="body" type="holdSchema:userDefinedBody"/>
  </message>

  <message name="HoldCancellationRequest">
    <part name="header" type="holdSchema:holdCancellationRequestHdr"/>
    <part name="body" type="holdSchema:userDefinedBody"/>
  </message>

  <message name="HoldCancellationResponse">
    <part name="header" type="holdSchema:holdCancellationResponseHdr"/>
    <part name="body" type="holdSchema:userDefinedBody"/>
  </message>

  <message name="HoldCancellationNotification">
    <part name="header" type="holdSchema:holdCancellationNotificationHdr"/>
    <part name="body" type="holdSchema:userDefinedBody"/>
  </message>

  <message name="HoldStatusQueryRequest">
    <part name="header" type="holdSchema:holdStatusQueryHdr"/>
    <part name="body" type="holdSchema:userDefinedBody"/>
  </message>

  <message name="HoldStatusResponse">
    <part name="header" type="holdSchema:holdStatusResponseHdr"/>
    <part name="body" type="holdSchema:holdStatusResponseBody"/>
  </message>

  <message name="HoldErrorResponse">
    <part name="header" type="holdSchema:holdErrorHdr"/>
    <part name="body" type="holdSchema:holdErrorBody"/>
  </message>

  <portType name="TentativeHoldServicePortType">
    <operation name="InitiateHold">
      <input message="tns:HoldRequest"/>
      <output message="tns:HoldRequestAck"/>
      <fault message="tns:HoldErrorResponse"/>
    </operation>

    <operation name="InitiateHoldModify">
      <input message="tns:HoldModifyRequest"/>
      <output message="tns:HoldModifyResponse"/>
      <fault message="tns:HoldErrorResponse"/>
    </operation>

    <operation name="InitiateHoldCancellation">
      <input message="tns:HoldCancellationRequest"/>
      <output message="tns:HoldCancellationResponse"/>
      <fault message="tns:HoldErrorResponse"/>
    </operation>

    <operation name="InitiateStatusQuery">
      <input message="tns:HoldStatusQueryRequest"/>
      <output message="tns:HoldStatusResponse"/>
      <fault message="tns:HoldErrorResponse"/>
    </operation>
  </portType>

  <portType name="TentativeHoldNotificationServicePortType">
    <operation name="NotifyHoldGranted">
      <output message="tns:HoldGrantResponse"/>
    </operation>

    <operation name="NotifyHoldDenied">
      <output message="tns:HoldDenialResponse"/>
    </operation>

    <operation name="NotifyServerHoldCancellation">
      <output message="tns:HoldCancellationNotification"/>
    </operation>
  </portType>

  <binding name="TentativeHoldSoapBinding" type="tns:TentativeHoldServicePortType">
    <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http/">
    <operation name="InitiateHold">
      <soap:operation soapAction="http://www.w3.org/2001/08/thp/InitiateHold"/>
      <input>
        <soap:body use="literal"/>
      </input>
      <output>
        <soap:body use="literal"/>
      </output>
      <fault>
        <soap:fault use="literal"/>
      </fault>
    </operation>

    <operation name="InitiateHoldModify">
      <soap:operation soapAction="http://www.w3.org/2001/08/thp/InitiateHoldModify"/>
      <input>
        <soap:body use="literal"/>
      </input>
      <output>
        <soap:body use="literal"/>
      </output>
      <fault>
        <soap:fault use="literal"/>
      </fault>
    </operation>

    <operation name="InitiateHoldCancellation">
      <soap:operation soapAction="http://www.w3.org/2001/08/thp/InitiateHoldCancellation"/>
      <input>
        <soap:body use="literal"/>
      </input>
      <output>
        <soap:body use="literal"/>
      </output>
      <fault>
        <soap:fault use="literal"/>
      </fault>
    </operation>

    <operation name="InitiateStatusQuery">
      <soap:operation soapAction="http://www.w3.org/2001/08/thp/InitiateStatusQuery"/>
      <input>
        <soap:body use="literal"/>
      </input>
      <output>
        <soap:body use="literal"/>
      </output>
      <fault>
        <soap:fault use="literal"/>
      </fault>
    </operation>
  </binding>

  <binding name="TentativeHoldSMTPBinding" type="tns:TentativeHoldNotificationServicePortType">
    <soap:binding style="document" transport="http://www.w3.org/2001/08/thp/smtp/">
    <operation name="NotifyHoldGranted">
      <output>
        <soap:body use="literal"/>
      </output>
    </operation>

    <operation name="NotifyHoldDenied">
      <output>
        <soap:body use="literal"/>
      </output>
    </operation>

    <operation name="NotifyServerHoldCancellation">
      <output>
        <soap:body use="literal"/>
      </output>
    </operation>
  </binding>

  <service name="TentativeHoldService">
    <documentation> Mythical Tentative Hold Web service</documentation>
    <port name="TentativeHoldPort" binding="tns:TentativeHoldSoapBinding">
      <soap:address location="http://xyz.com/tentativeHold/">
    </port>
  </service>

  <service name="TentativeHoldNotificationService">
    <port name="NotificationPort" binding="tns:TentativeHoldSMTPBinding">
      <soap:address location="mailto:[email protected]"/>
    </port>
  </service>
</definitions>

4. Component Requirements

This section will describe the functionality requirements for the key components in a tentative hold protocol implementation, viz., Client Coordinator, Client-Side Persistent Store, Resource Coordinator, Resource Persistent Store and the Rules Integration Module.

4.1 Notational Conventions

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [KEYWORDS].

4.2 General Tentative Hold Protocol Requirements

4.2.1 Tentative Hold Protocol SHALL NOT require any specific transaction completion product or approach.

4.2.2 The Tentative Hold Protocol Client and Resource Coordinators SHALL be able to communicate through firewalls.

4.3 Client Coordinator Requirements

4.3.1 At startup, the CC SHALL resolve the status of any previously granted holds.

4.3.2 The CC SHALL be a lightweight implementation, capable of running on a wide range of platforms (e.g., including small form factor devices that support SOAP).

4.3.3 The CC SHALL provide an interface that allows a client application to:

4.3.3.1 Request a hold from a specific resource owner for a specific resource;

4.3.3.2 Query existing holds owned by this client;

4.3.3.3 Cancel an existing hold owned by this client;

4.3.3.4 Query for the logged Tentative Hold Protocol activity;

4.3.3.5 Request a modification of an existing hold;

4.4 Client-side Persistent Store Requirements

4.4.1 The Client-side Persistent Store SHALL maintain at a minimum the following items in a persistent (i.e., across system restarts) manner:

4.4.1.1 List of current holds and associated information (e.g., resource owner and resource hold is against, timeout, etc.);

4.4.1.2 Activity log storing historical Tentative Hold Protocol information;

4.5 Resource Coordinator Requirements

4.5.1 At startup, the RC SHALL resolve the status of any previously granted holds by querying the Resource Persistent Store for outstanding holds, then verifying their expiration times.

4.5.2 The RC SHALL respond to CC hold requests either synchronously (hold request response is sent immediately) or asynchronously (RC shall send an acknowledgement of the request, followed at some later time by a hold request response).

4.5.3 The RC SHALL use the resource owner developed Rules Integration Module to satisfy new hold requests.

4.5.4 The RC SHALL asynchronously notify affected CCs should a resource become unavailable (e.g., the resource is allocated to another party);

4.5.5 The RC SHALL provide an interface that allows a resource owner's application to:

4.5.5.1 Query existing holds granted by this resource owner;

4.5.5.2 Cancel an existing hold granted by this resource owner;

4.5.5.3 Query for the logged Tentative Hold Protocol activity;

4.6 Resource Persistent Store Requirements

4.6.1 The Resource Persistent Store SHALL maintain at a minimum the following items in a persistent (i.e., across system restarts) manner:

4.6.1.1 List of current holds and associated information (e.g., client owning hold, resource held, timeout, etc.);

4.6.1.2 Activity log storing historical Tentative Hold Protocol information;

4.7 Rules Integration Module Requirements

4.7.1 The Rules Integration Module SHALL implement any business rules associated with the grant of holds as well as their respective timeouts.

4.7.2 The RIM SHALL insert triggers on applications managing the resources granted holds, which when triggered shall notify the Resource Coordinator of the resource state change.

5. References

[KEYWORDS] 
S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119, Harvard University, March 1997 

[SOAP] 
W3C Note, "SOAP: Simple Object Access Protocol 1.1," 08 May 2000. 

[URI] 
T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax," RFC 2396, MIT/LCS, U.C. Irvine, Xerox Corporation, August 1998. 

[XML-ns] 
W3C Recommendation, "Namespaces in XML," 14 January 1999. 

[XML-Schema1] 
W3C Recommendation, "XML Schema Part 1: Structures," 24 October 2000. 

[XML-Schema2] 
W3C Recommendation, "XML Schema Part 2: Datatypes," 24 October 2000. 

Appendix A - Requesting a Tentative Hold

The following diagram provides a high level overview of the sequence of events and actions involved in tentative holds. In this scenario, Client 1 makes a request for a resource and is granted a tentative hold on that resource (please see steps 1 through 5 in the following diagram); subsequently, Client 2 requests and is granted a hold on the same resource (steps 6 through 10). Client 2 then purchases the resource, invalidating the tentative hold owned by Client 1, who is notified in steps 6 through 8.

Figure 3. Tentative Hold Request 

Hold Request Process

This describes the expected actions that will occur when a Client requests a Tentative Hold Protocol hold on a resource owner's resource:

Step 2. The CC will contact the appropriate Resource Coordinator, forwarding the request for a tentative hold;

Step 3. The Resource Coordinator may reply either synchronously or asynchronously to this request. If responding asynchronously, the RC will receive this request and send a 'Request Received' acknowledgement to the CC, sending a detailed status at a later time. Otherwise, the response to the CC will be the result of the hold request process as noted in the following bullets. The RC will query the resource owner's RIM with the new hold request;

Step 4. The RIM will:

• satisfy itself that the request is valid (based on any defined business rules)
• verify that the resources are available for hold (e.g., by querying the resource owner's inventory system) 
• apply any desired business rules (e.g., should any preferred customers be notified that an item they have reserved is being reserved by another party?) 
• determine what the timeout period should be for this hold
• If the hold is granted, a trigger will be inserted on the application controlling that resource, allowing the Resource Coordinator to be notified if that resource is allocated by some other party 

Steps 6-10. These are duplicates of Steps 1-5, requesting a tentative hold on the same resource as Client 1, with the exception that it is from a different client (Client 2). This shows that the same resource has more than one tentative hold associated with it.

Step 11. Client 2 purchases the resource. The resource owner now must notify anyone affected by this change, anyone having a tentative hold on this resource - Client 1 in this case.

Step 12. A trigger fires in response to the state change - the allocation of the resource - notifying the Resource Coordinator.

Step 13. The Resource Coordinator notifies any Client Coordinators impacted by the resource state change, sending a Hold Cancellation message.

Step 14. The Hold Cancellation notification is received by Client 1's Client Coordinator and passed upward.

Canceling a Tentative Hold

Tentative Hold Protocol holds can be cancelled in the following ways:

• Hold expires - When a tentative hold is granted, there is a hold timeout associated with it, determined by the resource owner's Rules Integration Module. Once this timeout has expired, the hold is cancelled; the affected Client Coordinator will then be notified
  
• Client cancels hold - A Client that has a previously established tentative hold can cancel the hold unilaterally. The Client Coordinator will send an appropriate message to the Resource Coordinator which will cancel the hold
  
• Resource owner cancels hold - A resource owner has the ability to cancel any outstanding tentative hold on their resources. The resource owner's application would notify the Resource Coordinator, requesting that the hold be cancelled; all affected clients will then be notified
  
• Resource associated with tentative hold is allocated or becomes otherwise unavailable. This case is shown in Figure 3, specifically step VI where Client 2 purchases the resource; the Resource Coordinator is notified of the resource state change (step 12), determines that Client 1 is affected, then sends a cancellation notification (step 13) to the affected Client Coordinator, which then forwards the notice to the client application (step 14)
  

Appendix B - Sample Messages

Hold Request Acknowledgement

<SOAP-ENV:Envelope 
        xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
        xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema">
 <SOAP-ENV:Body>
  <holdSchema:holdRequestAckHdr
          xmlns: holdSchema = "http://www.w3.org/2001/08/thp/schemas"
          xsi:schemaLocation="http://www.w3.org/2001/08/thp/schemas/HoldRequest.xsd">
    <holdSchema:baseHeader> 
      <holdSchema:holdHeader>
        <holdID>2B7367E7-6913-4E89-8792-90F1D80EDDDF</holdID>
        <customerID>ABC105</customerID>
        <replyTo>[email protected]</replyTo>
        <comment>consider this urgent</comment>
      </holdSchema:holdHeader>
    </holdSchema:baseHeader>
    <timeUntilResponse> 2D </timeUntilResponse>
  </holdSchema: holdRequestAckHdr>
  <holdSchema:userDefinedBody>
  </holdSchema:userDefinedBody>
</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Hold Grant

<SOAP-ENV:Envelope 
        xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
        xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema">

<SOAP-ENV:Body>
  <holdSchema:holdGrantHdr
          xmlns: holdSchema = "http://www.w3.org/2001/08/thp/schemas"
          xsi:schemaLocation="http://www.w3.org/2001/08/thp/schemas/HoldRequest.xsd">
    <holdSchema:baseHeader> 
      <holdSchema:holdHeader>
        <holdID>2B7367E7-6913-4E89-8792-90F1D80EDDDF</holdID>
        <customerID>ABC105</customerID>
        <replyTo>[email protected]</replyTo>
        <comment> This hold is valid for the complete holdDuration</comment>
      </holdSchema:holdHeader>
    </holdSchema:baseHeader>
    <holdDuration> 3D </holdDuration>
  </holdSchema:holdGrantHdr>
  <holdSchema:userDefinedBody>
  </holdSchema:userDefinedBody>
</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Hold Denial

<SOAP-ENV:Envelope 
        xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
        xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema">

<SOAP-ENV:Body>
  <holdSchema:holdDenialHdr
          xmlns: holdSchema = "http://www.w3.org/2001/08/thp/schemas"
          xsi:schemaLocation="http://www.w3.org/2001/08/thp/schemas/HoldRequest.xsd">
    <holdSchema:baseHeader> 
      <holdSchema:holdHeader>
        <holdID>2B7367E7-6913-4E89-8792-90F1D80EDDDF</holdID>
        <customerID>ABC105</customerID>
        <replyTo>[email protected]</replyTo>
        <comment> Hold request denied </comment>
      </holdSchema:holdHeader>
    </holdSchema:baseHeader>
    <reason> Hold request cannot be satisfied at this time </reason>
  <holdSchema:userDefinedBody>
  </holdSchema:userDefinedBody>
</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Hold Modify Request

<SOAP-ENV:Envelope 
        xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
        xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema">

<SOAP-ENV:Body>
  <holdSchema:holdModifyRequestHdr
        xmlns: holdSchema = "http://www.w3.org/2001/08/thp/schemas"
        xsi:schemaLocation="http://www.w3.org/2001/08/thp/schemas/HoldRequest.xsd">
    <holdSchema:modifiedHoldRequest> 
      <holdSchema:holdHeader>
        <holdID>2B7367E7-6913-4E89-8792-90F1D80EDDDF</holdID>
        <customerID>ABC105</customerID>
        <replyTo>[email protected]</replyTo>
        <comment> Modify the hold with above holdID</comment>
      </holdSchema:holdHeader>
    </holdSchema:modifiedHoldRequest>
  </holdSchema:holdModifyRequestHdr>
  <holdSchema:userDefinedBody>
  </holdSchema:userDefinedBody>
</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Hold Modify Grant

<SOAP-ENV:Envelope 
        xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
        xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema">

<SOAP-ENV:Body>
  <holdSchema:holdModifyGrantHdr
        xmlns:holdSchema = "http://www.w3.org/2001/08/thp/schemas"
        xsi:schemaLocation="http://www.w3.org/2001/08/thp/schemas/HoldRequest.xsd">
    <holdSchema:modifiedHoldRequest> 
      <holdSchema:holdGrantHdr>
        <holdSchema:baseHeader> 
          <holdSchema:holdHeader>
            <holdID>2B7367E7-6913-4E89-8792-90F1D80EDDDF</holdID>
            <customerID>ABC105</customerID>
            <replyTo>[email protected]</replyTo>
            <comment> Hold modify granted </comment>
          </holdSchema:holdHeader>
        </holdSchema:baseHeader>
        <holdDuration> 3D </holdDuration>
      </holdSchema:holdGrantHdr>
    </holdSchema:modifiedHoldRequest>
  </holdSchema:holdModifyGrantHdr>
  <holdSchema:userDefinedBody>
  </holdSchema:userDefinedBody>
</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Hold Modify Denial

<SOAP-ENV:Envelope 
        xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
        xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema">

<SOAP-ENV:Body>
  <holdSchema:holdModifyDenialHdr
        xmlns: holdSchema = "http://www.w3.org/2001/08/thp/schemas"
        xsi:schemaLocation="http://www.w3.org/2001/08/thp/schemas/HoldRequest.xsd">
    <holdSchema:modifiedHoldRequest> 
      <holdSchema:holdDenialHdr>
        <holdSchema:baseHeader> 
          <holdSchema:holdHeader>
            <holdID>2B7367E7-6913-4E89-8792-90F1D80EDDDF</holdID>
            <customerID>ABC105</customerID>
            <replyTo>[email protected]</replyTo>
            <comment> Modify Hold request denied</comment>
          </holdSchema:holdHeader>
        </holdSchema:baseHeader>
        <reason> Modify Hold request cannot be satisfied </reason>
      </holdSchema:holdDenialHdr>
    </holdSchema:modifiedHoldRequest>
  </holdSchema:holdModifyDenialHdr> 
  <holdSchema:userDefinedBody>
  </holdSchema:userDefinedBody>
</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Hold Cancellation Request

<SOAP-ENV:Envelope 
        xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
        xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema">

<SOAP-ENV:Body>
  <holdSchema: holdCancellationRequestHdr
        xmlns: holdSchema = "http://www.w3.org/2001/08/thp/schemas"
        xsi:schemaLocation="http://www.w3.org/2001/08/thp/schemas/HoldRequest.xsd">
    <holdSchema:customerHold> 
      <holdSchema:holdHeader>
        <holdID>2B7367E7-6913-4E89-8792-90F1D80EDDDF</holdID>
        <customerID>ABC105</customerID>
        <replyTo>[email protected]</replyTo>
        <comment> Cancel the hold</comment>
      </holdSchema:holdHeader> 
    </holdSchema:customerHold>
    <customerReason> 101:No longer interested in the lamps </customerReason>
  </holdSchema:holdCancellationRequestHdr>
  <holdSchema:userDefinedBody>
  </holdSchema:userDefinedBody>
</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Hold Cancellation Response

<SOAP-ENV:Envelope 
        xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
        xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema">

<SOAP-ENV:Body>
  <holdSchema:holdCancellationResponseHdr
        xmlns: holdSchema = "http://www.w3.org/2001/08/thp/schemas"
        xsi:schemaLocation="http://www.w3.org/2001/08/thp/schemas/HoldRequest.xsd">
    <holdSchema:customerHold> 
      <holdSchema:holdHeader>
        <holdID>2B7367E7-6913-4E89-8792-90F1D80EDDDF</holdID>
        <customerID>ABC105</customerID>
        <replyTo>[email protected]</replyTo>
        <comment> Hold cancellation accepted </comment>
      </holdSchema:holdHeader> 
    </holdSchema:customerHold>
  </holdSchema:holdCancellationResponseHdr>
  <holdSchema:userDefinedBody>
  </holdSchema:userDefinedBody>
</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Hold Cancellation Notification

<SOAP-ENV:Envelope 
        xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
        xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema">

<SOAP-ENV:Body>
  <holdSchema:holdCancellationNotificationHdr
        xmlns:holdSchema = "http://www.w3.org/2001/08/thp/schemas"
        xsi:schemaLocation="http://www.w3.org/2001/08/thp/schemas/HoldRequest.xsd">
    <holdSchema:customerHold> 
      <holdSchema:holdHeader>
        <holdID>2B7367E7-6913-4E89-8792-90F1D80EDDDF</holdID>
        <customerID>ABC105</customerID>
        <replyTo>[email protected]</replyTo>
        <comment> Hold cancellation notification </comment>
      </holdSchema:holdHeader>
    </holdSchema:customerHold>
    <cancellationReason> Hold expired </cancellationReason>
  </holdSchema:holdCancellationNotificationHdr>
  <holdSchema:userDefinedBody>
  </holdSchema:userDefinedBody>
</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Hold Status Query Request

<SOAP-ENV:Envelope 
        xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
        xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema">

<SOAP-ENV:Body>
  <holdSchema:holdStatusQueryHdr
        xmlns:holdSchema = "http://www.w3.org/2001/08/thp/schemas"
        xsi:schemaLocation="http://www.w3.org/2001/08/thp/schemas/HoldRequest.xsd">
    <holdSchema:customerHold> 
      <holdSchema:holdHeader>
        <holdID>2B7367E7-6913-4E89-8792-90F1D80EDDDF</holdID>
        <customerID>ABC105</customerID>
        <replyTo>[email protected]</replyTo>
        <comment> Status of above holdID</comment>
      </holdSchema:holdHeader> 
    </holdSchema:customerHold>
  </holdSchema:holdStatusQueryHdr>
  <holdSchema:userDefinedBody>
  </holdSchema:userDefinedBody>
</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Hold Status Query Response

<SOAP-ENV:Envelope 
        xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
        xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema">

<SOAP-ENV:Body>
  <holdSchema:holdStatusResponseHdr
        xmlns:holdSchema = "http://www.w3.org/2001/08/thp/schemas"
        xsi:schemaLocation="http://www.w3.org/2001/08/thp/schemas/HoldRequest.xsd">
    <holdSchema:baseHeader> 
      <holdSchema:holdHeader>
        <holdID>2B7367E7-6913-4E89-8792-90F1D80EDDDF</holdID>
        <customerID>ABC105</customerID>
        <replyTo>[email protected]</replyTo>
        <comment> Status of above holdID </comment>
      </holdSchema:holdHeader> 
    </holdSchema:baseHeader> 
  </holdSchema:holdStatusResponseHdr>
  <holdSchema:holdStatusResponseBody>
    <holdItemsCount> 1 </holdItemsCount> 
    <itemList>
      <holdSchema:statusStructure>
        <holdState>VALID</holdState>
        <itemHeader>
          <holdSchema:holdHeader>
            <holdID>2B7367E7-6913-4E89-8792-90F1D80EDDDF</holdID>
            <customerID>ABC105</customerID>
            <replyTo>[email protected]</replyTo>
            <comment> Status of above holdID </comment>
          </holdSchema:holdHeader>
        </itemHeader>
      </holdSchema:statusStructure>
    </itemList>
  </holdSchema:holdStatusResponseBody>
</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Error Message

<SOAP-ENV:Envelope 
        xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
        xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema">

<SOAP-ENV:Body>
  <holdSchema: holdErrorHdr
        xmlns:thpSchema = "http://www.w3.org/2001/08/thp/schemas"
        xsi:schemaLocation="http://www.w3.org/2001/08/thp/schemas/HoldRequest.xsd">
    <holdSchema:baseHeader> 
      <holdSchema:holdHeader>
        <holdID>2B7367E7-6913-4E89-8792-90F1D80EDDDF</holdID>
        <customerID>ABC105</customerID>
        <replyTo>[email protected]</replyTo>
        <comment> Error Message </comment>
      </holdSchema: holdHeader > 
    </holdSchema:baseHeader >
  </holdSchema:holdErrorHdr>
  <holdSchema:holdErrorBody>
    <holdErrorType>500 </holdErrorType>
    <holdErrorDesc> Invalid status query </holdErrorDesc> 
  </holdSchema:holdErrorBody>
</SOAP-ENV:Body>

</SOAP-ENV:Envelope>