eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The Web Services Reliability (WS-Reliability) specification will be going to the Organization for the Advancement of Structured Information Standards, or OASIS, standards body in a new technical committee known as the Web Services Reliable Messaging Technical Committee.
In a memo sent to OASIS members Thursday, the organization called for interested members to participate in the new technical committee that has been proposed by Sun Microsystems Inc., Sonic Software Corp., IONA Technologies Inc., Fujitsu Limited, Hitachi Ltd., NEC Corp. and Oracle Corp.—developers of the initial WS-Reliability specification—as well as CommerceOne Operations Inc., SeeBeyond Technology Corp., webMethods Inc. and SAP AG.
The new technical committees goal is to “create a generic and open model for ensuring reliable message delivery for Web services,” the OASIS memo said. In addition, the technical committee defines “reliable message delivery as the ability to guarantee message delivery to software applications—Web services or Web service client applications—with a chosen level of quality of service (QoS).”
Initial input for the WS-RM specification will come from the WS-Reliability specification published by Fujitsu, Hitachi, Oracle, NEC, Sonic Software and Sun on Jan. 9, 2003, when the group announced its intent to create a standard and submit it to a standards body.
In an interview with eWEEK at Oracles headquarters in Redwood Shores, Calif., Jeff Mischkinsky, Oracles director of Web services and the companys lead representative on the new OASIS technical committee, said reliability, security and interoperability are the three main obstacles that need to be overcome before Web services really take off— particularly for use outside the firewalls of an enterprise. “We need to get those three things nailed,” he said.
Mischkinsky said Oracle had some ongoing work that fit well into the WS-Reliability scheme. “We have tons of experience doing reliability with all of our database work,” he said. “This problem has been solved before in proprietary ways,” but the committees goal is to deliver a standard solution, he said.
“The specification is a way to extend the standard SOAP framework,” Mischkinsky said. “It adds reliability to SOAP messages.”
Sources said the group expected several more companies to join as sponsoring members of the specification, including IBM and BEA Systems Inc. In fact, sources said the announcement that the group was moving to OASIS was delayed in hope that IBM or BEA would join the sponsoring group, but neither company would make the move by the middle of this week.
When the WS-Reliability founding group announced the specification last month, IBM said it was considering getting involved. BEA, for its part, said it too is considering the specification—and the new technical committee.
John Kiger, director of Web services at San Jose, Calif.-based BEA, said: “Reliable messaging is one of the most important areas that need to be addressed for Web services in 2003. BEA has implemented reliable messaging for Web services in the upcoming release of BEA WebLogic Platform and will be actively engaged with industry partners to drive an open, industry standard for reliable messaging. BEA has reviewed the WS-Reliability specification, and we are evaluating various groups to work with on producing a widely adopted, open, royalty-free reliable messaging standard.”
The OASIS memo said QoS will be defined as the ability to determine message persistence, message acknowledgement and resending, elimination of duplicate messages, ordered delivery of messages, and delivery status awareness for sender and receiver applications.
Ronald Schmelzer, an analyst with ZapThink LLC, Cambridge, Mass., said, “Developers and IT organizations wont implement any important Web services without being able to guarantee that they will be executed in a guaranteed manner.”
The technical committees first meeting will be held on March 26 over the phone. A requirements document will follow within two months of the first meeting, with a final draft of the specification due within six months of the first meeting.