Tuesday Aug 19, 2008

Metro 1.3

Approximately two weeks ago we released Metro 1.3. There is not much to say from the WS-Policy perspective. It's been mostly a bugfix release and there haven't been any significant bugs to fix in policy.

One of our users noted an invalid reference in the NetBeans project settings for the Metro 1.3 source code: nbproject for rt build depends on missing xmldsig.jar. The NetBeans project setup has been fixed on the trunk of course but if you need to work with the source code for Metro 1.3, do the following:

  • Open the WSIT Runtime project in NetBeans.
  • Right-click on the project in the Projects navigator and select Properties.
  • Select the Libraries category.
  • In the list of compile-time libraries, search for the entry "Broken reference: xmldsig.jar". Select that reference and click the Remove button.
  • Press OK and allow NetBeans to regenerate the build-impl.xml.

That's it. The cause for this slip was that we are using a new version of the xmlsec.jar that already contains a copy of the xmldsig.jar.

Friday Jul 04, 2008

Printing SOAP messages II

In Printing SOAP messages I was describing a proprietary feature how to monitor SOAP responses and requests on a Metro web service client. Not quite unexpectedly, we got some requests for similar functionality on the server. Marek therefore went and refactored the existing implementation somewhat to enable you to listen to SOAP messages on the server as well. This means that the packages for the client changed a little as well. I will first describe what you need to do with the client if you are using the current Metro builds. Then I will describe what you can do on the server now. Check Marek's blog for a description of some more features that he implemented and that make monitoring on the server more feasible.

Printing SOAP messages on the client

Very little changed actually compared to Printing SOAP messages. The package name is different however and I am repeating the code from the previous article with the new package names:

import com.sun.xml.ws.messagedump.MessageDumpingFeature;

    // Prepare to plug in the code that allows to read SOAP messages
    MessageDumpingFeature messageDumper = new MessageDumpingFeature();

    // Instantiate the web service client
    YourService service = new YourService();

    // Plug in the SOAP message dumper
    YourPort port = service.getYourServicePort(messageDumper);

    // Invoke the web service
    YourResult result = port.yourmethod(yourparameter);

    // Read the SOAP messages that were exchanged
    String request = messageDumper.nextMessage();
    String response = messageDumper.nextMessage();

Printing SOAP messages on the service

This task is a little less straight-forward and the example implementation I am showing is somewhat restricted. Usually, you implement a web service implementation class with some operations. You can access the MessageDumpingFeature inside those operations. That means however that that code will only be able to see the SOAP request that came in. The SOAP response has not been generated at that point in time and you do not have access to it. You will however see the SOAP response to the previous request. There are some ways to work around these restrictions and Marek will discuss them in the coming days. I will only show the simple case here where you are accessing the MessageDumpingFeature inside an operation:

import com.sun.xml.ws.api.WSBinding;
import com.sun.xml.ws.api.message.Packet;
import com.sun.xml.ws.api.server.WSEndpoint;
import com.sun.xml.ws.api.server.WSWebServiceContext;
import com.sun.xml.ws.messagedump.MessageDumping;
import com.sun.xml.ws.messagedump.MessageDumpingFeature;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;
import javax.annotation.Resource;
import javax.xml.ws.WebServiceContext;

 \* The WebService annotation announces to JAX-WS that this is a web service implementation class.
 \* The second annotation enables the message dumping feature.
public class TestService {

    WebServiceContext context;

     \* A web service operation
    @WebMethod(operationName = "echo")
    public String echo(@WebParam(name = "text") final String text) {
        if (context != null) {

            // We need to get access to the MessageDumpingFeature object. This is a little tricky,
            // we need to work our way through some JAX-WS implementation classes.
            WSWebServiceContext wsContext = (WSWebServiceContext) context;
            Packet packet = wsContext.getRequestPacket();
            WSEndpoint endpoint = packet.endpoint;
            WSBinding binding = endpoint.getBinding();

            // Got it finally
            MessageDumpingFeature messageDump = binding.getFeature(MessageDumpingFeature.class);
            if (messageDump != null) {

                // The first time this method is invoked, it will return the SOAP request. All other invocations will
                // return the SOAP response of the previous invocation.
                String previousResponse = messageDump.nextMessage();

                // The first time this method is invoked, it will return null. All other invocations will return the
                // current SOAP request.
                String request = messageDump.nextMessage();

        // This is the actual business logic. In this case it is a very simple operation.
        return text;

Tags: , , , ,

Friday Jun 27, 2008

Printing SOAP messages

Metro has a (proprietary, may change at any time) feature that provides read access to the SOAP messages that a client exchanges with a web service. That allows to display the SOAP messages to users or log them for diagnostic purposes. Metro can be configured extensively to log SOAP messages and other properties, see http://blogs.sun.com/arungupta/entry/message_logging_in_wsit_updated, but with this feature it is possible to get the content of SOAP messages at run-time and process them with your own code any way you like.

This feature hinges on the use of the internal class com.sun.xml.ws.assembler.MessageDumpingFeature. It is very simple to use. Here is some sample code:

import com.sun.xml.ws.assembler.MessageDumpingFeature;

    // Prepare to plug in the code that allows to read SOAP messages
    MessageDumpingFeature messageDumper = new MessageDumpingFeature();

    // Instantiate the web service client
    YourService service = new YourService();

    // Plug in the SOAP message dumper
    YourPort port = service.getYourServicePort(messageDumper);

    // Invoke the web service
    YourResult result = port.yourmethod(yourparameter);

    // Read the SOAP messages that were exchanged
    String request = messageDumper.nextMessage();
    String response = messageDumper.nextMessage();

The Strings request and response will hold the SOAP messages that were exchanged in clear text. The same approach works with a dispatch client as well.

Tags: , , , ,

Thursday May 22, 2008

Using Metro With Spring

The question on how to configure/deploy/use Metro, i.e. JAX-WS and the WS-\* interoperability features, with Spring is coming up quite frequently. I wrote up a set of instructions with screenhots etc. how to do it: https://metro.dev.java.net/guide/#springa.

The instructions are based on the information provided by the JAX-WS Commons Spring project.

Tags: , , , , ,

Tuesday May 20, 2008

WS-Policy in Metro 1.2

Metro 1.2, our Java web services stack, was released right before JavaOne. Our support for WS-Policy has been very stable and we had to do very few bug fixes only. Indeed I am aware of only two:

Both are not even real bugs but features. The first one allows our underlying transport implementation to manipulate WSDL in ways it hasn't been able to do previously. The other bug removes some legacy code that was trying to load a file named wsit.xml to configure a service instead of wsit-name.of.endpoint.implementation.class.xml. This code had been lingering from before we released WSIT 1.0.

Tags: , , , ,

Monday Apr 21, 2008

Metro Hands-on Lab at JavaOne 2008 completely booked

I am being told that the hands-on lab for Metro at JavaOne 2008 is already completely booked. That is certainly a motivator for us to make sure you get the most out of this lab. Hope to see you there, and if you did not get in, try to stop by at the venue, there usually are some no-shows and I believe they will let in people from a waiting queue instead.

Tags: Web Services, Metro, JavaOne

JavaOne 2008

Thursday Apr 17, 2008

Metro Hands-on Lab at JavaOne 2008

Carol McDonald, Martin Grebac and me have developed a hands-on lab for Metro at JavaOne 2008. At the hands-on lab you bring your own laptop and can try out Metro in practice. We have a script with screenshots etc. that you can work through to familiarize yourself with Metro. Carol and I will talk you through the lab. There will be proctors who can help should you have any questions or difficulties. We hope to see you there. I am sure it will be worth your while, the lab involves kittens! (No animals are going to be harmed nor were they harmed when developing the lab and writing this blog.) You can find out more about the lab here: https://www28.cplan.com/cc191/session_details.jsp?isid=296941&ilocation_id=191-1&ilanguage=english

The title of the lab is "Metro: Try Out Simple and Interoperable Web Services". Session ID is 3410. The lab takes place on Tuesday, 10:50 - 12:50. I don't know exactly what room it will be, please check the JavaOne program once you have registered. Here is the complete abstract:

Metro is a high-performance, extensible, easy-to-use web service stack. You can use it for every type of web service, from simple to reliable, secured, and transacted web services that interoperate with .NET services. Metro bundles stable versions of the JAX-WS (Java™ API for XML Web Services) reference implementation and WSIT (Web Services Interoperability Technology).

JAX-WS is a fundamental technology for developing SOAP-based and RESTful Java technology-based web services. WSIT enables secure, reliable interoperability between Java technology-based web services and Microsoft’s Windows Communication Foundation.

This Hands-on Lab starts by developing a simple Metro web service and showing how to enhance this web service with Metro features such as reliability and security. The next part of the lab enables a web service client with Metro security features and has it interoperate with the previously built service. The lab shows the ease of development the NetBeans™ 6.0 release provides for achieving this.

The lab uses the NetBeans 6.0 release to modify and configure both the web service and the client, using Sun’s GlassFish™ project application server as the container. The lab uses WS-Reliability and WS-Security as examples of Metro’s secure, reliable features.

The lab comprises the following sections:

Introduction to Metro
  • Develop and deploy a basic catalog web service to return a list of catalog items
  • Test the web service, using the Tester application provided by the GlassFish project
Metro Reliability
  • Enable reliability on the catalog web service, and examine the messages
  • Develop and deploy a Metro client for the catalog web service, and configure the client for reliable access to the web service
Metro Security
  • Enable security on the catalog web service, and examine the messages
  • Configure the Metro client for the catalog web service (from the previous exercise) for secure access to the secure web service

Prerequisites: some understanding of Servlets, XML, and SOAP

At JavaOne, this lab will be presented in Hall E (Room# 132).

Please bring your laptops to this lab as there no machines provided in this room.

System requirements:
  • Supported OS: Windows 2000/XP, Solaris 10/11, Linux
  • Memory requirement: 768MB minimum, 1GB recommended
  • Disk space requirement: 300 MB

Software requirements:

Also please make sure to install the following software prior to coming to this lab:
  • JDK 5.0 or 6
  • NetBeans 6.0.1 with Web & Java EE pack
  • GlassFish V2 UR1
Tags: Web Services, Metro, JavaOne
JavaOne 2008

Thursday Feb 14, 2008

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/" 
    <import location="EchoService.xml" namespace="http://service.echo.ws.xml.sun.com/"/>

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: , , , , , ,

Monday Feb 11, 2008

Policy code fully integrated again

As I explained in my last blog entry, we moved the policy core code with support for WS-Policy into a separate workspace on java.net several weeks ago: https://policy.dev.java.net/. Since late January that code has been successfully reintegrated into Metro. It was a very smooth process indeed. I set up a build job to create a policy.jar with Maven 2. Then I removed the policy core code from the Project Tango code base and added the policy.jar to the compile class path. The builds have been working flawlessly ever since. You do not actually notice any difference from the outside because the policy.jar like all other run-time libraries for Metro is repackaged in Metro's webservices-rt.jar.

One final step that is still outstanding and that we will realize with JAX-WS 2.2 remains. Right now Project Tango still contains all policy code that has a dependency on JAX-WS. That code will be moved into JAX-WS 2.2 and out of Project Tango entirely. This will allow us to support e.g. WS-Addressing policy assertions directly from JAX-WS without the addition of Project Tango.

Tags: , , , , , ,

Monday Jan 14, 2008

New workspace for policy

We are currently working on moving the existing policy code out of Project Tango and into a separate workspace. This open source project is hosted as a part of the Metro community within GlassFish on java.net. The new workspace will allow us to do two things:

  • Enable direct support of WS-Policy in JAX-WS. JAX-WS will be able to read and generate e.g. WS-Addressing policy assertions without the addition of the Tango code. Essentially, we are moving up the policy code in the Metro stack from Tango to a base library.
  • Pursue experimental APIs, policy languages, etc. This workspace gives us a sandbox to work on new ideas and concepts.

The web site is already fully operational and the policy base code checked in. We are now working on reintegrating that code into the Metro stack.

Tags: , , , , , ,

Friday Dec 21, 2007

WS-Policy in Metro 1.0.1, 1.1 and GlassFish V2 UR1

There has been quite a flurry of release activities this week. We had Metro 1.0.1 and Metro 1.1. Metro 1.0.1 is included with the freshly released GlassFish V2 UR1. For more details about Metro and the releases, see e.g. Vivek Pandey's blog. Our WS-Policy implementation in the context of Project Tango / Web Services Interoperability Technology is an integral part of the Metro stack.

So what is new in WS-Policy for Metro 1.0.1? We really didn't find any severe bugs we needed to fix, i.e. the WS-Policy implementation has no significant changes over Metro 1.0. The same goes for Metro 1.1. Well, there was one bug fix, issue #654: @Addressing annotation does not generate WS-Addressing policy assertions. In practice, this bug had no real practical repercussions because the addressing implementation would be enabled by the annotation anyway.

The one new and exciting feature is that the Metro 1.1 runtime now supports WS-Policy 1.5! We had very successful tests with our implementation at the W3C interop test rounds in spring already and now we finally have proper support in the product. Marek did virtually all the work implementing that feature and it has worked smoothly ever since. Note that our tooling still generates WS-Policy 1.2 expressions to maintain backwards compatibility.

Tags: , , , , , ,

Get GlassFish V2 UR1

Tuesday Sep 18, 2007

WS-Policy in Metro

After almost two years of work, I am very pleased that our code has been released as part of the Metro Web Services stack yesterday! Jakub, Marek and me were responsible for the WS-Policy implementation in the run-time, Martin for tooling. Our implementation provides support for WS-Policy and WS-PolicyAttachment 1.2. It is an open source implementation and among others is built into GlassFish v2.

Our implementation has been designed to work invisibly in the background. The only time you will notice WS-Policy is when policy expressions are included in the WSDL that JAX-WS is generating at run-time. There are no APIs that you need to bother with, you only write ordinary JAX-WS code. You do not need to compile stubs to make use of our WS-Policy implementation, the configuration is picked up at deploy/run-time. NetBeans is providing extensive support to generate the necessary configuration.

In the mean time, we are of course working full swing on the next version already. We have a nice list of features that we plan on supporting in the future, e.g. support for WS-Policy 1.5, better policy enforcement, easier configuration, etc.


Friday Sep 07, 2007

WS-Policy 1.5 published as a W3C recommendation

A few days ago, WS-Policy 1.5 was published as a standard by the W3C. Check out the press release for the relevant links. Monica Martin and me have been active members of the working group and I have been impressed by Monica's capacity and dedication to creating standards of high quality.

We are actively working on support for WS-Policy 1.5 in Project Tango. You can already see our work in action on our interop test site.


Monday Jun 18, 2007

WSIT with a Java SE endpoint

The JAX-WS RI is supporting an Endpoint API that allows you to implement a web service just in plain Java without the need for a Servlet or EJB container. While we don't explicitly test WSIT with this API, it is still working just fine with it. You just need to take into account a few caveats.

Here is some sample web service code. It does not differ in any way from any other JAX-WS web service:

import javax.jws.WebService;

public class MyService {

public String hello(final String text) {
return text;


Since you don't have a container, you will need to write a little bit of code to start a server that can host the web service. This code is ripped right off the Endpoint API documentation:

import javax.xml.ws.Endpoint;

public class Main {

private static final int PORT = 58888;

public static void main(String[] args) {
Endpoint endpoint = Endpoint.create(new MyService());
endpoint.publish("http://localhost:" + PORT + "/");

You will still need to generate the portable artifacts of your web service before you run it. See the JAX-WS RI User Guide for details.

So far all we have is an ordinary JAX-WS web service. If you are running Java 6, please remember that you need to put the API library into an endorsed directory, otherwise the JAX-WS 2.0 APIs included in Java 6 will override the JAX-WS 2.1 APIs that we require. Put webservices-api.jar into an endorsed directory if you are running Java 6. At runtime you will need webservices-rt.jar and webservices-extra.jar on the classpath and to generate the portable artifacts you need webservices-tools.jar.

So, this was still all plain JAX-WS. All that you need to do to unleash WSIT is provide a configuration file and put it into the META-INF directory of your JAR (or if you have not jared up your code yet, put it in a META-INF directory on your classpath.) Writing a correct configuration file manually is an unpleasant task. I strongly recommend that you use NetBeans to generate one for you and then copy it into your project. The WSIT tutorial has extensive documentation on how to generate a configuration file.


Tuesday May 29, 2007

Public WS-Policy Test Site

The W3C Web Services Policy Working Group ran an interop event last week in Ottawa. We put up a web site for all the policy interop scenarios that we are supporting. All the functionality is built on the open source code of Project Tango / WSIT. The only significant difference is that the interop site supports the new W3C policy namespace while WSIT uses the member submission policy namespace. The address for our web site is http://wsinterop.sun.com:3280/wspolicy_interop/.

The site is meant to demonstrate the current technology and aid our interop testing. I will keep it up as long as I can, but it is not meant to stay up forever or feature product quality. If you are having any issues with the site, please let me know.





« August 2016