The concurrence of a web service stack's various pieces
I think this move is a bit like the one we did with JWSDP, for those of you who remember. Back then, we've been developing a bunch of composable but independent technologies (JAXP, JAXB, JAXM, SAAJ, JAX-RPC, JAXR, ...), and we realized that for most people they are too fine-grained. It is more convenient to be able to get them in a bundle, with a lot of testing to ensure that pieces work together.
In many ways, Metro is just that. The JAX-WS RI is made highly extensible and pluggable, so that enabled us to build composable but independent features (like transaction, security, reliability, custom transports, Spring support, JSON, ...) on top of the basic web service. But for most users, especially for those who are not using a dependency management system like Ivy or Maven, this is actually a nightmare, because you need to deal with a dozen or more of small jars. And as the number of configuration increases, people feel less comfortable about whether their particular configuration is tested.
So while it looks like a merger, or at least a friendly affiliation, of two projects under a common GlassFish umbrella, Metro can be more than that. It hopes to be a single destination for those who need an integrated, tested web services stack, yet still be flexible enough for those who want to swap in different pieces.
In light of this, we've cast
this week's Spotlight on
Metro. Combining the JAX-WS RI and WSIT projects, Metro bills itself as "a high-performance, extensible, easy-to-use web service stack. It is a one-stop shop for all your web service needs, from the simplest hello world web service to reliable, secured, and transacted web service that involves .NET services." More information and perspective is available in introductory blogs by Kohsuke Kawaguchi, Arun Gupta, and Harold Carr.
We begin the Java Today section with a related project. The JAX-WS Commons project, part of Project Metro, has added JSON Support for JAX-WS. "JAX-WS supports a "pluggable encoding" -- meaning it can use formats other than textual XML. This extension takes advantage of this and allows JAX-WS services to be exposed via JSON. JSON support is implemented as a custom binding. So just like there are SOAP/HTTP binding or Plain Old XML binding, you can specify JSON binding to expose a service as JSON service."
Work has begun on a new version of the Servlet API with the submission of JSR-315, Java Servlet 3.0 Specification, to the JCP. "Servlet 3.0 specification will work on extensibility / pluggability. Web framework pluggability will be a key driver of the Servlet 3.0 specification. As part of the revision for Java EE 6 we would like to revise the Servlet specification to support the Ease of Development (EoD) using the newer language features. Also along with EoD there have been requests for enhancements in other areas as well to support the modern next generation web application development." Balloting for this JSR closes on July 2.
Portlets define a streamlined way to aggregate content from several sources into a single Web application. In an MP3 interview with Artima, Use-Cases for Portlets, Brian Chan, chief architect of open-source portlet vendor Liferay, describes the use-cases for portlets.
Differing notions of Beans Binding top today's Weblogs. Shannon