1 2 3 Previous Next


37 posts

 One of the features introduced in JAX-WS 2.2.2 RI, integrated in Glassfish 3.1 MS4, is the clientjar option to ease client-side web services programming. 

As you know, the standard client-side programming with JAX-WS RI involves running wsimport on the service wsdl, which generates the necessary classes needed for web service invocation. But all the information required by the JAX-WS runtime is not captured in the SEI or the WebServiceClient through standard web service annotations defined in the JAX-WS/JSR-181 spec. JAX-WS RI also saves the location of the wsdl in the generated classes so that it can retrieve the additional metadata of the service. This ability to fetch metadata at runtime is useful when there are some changes in endpoint policy or some compatible changes made in the service definition, the clients need not have to be regenerated. But, this  requires an additional connection just to access the metadata each time a service instance is created which can be costly at times. To workaround this, One could download the wsdl and make it accessible to the client runtime via jax-ws-catalog or other means. But, its painful to download all the wsdls and schema associated with the service and generate  jax-ws catalog to use the local files. 

In JAX-WS 2.2.2 RI, we are introducing -clientjar option for wsimport, which automatically downloads the wsdl and schema and packages all the generated client-side artifacts into a jar file. Just invoke wsimport as follows "wsimport -clientjar wsclient.jar http://example.com/service/hello?WSDL". So, invoking the web service from your program is as easy as placing the generated client jar in the classpath. A sample "wsimport_clientjar" is bundled in JAX-WS RI/ Metro 2.0 nightly bundles. Give it a try.

As you know, JAX-WS RI  has long supported publishing of asynchronous web services through the use of  RI specific AsyncProvider api. There have been requests to add the asynchronous support for the SEI based web services (the more common developer paradigm) and standardize it, I hope it would have a place in the future revision of the JAX-WS Spec. But the current AsyncProvider api can serve the purpose for advanced use cases with more control over the SOAP messages. Though this is an important ingredient for making the web services asynchronous, its usefulness could be leveraged only with the support of the underlying transport/communication framework. As Kohsuke mentioned in his blog, JBI has implemented a custom HTTP binding component over Grizzly that has capability to process requests in asynchronous manner.  But, like most other web frameworks, normal JAX-WS web service endpoints are published as servlets running in the web container. The SOAP messages get processed by the jax-ws runtime via servlet request/response. Until servlet 2.5, the servlet request processing is synchronous, i.e if the web service (underlying servlet) is waiting for a resource or event to happen, a container thread has to wait until the request is processed and response is committed. This would result into wasting precious container resources while the thread is blocked. This would be more apparent when you have thousands of concurrent requests to long running/slow running operations, where each thread servicing the request is blocked . Though the jax-ws runtime is capable of  asynchronous processing of requests,  it is limited by the blocking invocation model of the underlying servlet.

It's no longer the case as JAX-WS 2.2.2 RI makes use of the asynchronous  servlet capabilities introduced in Servlet 3.0. With async programming  model, the container thread is relinquished while the request is  processed asynchronously, and when processing is done or a timeout  occurs, the response can be sent or the request can dispatched back to  the container. To make this happen, first the servlet needs to be  declared as async-supported in web.xml or through @WebServlet  annotation. For more details on asynchronous servlet programming model,  refer to this techtip.  JAX-WS runtime takes advantage of this asynchronous servlet layer( a  transport layer interns of jax-ws) and the already existing  AsyncProvider API to provide better scalability and efficient use of  server resources. 

This asynchronous servlet transport feature is introduced in Glassfish V3.1 MS3 and you can find a working "asyncservice" sample in latest JAX-WS RI 2.2.2 nightly build or latest Metro 2.1 promoted build to try on any Servlet 3.0 supported container. I added a "asyncservice" sample demonstrating the usage of this  feature.A quick recap of the how web service implementation looks,

public class AsyncProviderImpl implements AsyncProvider<Source> {    
    public void invoke(Source source, AsyncProviderCallback cbak, WebServiceContext ctxt) {
        //queue the request for long running operation
        //return, response is sent via cbak.send(response) or cbak.sendError(throwable) in a separate thread
Here, the request is queued or processed in a separate thread releasing the container thread. The response is sent by calling the AsyncProviderCallback.send(response) or AsyncProviderCallback.sendError(throwable). As a second step, to make it truly asynchronous with the servlet web service endpoints, you need to mark the JAXWSServlet as async capable by specifying  <async-supported> true</async-supported>. As I blogged earlier, web.xml configuration is optional now, in that case, JAX-WS by default registers the servlet as async supported. If the response is not sent in a expected time interval, timeout occurs and JAX-WS runtime sends an error response. Currently, the timeout for the web service relies on the servlet implementation default. In future, we may provide an explicit configuration for the timeout.

Though this feature helps in better scalability on the server-side, the HTTP connection is still open in the background and the client  might be still waiting for the response because HTTP is a request/response protocol. One could use the support of the other WS-* specifications like Non-anonymous Addressing feature for addressable clients or WS-MakeConnection for non-addressable clients to make it asynchronous end-to-end. I will write about doing that with Metro in a future blog.


With JAX-WS 2.2.2 RI /Metro 2.1, Web Services deployment using RI deployment model has been made even simpler by making the web services configuration in web.xml optional.

 As you know, JAX-WS RI supports two deployment models to publish web services, one using JSR-109 deployment model and the other JAX-WS RI specific deployment model. In JSR-109 deployment model, a web service can be specified in web.xml as a servlet class and any additional configuration is specified in webservices.xml. JSR-109 supported container would then publish the web service using the servlet framework. With Java EE5, configuration of web.xml is made optional with the use of annotations. Though this is made quite simple, it works only on Java EE Containers supporting JSR-109.  To support web service deployment on plain servlet container like Tomcat, We use JAX-WS RI deployment model, where web service configuration is specified in sun-jaxws.xml and explicit declaration of RI specific servlet classes in web.xml. So, to deploy JAX-WS web services on a Servlet 2.4 Container, one has to at the minimal configure web.xml and sun-jaxws.xml. Here is sample web.xml configuration for JAX-WS web service.

 Old configurtation in web.xml:

<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"


         xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">







        <description>JAX-WS endpoint - fromwsdl</description>















Most of the time such configuration is auto-generated by IDEs like Netbeans and is unnecessary. With the introduction of dynamic registration of Servlets feature in Servlet 3.0, this whole thing can be made optional. With JAX-WS 2.2.2 RI, JAX-WS Runtime utilizes the Servlet 3.0 capabilities to dynamically register a servlet for each web service endpoint specified in sun-jaxws.xml. This should work in any Servlet 3.0 container like GlassFish V3, Tomcat 7 etc. This simplified deployment feature is introduced in GlassFish 3.1 MS3 and you can find a working sample from Metro 2.1 latest promoted build  here.  The dynamically registered JAX-WS servlet uses default settings in most cases and if you need to do advanced configuration like security, you can still  specify in web.xml as you used to earlier.

 Of course, with the use of jax-ws annotations, even configuration sun-jaxws.xml can be made optional making it completely descriptor free, but that requires specifying a default url-pattern like in JSR-109 or custom pattern like in Jersey REST services, in the JAX-WS specification. As it is, such descriptor free deployment is already supported by 109 implementation from Glassfish V2. This definitely is a step towards that goal and one less configuration file to worry about. 

 You can download the optional_webxml sample from JAX-WS RI 2.2.2 nightly build or Metro 2.2.1 promoted build and let us know your feedback.


Rant on Ant 1.7.1 Blog

Posted by ramapulavarthi Mar 29, 2010

If you are using Ant 1.7.1 for developing Web Services with JAX-WS/JAXB, I suggest you to move to the latest version Ant 1.8.0.

JAXB/JAX-WS rely on package level runtime annotations for lot of things. For ex: JAXB relies on the @XmlSchema annotation in package-info.java and uses it for binding Java data types to XML schema types. You might be puzzled to see that the mappings are not as expected. I wasted almost half a day trying to figure out if there was some regression in JAX-WS/JAXB as I was suspecting Ant the least. A bug in Ant 1.7.1 javac ant task, makes it not compile package-info.java. This is a serious regression and the impact is not directly obvious until you see the behavior change in this case. The issue is resolved in Ant 1.8.0 and I encourage all JAXB/Metro users to use Ant 1.8.0 for development.

We are trying our best to keep the JDK up to date with latest JAX-WS RI. The recently released JDK 6 Update release 14 has JAX-WS 2.1.6 RI along with JAXB 2.1.10 RI. You can find more about the changes that went in to the release can be seen at JAX-WS 2.1.6 change log and JAXB 2.1.10 change log. I hope the JAX-WS users find this helpful.

Its been a long time I blogged. You might be wondering what we are up to with JAX-WS RI lately. We are busy implementing the JAX-WS 2.2 RI.

Jitu, Spec lead for JSR 224 has already sent the proposals on JAX-WS 2.2 features. JAX-WS 2.2 is mainly aimed to add the missing support for WS-Addressing 1.0 - Metadata specification in the earlier release. This requires WS-Policy 1.5 support in JAX-WS to understand the WS-Addressing Metadata defined policy assertions. For WS-Policy 1.5  support, JAX-WS is using the Policy implementation from WSIT ( Policy project on java.net). We have integrated the Policy libraries in JAX-WS 2.2 and with this JAX-WS can understand/generate policies as defined in Web Services Policy 1.5 -Attachment. 

JAX-WS 2.2 will be part of Metro 2.0. The roadmap for Metro 2.0 can be found here and more details on the features targeted for Metro 2.0 are on Metro One Pagers. Some of the support for WS-Addressing Metadata is already implemented. The development for JAX-WS 2.2 is happening on jaxws22 branch of jax-ws-sources/jaxws-ri repository. Since JDK 6 already has JAX-WS 2.1 API, there are some possible classloading issues if you are using JAX-WS 2.2 on JDK 6. You have to resort to endorsed mechanism or use JDK 5 for now. We are working on alleviating this problem going forward.

I am going to write in detail about the features for WS-Addressing and other enhancements in JAX-WS 2.2 in a later blog.  The nightlies will be out soon once the 2.2 API are finalized.

Regarding the JAX-WS 2.1 implementation in JDK 6, We are working on syncing up JDK 6 with latest JAX-WS 2.1.X. You should see it in a future JDK 6 feature update release. 

JAX-WS relies on JAXB for data binding. When you invoke Wsimport Tool on a wsdl, It in-turn calls XJC tool in JAXB RI to generate the beans used by the JAX-WS runtime. Occasionally, You may need to pass XJC specific command line options through wsimport tool to customize the databinding. You can do it easily with Wsimport. This feature has been there from JAX-WS 2.1 and hopefully this blog explains the common questions on its usage.

If you are using XJC directly, you could pass those options on the command-line for XJC tool or as nested <arg> elements incase of XJC ant task. For example, if you want to disable the strict schema correctness checking while compiling the schema.

You can use

/path/to/jaxb/bin/xjc.sh -nv myschema.xsd
or in ant like
<xjc schema="src/myschema.xsd" destdir="src">
     <arg value="-nv" />
More about XJC command-line options can be found here.

But, if you want to customize the XJC behavior using wsimport tool, you can use on of the following method. For the command-line wsimport tool, you can pass xjc options using -B prefix. For passing the similar xjc option as described above, you can use

/path/to/jaxws/bin/wsimport.sh -B-nv myservice.wsdl
Notice that XJC options are differentiated from wsimport options by prepending "-B" to the option.

The same through wsimport ant task  can be done using the nested <xjcarg> element which follows the same command-line argument mechanism in Ant.

<wsimport wsdl="myservice.wsdl">
  <xjcarg value="-nv"/>

This mechanism can also be useful for using XJC plugins through wsimport as explained in Kohsuke's blog. Similarly, you can pass episode files created through previous jaxb compilation to Wsimport ant task using the nested <xjcarg> element.


Hudson@JavaOne Blog

Posted by ramapulavarthi May 15, 2008
You can find javac compilation issue with classes in javax.xml.ws.wsaddressing package in my previous blog "A little update for JAX-WS 2.1 users with JDK 6 Update 4 and Update 5" The corresponding bug 6672868 is fixed in JDK 6 update 6. The fix should be available in Open JDK 6 as well. So, you don't have to use the compiler switches or workarounds as mentioned in my previous blog to make it work :)

Filter Blog

By date: