The web services integration and Corba software vendor recently announced it has co-sponsored the formation of the OASIS Web Services Reliable Exchange (WS-RX) Technical Committee, which has the goal of driving progress of the WS-ReliableMessaging (WS-RM) specification toward standardization.

Before it was handed over to OASIS for ratification as a standard, the spec was authored by BEA Systems, IBM, Microsoft and Tibco.

For several years, Microsoft and IBM have been working on WS- specs, such as WS-Security and WS-Trust, to enable interoperable web services. While other vendors can and do contribute, the process is invitation only.

The issues surrounding the authoring of web services specifications came to a head earlier this month, when executives from IBM and Microsoft faced criticism that WS- specs are not pushed into standards processes early enough.

A debate at the Digital ID World conference in San Francisco saw attendees asking Microsoft and IBM to develop the specs in the open, where any vendor could contribute, and Microsoft and IBM saying such processes are not suitable.

It’s not necessarily the optimal process for everything, John Shewchuk, chief technology officer of Microsoft’s Distributed Systems Group, said during the debate, in what some considered a ‘gotcha’ moment. What comes out at the end may not meet our technical objectives as a vendor.

But Iona’s Newcomer said: There are two issues here: the speed of submission of specs to a standards body, and the visibility into the development of those specs in the first place.

We have talked to IBM and Microsoft about improving the processes on both counts, Newcomer continued. Speeding up their submission to standards bodies, and enabling greater visibility, so that companies like us and others that face the risk that specs might change can see what’s going on. If we could improve the visibility that would help a great deal.

Newcomer did say however that he could see the point of view of IBM, Microsoft and other web services specification authors.

I do have some sympathy, he said. The approach sometimes needs to be different if you are after quick, quality results. Sometimes it can be better to progress a technical spec in a small team. We have worked with both the W3C and OASIS and it can be difficult. There is a trade-off between involving everyone and potentially having slower progress, and between getting a quicker result.

Newcomer said that as a result some web services specs may best be written by just a few vendors, as they are today. But either way, greater visibility into the process for other interested parties would be a good thing.

Meanwhile OASIS has attempted to allay fears that even after they have been submitted to the standards group for ratification, the evolution of web services specifications into standards could be controlled by a few of the largest vendors, who if nothing else are able to contribute the most developer resources to the work.

Announcing the formation of the OASIS WS-RX Technical Committee, which will oversee the development of the WS-ReliableMessaging v1.0 and WS-RM Policy v1.0 specifications, OASIS said that changes to these documents, as well as other contributions, will be considered and evaluated based on technical merit, business requirements of users, and the Committee’s charter.

But Newcomer conceded that despite these assurances, It is true – the fact some companies have greater means to influence a spec is a concern. The flip-side of that coin, he said, was the fact that, We’re always very happy whenever a specification gets submitted to a standards group, because then we and the other contributors do have the ability to influence the specs in an open environment.

To date over 25 organizations have joined the WS-RX Technical Committee, and it’s still accepting participants. Existing members include Actional, Adobe, BEA Systems, DataPower, Entrust, Hitachi, IBM, Iona, Microsoft, NEC, Novell, Oracle, Reactivity, SAP, SeeBeyond, Sonic Software, Sun Microsystems, Systinet, Tibco and webMethods.

WS-RM is intended to provide a standard method for ensuring that a message delivered between disparate systems and applications reaches the intended destination reliably.