The WAR files are in the root directory of the MSS_WebService.ear file. Within each WAR file, the WSDL file is located in the WEB-INF/wsdls directory. The schemas are also available in the mss_webservice_schemas.jar file. You find this JAR file as a deliverable with the MSS installer. Table 1-2 provides the WSDL and WAR file names for each web service:

The WSDL definitions at the beginning of the WSDL file define the web service as being deployed using the SOAP 1.1 protocol over HTTP.

See the following websites for more information about WSDL 1.1 and SOAP 1.1:

• https://www.w3.org/TR/wsdl

• https://www.w3.org/TR/2000/NOTE-SOAP-20000508/

See "About MSS Web Service Standards and Specifications" for more information about the standards that apply to the MSS Web Services.

Example 1-1 shows the definitions section of the OrderAPI.wsdl file.

<wsdl:definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
                  xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
                  xmlns:s="http://www.w3.org/2001/XMLSchema"
                  xmlns:s0="http://www.openuri.org/"
                  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
                  xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
                  xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
                  targetNamespace="http://www.openuri.org/">

For each MSS Web Service, you can access the WSDL with a URL location.

Table 1-3 provides the URL locations where:

• mssHost is the name of the host on which MSS is installed

• port is the port number of the machine on which MSS is installed

http://mssHost:port/MssWS/customer/CustomerAccount?WSDL

http://mssHost:port/MssWS/events/IntegrationEvent?WSDL

http://mssHost:port/MssWS/inventory/Inventory?WSDL

http://mssHost:port/MssWS/order/Order?WSDL

http://mssHost:port/MssWS/activation/ServiceActivationData?WSDL

http://mssHost:port/MssWS/soa/Soa?WSDL

In the WSDL file, the bindings define the protocol details and message formats for the web service operations. Example 1-2 shows a portion of the WSDL file with the binding definition of the addTaskJeopardyRequest operation.

<wsdl:binding name="OrderSoap" type="s0:OrderSoap">
    <soap:binding transport="http://schemas.xmlsoap.org/soap/http"
                  style="document"/>
    <wsdl:operation name="addTaskJeopardyRequest">
      <soap:operation soapAction="http://www.openuri.org/addTaskJeopardyRequest"
                      style="document"/>
      <wsdl:input>
        <soap:body use="literal"/>
      </wsdl:input>
      <wsdl:output>
        <soap:body use="literal"/>
      </wsdl:output>
      <wsdl:fault name="WSException">
        <soap:fault name="WSException" use="literal"/>
      </wsdl:fault>
    </wsdl:operation>
</wsdl:binding>

Each WSDL file defines a namespace to avoid naming conflicts. The namespace definition appears after the WSDL definitions section.

You use the namespace to determine the schema file location of the schema reference. Example 1-3 shows how a namespace defined in the WSDL correlates to the supporting schema files.

In this example, the Order Web Service WSDL file named OrderAPI.wsdl defines and references the ord namespace. This excerpt shows momAddTaskJeopardyRequest has a namespace designation and how the namespace is defined:

.
.
.
<s:schema xmlns:ord="http://xmlns.oracle.com/communications/mss/OrderManagementAPI">

<s:import namespace="http://xmlns.oracle.com/communications/mss/OrderManagementAPI"
      schemaLocation="../schemas/OrderManagementAPI.xsd"/>
.
.
.
<s:element name="addTaskJeopardyRequest">
  <s:complexType>
    <s:sequence>
      <s:element ref="ord:momAddTaskJeopardyRequest"/>
    </s:sequence>
  </s:complexType>
</s:element>
.
.
.

The addTaskJeopardyRequest element declaration tells you that momAddTaskJeopardyRequest is defined in the schema file that supports the specified namespace. A search for the specified namespace reveals that the ord namespace represents the OrderManagementAPI schema file.

After you determine that the OrderManagementAPI.xsd schema file defines the XML structure that the WSDL file references, you can navigate through the schema files to determine child XML structures.

Refer to the following website for more information on namespaces:

https://www.w3.org/TR/REC-xml-names/

The WSDL file defines the web service and its operations. It also defines the input, output and fault messages of each operation. MSS WSDL operations follow the request-response or round-trip pattern. When the client sends a request message to the web service, the operation either sends a response message back or the operation sends a fault message back to the client for an error.

In the WSDL file, each service is bound to a port. For example, in the OrderAPI.wsdl file, the Order Web Service is bound to the OrderSoap port. Example 1-4 shows the definition of the Order service and the port name.

<wsdl:service name="Order">
  <wsdl:port name="OrderSoap" binding="s0:OrderSoap">
    <soap:address location="http://localhost:7001/MssWS/order"/>
  </wsdl:port>
</wsdl:service>

The Order service and port declaration reference the portType through the OrderSoap definition. The portType element combines multiple message elements to define the list of web service operations and their parameters.

Example 1-5 demonstrates the following aspects of the portType definition in the Order Web Service:

• The portType element definition of the name as OrderSoap

• The definition of addTaskJeopardyRequest as a round-trip operation

• The declaration of the input, output and fault message types for addTaskJeopardyRequest

<wsdl:portType name="OrderSoap">
  <wsdl:operation name="addTaskJeopardyRequest">
    <wsdl:input message="s0:addTaskJeopardyRequestSoapIn"/>
    <wsdl:output message="s0:addTaskJeopardyRequestSoapOut"/>
    <wsdl:fault message="s0:WSException" name="WSException"/>
  </wsdl:operation>
.
.
.
</wsdl:portType>

Message definitions determine the input and output parameters for the operation. Example 1-6 shows a WSDL excerpt with the message definitions and their respective elements.

  <wsdl:message name="addTaskJeopardyRequestSoapIn">
    <wsdl:part name="parameters" element="s0:addTaskJeopardyRequest"/>
  </wsdl:message>
  <wsdl:message name="addTaskJeopardyRequestSoapOut">
    <wsdl:part name="parameters" element="s0:addTaskJeopardyRequestResponse"/>
  </wsdl:message>
  <wsdl:message name="WSException">
   <wsdl:part name="fault" element="s0:WSException"/>
  </wsdl:message>

Table 1-4 summarizes the definitions in Example 1-5 and Example 1-6 to list the message types, messages and elements for the addTaskJeopardyRequest operation.

The details of the element for each message are defined in declarations in the WSDL file. For example, the input request, output response, and exception/fault elements listed in Table 1-4 are defined by the declarations shown in Example 1-7.

      <s:element name="addTaskJeopardyRequest">
        <s:complexType>
          <s:sequence>
            <s:element ref="ord:momAddTaskJeopardyRequest"/>
          </s:sequence>
        </s:complexType>
      </s:element>
      <s:element name="addTaskJeopardyRequestResponse">
        <s:complexType>
          <s:sequence>
            <s:element ref="ord:addTaskJeopardyResponse"/>
          </s:sequence>
        </s:complexType>
      </s:element>
      <s:element name="WSException">
        <s:complexType>
          <s:sequence>
            <s:element name="faultCode" type="s:string" minOccurs="0"/>
            <s:element name="faultString" type="s:string" minOccurs="0"/>
          </s:sequence>
        </s:complexType>
      </s:element>

The elements include references to the locations in schema files where they are fully defined. The references include namespaces that you use to locate the schema file for each element. For example, the namespace ord was defined earlier to point to the OrderManagementAPI.xsd file.

The schema files can themselves include references to other schema files.

Refer to "About Namespaces" for more information on namespaces, and "About Schema Files" for more information on schema files.

Numerous schema files support the MSS Web Services. Within the WAR files, you find the schema files located in the WEB-INF/wsdls directory. The schemas are also available in the mss_webservice_schemas.jar file. You find this JAR file as a deliverable with the MSS installer.

These schemas are categorized as common schemas, entity schemas, data schemas, and API schemas. The entity, data, and API schema files are different for each web service.

Identical common schema files are included in the WAR files for all web services. The following are the common schema files:

• Common.xsd

• Core.xsd

• Customer.xsd

• DataTypes.xsd

• Location.xsd

• Resource.xsd

• Service.xsd

Refer to the individual web service chapters for more information about schema files.

The reference chapters for the web services include sections for the request and response documentation. For each operation's request and response, one or more tables describe the primary XSD elements and types. An operation can have multiple tables describe complex payloads.

These tables enable you to navigate the request or response in the following ways:

• They provide an overall view of the payload.

• They aid in locating the request or response definitions and their XSD file location.

• They show you XSD definitions, for instance, whether they are elements or a complex types.

The table describing a request contains the following information:

• The input request element defined in the first row.

• A row for each element, describing how the element or complexType is defined in the XSD, its type, and the file name where it is defined.

• A row for each type listed in the table, placed following the row in which the type is first mentioned.

Table 1-5 is an example of the request elements and complex types for the addTaskJeopardyRequest operation.

In this example, addTaskJeopardyRequest is the name value in first row. This addTaskJeopardyRequest element is defined as the input message element for the operation. It is defined as an element and is located in the OrderAPI.wsdl file. (See Example 1-6 for an excerpt of this input message definition.)

The type for the addTaskJeopardyRequest element is momAddTaskJeopardyRequest. This type is listed in the second row and similarly described.

This pattern continues until one of the following is true:

• The item referenced is a core or common schema item.

• The item referenced is a series of fields where the series contains simple types or complex types that are located in the same schema file.

To get specific information about fields, you consult the XSD schema file itself. For the AddTaskJeopardyRequestValueType, you find the field information in the OrderManagementData.xsd file. Annotations in the file describe the field details of AddTaskJeopardyRequestValueType.

Similarly, response messages are defined in tables that have the same format and layout as the request information. Optionally, the response section includes a list of error conditions that can be thrown by the operation.

Table 1-6 shows an example of the possible error messages for the addTaskJeopardyRequest operation.