3.3. Step 3: Configuring the deployment in WSDD (and JNDI)

Up to this point, we have written the two most important parts of our stateful Web service: the service interface (WSDL) and the service implementation (Java). However, we still seem to be missing something... How do we actually make our web service available to client connections? Does our Java class simply float around in some sort of mysterious ether? This next step will actually take all the loose pieces we have written up to this point and make them available through a Web services container. This step is called the deployment of the web service.

[Note]

Remember: The "Web Services container" is a catch-all term referring to all the software (SOAP Engine, Application Server, and HTTP Server) we need to make Web services available to clients. This might be a good moment to review Section 1.2.5, “The server side, up close”.

3.3.1. The WSDD deployment descriptor

One of the key components of the deployment phase is a file called the deployment descriptor. It's the file that tells the Web Services container how it should publish our web service (for example, telling it what the our service's URI will be). The deployment descriptor is written in WSDD format (Web Service Deployment Descriptor). The deployment descriptor for our Web service will look like this:

<?xml version="1.0" encoding="UTF-8"?>
<deployment name="defaultServerConfig" 
    xmlns="http://xml.apache.org/axis/wsdd/" 
    xmlns:java="http://xml.apache.org/axis/wsdd/providers/java" 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">

    <service name="examples/core/first/MathService" provider="Handler" use="literal" style="document">
        <parameter name="className" value="org.globus.examples.services.core.first.impl.MathService"/>
        <wsdlFile>share/schema/examples/MathService_instance/Math_service.wsdl</wsdlFile>
        <parameter name="allowedMethods" value="*"/>
        <parameter name="handlerClass" value="org.globus.axis.providers.RPCProvider"/>
        <parameter name="scope" value="Application"/>
        <parameter name="providers" value="GetRPProvider"/>
        <parameter name="loadOnStartup" value="true"/>
    </service>

</deployment>
[Note]

This file is $EXAMPLES_DIR/org/globus/examples/services/core/first/deploy-server.wsdd.

Let's take a close look at what all this means...

The 'service name'

<service name="examples/core/first/MathService" provider="Handler" use="literal" style="document">

This specifies the location where our web service will be found. If we combine this with the base address of our Web Services container, we will get the full URI of our web service. For example, if we are using the GT4 standalone container, the base URL will probably be http://localhost:8080/wsrf/services. Therefore, our service's URI would be:

http://localhost:8080/wsrf/services/examples/core/first/MathService

className

<parameter name="className" value="org.globus.examples.services.core.first.impl.MathService"/>

This parameter refers to the class which implements the service interface (in our case, MathService from the previous section).

The WSDL file

<wsdlFile>share/schema/examples/MathService_instance/Math_service.wsdl</wsdlFile>

The wsdlFile tag tells the Web Services container where the WSDL file for this service can be found. Notice how there's a "_service" at the end of the filename. This is not a typo. This WSDL file (Math_service.wsdl) will be generated automatically by a GT4 tool when we compile the service.

The operation providers

For now, you can safely ignore the providers parameter, as we will not be using it in this example.

Load on startup

<parameter name="loadOnStartup" value="true"/>

This parameter allows us to control if we want the service to be loaded as soon as the container is started. Since our service has a single resource, it is usually best to load it at startup.

The common parameters

<parameter name="allowedMethods" value="*"/>
<parameter name="handlerClass" value="org.globus.axis.providers.RPCProvider"/>
<parameter name="scope" value="Application"/>

These are three parameters which we'll see in every web service we program and are better left untouched.

3.3.2. The JNDI deployment file

This file barely comes into play in this example since we're implementing our service the simplest possible way. However, we still have to include this file, but we need you to take a little leap of faith at this point and just accept that we need the file "because we need it". In the next chapter we will introduce the concept of resource homes and we will explain this file in more detail (we will also revisit the file seen in this example).

So, the JNDI deployment file looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<jndiConfig xmlns="http://wsrf.globus.org/jndi/config">

<service name="examples/core/first/MathService">
	<resource name="home" type="org.globus.wsrf.impl.ServiceResourceHome">
	<resourceParams>

		<parameter>
			<name>factory</name>
			<value>org.globus.wsrf.jndi.BeanFactory</value>
		</parameter>

	</resourceParams>
		
	</resource>
</service>

</jndiConfig>
[Note]

This file is $EXAMPLES_DIR/org/globus/examples/services/core/first/deploy-jndi-config.xml.