Vivek Pandey's Blog

Web Services and XML Archives

Metro 1.0.1 and 1.1 Released

Metro team is pleased to announce the release of Metro 1.1 and Metro 1.0.1. Both these releases are fully tested with many thousands of SQE/Unit/Compatibility/Interop tests on Glassfish V2 UR1.

Metro 1.0.1 is a restricted bug fix release and is integrated with Glassfish V2 UR1.

Metro 1.0.1 includes WSIT 1.0.1 and JAX-WS RI 2.1.2.1.

• WSIT 1.0.1 changes
• JAX-WS RI 2.1.2.1 changes

Metro 1.1 release includes WSIT 1.1 and JAX-WS RI 2.1.3. Metro 1.1 is a stand alone release but can be easily installed on Glassfish v2 UR1, see the instructions on how to here. Good news is that Metro 1.1.1 which is a bug fix and selected feature release of Metro 1.1, will be integrated in to upcoming Glassfish v2.1 (Sailfin). See Metro roadmap for details.

Here are some key features in Metro 1.1

• Efficient Handler using Handler<Message> support. See Rama's blog
• Large and Streaming attachment support
• XML Schema validation support for SOAP message
• Authentication support in wsimport
• Additional header support
• Early Access WS-Reliable Messaging 1.1 support
• Early Access Kerberose Token support

• JAX-WS RI 2.1.3
• WSIT 1.1

For the users who like JAX-WS RI stand alone bundle and Maven releases there is corresponding release of JAX-WS RI, JAX-WS RI 2.1.3 and JAX-WS RI 2.1.2.1. These version are also released in the JAX-WS Maven repository. See the detailed announcement here.

What is next? We are planning Metro 1.2 that will be released around March 2008 and also on Metro 1.1.1. Metro 1.1.1 will be integrated with upcoming Glassfish v2.1. See the details on Metro roadmap.

Continue sending your feedbacks to the forum and to the mailing list.

Metro Roadmap

There have been many postings on Metro forum and elsewhere about the Metro roadmap. In fact we have been working on it and it took more time that expected but better late than never.

Here are key points about Metro release

• Bundles stable versions of JAX-WS RI and WSIT
• WSIT will no longer have a separate release, it will be part of Metro bundle
• We will keep releasing JAX-WS RI as a separate bundle as it is an RI of JSR-224, at least for sometime
• Any of JAX-WS RI releases will be completely synchronized with the Metro release
• Each Metro release will be tested on the latest available stable Glassfish release on JDK5 and JDK6 on linux/solaris/windows

Now an update on what are we up to:

Key fatures in upcoming Metro 1.1

1. Large and Streaming Attachment Support
2. Efficient Handler - Handler<Message>
3. XML Schema validation support
4. New wsimport features and enhancements
5. Early access Reliable Messaging 1.1 and Kerberos Token Support

With respect to JAX-WS RI, we are working on JAX-WS RI 2.1.3 and it goes in to Metro 1.1. As mentioned above the JAX-WS RI releases will be completely synchronized with the Metro release. So stay tuned, JAX-WS RI 2.1.3 is also in final testing phase and close to getting released along with Metro 1.1.

Metro Core - JAX-WS RI 2.1.2 released

We are finally there! Glassfish v2 is released and so is the Metro 1.0  - the Glassfish Web Services Stack, along with it comes JAX-WS RI 2.1.2 a.k.a Metro Core. See Kohsuke's blog on Metro 1.0 highlights and key features and Harold's blog on the Metro users and Tango.

There are some new features and lots of bug fixes went in to JAX-WS RI 2.1.3. Here are some of the highlights:

• GZIP compression support, see Jitu's blog
• Woodstox support
  • Tested to work with Woodstox 3.2.1. See Bhkati's and Santiago's blog for detail on how to enable Woodstox.
• SOAPAction Based Dispatching
• .Net 2.0/WSE 3.0 MTOM Interop support
• JAXB RI 2.1.5

The JAX-WS RI 2.1.2 bits are integrated in to Glassfish v2 release via Metro 1.0. Go ahead and download JAX-WS RI 2.1.2 or Metro 1.0 or just get Glassfish v2 which has everything with it.

Now what is next? We are working on JAX-WS.next roadmap and how it ties up with Metro releases. The plan is to have a consistent and frequent release cycle, maybe 8 weeks or so. The biggest challenge is automation of tests and speedy releases. We are working on the plan and the good thing is there is a consensus among various group here so most likely it will happen.

On the next version of JAX-WS RI, it is going to be JAX-WS RI 2.1.3, we are looking for a Nov release and the corresponding Metro 1.1 release at the same time. I will go over what are the new things coming up in JAX-WS RI 2.1.3 and Metro 1.1 in another blog.

Send your feedback to our forum or to user alias and report any issues to the IssueTracker.

JAX-WS RI 2.1.2 RC1 released

I have just released JAX-WS 2.1.2 RC1, Core of Metro. The JAX-WS RI 2.1.2 RC1 bits are part of Metro 1.0 M6 release. Metro 1.0 M6 is integrated with Glassfish v2 Build 58b(RC3) so you can just get Glassfish v2 RC3 and get all of Metro stack  (JAX-WS RI and WSIT) with it.

JAX-WS RI 2.1.2 RC1 is tested with all of the unit, SQE and TCK tests. This release candidate is targeted for the JAX-WS 2.1.2 and Metro 1.0 FCS release. If all goes well we are looking for FCS release around Sept 17th.

Download, use it and continue providing feedback to users@metro.dev.java.net or to the Metro Forum and report your issues and feature requests at IssueTracker.

Running wsimport got easier!

I recently updated my Vista notebook with Cygwin and tried to run wsimport CLI. Guess what, it did not run. Part of the problem was the wsimport shell script. It is always problematic maintaining scripts across various platforms.

This prompted me to think that why do we even need a shell script to run wsimport. We should simply be able to run it as:

$java -jar $JAXWS_HOME/lib/jawws-tools.jar endpoint.wsdl

So, I enabled this support in JAX-WS RI 2.1.3 code base and wsimport.sh|bat are modified accordingly. Try it from the nightly and send us feedback to us.

Metro and NuSOAP interoperability

Web Services is all about interoperability. Synodinos has written a nice blog about JAX-WS RI - Metro Core and NuSOAP (SOAP PHP toolkit) interoperability.

JAX-WS RI brings in core interoperability, such as WS-I BP 1.1, AP 1.0 and SSBP 1.0 in to Metro stack. This ensures interoperability interoperability in the web services description (WSDL/XML Schema) and also SOAP wire level protocol. We have verified interoperability for the basic web services with various other stacks such as .NET 2.0/3.0, Axis, Xfire etc.

Metro also bring in the advanced web services, such as message level security(Ws-Security), quality of service(WS-RM), brokered trust(WS-Trust/WS-Secure Conversation) through WSIT which are fully tested to be .NET 3.0 interoperable.

In summary use Metro and get a comprehensive interoperability. Keep sending us your feedback at Metro forum or the user alias.

Metro in JBossWS

Thomas in his blog announced the support for Metro - a Glassfish community project in the JBossWS.

Many JBoss users are already using Metro,  see Metro announcement for details. This is the latest addition to the Application Servers supporting Metro, Glassfish v2, Web Logic Server and TmaxSoft JEUS. I would like to highlight as why you should chose Metro in Glassfish as your Web Services stack:

• Easy to use JAX-WS programming model
• Spring integration
• Stateful Web Services
• Pluggable encodings - JSON, FI
• Pluggable transport - SMTP, TCP, JMS
• Tools - CLI, Ant based, Maven plug-ins
• IDE plug-ins - Netbeans, IDEA, Eclipse
• Well tested and out of the box .NET 3.0 interop
•  BP conformance - WS-I BP 1.1, AP 1.0, SSBP 1.0
• Tested for high performance and scalability
• and many more...

You may like to check out Metro and it's components- JAX-WS RI and Tango. Metro is not final yet. We are planning to make a final or FCS release in September 2007.

Portable client application with locally packaged WSDL

In the JAX-WS programming model to develop a web services client you would compile the deployed WSDL using wsimport and then at runtime the same WSDL is used to determine binding information. The runtime accesses the WSDL over the network, but sometimes because of the size of the WSDL or for whatever reason (such as you want to edit it to fix workaround some bug, dangerous but we do it sometimes) you may like to keep the WSDL locally and would expect the runtime to access the local wsdl. It does not happen automatically.

There are the different ways in which you can provide the local WSDL information to the JAX-WS runtime:

Use Service API to pass the WSDL information

        URL baseUrl = client.MtomService.class.getResource(".");
        URL url = new URL(baseUrl, "../Soap11MtomUtf8.svc.xml");
        MtomService service = new MtomService(url, new QName("http://tempuri.org/", "MtomService"));
        IMtomTest proxy = service.getBasicHttpBindingIMtomTest();
        String input="Hello World";
        byte[] response = proxy.echoStringAsBinary(input);
    

Xml Catalog

• Create a catalog file
• META-INF/jax-ws-catalog.xml

        <catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog" prefer="system">
            <system systemId="http://131.107.72.15/MTOM_Service_Indigo/Soap11MtomUtf8.svc?wsdl"
                    uri="Soap11MtomUtf8.svc.xml"/>
        </catalog>
        
    

• For details see the details on using catalog scheme

This works well but requires some work, such as composing the right catalog file then package it appropriately.

Using -wsdlLocation switch

There is another easy way to do it - just run wsimport with -wsdlLocation switch and provide the WSDL location value which is relative to the generated Service class and you need to put this WSDL file at this relative location.

Let us try to create a client for the NET 3.0 MTOM endpoint. I am using Metro 1.0 M5.

First I save the .NET 3.0 MTOM WSDL locally then run wsimport giving the relative location to where you will package the wsdl with your application Sample wsimport command

        wsimport -keep -d build/classes -p client etc/Soap11MtomUtf8.svc.xml -wsdlLocation ../Soap11MtomUtf8.svc.xml
    

Why is the relative location is ../Soap11MtomUtf8.svc.xml? Basically the generated Service will be at build/classes/client location and I would copy this WSDL at build/classes, see option -d and -p.

Here is excerpt from the generated MtomService class. You can see how the wsdlLocation value is generated inside it and is used internally to create the Service.

        /**
        * This class was generated by the JAX-WS RI.
        * JAX-WS RI 2.1.2-hudson-53-SNAPSHOT
        * Generated source version: 2.1
        *
        */
        @WebServiceClient(name = "MtomService", targetNamespace = "http://tempuri.org/", ../Soap11MtomUtf8.svc.xml")
        public class MtomService
        extends Service{

            private final static URL MTOMSERVICE_WSDL_LOCATION;
            private final static Logger logger = Logger.getLogger(client.MtomService.class.getName());

            static {
                URL url = null;
                try {
                    URL baseUrl;

                    baseUrl = client.MtomService.class.getResource(".");
                    url = new URL(baseUrl, "../Soap11MtomUtf8.svc.xml");
                } catch (MalformedURLException e) {
                    logger.warning("Failed to create URL for the wsdl Location: ../Soap11MtomUtf8.svc.xml");
                    logger.warning(e.getMessage());
                }
                MTOMSERVICE_WSDL_LOCATION = url;
            }

            public MtomService() {
                super(MTOMSERVICE_WSDL_LOCATION, new QName("http://tempuri.org/", "MtomService"));
            }

            ...
    

See Client.java below it invokes the .NET 3.0 service. You may notice here that you dont need to enable MTOM explicitly. Metro bring in .NET 3.0 interop thru WSIT and due to this the MTOM policy assertions in the .NET 3.0 WSDL, it correctly interpreted and the IMtomTest port is configured with MTOM enabled.

package client;

import com.sun.xml.ws.transport.http.client.HttpTransportPipe;

/**
 * Client that invokes .NET 3.0 MTOM endpoint using a local wsdl
 */
public class Client {

    public static void main(String[] args) {

        //enble SOAP Message logging
        HttpTransportPipe.dump = true;

        //Create IMtomTest proxy to invoke .NET 3.0 MTOM service
        IMtomTest proxy = new MtomService().getBasicHttpBindingIMtomTest();
        String input="Hello World";
        byte[] response = proxy.echoStringAsBinary(input);
        System.out.println("Sent: "+input+", Received: "+new String(response));
    }
}

Get the complete client bundle from here and see the enclosed Readme.txt for instructions on how to run it.

JAX-WS 2.1.2 M1 Posted

I have pushed JAX-WS RI 2.1.2 M1 release. This milestone release has some important bug fixes and some features:

• JMX Agent on the server side
• .NET 2.0/WSE 3.0 MTOM interop
• Woodstox support. See Bhkati's and Santiago's blog for detail on how to enable Woodstox.

These are the bug fixes in this release. See the roadmap for detail on JAX-WS 2.1.2 plan. This release is integrated and tested on Glassfish v2 b50. All our unit tests, SQE and TCK tests are passing. Download it from here or from the maven and send your feedback to users@jax-ws.dev.java.net or to the JAX-WS Forum and report your issues and feature requests at IssueTracker.

JavaOne wrap-up

It took me so long to recover from JavaOne! Well not really, right after JavaOne got pulled into various things and could never get to it.

Overall, it was great to meet JAX-WS RI users and hear their feedback and most importantly it was really good to know that its adoption is increasing!

JavaOne slides are out, get the slides for our Technical Session and BOF.

Someone in audience asked about the SMTP demo code. I will post it soon in a separate blog. The demo code is part of SMTP repository so you can have a look at it in the meantime.

JAX-WS RI was mentioned  in many talks, some of them were

• There was JMX session, where they talked about uses of JAX-WS RI
  • Wiseman is using JAX-WS RI 2.1.1 to implement WS-Management.
  • Web Services Connector JMX Agents also uses JAX-WS RI 2.1.1
• Another talk was on the CommunityOne day by Rod Johnson, where he discussed about how JAX-WS RI supports Spring by extending XML configuration of Spring 2.0. See his blog on the JAX-WS Spring support and Glassfish.
• There was a session by Salesforce.com where they talked about uses of JAX-WS RI, wsimport etc. and how it gives them better performance. During the JavaOne week Salesforce.com announced the Apex toolkit using JAX-WS 2.1.1 RI. See Arun's blog for details.

Thanks everyone for your continued interest in JAX-WS RI, keep sending your feedback to us.

JAX-WS 2.1.1 RI Released

So I have just released JAX-WS RI 2.1.1 This release is update to JAX-WS RI 2.1 and implements the re-spun  JAX-WS 2.1 MR2(JSR 224) specification.

See here for the changes in this release, and yes can use this release with woodstox 3.2.1, see Jitu's blog.

Get the JAX-WS 2.1.1 RI from here or from maven repository and continue providing feedback to users@jax-ws.dev.java.net or to the JAX-WS Forum and report your issues and feature requests at IssueTracker.

JAX-WS 2.1.1 RC1 is posted

I have just posted JAX-WS 2.1.1 RC1 RI. This is a candidate build that we are targeting for the JAX-WS 2.1.1 release. All the unit, SQE and TCK tests passing with these bits. In the next few weeks rigorous testing will be done with this candidate to make sure its ready for our final release.

It is tested to work with Glassfish Promoted Build v2 41a (Beta 2 Candidate 2) and Tomcat 5.x.

Please note that JAX-WS 2.1 MR (JSR 224) is out for 30 days review at JCP and JAX-WS 2.1.1 RI release is pending approval of this spec. The tentative JAX-WS 2.1.1 RI release date is May 7th.

Continue providing feedback to users@jax-ws.dev.java.net or to the JAX-WS Forum and report your issues and feature requests at IssueTracker.

Update to JAX-WS RI release

Since I posted my last blog there have been questions and concerns by our users about what's next? When is the new release going to be available? I indicated to be back in couple of weeks and I apologize it took more than that to get back with the dates for the next JAX-WS RI release.

Here is what has been happening -  being RI of JSR 224 (JAX-WS 2.1 MR) we worked closely with Doug to update the JAX-WS 2.1 MR change log and updated Javadocs to remove references to now-dead WS-Addressing WSDL Binding specification. This work is complete and the re-spun spec is submitted to JCP for 30 days review.

We plan to release JAX-WS RI 2.1.1 in the first week of May 2007 - around JavaOne 2007. See the JAX-WS 2.1.1 roadmap for details.

JAX-WS RI 2.1.1 is feature complete and is undergoing testing cycle for compatibility and quality. Things are looking good and we are looking forward to release JAX-WS RI 2.1.1 in the first week of May.

In the meantime, continue using JAXWS 2.1 nightly.

What happened to JAX-WS 2.1 RI download?

You might have noticed that JAX-WS 2.1 RI download link takes you to an Error page. We have fixed that to say what is really going on with JAXWS 2.1 specification and RI.

So why we have to do this? Well, WS-Addressing WSDL Binding spec was normatively referenced by JAX-WS 2.1 specification and was in CR state when the spec and RI went final few weeks back. After we released JAXWS 2.1 RI and the spec, it came to our attention that WS-Addressing Working  Group has decided to drop this spec and instead do WS-Addressing Metadata (a Working Draft now). So in effect the Binding spec is dead and JAXWS 2.1 specification references it!

We believe we need to take corrective action to address this issue. Doug is working with JAX-WS expert group to remove references to now dead WS-Addressing WSDL Binding spec and make related changes in the spec and API javadocs.

Hence, we have temporarily removed access to the JAXWS 2.1 RI to prevent any use of these until the specification issues are resolved. We apologize for any inconvenience caused. We will have some more updates on it in approximately two weeks.

In the meantime, continue using JAXWS 2.1 nightly. 

JAXWS 2.1 FCS - Fast and Furious

Phew, what a ride! As usual there has been a few last minutes test failures and re-spinning the build, making sure the Orb is blue in the break area, but finally we are here... JAX-WS 2.1 RI is Final! It was non-stop months of effort by everyone in the JAX-WS team and of course hudson which kept reminding us of any regression we caused before anyone else noticed!

JAX-WS 2.1 RI provides convenient programming model built on JAX-WS 2.1 standard APIs and also provides extensions on which middleware developers can build the solutions to enhance it, such as WSIT,  Open JBI component, and Glassfish v2. See Kohsuke's blog on extending JAX-WS 2.1 and Jitu's blog  on plugging in the Tube and also many developer productivity features.

It has been well tested with unit tests, SQE tests and all of the Java compatibility tests(TCK) on top of Glassfish v2 M4 and Tomcat 5.5.x using JDK 1.5_06 and JDK 6. Get the JAX-WS 2.1 RI from here or from maven repository and send your feedback to users@jax-ws.dev.java.net or to the JAX-WS Forum and report your issues and feature requests at IssueTracker.

Here is JAX-WS 2.1 RI  release announcement:

JAX-WS team is pleased to announce general availability of JAX-WS 2.1 RI. We have put tremendous effort in bringing this where it is! Besides cool features and JAX-WS 2.1 API, two main architectural changes that went in to this release - Performance and Extensibility. JAX-WS 2.1 RI is built on Java standards such as JAX-WS -2.1 (JSR 224), JAXB 2.1 (JSR 222), SAAJ, StAX and whole bunch of related Java standards. Not only that, the Web Services standards and profiles compliance  is at the core - from tools to the complete runtime system. Important thing about JAX-WS 2.1 RI is that it is a complete re-architecture and re-write of JAX-WS 2.0. We did it for two main reasons  - to make it high performing and extensible! See the reason we did it and also our 2.0.1 M1 release with these architectural changes and merge of 2.0.1 into 2.1. JAX-WS 2.1 RI brings in new productivity features and also extension APIs for the middleware developers to enhance JAX-WS 2.1 with their custom extensions, such as WSIT,  Open JBI component, and Glassfish v2 . Key Features Reference Implementation (RI) of JAX-WS 2.1. Full JAX-WS 2.1 Specification compliance Development Tools WSDL to Java generator Wsimport comman line tool, ant task and Maven2 plugin Java to WSDL generator Wsgen command line tool, ant Task  and Maven2 plugin Integrated with NetBeans  5.5.1 Standards Web Services Addressing 1.0 - Core, SOAP Binding and WSDL Binding WS-Addressing  - Member Submission SOAP 1.1 and 1.2 REST and XML/HTTP WS-I Basic Profile 1.1, Simple SOAP Binding Profile 1.0 and Attachment Profile 1.0 MTOM Extensions (May not be final unless says so) Web Services Interoperable Technologies ( WSIT) - enables .NET 3.0 interoperability WS-ReliableMessaging WS-Policy WS-MEX WS-Security/WS-Security Policy WS-Trust/WS-Secure Conversation WS-AT/WS-Tx (Supported only on Glassfish v2) SOAP/TCP Spring support Pluggable Transport In-VM transport Servlet transport (bundled with the RI) JMS transport SOAP over TCP transport (part of WSIT) FastInfoset (bundled with JAX-WS 2.1 RI) ITU-T Rec. X.891 | ISO/IEC 24824-1 JBI Service Engine and Binding Component(part of Glassfish v2) HTTP Binding Component, used by Open JBI component Data binding - JAXB 2.1.2 RI Server Side Asynchrony - AsyncProvider Stateful Web Services Support for custom WebServiceFeature Hosting API These APIs can be used by a J2EE application server to integrate JAX-WS 2.1 RI for hosting JAX-WS services Endpoint Deployment Glassfish v2 Tightly integrated with Glassfish Supports EJB and Web endpoints 109 based deployment support for better portability JAX-WS RI specific deployment descriptor support Sun One Application Server 9.0 ur1 Light weight HTTP server On JDK 1.5 through http.jar distributed with the JAX-WS 2.1 RI bundle Bundled with JDK 6 Any other container that supports Servlet 2.4, such as Tomcat, Jetty, Geronimo, JBoss, Resin, ... You name it!

Performance comparison with Axis2 1.1.1

We ran our benchmark tests against Axis2 1.1.1. Details on this benchmark can be found here.

People usually care about the server-side performance so the benchmark tests measures the performance on the server side. Large numbers of clients were used to invoke the endpoints simultaneously so we measured number of invocations per second.  Since invocations per second varies greatly from tests to tests, we normalized the number so that you'll always see Axis2 as '100%'.

On tests like echoVoid where the payload is small, the benchmark tends to reflect the performance of the web service toolkit itself, and there you can see JAX-WS RI 2.1 to be about twice as fast than Axis2. On tests like echoArray where the payload is bigger, the benchmark reflects the data binding performance as well, and here you still see us at least 25% faster.

The types of data included empty message (echoVoid), int, float, String, Date, structures of varying sizes(echoStruct) , arrays of varying sizes (echo Array) and binary data of varying sizes (echoSynthetic).

You can see in the graph below for simple types you are looking at the performance comparison with the least amount of data binding and for larger messages the comparisons show performance with respect to data binding.

As it looks above in the graph JAX-WS 2.1 RI is performing lot better than Axis2 for all different message sizes. In each of the tests invocations per second includes all the server-side network processing/container etc., so achieving overall 2x performance means that the web services stack has to perform more than double.

So get the JAX-WS 2.1 from here or from maven repository and continue providing feedback to users@jax-ws.dev.java.net or to the JAX-WS Forum and report your issues and feature requests at IssueTracker.

JMS SOAP/WSDL Binding

Running JAXWS 2.1 wsimport on JDK 1.6

In my previous post I wrote about developing a web service  endpoint on JDK 1.6 and at the end of the blog I wrote how to run wsimport command line tool from the  standalone JAXWS 2.1 RI on top of jdk 1.6.

You do not want to put all the jars from @JAXWS_HOME/lib into endorsed directory. This may work for wsimport command line tool as mentioned in my previous blog, but will cause error when you try to run Wsimport ant task.  the reason is that Wsimport ant task class will be loaded by the boot classloader and when it tries to load ant's classes it fails as they are not loaded by the boot classloader. So in this case it would fail with this error:

taskdef A class needed by class com.sun.tools.ws.ant.WsImport cannot
be found: org/apache/tools/ant/taskdefs/MatchingTask

See the issue reported for details.

Basically you need to put only two jars in the endorsed directory, jaxws-api.jar and jaxb-api.jar, see Endorsed Directory Mechanism for more details.

You would pretty much do the following to run wsimport, both ant task and command line tool from JAXWS 2.1 RI on JDK 1.6:

• cp $JAXWS_HOME/lib/jaxws-api.jar c:/jdk6/jre/lib/endorsed
• cp $JAXWS_HOME/lib/jaxb-api.jar c:/jdk6/jre/lib/endorsed

$JAXWS_HOME points to the directory where you installed JAXWS 2.1 RI.

Continue providing feedback to users@jax-ws.dev.java.net and if you find an issue report them at IssueTracker.

JAXWS 2.1 EA3 Posted

• Improved wsimport
  • -quiet switch
    • wsimport works in silent mode
  • -target switch
    • wsimport generates code as per target spec version. It preserves the source level compatibility with different JAXWS specification version. The supported versions are 2.0 and 2.1. Default is 2.1.
  • Improved error reporting
    • wsimport reports more meaningful error messages with line number information.
    • Before
      • warning: s4s-att-not-allowed: Attribute 'minOccurs' cannot appear in element 'element'.
line ? of http://localhost:8080/invalid/?wsdl#types?schema1
error: uniqueness constraint violation
    • Now:
      • [WARNING] s4s-att-not-allowed: Attribute 'minOccurs' cannot appear in element 'element'.
line 77 of http://localhost:8080/invalid/?wsdl#types?schema1

[ERROR] parts in wsdl:message "echoRequest", reference "{http://example.com/types}echo", they must reference unique global elements.
line 88 of http://localhost:8080/invalid/?wsdl

     

• Bug fixes

Please use it and send your feedback to users@jax-ws.dev.java.net

JAXWS 2.1 EA2 RI

JAXWS 2.1 EA2 is out! We are continuing to add new features and improve quality with each successive releases.

 Here are the new features with this release:

• Complete WS-Addressing W3C and Member Submission support
• Type Substitution (supported using @XmlSeeAlso annotation)
• Stateful webservices
• AsyncProvider
• More JAXWS 2.1 API implemented
• Bug fixes

Its tested to work with Glassfish v2 M2 and Topmcat 5.x. Refer to ReleaseNotes for detail on installation instruction.

So try it out and send your feedback to users@jax-ws.dev.java.net.

JAXWS 2.1 Early Access 1 is out

The key new feature in this release is the support for WS-Addressing implementation. some key points here are:

• Includes implementation of W3C and Member Submission versions of WS-Addressing
• Programming model includes development of WS-Addressing aware endpoints both starting from Java and from WSDL and also WS-Addressing aware client by importing the W3C WS-Addressing WSDL. For details see Rama's blog.

Other new thing to note is that this release is integrated with JAXB 2.1 EA RI. So you have all the JAXB 2.1 features to try out.

This means you would need JAXB 2.1 EA jars together with JAXWS 2.1 EA1 to run your applications and it may not work with earlier release of JAXWS. We are planning to provide some mechanism in wsimport so that you can control the version of the generated artifacts. Stay tuned...

We have run our TCK/SQE/Unit tests and the quality seems to be same as JAXWS 2.0.1 M1 release. So go ahead and try it out. The jars are pushed into maven repository.

We would like to hear from you so please send your feedback to users@jax-ws.dev.java.net.

Continuation of JAXWS 2.0.1 RI...

• WS-Addressing implementation
• Asynchronous stack
  • server side asynchrony
  • Pipe->Tube and Fiber features
• JAXWS 2.1 MR specification implementation
• Integration of JAXB 2.1 RI
• Type substitution
• Tools improvement

Among the above requirements, the implementation of JAXWS 2.1 MR specification means that we would change the version number from JAXWS 2.0.1 to JAXWS 2.1 to align with the spec that this RI implements. So going forward the JAXWS release will be versioned 2.1 and not 2.0.1, such as JAXWS 2.1. See the JAXWS roadmap for detailed feature list and release plan.

We would like to hear from you so please send your feedback to users@jax-ws.dev.java.net.

Architecture Document for JAXWS 2.0.1 RI published

I wrote in my previous blog  about the value JAXWS 2.0.1 M1 RI brings in writing plugins, such as Transports, Pipes, Adapters etc and referenced such plugins.

So that you can start writing such plugins we have published the Architecture Document for the  JAXWS 2.0.1 RI. or re-architected JAXWS.

Its available as well written javadocs. Good place to start looking in to this document would be the api section.

Start using it and send us feedback at users@jax-ws.dev.java.net.

Whats coming up with JAXWS 2.0.1

So what's keeping the JAXWS team busy these days? Well, we have been working on JAXWS 2.0.1 for improved performance and making it pluggable. This required re-architecting the runtime significantly. The new architecture is based on key abstractions such as Pipe and Message. Each Pipe works on the Message and gives it to the next or previous Pipe in the chain.

This allows plugging in features such as WS-Reliable Messaging, WS-Security, WS-Metadata Exchange etc. One can also write custom transport and binding. wsit a.k.a. Project Tango uses this architecture to plug-in support for WS-Security, WS-Trust, WS-Reliable Messaging etc.

Here are the new things that JAXWS 2.0.1 brings in,

• Better Performance. The numbers are showing really good improvement, we will post these in latter post
• New Architecture Plugging in transport. Oleksiy has implemented the JMS and TCP transports using this new architecture
• Custom message processing using Pipe

We are working to make it stable and feature complete with respect to our previous release JAXWS 2.0 FCS. The nightly bits are regularly posted and soon we will be posting a stable release. Try out the nightly and send your comments to the JAXWS user mailing list and stay tuned for more...

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 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.

MTOM in JAXWS 2.0 RI EA3

By default MTOM encoding is disabled. To enable MTOM on a service all you need to do is to add enable-mtom attribute on the endpoint descriptor element.

Here is a sample descriptor from the mtom sample:

Object port = new HelloService().getHelloPort ();

//get the binding and enable mtom
SOAPBinding binding = (SOAPBinding)((BindingProvider)port).getBinding ();
binding.setMTOMEnabled (true);

Thats pretty much what you need to do to enable MTOM.  For details see the MTOM online documentation in jaxws-ws project on java.net. to try the sample, assuming you have JWSDP 2.0 installed with S1AS 8.2_02, try the mtom samples: $JWSDP_HOME/jaxws/samples/mtom and $JWSDP_HOME/jaxws/mtom-soap12. Here $JWSDP_HOME is where you installed JWSDP 2.0.

You can post your queries to jax-ws dev mailing alias.

This work is licensed under a Creative Commons License.