Earlier this week, Sun Microsystems officially released the newest version of its Java Web Services Developer Pack (JWSDP), a bundled download of the APIs necessary for building, testing, and deploying Java Web services. New to the release are the Java API for XML Registries (JAXR) and the Java API for XML Remote Procedure Call (JAX-RPC), both fresh from the Java Community Process (JCP).
All the APIs necessary for building and deploying Web services in Java will emerge from the JCP. Launched in December 1998 and revamped in 2000, the JCP is the process by which Java evolves and it will play a significant role in Java's future. However, many question the JCP's efficiency and capability in addressing Web services. Is the JCP adequately preparing Java for Web services? Perhaps a look at its recently released and forthcoming Web services APIs will give us the answer.
JAXR and JAX-RPC: The newest Web services APIs
In April, the JCP released the final JAXR version, which gives developers an API for building Web services that interact with standard XML registry specifications, including the two dominant registries: Universal, Description, Discovery, and Integration (UDDI) and ebXML. Regardless of whether a service has been published in a UDDI registry or an ebXML registry, with JAXR, a Web service can discover that service and publish its own services to either registry.
"JAXR is targeted to make life easier for the developer, which is true for all our APIs for XML," says Farrukh Najmi, JAXR specification lead and a Sun staff engineer. "And it starts by the mere fact that the programmer doesn't need to be an XML expert." The API hides certain details from the programmer, such as validating data, which JAXR automatically handles.
JAXR represents the most crucial API to Web services' adoption says Frank Sommers, JavaWorld's Web Services columnist, and founder and CEO of Autospaces. "It's like search engines," he says. "If people can't find your Webpage, it doesn't matter what it does, how you created it, or how one can interact with it—people just can't find it. Having searchable directories allows that discovery to happen, and JAXR lets a Java programmer programmatically interact with Web service registries."
Peter Kacandes, senior product manager for Java XML APIs in the Java software products division at Sun praises JAXR for helping developers work more efficiently. "You learn JAXR and now you have full access to the full range of both the ebXML standard and UDDI spec," he says. "With IBM's UDDI4J, for example, programmers have to learn the UDDI4J API, and when they want to use ebXML, they'd have to use some other specific API."
This ability to leverage multiple underlying standards with one API makes developers more efficient says Sun. JAX-RPC, just finalized in June, features similar capabilities. JAX-RPC allows developers to build Web applications that incorporate XML-based RPC (remote procedure call). The RPC mechanism lets a client communicate a remote procedure call to a server. JAX-RPC uses the Web services standards SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language), and XML Schema, and defines how to develop and deploy portable and interoperable Web services with Java.
"JAX-RPC is the Java way of developing and deploying Web services," says Rahul Sharma, JAX-RPC specification lead and a Sun staff engineer. "You develop a Web service endpoint using the JAX-RPC programming model. When you're developing this endpoint, you never assume what kind of client would invoke this Java endpoint for a Web service."
Both APIs are now available in the latest JWSDP, officially released by Sun on June 19. By using JAXR, JAX-RPC, and the other APIs available with JWSDP, developers can begin extending J2EE (Java 2 Platform, Enterprise Edition) 1.3 now. Sun says that JWDSP will link J2EE 1.3 to the upcoming 1.4 version, its Web services platform, so programmers don't need to delay Web services development. Earlier this year, Sun postponed its release of J2EE 1.4 to early 2003, citing that the JCP needed more time to approve necessary APIs. This announcement raised eyebrows and questions about the JCP's efficiency.
Is the JCP too slow?
The JCP receives the most criticism about its pace; many hold it responsible for slowing Java's development. The process involves numerous steps: First a vendor, group, or organization submits a Java Specification Request (JSR)—a request to develop a new spec or revise an existing one. Depending on the type of specification, either the Standard and Enterprise Editions Executive Committee (EC) or the Micro Edition EC reviews the request. Once the appropriate EC approves the JSR, the submitting organization forms an expert group, which drafts the JSR and submits it through numerous community and public reviews before proposing its final approval ballot. After the final release, any needed revisions go through a maintenance review. The process can span just a few months or drag out for years, depending on the specification and expert group; JAXR and JAX-RPC each took less than 18 months to develop.
"It takes too long to bring JSRs from initial concept to a workable version," says Humphrey Sheil, a technical architect.
This sentiment has only increased since Microsoft released .Net, its competing Web services platform, causing industry analysts to declare that Sun has allowed Java to fall behind. Sun denies such claims. "Think about it," says Kacandes. "UDDI is not a standard. It has not been submitted to a standards organization, but yet we're already providing support for it. The idea that we're behind is a myth because we're supporting these things even when they're still in their most fragile stages of adoption. We're giving Java developers the earliest access tools to get started with these technologies and standards."
Sommers agrees. "JAXR is a very well-architected API in the sense that it supports not only UDDI, but also ebXML, and other registry standards. Considering that presently only four to five UDDI 2.0 registries are currently operational—and (based on my experience) quite unreliable—and that only one ebXML registry is available, if anything, JAXR is ahead of the curve."
"Besides," he adds, "I don't see customers crowding at the gates, angrily demanding faster progress. If anything, faster progress might lead to a bigger disappointment down the road."
One reason developing a JSR can become time consuming is that in addition to forming the specification, the expert group produces the reference implementation that proves all aspects of the specification can be implemented, as well as a set of technology compatibility kits, which ensure the reference implementation conforms to the specification's details. The combination of these three goals gives Java its famous compatibility, its advantage over Microsoft. As Sun boasts, the process allows vendors to collaborate on the standards, yet compete with each other on the implementations.
Sometimes the inchoate underlying standards dictate the progress of pending APIs, as does the approval of principal JSRs. Plus, the sheer communal nature of the JCP just doesn't prove conducive to speedy progress, which, as Sommers hints, has its benefits as well. Regardless, the JCP's momentum continues to concern developers, specifically for crucial APIs.
"This situation could and should be addressed by fast-tracking top-priority JSRs," suggests Sheil.
Does the JCP have Web services covered?
Currently, JCP members are collaborating on the following APIs that will impact Java Web services development:
- JSR 67, the Java APIs for XML Messaging 1.0, provides an API for packaging and transporting business transactions using on-the-wire protocols
- JSR 104, XML Trust Service APIs, defines a standard API set and protocol for minimizing the complexity of applications using XML Signature
- JSR 105, XML Digital Signature APIs, defines a standard set of APIs for XML digital signatures services
- JSR 106, XML Digital Encryption APIs, defines a standard set of APIs for XML digital encryption services
- JSR 107, Java Temporary Caching API (JCache), specifies an API and semantics for temporary, in-memory caching of Java objects
- JSR 109, Implementing Enterprise Web Services, defines the programming model and runtime architecture for implementing Java Web services
- JSR 110, Java APIs for WSDL, provides a standard set of APIs for representing and manipulating services described by WSDL documents
- JSR 155, Web Services Security Assertions, proposes APIs that support Web services authentication and authorization protocols
- JSR 172, J2ME Web Services Specification, defines how Java 2 Platform, Micro Edition clients will access Web service endpoints
- JSR 175, Metadata Facility for the Java Programming Language, allows classes, interfaces, fields, and methods to be marked as having particular attributes
- JSR 181, Web Services Metadata for the Java Platform, defines an annotated Java format that uses JSR 175 to enable easy definition of Java Web services in a J2EE container
- JSR 183, Web Services Message Security APIs, defines a standard set of APIs for Web services message security
Sheil believes that JSR 109 is the most crucial to Java developers. "Don't get me wrong," he says, "the other JSRs for Web services are important too—without any one of them, the Java platform would not be able to provide full Web services support. However, it looks like the JSR that most Java developers will work with on a day-to-day basis is JSR 109."
As evidenced by the list above, the JCP is currently reviewing numerous Web services JSRs. Will these APIs suffice developers' Web services needs? "All of the main specifications that will underpin Web services on the Java platform are registered through the JCP," says Sheil. "However, the JCP only addresses the Java platform. Web services is technology agnostic, so Sun itself also needs to participate—be allowed to participate—on the industry-wide bodies, such as the Web Services Interoperability Organization (WS-I), to help define the standard and ensure that Java stays ahead of the game."
The WS-I organization, cofounded by IBM and Microsoft, invited Sun to join only days before the organization was publicly announced. Because Sun was not initially asked to be a founding member—a slap in the face to the company that invented the language that will serve as a basis for Web services—it has yet to accept its invitation. Sun has said it will join WS-I if the board accepts a proposal to add two new board members. This week the board agreed to such a plan, which, however, does not guarantee Sun one of those seats.
Unfortunately, Sun can't control the politics rampant in the IT industry, which Sheil believes could infiltrate the JCP itself. "I feel too that vendors with hidden agendas can kill or adversely influence a JSR to protect their own interests over the interests of the wider community," he says.
In addition, Sheil is still not satisfied with the JCP's treatment of open source projects. In March, Sun announced that the JCP would support open source JSR implementations. "However, Sun specifically did not bring some important J2EE specifications such as the Enterprise JavaBeans (EJB) specification under this new JCP umbrella, so open source J2EE server initiatives are still not covered," he says.
Sommers expresses concern that the JCP is overlooking Web services security. "There are proposals out there, but the real issues are more complex and subtle than what's being addressed," he says. "I just don't think anyone really knows the answers to the hard questions or has a roadmap for handling partial failure of highly interdependent Web services. For example, what happens when my service depends on your service, which depends on someone else's service, which then fails from time to time?"
Regardless of his security concerns, Sommers thinks the JCP is doing a good job tackling Web services and giving developers what they need to get started. He praises the JWSDP for being developer friendly. "It's a high-quality release that's usable out of the box," he says. "So, based on that, [the JCP] is working very hard on getting things out the door."