| QUESTION & ANSWER |
Breaking through fog of Web services standards |
 |
By Mark Brunelli, News Writer
17 Aug 2004 | SearchWebServices.com |
|
|
SearchWebServices.com caught up with Anne Thomas Manes, vice president and research director for Midvale, Utah-based Burton Group, for an update on what is happening in the ever-evolving world of Web services standards. Manes, an expert on such matters, offered a definition for what her company calls the Web Services Framework (WSF). She also discussed the three major organizations involved with developing standards and specifications, and she offered a glimpse at the new specifications to look for in the future.How does the Burton Group define the WSF?
Anne Thomas Manes:
The WSF is a collection of Web services specifications that work together to provide the environment that supports Web services. There is no one [standards] body in charge of the WSF. There are two primary standards bodies that develop a lot of the specs -- W3C and OASIS. W3C [World Wide Web Consortium] is responsible for most of the core standards.
What is the W3C group currently working on?
Manes: They do all the XML-based technologies, which are part of the foundation for everything; and they also do SOAP and WSDL [Web Services Description Language]. They have also got an effort to create a choreography language. It looks promising that there will be another working group started at W3C that is focusing on [Web services] addressing and referencing [They'll be looking at] how you reference a Web service and how you provide an address to that Web service.
What is OASIS working on?
Manes: Over at OASIS, we have UDDI [Universal Description, Discovery, and Integration], which is generally considered part of the foundation, but I would say that it's not quite as integral to the core as SOAP and WSDL. And then you also have WS Security, WS Resource Framework, and WS Reliable Messaging.
What does the WS Reliable Messaging specification do?
Manes: That provides an application-level reliability infrastructure so that you can ensure reliable delivery of messages. And you can set the scope. You can say, 'I want this message delivered once and only once,' or you can say, 'I just want to make sure that this message gets delivered, and I don't care how many times it gets delivered as long as it gets delivered.' You can also specify things like message receipts.
What else is on the horizon in the world of WSF standards?
Manes: What I have identified so far are the standards bodies that make this thing work. But in addition to that there are also vendor coalitions that also define specifications. A lot of specs actually get developed initially by a vendor coalition. They work on it for some period of time until they feel that it is reasonably mature enough. And then from there they generally submit it into a standards body for standardization. For example, [last Tuesday,] IBM, Microsoft, BEA, SAP and Sun Microsystems submitted WS Addressing to W3C. Originally, WS Addressing was developed by IBM, Microsoft, BEA and SAP, and Sun was not involved, so this is actually big news. As far as I know, this is the first vendor coalition submission that involved both Sun and the other guys. So I would say that we've broken history here.
Why is it so unusual for Sun to be involved, and why do you think there was a change of heart?
Manes: Typically, it's Sun and Oracle and a few other vendors versus the efforts being done by IBM and Microsoft. Sun traditionally has been very resistant to joining forces with IBM and Microsoft. Or, perhaps it is that IBM and Microsoft are resistant to allowing Sun to join forces with them. Neither of the coalitions will talk about the issue. I suspect the [change of heart] had something to do with the settlement between Microsoft and Sun. Here is the first demonstration of them working together.
How does the Web Services Interoperability (WS-I) organization come into play with regards to WSF?
Manes: The other major influence here is WS-I, which is not a standards body. It's a consortium of [vendors and end users] concerned with figuring out how to ensure that Web services products actually work together and interoperate. They have created what are called profiles.
What purpose do profiles serve?
Manes: Profiles clarify any ambiguities that exist in the specifications. A lot of specifications will specify that you may do this or that, or you should do this, or you must do this, or you must not do this. Any place where it says 'must,' it is very clear. This is the way you must do it. Any time it says, 'may,' 'should,' 'may not' or 'should not,' it's unclear because obviously there are other options besides this recommended approach. The profile basically goes through and defines the best process that you should follow in a situation where the specification is ambiguous.
Which profiles are completed and which ones are being worked on?
Manes:
WS-I has gone through and profiled the core specifications that include SOAP, WSDL and UDDI. They're still developing the profile for attachments, which says how to send attachments with your SOAP messages. They have created a draft of a profile for how to do security based on both SSL and WS-Security. I actually view WS-I profiles as the mark of maturity in that a specification cannot be deemed mature until such time as there is a profile that describes how to use it in an interoperable way.
Do profiles guarantee interoperability?
Manes: A WS-I profile does not guarantee 100% interoperability because there is one other very important aspect. The vendors have to turn around and agree to support what has been specified in the profile. For example, WS-I published the preliminary draft for the attachments profile, except that it's based on the SOAP with Attachments specification. Microsoft doesn't support SOAP with Attachments and has no intention of supporting SOAP with Attachments. If you don't get the major vendors' backing, what has been defined through WS-I still isn't necessarily considered solid and as concrete.
Do you expect this Microsoft/WS-I issue to get resolved?
Manes: This whole issue is going to get resolved probably within about a year. The reason is because the W3C XML Protocol Committee -- the team that developed SOAP 1.2 -- has also defined a new way to send binary data with your SOAP messages, using a featured known as MTOM. MTOM stands for Message Transmission Optimization Mechanism and is essentially a way to take your binary data and put it into a message information set and yet still attach it as an external attachment. It is a different approach from the way that SOAP with Attachments works because [under] SOAP with Attachments, the attachments are not part of the information set. It is something that is extra and so therefore it is not part of the SOAP envelope. With MTOM, this attachment … is technically part of the SOAP envelope. Microsoft is behind MTOM and they will support MTOM in the future. Meanwhile, the whole concept of attachments is pretty much non-interoperable today.
FEEDBACK: Are there too many Web services standards?
Send your feedback to the SearchWebServices.com news team.
|
|
|
|
