 | |||
|
|
||
| |||
| |||
| |||
|
||||||||||||||||||||
| |
|
Home > SOA News > Web Services Reliable Messaging Protocol - impresses more |
| |
|
|
|
|
| SOA News: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
|||||||||||||||||||||||||
Market Analysis In January a draft Web Services Reliability specification was announced and I wrote expressing some concerns about the specification. My first concern was the noticeable absence of IBM, Microsoft and BEA from the sponsor list. On March 13 it became clear why, when they, along with Tibco, announced their own 'Web Services Reliable Messaging Protocol' specification in this space. The two specifications address the same issue of how to ensure delivery of messages from one Web service to another, including the different levels of service ranging from 'at most once' to 'exactly once and in order'. However in their detail of how to do this, the terminology used and the schemas, required they are totally incompatible. Given that many of the other WS specifications have been created by people from both camps, and therefore the parallel development must have been apparent, it is difficult to understand why both specifications have got as far as publication. On initial viewing the 'Web Services Reliable Messaging Protocol' appears more coherent and complete than the previous specification, and its title more accurately describes the specification scope. My next concern was that there was no introduction of the problem space and the solution. In the new specification this has been answered by IBM and Microsoft jointly creating an introductory white paper called 'Reliable Message Delivery in a Web Services World: A Proposed Architecture and Roadmap' which helps to define the need for the specification and outlines how it relates to a set of other Web services specifications including addressing, policy, security, trust, encryption, coordination and transactions, and points to the need to develop further specifications relating to metadata exchange, endpoint resolution and transmission control. The one specification that was not referred to is the ebXML Message Services which seems surprising given the closely correlation between the problem spaces. I have a small niggle with the example used in this white paper; it appears to be a requirement for over night batch transfer of files between two enterprises, not exactly a cutting edge requirement and I would suspect not the major use that will be made of Web service reliable messaging. My third concern was the complexity of coding required in the applications. The solution to this is hinted at in the specification by making a clear separation, at the initiating end, between the 'Initial sender', the endpoint which sends the message, and the 'Source' which is the endpoint that transmits the message. There is the equivalent 'Ultimate receiver', 'Destination' pair at the receiving end. The specification is solely about messaging flowing between the 'source' and the 'destination'. With this separation it is reasonable to assume that the implementation of the source and destination will be standard and provided by the vendors as a Message Service Handler as defined in the ebXML specification. The application developer would then be left with a simple send and receive paradigm. I do not believe that this is made as clear as it could be, nor can I find any standard specification of the send and deliver protocol. I will be discussing this set of standards and the vendor developments in a report 'Intelligence in the Messaging Layer' later this year.
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:
|
|
|
|
|||||||||||||||||||||||
| ||||||||||||||||||||||||||
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
