Skip to main content


Posted by editor on June 25, 2007 at 7:31 AM PDT

The concurrence of a web service stack's various pieces

So why Metro? What's the deal big enough for several of our bloggers to be talking about it last week? I think Kohsuke does a great job explaining by example:

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 Hickey announces
Beans Binding 0.6.1 Release Available:
"Two days after the 0.6 release of Beans Binding, the 0.6.1 release is out with simpler and more intuitive method names and constants."

However, Rémi Forax brings up some concerns in
Beansbinding goes to the wrong direction:
"After reading the Shannon Hickey's Blog about the recent release of beanbinding 0.6, i've decided to take a look to beanbing and i think that the API doesn't guide the user enough."

Elsewhere in the blogs, David Van Couvering reacts to a remarkable open-source contribution in
Replication? In Java DB? Wow.
"Just found out that Egil Sorensen, a student at NTNU in Trondheim, has contributed his thesis work - replication and hot standby for Apache Derby - to the Derby community."

In today's Forums,
freelyfallers wants guidance in moving an app to a
handheld device.
"I have developed an application for Inventory Control System in Java some years ago. The front end is in Java Swing and backend is Oracle 9i. Now I want to develop the same application for PDA(Handheld device). Does J2ME support PDA for such development. if yes, how is it possible? What are the technicality i have to consider for this project."

Sean Sheedy resets the context of the proposed deprecation of ME's pauseApp() in
Re: pauseApp questions from the MIDP3 EG.
"The question is, has the low end of devices risen to the point where they are sufficiently capable of handling system critical tasks (phone calls) without having to turn off MIDlets? I think it is up to the manufacturers and implementers (and I take it that your company is the latter) to let us know where the manufacturers stand. As I am now an individual JCP member, I tend to take the perspective that if there is some way we can get CPU time for our threads when we don't have the display (such as in a phone call) and new notification mechanisms exist that replace those overloaded onto pauseApp, then we don't need a paused state any more."

What really matters in terms of app server performance? In
Re: Once again -> Glassfish vs. JBoss, whartung writes:
"In many cases, most applications are limited by their DB tier rather than the application server. And if your application is written well enough to partake in a load balanced configuration (not spectacularly difficult for many applications -- the community has been preaching the design models for year), then whatever performance difference is recorded between WLS and SJAS can be readily, and practically, compensated by hardware. And you can buy a LOT of hardware for the price of BEA WLS licenses. Finally, many IT systems are tapped out trying to eek out the last 10/10th of performance, but a significantly larger percentage really aren't. They're simply not loaded that hard. I can safely say, tho, so far, that because of JEE 5, EJB3, and the JPA, and leveraging that technology, our applications run better, and are easier to maintain."

Current and upcoming Java

Registered users can submit event listings for the href=""> Events Page using our href="">events submission form.
All submissions go through an editorial review before being posted to the

Archives and Subscriptions: This blog is delivered weekdays as
the Java
Today RSS feed
. Also, once this page is no longer featured as the
front page of it will be
archived along with other past issues in the href=""> Archive.

The concurrence of a web service stack's various pieces