>Over the last year, I concentrated much of my community contributions and development time for eclipse on the XML and XSD editors provided by the eclipse Web Tools Platform. The reason was primarily from frustration of using the tools when it came to real world B2B schemas produced by various standards organizations. Web Standard Tools 3.0 addresses many of the issues that plagued the XML and the XSD tools, and is much better suited to handling the large and complex XML related files that have to be exchanged.
The next victim that needs to be patched and bandaged up are the Web Services tools provided by the project. In particular the WSDL Editor and more importantly the WS-I Profile tooling, and the Web Services Explorer. The later which is just unuseable for WSDL that is produced by STAR or OAGi. The Web Service Explorer becomes unresponsive and has forced my recommendation of other tooling to get the work accomplished.
So, since I have a need this year to get this addressed for some tooling that I’m working on, I’ll be devoting some of my time to trying to help the Web Services team, patch up and address the performance and compliance related issues. In particular, we need to make sure that eclipse is the standard for WS-I profile compliance testing. It also should be extensible enough that new profile plugins can be added easily as the profiles are completed. The compliance reports also need to have the ability to run in eclipse, and without eclipse. There needs to be a way to generate the WS-I Compliance reports quickly and easily.
Better support for newly released standards like WS-Reliable Messaging, MTOM, WS-MakeConnection, WS-Policy and WS-PolicyAttachment needs to be included in the base frameworks. Some of these would be simple to do by including the appropriate XML schemas as optional jars to be installed. The same thing needs to happen for ebXML 2.0 and the forth coming ebXML 3.0 (yes there is an enterprise alternative to the WS-* mess).
Web Services Interoperability is a hard thing to obtain. Everybody has their own way they like to do things and their own specific requirements. The specifications are designed to be flexible, but with that flexibility comes interoperability issues amongst implementations. The tooling that eclipse provides should strive to become the reference implementation. This however also requires that the user community helps provide the expertise necessary to verify that the tooling is meeting the specification. If tools don’t meet the specifications, then it just propagates interoperability issues, and adds to the overall cost of system maintenance.