Is the JCP adequately preparing Java for Web services?
Tutorial Details:
Is the JCP adequately preparing Java for Web services?
Is the JCP adequately preparing Java for Web services?
By: By Jennifer Orr
A look at the recently released and forthcoming Web services APIs
arlier 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
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Is the JCP adequately preparing Java for Web services?
View Tutorial: Is the JCP adequately preparing Java for Web services?
Related
Tutorials:
 Program your Palm in Java, Part 1: The PalmOS
Emulator - JavaWorld November
1999
Program your Palm in Java, Part 1: The PalmOS
Emulator - JavaWorld November
1999
|
Program your Palm in Java, Part 1: The PalmOS
Emulator - JavaWorld November
1999
Program your Palm in Java, Part 1: The PalmOS
Emulator - JavaWorld November
1999
|
Add MP3 capabilities to Java Sound with SPI - JavaWorld November
2000
Add MP3 capabilities to Java Sound with SPI - JavaWorld November
2000
|
The art of EJB deployment - JavaWorld August 2001
The art of EJB deployment - JavaWorld August 2001
|
Web services hits
the Java scene,
Part 1
Web services hits
the Java scene,
Part 1
|
Use Web services
to integrate Web applications with
EISs
Use Web services
to integrate Web applications with
EISs
|
Discover and publish Web services with JAXR
Discover and publish Web services with JAXR
|
Is the JCP adequately preparing Java for Web services?
Is the JCP adequately preparing Java for Web services?
|
Effort on the
edge, Part 1
Effort on the
edge, Part 1
|
J2EE 1.4 eases Web service development
J2EE 1.4 eases Web service development
|
The Java Web Services Tutorial
This tutorial is a beginner\'s guide to developing Web services and Web applications using the Java Web Services Developer Pack (Java WSDP).
|
Call on extensible RMI
Call on extensible RMI
|
Improve Application Management With JMX
Improve Application Management With JMX
Leverage JMX technology and existing tools to boost the operations management capabilities of your business applications.
|
Turn EJB components into Web services
Summary
Web services have become the de facto standard for communication among applications. J2EE 1.4 allows stateless Enterprise JavaBeans (EJB) components to be exposed as Web services via a JAX-RPC (Java API for XML Remote Procedure Call) endpoint, al
|
The JavaTM Web Services Tutorial
A beginner's guide to developing Web services and Web applications on the Java Web Services Developer Pack
|
The Things I Wish I Learned in Engineering School: A Conversation with Sun Microsystems Distinguished Engineer Rick Catt
Sun Microsystems' Rick Cattell discusses why innovative software often never sees the light of day and how to remedy this problem.
|
J2ME Wireless Toolkit 2.2
Now available.This version of the toolkit is fully compatible with the Java Technology for the Wireless Industry (JTWI) specification (JSR 185).
|
Getting Started with Java Management Extensions (JMX): Developing Management and Monitoring Solutions
The Java Management Extensions (JMX) API is a standard specification developed through the Java Community Process (JCP) as JSR 3 for managing and monitoring applications and services.
|
Struts, JavaServer Faces, and Java Studio Creator:
The Evolution of Web Application Frameworks Sun Microsystems' Craig McClanahan, the creator of the Apache Struts Framework, co-specification lead for JavaServer Faces 1.0, and prime architect for Sun Java Studio Creator's new release, explains all three.
|
Chat Transcript: Java Web Services Developer Pack (Java WSDP) 1.5
Learn about the exciting new web services features in the recently-released Java WSDP 1.5.
|
|
|
|
