By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Having just set up Bloor Research's Integration Infrastructure practice I thought I should review the press releases since the beginning of the year.
I came across an announcement from January 9th that started: 'A group of leading IT vendors, consisting of Fujitsu Limited, Hitachi, Ltd., NEC Corp, Oracle Corp., Sonic Software, and Sun Microsystems, today announced the publication of the Web Services Reliability (WS-Reliability) specification working draft. By providing a fundamentally more reliable transport infrastructure, WS-Reliability will help accelerate adoption of Web services, making them relevant for an even wider range of enterprise application and integration challenges.'
This caught my eye firstly because I agree with the sentiment that web services need to be made more reliable, but also because of the likely suspects missing from the list, especially IBM, BEA and Microsoft.
I looked at the draft and having spent the last few years working with reliable messaging I was somewhat surprised that this was just a definition of the message structures that should flow between SOAP nodes.
The application was still responsible for all the logic to ensure that a message was delivered including: creating unique message ids, saving the message in persistent storage, processing acknowledgements and timeouts, dealing with duplicate messages and messaging ordering.
I had hoped that all that would be dealt with by some middle layer. In fact I believe that this must be dealt with by standard middleware otherwise the fragility of the code will compromise the reliability of the whole system.
The draft specification states that :'(it) borrows from previous work in messaging and transport protocols, e.g., SOAP and the ebXML Message Services (ebMS). It proposes appropriate modifications to apply this work to Web Services'.
I looked at these specifications and it is certainly true that WS-Reliability borrows from them; but I found it more difficult to understand what modifications had been made and for what purpose. In fact I felt that the ebMS specification with its definition of Message Service Handler (MSH) covered what I had expected to see in the WS-Reliability specification.
In conclusion I failed to be impressed because:
- It failed to explain why it was important
- It failed to explain how it integrated with the existing standards
- It failed to simplify the coding required by the application
Watch this space for more detail as I continue my exploration of this area.
Copyright 2003 IT-Director.com provides IT decision makers with free daily e-mails containing news analysis, member-only discussion forums, free research, technology spotlights and free on-line consultancy. To register for a free email subscription, click here.
For More Information:
- Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
- Are you tired of technospeak? The Web Services Advisor column uses plain talk and avoids the hype.
- For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
- Hey Codeheads! Start benefiting from these time-saving XML Developer Tips and .NET Developer Tips.
- Visit our huge Best Web Links for Web Services collection for the freshest editor-selected resources.
- Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
- Choking on the alphabet soup of industry acronyms? Visit our helpful Glossary for the latest industry lingo.
- Couldn't attend one of our Webcasts? Don't miss out. Visit our archive to watch at your own convenience.
- Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.