Creating a RPC transport web service

This recipe explains how to annotate a web service in order to support the Remote Procedure Call (RPC) transport style. Using the RPC style, the body part of the SOAP message may contain only one element that is named after the operation. All parameters are represented as child elements of this element. The name of the child element must match the name of the parameter and the type of the element must match the type of the parameter.

Getting ready

For this recipe, we will use the example from the Creating a document transport web service recipe.

How to do it…

In the JDeveloper project, open the BookLibraryImpl.java file. Search for the @SOAPBinding annotation.

Now change the style attribute to SOAPBinding.style.RPC as shown in the following code:

@WebService(name = "BookLibrary", serviceName = "BookLibraryService", portName = "BookLibraryPort")
//@SOAPBinding(style = SOAPBinding.Style.DOCUMENT)
@SOAPBinding(style = SOAPBinding.Style.RPC)

How it works…

The RPC transport style presents an alternative way for transferring data from the client towards the web service. The main difference from the document transport style is how parameters are formatted. Remember, with the document transport style, the parameters are defined through the schema which enables greater flexibility in case the web service methods are changed. On the other hand, the RPC transport style maps the input and output parameters according to the method definitions. The web service is presented as an application where a client delivers the parameters and not the content as is the case with the document transport style.

Let's examine the difference between the document and RPC transport styles. First, let's look at the document transport style for the reserveBook operation. The request and response message definitions are as follows:

<wsdl:message name="reserveBookInput">
    <wsdl:part name="parameters" element="tns:reserveBook"/>
</wsdl:message>
<wsdl:message name="reserveBookOutput">
    <wsdl:part name="parameters" element="tns:reserveBookResponse"/>
</wsdl:message>

The elements tns:reserveBook and tns:reserveBookResponse are defined in the corresponding schema:

<xsd:complexType name="reserveBook">
  <xsd:sequence>
    <xsd:element name="arg0" type="xsd:int"/>
    <xsd:element name="arg1" type="xsd:int"/>
  </xsd:sequence>
</xsd:complexType>
<xsd:element name="reserveBook" type="tns:reserveBook"/>
<xsd:complexType name="reserveBookResponse">
  <xsd:sequence/>
</xsd:complexType>
<xsd:element name="reserveBookResponse" type="tns:reserveBookResponse"/>

If we now check the definitions for the RPC transport style of the same operation, we will see the following definitions for the request and response messages:

  <wsdl:message name="reserveBookInput">
    <wsdl:part name="arg0" type="xsd:int"/>
    <wsdl:part name="arg1" type="xsd:int"/>
  </wsdl:message>
  <wsdl:message name="reserveBookOutput"/>
  <wsdl:message name="borrowBookInput">
    <wsdl:part name="arg0" type="xsd:int"/>
    <wsdl:part name="arg1" type="xsd:int"/>
  </wsdl:message>

There is no further schema definition because input parameters are directly mapped to the messages. So, instead of communication via content as we do with the document transport style, we communicate through direct mapping of operations parameters.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset