WS-Policy and more

Non-standard WSIT configuration file locations for Metro

Rickard Lundin recently asked this question: "I need to be able [at] "runtime" to choose wsit config file. One way would be to have multiple "WEB-INF/..xml" and add exactly one of them to the jvm classpath."

There are at least two ways to approach that question. The approach we designed the WSIT configuration for is that you know all your services that you are talking to in advance. That is a reasonable assumption since you need to know the structure of the SOAP messages, etc. to talk to a web service anyway. If you already know the service you are going to talk to, you can do the WSIT configuration before deployment. So the first approach boils down to:

Configuring multiple WSIT web services or clients at once

Creating and configuring multiple web services has been designed into WSIT from the beginning. The WSIT tutorial has an extensive example how to configure one web service without the help of NetBeans. The important aspect of this example is that it uses a configuration file named wsit-fromjava.server.AddNumbersImpl.xml. The configuration file is named after the web service implementation class. That makes it very easy to configure multiple web services. Simply add a configuration file for each service.

The web service client is only slightly more complex to configure. A client has no notion of an implementation class. Thus it always searches for the configuration file wsit-client.xml on the class path. So what do you do when you have multiple clients and all pick up the same configuration file? The solution is to simply put the configuration for all clients into the same file. NetBeans actually does that for you already and it is easy to take the same approach manually. NetBeans generates a wsit-client.xml that looks like this:

<?xml version="1.0" encoding="UTF-8"?> 
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/" 
              xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
              name="mainclientconfig">
    <import location="EchoService.xml" namespace="http://service.echo.ws.xml.sun.com/"/>
</definitions>

The actual configuration is contained in the file EchoService.xml. That makes it very easy to configure clients for additional web services. Simply add more import statements to the wsit-client.xml.

Now while the above covers most use cases, we ran into a problem with Open ESB. Open ESB builds composite applications, which ultimately means in our case that it bundles web services inside an application inside a composite application. Consequently, looking up our configuration files from the class path did not work anymore because the files were inside a bundle on the class path. So we had to create a proprietary extension to:

Pass configuration file location into WSIT

Note that the following is an unsupported extension to WSIT and the interfaces may change any time without notice. Moreover,  the same mechanisms are used to pass servlet data into JAX-WS and you are likely introducing unpleasant side-effects if using this when running a web service as a servlet.

On the client side, you need to create a client by using the create(URL wsdlDocumentLocation, QName serviceName, WSService.InitParams properties) method on WSService. The method returns a Service object that you can use like any ordinary web service client. The properties parameter takes a Container that you need to implement and set as parameter. This Container, when invoked with getSPI(Class<ResourceLoader> ResourceLoader.class), has to return an implementation of the ResourceLoader interface. Finally, the ResourceLoader will be invoked by the PolicyConfigParser with getResource("wsit-client.xml"). That is the point where your application can return a URL to the file it wants WSIT to read. Your file does not have to be named wsit-client.xml.

The implementation on the web service side is pretty similar. Instead of WSService you need to use one of the two create methods on WSEndpoint to create your service. All the create methods take a Container as parameter. From there on the implementation is similar to the client. The getResource call will of course be invoked with the name of the server-side configuration file WSIT is looking for.

Tags: GlassFish, WS-Policy, Web Services, Metro, JAX-WS, Project Tango, WSIT

Posted at 07:12PM Feb 14, 2008 by Fabian Ritzmann in Sun  |  Comments[2]