Using External Policies

In Manual Web Service Configuration In From Java Case you saw how to manually configure Java web service endpoint. This entry describes how to use external policies for endpoint configuration instead of including policy assertions directly into WSIT config file. The scenario enables you to store and maintain all your policies at one central place...


To be able to reproduce following steps you will need an installation of glassfish v2. (I was using gf v2 b46)
I presume, your GlassFish instance is running and has $AS_HOME base directory.

Step 1. Create And Publish Your "Policy Repository"

The easiest way how to do that is to publish them as a static XML file:
$ vim $AS_HOME/domains/domain1/docroot/policies.xml

Content of your newly created "policy repository" could be as follows:
<?xml version="1.0" encoding="UTF-8"?>
<wsp:Policy wsu:Id="Class1BindingPolicy">

This way your "policy repository" should be available at http://localhost:8080/policies.xml and you have defined just one policy Class1BindingPolicy which could be referenced as http://localhost:8080/policies.xml#Class1BindingPolicy

Step 2. Create Your Endpoint

The endpoint is created the same way as in Manual Web Service Configuration In From Java Case
For sake of clarity I will repeat the steps here:

Creating the endpoint implementation class:

$ mkdir work-wspol ; cd work-wspol ; vim Stock.java
package org.example;
import javax.jws.WebMethod;
import javax.jws.WebService;
@WebService(serviceName="StockSvc", portName="StockPort", targetNamespace="http://example.org")

public class Stock {
public boolean itemAvaiable (String itemId, int amount) {
return Math.random() > 0.6;

Compiling it:

$ mkdir -p WEB-INF/classes; javac -cp $AS_HOME/lib/javaee.jar -d WEB-INF/classes Stock.java

And creating a wsit config file skeleton:

$ $AS_HOME/bin/wsgen -wsdl -cp WEB-INF/classes org.example.Stock ; mv StockSvc.wsdl WEB-INF/wsit-org.example.Stock.xml
Now remove useless lines from the skeleton:
$ vim WEB-INF/wsit-org.example.Stock.xml
Lines to remove:
<xsd:import namespace="http://example.org" schemaLocation="StockSvc_schema1.xsd"/>

<soap:address location="REPLACE_WITH_ACTUAL_URL"/>

Step 3. Attach The External Policy

Attaching an external policy simply means adding a PolicyReference to the config file.
In our case, we will only add the following line to our wsit config file:
<wsp:PolicyReference xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"

So that our config file will look like:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<definitions targetNamespace="http://example.org" name="StockSvc"
<message name="itemAvaiable">
<part name="parameters" element="tns:itemAvaiable"/>
<message name="itemAvaiableResponse">
<part name="parameters" element="tns:itemAvaiableResponse"/>
<portType name="Stock">
<operation name="itemAvaiable">
<input message="tns:itemAvaiable"/>
<output message="tns:itemAvaiableResponse"/>
<binding name="StockPortBinding" type="tns:Stock">
<wsp:PolicyReference xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"

<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
<operation name="itemAvaiable">
<soap:operation soapAction=""/>
<soap:body use="literal"/>
<soap:body use="literal"/>
<service name="StockSvc">
<port name="StockPort" binding="tns:StockPortBinding">

Step 4. Deploying The Newly Created And Configured Endpoint

You should now be able to deploy the endpoint in one shot by:
$ jar cvf $AS_HOME/domains/domain1/autodeploy/stock.war WEB-INF

Closer View

If you look at the published WSDL of our endpoint, you will probably notice that
original external reference was replaced by a local one and the policy definition was included into the wsdl.
It means that consumer of your endpoint does not need to have access to original "policy repository". On the other hand, if you forbid access to your "policy repository" from outside, described mechanism will still work! So what? You can store sensitive information in your policy repository (keystore locations, passwords, etc.). Such information will be properly used for configuring your endpoints and safely removed from published WSDLs. It means you can maintain such a sensitive information at just one place and still be able to use it for configuring lots of your endpoints.

Join the discussion

Comments ( 3 )
  • mark wiseman Monday, July 14, 2008

    Links are broken... I'm interested in what the internally referenced wsdl looks like. Can all external references be changed to internal, for the case of intranet-only web services in a secure environment?

  • Jakub Tuesday, July 15, 2008

    Mark, i have just published the wsdl at http://blogs.sun.com/japod/resource/wspol/StockSvc.wsdl

    (btw. the link in the original post is not broken. It was meant like you reproduce the steps as you read and finally have the service and it's wsdl published at your machine)

  • Andy Basu Tuesday, April 28, 2009

    Can you attach a ws-securitypolicy to an operation instead of the service binding? Whenever I tried that in a tomcat container I get a policy exception? According ws-policy doc I should be able to attach a policy simply to an operation and not the whole portType...

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha

Integrated Cloud Applications & Platform Services