A Web Services Primer
by Venu Vasudevan | Pages: 1, 2, 3
The traditional notion of a database transaction is an atomic, that is, all-or-none action; either the entire action happens or it doesn't. Providing this kind of guarantee in a distributed infrastructure involves an expensive process called two-phase commit. An alternative optimistic model has been proposed in database research (originally called sagas and proposed by Hector Garcia-Molina), where actions have explicit compensatory actions which negate the effect of the action. In the real world of actions, the existence of compensatory actions is quite common. For instance if I debit a credit card $52, the compensatory action is to credit the credit card $52. If I sent out an e-mail saying "you'll get the product you ordered in seven days", the compensatory action is to send an e-mail saying, "oops, it's going to take longer". XLang is a notation for expressing the compensatory actions for any request that needs to be undone. The web services infrastructure can leverage XLang specifications to perform complex undo operations.
Transaction Authority Markup Language (XAML) provides a more traditional two-phase commit style transactional semantics over web services. A business-to-business web transaction to purchase benzene follows -- a working example from the XAML specification. XAML does not completely restrict itself to two-phase commits, and it leaves open the possibility that some action "undos" will be compensatory actions like XLang. While two-phase commit is clearly useful in enterprise integration, a number of web transactions (e.g business-to-consumer transactions) are well captured by the computationally cheaper compensatory action model. Until XAML makes compensatory actions a first class citizen of their model, it would seem that XLang has ample justification to exist.
The following scenario demonstrates a business-level transaction involving a set of web services that would utilize XAML. Consider an industrial company that purchases benzene from a chemical manufacturer on the Web. In order for the buyer to purchase the benzene, she requires additional value-added services provided by third parties, such as shipping with specific delivery terms, payment financing, casualty insurance, and government compliance for safe transport. The buyer will not agree to the purchase of benzene until all of these services are available, and until all of them meet her requirements. She will purchase all of them or none of them. In other words, all of these related requirements need to be satisfied in order for the business transaction to be completed.
The software providing the top-level business transaction needs to coordinate
with each of the participating web services. These include (1) the chemical
provider's inventory system; (2) an insurance policy service to insure the
product being shipped; (3) a financing service to ensure payment according to
vendor terms; (4) a transportation service to guarantee timely shipment and
delivery of product; and (5) a regulatory service to ensure compliance with
government safety requirements.
XKMS is an effort by Microsoft and Verisign to integrate PKI and digital certificates (which are used for securing Internet transactions) with XML applications. The key idea is to delegate the signature processing to a trust server on the Web, so that thin or mobile clients don't have to carry around the smarts to do all this themselves. XKMS relies on the XML Signature specification already being worked on by W3C and on anticipated work at W3C on an XML encryption specification.
XKMS consists of two parts: the XML Key Information Service Specification (X-KISS) and the XML Key Registration Service Specification (X-KRSS). The X-KISS specification defines a protocol for a trust service that resolves public key information contained in XML-SIG elements. The X-KISS protocol allows a client of such a service to delegate part or all of the tasks required to process <ds:KeyInfo> elements (information about the key signer). A chief objective of the protocol design is to minimize the complexity of application implementations by allowing them to become clients, thereby shielded from the complexity and syntax of the underlying PKI used to establish trust relationships. These may be based upon a different specification such as X.509/PKIX, SPKI, or PGP. X-KRSS describes how public key information is registered.
While there are no inviolable ties in these proposals to protocols and transports, the current XKMS specification relies on XML, SOAP, and WSDL.
Other initiatives in this area include S2ML (Security Services Markup Language) and AuthXML, which are being unified under the auspices of OASIS's XML Security Services committee.
The web services platform is an evolving ecosystem in which Darwinian processes are still at work. As with all things Darwinian, there is constant evolution, bio-diversity, competition, and, yes, even confusion. The list below is a small sample of such complementary or competing initiatives.
Given the existence of UDDI registries, ADS asks the question "how do I facilitate the building of a UDDI crawler that can pull UDDI advertisements off the Web, without people having to push ads to the registry?" Furthermore, while ADS accepts WSDL as the XML format for a service, it also wants to deal with discovering services that don't have the XML capabilities to build WSDL descriptions. For the XML world, it standardizes on a svcsadvt.xml file placed in the root of a web server, which then collectively advertises all the services available on that web site. This takes away the burden on each service to advertise itself, and it provides service crawlers a single place to look for advertisements. For the mom and pop e-shops of the world that want to advertise their services without the XML overhead, ADS proposes an augmented HTML META tag with name=<serviceDescriptionLocation >and content=<valid URL of document containing service advertisements>. In case of HTML based service crawling, the crawler makes some conclusions about the service properties based on the traversal context.
The XMethods filesystem service enables you to post and read files via a SOAP interface. This system enables developers to create services that utilize centralized, persistent data. Ideally, this type of filesystem can be used to centralize the storage of information which can be accessed by multiple nodes. For example, one could use this space to support automatic patch updates. XFS provides a client tool that integrates the XFS web service into a Windows Explorer shell. Windows Explorer is then integrated with the XML-SOAP-based file system. XFS is an open-source initiative by xmethods.com, the momentum of which is unclear. However, the idea is technically attractive.