Vivek Pandey's Blog

Community: Java Web Services and XML Archives

What's up with Scripting support on Glassfish?

JSR-223 let you execute dynamic languages from inside Java. However the interpreters for such languages are written in Java and generate bytecodes and at runtime deal with all the dynamic types and method dispatching and what not. This is because JVM is designed to be used for statically typed language such as Java where you know the types at the compile time and to take care of  types at the runtime the dynamic language interpreters use complex mechanism, which results in to uses of more memory, performance etc. JRuby overcomes these by doing JIT ahead of time, but then this poses limitation specially on the server side considering Rails which is single threaded.

The good news is that there are efforts in place in JVM to support Dynamic Languages, such as JSR -292 is going to add a new bytecode, invokedynamic, that supports efficient and flexible execution of method invocations in the absence of static type information. There is also a new project Da Vinci Machine that is going to bring in support for dynamic languages (or any other language) to JVM.

You might wonder why I am talking about all the scripting stuff! Well, I have taken up the role of Scripting Lead in Glassfish. I will ensure that Glassfish is home to many of the popular scripting languages out there and in fact will try to bring best of both worlds to Glassfish. JAX-WS will be lead by very capable Jitu.

I am working on wrapping up implementing some new features for upcoming Metro 1.2 or JAX-WS RI 2.1.4 and starting to take on Scripting Lead. Stay tuned, you will be hearing more form me in coming days...

Webservices in JDK 6

• JAXWS Tools wsimport and wsgen part of JDK
• Simplified deployment using Endpoint API and light-weight HTTP Server in JDK
• Uses JAXB 2.0, also part of JDK6, for all data binding needs.
• Also uses Stax, SAAJ 1.3 for message processing. Both these jars are part of JDK 6.

Web service Endpoint

Lets start with a POJO annotated with @WebService annotation. This annotation tells JAXWS that its a Web Service endpoint. You may like to annotate the methods that will be exposed as web services method with @WebMethod annotation. You dont need to specify it if all the methods will be exposed as web services method.

Calculator.java

package example;
import javax.jws.WebService;
import javax.jws.WebService;
import javax.xml.ws.Endpoint;

@WebService
public class Calculator {
    @WebMethod
    public int add(int a, int b) {
        return a+b;
    }
    
    public static void main(String[] args){
        // create and publish an endpoint
        Calculator calculator = new Calculator();
        Endpoint endpoint = Endpoint.publish("http://localhost:8080/calculator", calculator);        
    }
}

Now you need to do 2 things to build and publish this endpoint:

• Run apt to compile and generate required wrapper classes
  • apt -d sample example/Calculator.java
• Publish
  • java -cp sample example.Calculator

Thats it! You have deployed your web services endpoint. Now, try accessing the deployed WSDL by typing http://localhost:8080/calculator?wsdl in your web browser to see the published WSDL. No need to provide deployment descriptor, starting a container etc. Its all done for you internally by JAXWS using light-weight HTTP server available in JDK 6. In short - extremely fast prototyping!

Web Services Client

Lets see how we develop a client based on proxy.

Run wsimport

You would run wsimport on the deployed WSDL URL:

wsimport -p client -keep http://localhost:8080/calculator?wsdl

This step will generates and compile some classes. Notice -keep switch, you need it to keep the generated Java source files. By default wsimport only leaves behind the compiled class files. In this example the classes that matters are

• Calculator.java - Service Endpoint Interface or SEI
• CalculatorService - Generated Service, instantiate it to get the proxy

Invoke the endpoint

CalculatorApp.java

package client;
class CalculatorApp {
	public static void main(String args[]){
        /**
         * Instantiate the generated Service
         */ 
    	CalculatorService service = new CalculatorService();
        
        /**
         * Get the port using port getter method generated in CaculatorService
         */
        Calculator calculatorProxy = service.getCalculatorPort();
        
        /**
         * Invoke the remote method
         */
        int result = calculatorProxy.add(10, 20);
        System.out.println("Sum of 10+20 = "+result);
	}
}

Now that you have your client code is ready simply compile it:

javac -cp . CalculatorApp.java

and run:

java -cp . client.CalculatorApp

It will print:

Sum of 10+20 = 30

Running latest JAXWS RI on JDK6

The obvious question might be that how would you use latest JAXWS 2.1 RI on top of JDK6. JAXWS 2.1 RI is feature complete and we are busy fixing bug. For list of JAXWS 2.1 features and plan refer to the JAXWS 2.1 roadmap.

All you need to do is to use Endorsed Directory Mechanism  to point to the lib directory in JAXWS intallation:

Runtime

• java -cp . -Djava.endorsed.dirs=$JAXWS_HOME/lib client.CalculatorApp

Tools

• Run the tools from JAXWS distribution
  • export JAXWS_HOME to your JAXWS distribution installation
  • $JAXWS_HOME/bin/wsimport
  • $JAXWS_HOME/bin/wsgen
• For wsimport set WSIMPORT_OPTS="-Djava.endorsed.dirs=$JAXWS_HOME/lib"
• For wsgen set WSGEN_OPTS="-Djava.endorsed.dirs=$JAXWS_HOME/lib"

Use JDK 6 to develop your web services application and continue providing feedback to users@jax-ws.dev.java.net and if you find an issue report them at IssueTracker.

JAXWS 2.0.1 M1 is out!

JAXWS 2.0.1 M1, a.k.a. re-architected JAXWS 2.0 RI is out! These bits are also delivered with the Glassfish 9.1 v2. So you can get all the improvements we made in JAXWS 2.0.1 right from this glassfish download.

JAXWS 2.0.1 M1 is significantly modified since JAXWS 2.0 FCS. So what does this re-architecture brings in:

Performance

Performance boost - 70% compared to JAXWS 2.0 FCS. See Sameer's blog for the details on JAXWS 2.0.1 M1 performance. Here is what we did to boost performance:

• Revisited some of the key abstractions
  • Message and Pipe as the central abstraction
• More supporting abstractions
  • Encoder, Decoder, TransportFactory, ...
• Reduced # of special-purpose interface
  • No performance penalty when not used
  • No more custom hook for JavaEE

Pluggability

Based on abstractions - Message and Pipe. WSIT  components use this pluggable architecture to enable WS-Security, WS-Trust, WS-Relaible Messaging, WS-Addressing, etc.

A typical pipeline on the client side would look like:

Similarly a server pipeline would look like:

The Pipe line is assembled based on the binding, handler or policy assertions.

WSIT  components use this pluggable architecture to enable WS-Security, WS-Trust, WS-Relaible Messaging, WS-Addressing, WS-Policy, WS-MetadataExchange etc.

See Jitu's blog on JAXWS transports which are written as Pipe.

JAXWS 2.0.1 M1 is feature complete with respect to the previous JAXWS 2.0 FCS release. We have run all the JAXWS 2.0 FCS SQE and TCK tests and found more than 90% of tests passing. So its stable but there are still few open P3 bugs.

Download Glassfish 9.1 v2  thats released today, it has JAXWS 2.0.1 M1 bits in it.  See Carla's blog on this release. So try out and send us your feedback.

You can also download JAXWS 2.0.1M1 directly from java.net and tryout with other servlet containers as well. Checkout the doucmentation for details.

More on JAXWS and WSIT MTOM interoperability ...

So what that extra interoperability MTOM feature in JAXWS 2.0.1 EA will bring in when used with or without WSIT?

• MTOM enabled client/endpoint always sends MTOM encoded message

In JAXWS 2.0 FCS, when MTOM is enabled the MTOM encoding takes place only when the message has binary data and its size is greater  than the MTOM threshold value. The fact that WCF MTOM enabled client/endpoint expects the message to always be MTOM encoded whether the message has binary data or not, this requires JAXWS 2.0 FCS client/endpoints to always set their threshold value to set to 0 in-order to interoperate with WCF.

In JAXWS 2.0.1 EA, as part of re-architecting the MTOM encoding we found that to keep the previous behavior we need to process the message completely. This required buffering the entire message and the cost saved was only encoding/decoding of Content-Type as per MTOM spec. The buffering is expensive so we decided not do it in JAXWS 2.0.1 EA.  Now if MTOM is enabled, the MTOM encoding of Content-Type always takes place irrespective of the binary size or MTOM threshold value.  This makes MTOM interop

• MTOM policy assertion in the published WSDL

  JAXWS 2.0 FCS MTOM enabled service has no way to say in the published WSDL (WSDL 1.1) that MTOM is enabled. For this to work and interoperate correctly with a WCF client, developer has to use WCF defined mechanism to enable MTOM explicitly. This was a pain and not intuitive as the described service has no direct way to tell that it expects/sends MTOM messages.

  JAXWS 2.0.1 EA with WSIT inserts appropriate MTOM policy assertion in the published WSDL for an MTOM enabled endpoint. This allows a WCF client to automatically interoperate with the endpoint.

  The MTOM policy assertion in the published WSDL would appear as:

  <wsp:Policy wsu:Id="BasicHttpBinding_IMtomTest_policy">
    <wsp:ExactlyOne>
        <wsp:All>
            <wsoma:OptimizedMimeSerialization xmlns:wsoma="http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization" />
        </wsp:All>
    </wsp:ExactlyOne>
</wsp:Policy>

• MTOM policy assertion aware JAXWS 2.0.1 EA

  WCF endpoints publish MTOM endpoint WSDL with MTOM policy assertion, so if you're writing a JAXWS 2.0.1 EA client, run wsimport on the WCF endpoint's WSDL and write your application against the generated Service Endpoint Interface class and you're good to go.

• Secure MTOM

MTOM feature is architected in such a way that message processing layers are agnostic of it. for example security Pipe doesn't need to be aware of MTOM. This allows a Secure MTOM endpoint to interoperate well with  WCF Secure MTOM client/endpoint. I would write more on it in my next or latter blogs.

Checkout jaxws and wsit projects and stay tuned...

MTOM and WSIT

JAXWS RI 2.0 FCS was released last week and we are working on JAXWS 2.0.1 EA. JAXWS 2.0.1 EA is re-architected for better performance and to a greater extent a pluggable architecture that allows WSIT components such as WS-Policy, WS-Reliable Messaging etc. to plug-in both at runtime and tool time. Checkout WSIT project on java.net. Read more info on WSIT is here.

As part of this rearchitecture work MTOM implementation in JAXWS 2.0.1 EA is overhauled, re-architected and written form scratch. Feature wise its going to be the same as JAXWS RI 2.0 FCS but will be faster and more interoperable. Here are some of the key aspects of these changes:

• Streaming MTOM - uses stax-ex APIs
• Enabling MTOM using MTOM policy assertion with WSIT components
• Generation of MTOM policy assertion in the published WSDL with the WSIT components. This automatically enables MTOM interoperability with the WCF or Indigo clients.
• Fully interoperability with Microsoft WCF a.k.a. Indigo. It has been verified at WCF plugfests

I have BOF at Java One on 16th night where I will be talking about the MTOM implementation gory details and I will be happy to meet anyone interested in person and answer any question.

MTOM in JAXWS RI 2.0 Final

There are several bug fixes related to MTOM but I would like to mention couple of  important ones:

• Now @XmlMimeType can be used to annotate a method parameter or return types. This would result into xmime:expectedContentType in the generated schema and the MIME type would appear as Content-Type in the MIME part

public void sendImage(@XmlMimeType("image/png") java.awt.Image photo);

This would result into an equivalent XML schema declaration

<xml:element name="photo" type="xs:base64Binary" xmime:expectedContentType="image/png"/>

When serialzied over the wire, it will appear as:

--123@a.b.c
Content-Type:image/png
Content-ID:...
<http://a.b.c.org/photo1>
<Content-Transfer-Encoding: binary

¨wXVi ,Ú|h#PLÓ#$/

• xmime:ContentType schema annotation is serialized correctly now. Tt was causing .NET interoperability problem

Santiago has done some MTOM performance analysis and has a blog on it. For smaller data sizes MTOM and XML almost perform the same however you start seeing the performance benefits above 5-6KB.

There is MTOM user document and sample that you can get from jaxws. So go and try it out and send your feedback to the dev alias. JAXWS 2.0 FCS is also also delivered as part of Sun Java System Application Server PE 9 included in the Java EE 5 SDK. Check Carla's blog on the Sun Java System Application Server PE9.

This work is licensed under a Creative Commons License.