The Java Community Process(SM) Program - Press & Success

Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy

Press and Success
Success Stories

Organization Drop Proprietary Solutions in Favor of Java Community Process^SM (JCP^SM) Standard JSR 101 JAX-RPC API
JSR 101

Necessity may be the mother of invention, but unless a high technology "invention" conforms to standards, would-be adopters may embrace it only with reservations. Today's developers, businesses, and manufacturers are well aware that if an application programming interface (API) is not portable and interoperable, it is likely to lead down a proprietary dead end.

The Fits and Starts of JAX-RPC

Graham Hamilton, chief technology officer of Java Software at Sun Microsystems, is known as the brain that instigated JAX-RPC. By late 2000, several remote object access protocols, including CORBA (Common Object Request Broker Architecture) and RMI (Remote Method Invocation) had already been specified in the Java platform. However, with the goal of making the Java language the optimal way of programming XML (Extensible Markup Language), Hamilton felt it was "really important" to add fully integrated Java platform support for remote object access using SOAP/XML-based RPC.

Previous experiences with CORBA and RMI were enlightening. Hamilton says, "With CORBA we learned the importance of closely following standards and interoperating with other vendors. But with RMI we learned the benefits of providing a simple Java programming model where developers could do all their programming in Java and ignore things like interface definition languages. So with JAX-RPC we consciously tried to capture the best of both worlds."

Hamilton's group decided that JAX-RPC would support an RMI-like mapping, enabling programmers to define all their methods in Java and have them mapped to SOAP and WSDL (Web Services Description Language) automatically. Another central goal for JAX-RPC was careful adherence to the SOAP specifications, so JAX-RPC developers would always have full interoperability with other languages and platforms.

Hamilton was excited about JAX-RPC, but projects were hopping at Java Software. He complained to Rich Green, vice president of the Java Platform, "We're out of our budget cycle and we're out of money! Damn!" With remarkable foresight, Green agreed that JAX-RPC was a priority anyway, and he gave the project a green light.

Others confirmed the market's interest in the technology. "As soon as we started talking to JCP partners about JAX-RPC, we started getting lots of positive interest and feedback. It became clear this was a technology that was arriving at the right time," says Hamilton. Since he didn't have time to lead the JAX-RPC expert group, Hamilton passed the gavel to Rahul Sharma, one of Sun's senior Java architects.

BEA Systems, Systinet, and Oracle, as well as the open-source Apache community have no such reservations when it comes to implementing the new API specification, JSR 101 Java tm API for XML-based Remote Procedure Call (JAX-RPC), developed through the Java Community Process^SM (JCP^SM) Program. In fact, these organizations are supplanting their own proprietary solutions in favor of the JAX-RPC standard, thereby endorsing its efficacy.

RAPID PROGRESS THROUGH JCP STANDARDS BODY

JSR 101 JAX-RPC was developed through the Java Community Process standards body to help developers build Web Services that were assured of portability and interoperability. These two factors are critically important in guaranteeing that a Web Service such as a weather report or a stock quote works as flawlessly with one vendor's product as it does with a different vendor's product.

Spec lead for JSR 101 and a former senior Java architect at Sun, Rahul Sharma scheduled the Java Specification Request (JSR) to deliver a specification within a year. The expert group's active participation in face-to-face meetings, weekly conference calls, and email contributions allowed them to achieve their aggressive milestones while delivering a tightly scoped, high quality JSR.

Rahul Sharma, former Sun

Rahul says the team wanted to move quickly to ensure the portability and interoperability of Web Services through a standard Java API, since multiple non-standard APIs were emerging. Moreover, several other JSRs, including the latest specification for Java 2 Platform, Enterprise Edition (J2EE), depended on JSR 101's critical support for the development and deployment of Web Services.

Systinet and other companies were eager participants in the effort to develop JSR 101 JAX-RPC. "Systinet is a big believer in standard APIs, so as soon as the JCP started the effort to create a standard API for Java technology to access SOAP, we joined that expert group and started participating," says Anne Thomas Manes, an author and Systinet's former chief technology officer.

BEA BRINGS OUT JAX-RPC IMPLEMENTATION IMMEDIATELY

During the time expert group participants develop an API for the JCP, they may simultaneously develop their own implementation of the evolving spec. Through their active participation in the JSR 101 expert group, BEA Systems was the first company to implement the JAX-RPC specification and pass the Technology Compatibility Kit (TCK). BEA had been working on their implementation for at least six months, in parallel with the expert group's work. When JAX-RPC 1.0 was approved as final early in June 2002, BEA acted quickly. By the end of that month, BEA had delivered to developers and customers a production-quality implementation of that specification as part of their WebLogic Server 7.0.0.1 (WLS).

Before the 7.0.0.1 release, BEA had relied on a proprietary API for invoking Web Services, but that was replaced when the JAX-RPC API became available. John Kiger, director of Web Services, marketing, acknowledges the importance of standards, saying, "The value of providing a standard way to implement or deliver a technology is of tremendous importance to our customer, so it's part of the Web Services solution that BEA delivers, and part of the value proposition in our solution is our commitment to the open standards."

John Kiger, BEA

Standards are important to developers as well. Don Ferguson manages BEA's Web Services development team for the Web Services implementation that ships with WLS. He says, "As a developer, when you learn one set of APIs, it's more useful for that knowledge to be based on a standard. You can go into a bookstore and buy books that tell you how to use the standard. If you ever need to go to a different company, your knowledge is portable because you're based on standard technology."

APACHE ADDRESSES JAX-RPC AT USERS' REQUEST

Like BEA, the Apache open-source community moved quickly to incorporate JAX-RPC. Glen Daniels, Macromedia's Web Services tech lead, is a developer on the Apache Axis project and a participant in the JSR 101 expert group.

Apache already had a couple of Web Services engines -- the original Apache SOAP code base and its reimplementation in the Apache Axis project. But as Apache monitored JSR 101 development, it was decided that Axis should be a JAX-RPC implementation. Daniels says, "Originally we thought Axis was not going to be JAX-RPC compliant in the first version because we wanted to release something soon. But as the schedule slipped for Axis and JAX-RPC got closer to final, we heard comments from our users that it would be really good if we were JAX-RPC compliant. So we decided to hold off on our 1.0 release until we could meet the JAX-RPC spec."

Daniels did not find the implementation work to be difficult. "We took a lot of the code already in Axis and wrapped it in the JAX-RPC interfaces. In general, it was pretty easy to do because a lot of the concepts in JAX-RPC are fairly universal across any Java Web Service implementation." Having passed the essential JAX-RPC TCK milestone, Apache released Axis 1.0 early in October.

JAX-RPC technology elicits a variety of responses from the Apache community. According to Daniels, those who use it are pleased to have an agreed-upon API that everybody in the J2EE world who deals with Web Services can rely on. "It's nice to have a standard API for some things, so if you don't need any of those particular tweaky features that individual implementations have, you can write your framework one time and be able to use it on top of a number of different vendors' products," he says. Implementers at Apache are excited to be able to help define the technology, especially given the new update to JCP version 2.5, which makes enhancements to give open-source equal standing in the community, including no-cost access to TCKs for non-profits and the possibility of open-source licensing and independent implementations of a specification.

"As we move forward, Apache is going to enable all these great developers to get more input into the JCP in a way they might not have before, and that's a great thing," Daniels says. In general, the message from Apache is that "innovation is a really good thing, and standards overlaid on top of that make it possible to scale in a way that makes sense."

SYSTINET SHELVES PROPRIETARY API TO IMPLEMENT JAX-RPC

Like other organizations, Systinet had implemented a proprietary API to enable Web Services, but they are glad they can rely on a standard now. Anne Thomas Manes says, "We decided it was really not very helpful to have a proprietary API. Systinet is basically rearchitecting the product around JAX-RPC, and the proprietary API is going to go away."

This decisive move to embrace a new standard is certain to please Systinet customers -- developers, businesses, independent software vendors (ISVs), and original equipment manufacturers (OEMs). Sometimes it is necessary to use multiple SOAP stacks, and JAX-RPC provides a common API that works with any SOAP stack. "I view JAX-RPC as the standard Java language binding for SOAP. One key feature that it provides is a standard mapping between Java data types and XML Schema data types," says Thomas Manes. "A common API that works across all products is a wonderful thing for the developer. They only have to learn one API and not all the differences among the various products out there."

Anne Thomas Manes, former SystiNet

Business customers that use Systinet's solutions also appreciate the fact that the Systinet product supports standards. "They know their developers are going to be able to use them without going through a long learning curve to figure it out. And if they have to use multiple implementations for whatever reason, it's always nice to have ones that conform to the standard," Thomas Manes says.

Thomas Manes perceives an even greater advantage for the ISVs and OEMs who embed Systinet's technology. "They are trying to add SOAP support to their product, and they use our technology to add that SOAP support." They don't want to have to require their customers to buy Systinet tools in order to use their product. JAX-RPC is sufficient to use the product, "and that's a huge win for them," she says.

Systinet has preliminary support for JAX-RPC available today, based on the 0.7 release of the specification. Systinet's SOAP implementation for Java technology, WASP 4.0 (Web Applications and Services Platform) acts as middleware to allow one application to talk to another. The JAX-RPC API provides a standard interface for applications to talk to SOAP services, so JAX-RPC is the client API used to call one of Systinet's services.

Of the three interface APIs -- stub, service, and call -- that were defined as part of the JAX-RPC specification, Systinet has implemented support of the call interface for dynamic invocation, with support of the service interface for dynamic proxy soon to follow. Soon, support is expected for the stub interface, a Web Services description (WSDL) compiled into a routine that interfaces with a client. Once the entire JAX-RPC API has been implemented, Systinet's product will submit to compatibility testing under the TCK, which Systinet is in the process of licensing from Sun Microsystems.

ORACLE OPTS FOR CLEAN JAX-RPC IMPLEMENTATION

Unlike BEA, Apache, and Systinet, Oracle seems to be taking a more measured approach to implementing JAX-RPC. Their current Web Services product uses a non-standard API. Don Deutsch, Oracle's vice president for standards strategy and architecture, explains, "Because there was no standard solution, we, like everyone else, had to roll our own, and that's one reason we're enthusiastic about JAX-RPC. We see this as a fundamental building block for Web Services, and prior to JAX-RPC there really was not a standard API in any language for doing Web Services."

Don Deutsch, Oracle

Senior engineer Neal Wyse, of Oracle, adds, "Having a standards-based approach to the APIs and functionality as opposed to what everybody else rolls on their own helps provide a common set of features and functionality that everyone implements. For customers, they don't have to worry about whether Oracle's solution is different from Sun's, or different from IBM's." Having core functionality defined in the standards allows implementers to implement that core but also focus on where Oracle, for example, adds value. "This makes the process a lot cleaner," says Wyse.

Neal Wyse, Oracle

Oracle plans to implement JAX-RPC in the next major release of Oracle's Application Server. "Having been involved with the design of the specification, we're glad to see the fruit of our efforts," Wyse says.

RIGOROUS TCK ENSURES COMPATIBILITY

Bringing Web Services and J2EE technology standards together is an important step for extending the power of the J2EE platform into a Web Services environment. And JAX-RPC helps make that happen in a way that ensures portability and interoperability for all implementations that pass the compatibility testing. The Technology Compatibility Kit is the strong arm that makes sure implementations of the JAX-RPC API will work in a standard fashion.

Implementations that support JAX-RPC have to pass the TCK to claim compatibility with a specific standard set of APIs. The Sun Reference Implementation, BEA implementation into the WebLogic Server 7.0.0.1 (WLS), Apache Axis open source implementation, and Systinet WASP 4.0 must pass the compatibility test before they can achieve certified compatibility.

Don Ferguson of BEA is complimentary of the rigorous nature of the TCK. "We found the quality of the TCK to be high, and I think that's important for anyone who is implementing the technology. You want to have a good compatibility test. It proved to be very effective at finding areas where the specification had been somewhat ambiguous and showing how the implementation needed to be done," he says. "We were very fast in getting WebLogic Server 7.0.0.1 certified, passing the TCK, working with Sun to either fix product problems or to test problems, and getting a version out there for production use."

The TCK process was interesting for Apache on several fronts. Glen Daniels says, "This was the test case for the new licensing agreement for the TCK, so we were kind of the testing ground for that. Barring a few fits and starts in the beginning in terms of getting communication hooked up with the right people, it was just a great process." For Daniels, what constitutes a great process is the fact that Apache disputed several items in the TCK, and those items were successfully resolved.

A GREAT STEP FORWARD

Graham Hamilton, the original Sun Microsystems brain behind JAX-RPC, is pleased with JSR 101 and its handling by spec lead Rahul Sharma. "In watching the evolution of JAX-RPC I've been constantly impressed by Rahul's skill in balancing the needs and input of different expert group participants and thereby creating a single standard that can be used by the whole Java community. I think the final JAX-RPC specification is a great piece of technology that more than meets our original hopes for an easy-to-use Java technology integration of SOAP RPC," he says.

Graham Hamilton, Sun

"The JAX-RPC API has shown itself to be a well-conceived set of functions for doing standard synchronous invocation of Web Services," agrees Don Ferguson. Based on his reading of messages posted on the WebLogic developers newsgroups for Web Services, he concludes that customers are able to do what they need to do with the JAX-RPC API suite.

"JAX-RPC is a great step forward," says Glen Daniels. "There are further places to go, but JAX-RPC is a first very tangible step in getting Web Services into the consciousness of the Java community. In general we did a pretty good job getting the spec out there. It's not perfect and it doesn't cover every single base, but it's a very good start."

Plans are underway for the next version to give developers more of what they want. The current JAX-RPC API already helps Java developers with development of portable and interoperable Web Services, increased productivity, support for open standards (XML, SOAP, WSDL, XML Schema), and multiple implementations. Rahul Sharma says, "With continued feedback and support from a strong Java developer community, we aim to evolve the JAX-RPC API incrementally to address the evolving Web Services standards and technologies. Such support offered in a collaborative open process is what makes Java standards successful."