You are on page 1of 2

The Service class

At the heart of the client side JAX-RPC classes lies the javax.xml.rpc.Service class, as
shown below, which acts as a client side representation of the web service:

The Service class is effectively a factory for the Call object, which in turn
encapsulates the mechanisms to call a Service Endpoint (a web service
implementation).
Using Proxies
Remember that a web service exposes its functionality to clients in a WSDL (Web
Services Description Language) document, which essentially reveals the XML
schema for the web service and shows which messages are mapped to which ports.
This WSDL is typically generated from language interface files – for instance, you
may have a web service implementing the Java interface CalculatorIf.
<?xml version="1.0" encoding="UTF-8"?>
<configuration xmlns=
"http://java.sun.com/xml/ns/
jax-rpc/ri/config">
<service
name="MyCalculatorService"
targetNamespace="urn:qatraining"
typeNamespace="urn: qatraining "
packageName="calculator">
<interface
name="calculator.CalculatorIF"/>
</service>
</configuration>
This will create a number of files as follows:
 The Stub class, which will have the name CalculatorIF_Stub, representing the
web service proxy and implementing the CalculatorIF interface.
 The Service implementation class MyCalculatorService_Impl, which has a
single method, getCalculatorIFPort, which returns an instance of the Stub proxy class.
Dynamic Proxy Generation
When you are moving into the collaborative area of web services, and you are using a
partner's web service to perhaps perform some B2B function, then it is unlikely you
will have the language-specific interfaces used to create the web service.
Dynamic Invocation Interface
Perhaps the most flexible way to call a web service is to use Dynamic Invocation
Interface (DII). With DII you can discover a web service dynamically, possibly by
looking it up in a UDDI registry. This would return a set of ServiceBindings, as
shown below:

You might also like