Over the next little while, I'll be working my way through some web service stuff that I'll document here. If you're not very familiar with web services, join me in my study. If you're an expert, feel free to skip these.
At a W3C workshop on web services on the 11th and 12th of April, 2002 (forever ago in WS years), IBM and Microsoft presented a web services framework that addresses some specific issues directly related to interoperability of decentralized services. In some ways, the need here is the same as the void that PingID is trying to fill in the identity world. There's more to interoperability than some common protocols (although that's a start).
IBM and Microsoft presented a paper entitled Web Services Framework which listed the following functions as being key components in a working web services model. Where an existing protocol fits the need, its listed in parentheses to the side.
- Message envelop and controlled extensibility (XML Protocol) - I think of this as MIME for XML, maybe too simplistic, but it works for me.
- Binary attachments - Serialization may not be practical in all circumstances (i.e. converting the binary data XML may be too expensive). Passing by reference is a possibility.
- Message exchange or routing - Sending messages through intermediaries who may act on the message or modify it (e.g. wrap it in something to certify origin, etc.)
- Message correlation - Multiple message may be sent for one purpose and need to be reassembled or sorted.
- Guaranteed message exchange - Think JMS, but not language or vendor specific.
- Digital signature (XML Dsig) - Signed messages for all the usual reasons.
- Encryption (XML Encryption) - Encrypted messages for all the usual reasons.
- Transactions and activities - Multiple activities often need to be atomic (i.e. they all happen or none of them happen). Transactions accomplish this, but traditional models will not likely work in high latency scenarios.
- Service description (WSDL) - Describe (document) the service. My opinion is that WSDL is a good start, but doesn't go far enough. For example, it can adequately describe data resources made available in a RESTian way.
- Process flow contract description - Work flow for XML.
- Inspection (WSIL) - Metadata about services that would point to the service description and process flow description.
- Discovery (UDDI) - Automated discovery of services. I think we're still yet to see this become practical for a variety of reasons.
There are a number of specifications proposed to deal with these functions in the intervening year. It should be noted that other players like ebXML and ITEF are working on this same problem and likely have other classifications and other answers, but for now, I'll follow this path.
Web service discussion typically talk about three formats for protocols: wire-level, description, and discovery. Wire-level protocols are all those that represent or control what is sent during an exchange. So, when someone in the WS world talks about a wire-level protocol, they're not talking about the ISO network hierarchy. This confused me for a while. They're talking about message exchange and the things that control or augment it. From the list above, everything but a few are wire-level. Service description and process flow orchestration are both description formats and inspection and discovery are both discovery formats.