« January 27, 2003 | Main | January 29, 2003 »
January 28, 2003
Web Services Framework
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.
10:43 PM | Recommend This | Print This
Wasatch Digital IQ
Wasatch Digital IQ is a magazine that covers the high-tech industry along the Wasatch Front. For those of you not familiar with Utah, the Wasatch Front is the range of mountains along which 80% of Utah's population lives in a 100 mile strip. WDIQ has recently upgraded their web site in a major way with articles online, and other, daily features. They've even added a blog section some guest "columnists" will blog about particular topics. Overall, I think they've done an outstanding job on the upgrade.
10:00 AM | Recommend This | Print This
PingID and SourceID
Anyone who was at Digital ID World last year probably thought PingID was already launched, but today is actually their official birthday.
PingID provides a "network" for processing federated identity transactions in the same way that Visa or Mastercard provides a network for processing credit card transactions. Network in this sense doesn't mean wires and routers, but rather the protocols, agreements, and legal framework that makes transactions between two unacquainted parties possible. Like Visa and Mastercard, PingID is member-owned, meaning that the companies who use the network have an equity stake in it.
According to the PingID web site, the PingID services include
- Standardized business agreements for federated identity.
- Standardized processes for resolving disputes
- Access to enhanced interoperability services.
I think the last one probably need more fleshing out, but anyone who contemplated establishing a single-sign-on (SSO) relationship with a customer that requires more than one party provide the service will understand the first two. When I used to build e-commerce services, our business model included lots of partners providing services to the merchants (we sold that right for quite a bit of money). We were trying to do SSO with 20-30 entities for our customers and it was a lot of work to maintain those relationships, code up the various terms and conditions that each entailed, and figure out who was at fault when something went wrong. PingID would have been a welcome partner.
A related entity is the SourceID open source project for identity management. The first SourceID project is an open source implementation of the Liberty Alliance specification for SSO. PingID and SourceID aren't formally related, as far as I can tell, but they have the same founder Andre Durand of Jabber. My take on this from talking to Andre and Eric Nolin is that SourceID is the pointy end of the SSO stick and PingID is the business network that ties it all together.
Disclosure: I'm on the advisory board of PingID.