Eduardo Pelegri-Llopart's Blog

June 2004 Archives

JWSDP 1.4 is out!

• FCS implementation of JAX-RPC 1.1 with substantial performance improvements and implementing WS-I BP 1.1 and WS-I's Attachment Profile 1.0.
• FCS implementation of JAXB with substantial performance improvements.
• FCS JAXP 1.2, with new renamed packages, and with XSLTC as default transformation engine.
• EA support for OASIS's WS Security.
• EA support of JSR 105, implementing XML Digital Signature.
• Tested with several containers: Sun's App Server 8.0 PE (this the same as the free J2EE 1.4 SDK), Sun's Web Server 6.1, and Tomcat 5.0

A longer list is at Sun's web site, but below are some comments on this one.

In Sun's parlance, FCS stands for "first customer shipment", and means the component is production ready. In the case of the JWSDP, the license for FCS components allows deployment, but they are not supported - the supported versions will show up when bundled in later releases of Sun's products. EA stands for "early access" and indicates the component is useful for development but there may still be changes in the component, including the API!, before it becomes FCS quality.

JWSDP 1.4 has a number of substantial performance improvements. On the JAXB front, the biggest improvements were on marshalling and unmarshalling: when measured using an internal microbenchmarks we saw about 2x improvement; much of this thanks to direct feedback from the weekly builds at the JAXB project at java.net. I don't have specifics handy on the JAX-RPC improvements but they are key contributors to the recently published results on a macrobenchmark analysis comparing J2EE and .NET on WS and XML. XSLTC is, of course, the XSLT compiler that started as Sun experimental work, was then donated to Apache and is now in full product-ready mode (it is bundled in Tiger!); we see between 2.5x to 11x improvements in performance when compared with Xalan classic- although this depends on whether you apply the stylesheet only once, or several times. The usual disclaimer applies: although the numbers we quote are our best understanding of the real situation, your performance may vary... (there are lies, dammed lies, and benchmarks :-)).

The WS-I's Attachment Profile 1.0 is the MIME-based spec from WS-I that describes how to send attachments in WS messages. Attachments are critical to practical applications of WS and I believe that JWSDP is the first FCS-quality implementation of this standard.

The other major change on JAXP, besides the change of the default transformer (Xalan classic is still there, just not the default), is that the packages got renamed. This is so that you don't have to do classpath magic (which too often leads you into trouble) if you want to use at the same time the new JAXP classes and some other version of Xerces or Xalan.

I could also talk more about the JDBC RowSet Implementations 1.0 JWSDP 1.4 Co-Bundle, which provides a set of tools, documentation, samples and tutorial for developers who want to use JDBC RowSets with Web Services, but I'll talk more about that in another blog.

Finally, I just noticed that Marc also posted a blog on the JWSDP; Marc is a key participant at WS-I, among many other things, so he is your man in that area of the JWSDP!

JAXB 2.0 and JAX-RPC 2.0 EA specs are out

Check the specs out. As an EA, there are some relatively big holes in the specs; for example, the JAXB 2.0 spec is only hinting at the addition of updateable partial binding, which I think is a very big improvement. There are a number of other key improvements, including:

• Integration of the two specifications: you now will be able to use the full JAXB machinery to do data-binding on JAX-RPC invocations
• Completion of much of the customization features in JAXB that were hinted in JAXB 1.0.
• Updateable partial binding, where a portion of an XML document can be bound to Java objects, which can then be updated and then converted back to a document.
• Support for asynchronous messaging in JAX-RPC.
• Support for other transports to HTTP in JAX-RPC.

There are other features; attend the JavaOne sessions on these topics to get more details, and I'l invite Marc, Roberto, Sekhar and Joe to present at some technical forum in the near future.

You should know about the J2EE SDK...

AppServer 8.0 PE uses technology from multiple sources. For example, the JAXB and JAX-RPC implementations are verbatim from projects at Java.Net; while the JAXP implementation and JSP, Servlet and JSTL implementations are based on the XML and Jakarta projects at Apache. Other pieces, like the JMS and EJB implementations are Sun internal. The result is a strong implementation of the latest J2EE standard, J2EE 1.4.

I think Sun has done a pretty good job with the AppServer 8.0 PE. There is still work to be done, but it is much better suited to the needs of developers than previous versions. And, from the feedback I have seen, many people agree: we have seen a large number of downloads and the download numbers are increasing.

I can't tell if AS 8.0 PE is the server-side container for you. Maybe you like Tomcat better, although 8.0 PE has a version of TC 5.0 in it. Maybe you like Jetty, or Resin, or maybe you like JBoss. Or WebLogic or WebSphere or something else. But I think you might want to check it out, read its FAQ and, if that sounds interesting, perhaps download it. And, if you like it, vote for it at this week's poll :-).

Disclaimer: As a Sun employee working in the Java Platform group, I have carried two hats for the last 8 years. Most of the time I carry my Community Advocate hat; sometimes my Sun Employee hat; most of the time both hats (and the reason why I work at Sun is because for the most part these two hats are well aligned). I am carrying both hats for this blog - perhaps with a bigger Sun hat than usual :-)

Tiger Snapshots: bringing early feedback into the release cycle...

The intention of the snapshots are to get early feedback into the final stages of releasing Tiger. This approach has proven very successful in many communities - it is particularly common in the open source community - and I am particularly happy that Sun is embracing it in a number of product families. From my engineering perspective, it is nice to see this tendency: it can only lead to improved quality in the products.

Here are some other "early access" releases from Sun that I am aware of:

• Tiger snapshots
• Solaris express
• NetBeans Development Downloads
• Weekly builds for JAX-RCP and JAXB.

Technical Forum on Web and XML -- Call for topics and speakers

The topics for the forum would cover XML Applications, Web Applications and Web Services - again, we fine-tune as we go.

I already have a number of ideas and victims... err, potential volunteers. Please contribute ideas in the talkback of this blog.

Simple, Fast, no-Loss binary XML - Fast Infoset

There have been a number of attempts to address this problem by using some sort of binary encoding of XML. But the benefits of the approaches have not been researched carefully, and the lack of a standard has indered their adoption. I've been involved in a group that investigated this problem some time ago; the explicit goal was to match RMI-performance using WS interfaces and we discovered that if we exploited the type (schema) information in the WSDL we got very close to that goal. We coined the approach Fast Web Services and the approach is being standarized in ISO/ITU-T.

Fast Web Services relies on Schema information, but in some applications the Schema is not available (or even when we have a Schema information, whenever type Any appears), so some complementary solution is needed. Also Fast Web Services does not preserve the XML infoset - think of "sending the content, not the form" - while in many applications that is key. Both requirements are addressed by a technology we call Fast Infoset. The solution has good performance characteristics and is not hard to implement, and Fast Infoset is also being standarized at ISO/ITU-T.

One way to think of Fast Infoset is as a GZIPed XML. It has the same property that you only need to know it is encoded to recover the original. The main difference is that Fast Infoset is customized for XML and leads to better encoding and decoding times. Check out the article by Paul, Alessandro and Santiago to get all the details.

I believe that both Fast Infoset and Fast WebServices are useful; we will find out how much when the standards are finalized later this year and we start seing implementations. There is also a W3C Working Group in XML Binary Characterization that will consider the role of this and other technologies.

This work is licensed under a Creative Commons License.