Web Services Enhancements 1.0 for Microsoft .NET, or WSE, is a new .NET class library for building Web services using the latest Web services protocols, including WS-Security, WS-Routing, DIME, and WS-Attachments. WSE integrates with ASP.NET Web services, offering a simple way to extend their functionality. This paper explores the architecture of WSE and explains how to use it to build a simple Web service. But before I get into the details, let me provide a little background and make some observations about Web Services Enhancements in general.
The standards at the heart of basic Web services—XML, SOAP, XSD, WSDL, and UDDI—provide enough functionality to build simple distributed systems. There are lots of toolkits that support these protocols, mapping them to a range of programming models, from raw XML messaging to method invocations against objects. While the basic Web service standards are necessary, they are not sufficient for building complex applications. For instance, there is no standard approach to building secure Web services. If you want to build a secure Web service, you have to roll your own solution. Most people rely on the security infrastructure of their service's underlying transport protocol, typically HTTP.
Security is just one of the architectural problems that the basic Web service stack does not address. There is no standard approach to routing messages, ensuring reliable delivery, coordinating distributed work using compensating transactions, or a number of other common problems. Given that these problems are not application specific, it makes sense to develop common solutions as part of the next generation Web service infrastructure. This is the goal of a collection of Web service architecture protocols written by Microsoft, IBM, and others describing ways to implement these features. WSE is one implementation of (a subset of) these protocols. The first version of the kit focuses on the basic message-level protocols: WS-Security, WS-Routing (and WS-Referral), and DIME and WS-Attachments.
The design of WSE reflects the principles of the protocols themselves:
- Decentralization and federation
- Modularity
- XML-based data model
- Transport neutrality
- Application domain neutrality
WSE provides a very "close to the metal" programming model focused on directly manipulating the protocol headers included in SOAP messages. The advantage of this approach is that you can use Web Services Enhancements to build a wide range of applications and infrastructure. The disadvantage is that you have to do much of the work required to integrate the protocols with your application yourself. Consider security, for instance. The WSE implementation of WS-Security gives you direct control over when and how a message is authenticated, but you have to write some code to map usernames to passwords or interpret the meaning of particular digital certificates.
From my perspective, the flexibility of WSE is a huge asset. It provides plumbing to handle the grungy details of building messages with advanced protocol headers without forcing you to adopt a particular programming model. That means you can use WSE to solve a very wide range of problems without having to stay inside a particular set of architectural boundaries.
However, it is important to note that, today at least, you do have to stay inside a particular set of interoperability boundaries. Unlike the basic Web service protocols, which are widely implemented across many platforms, there are very few toolkits that implement any of the more advanced Web service protocols. If you use WSE to build a Web service, you have to use the WSE or a compatible toolkit to build the client. In the short term, that essentially restricts the use of WSE to integrating applications within an enterprise (EAI) or, more interestingly, across core organizational boundaries, i.e., with particular business-to-business partners. Since having support for message-based security that is not tied to particular HTTP connections and the ability to route messages are both extremely useful in these scenarios, having to adopt a toolkit that understands these protocols is a small price to pay to enable them.
Beyond the limited number of tools that understand the latest protocols, there is another reason WSE is best used in situations where you and the person implementing the code at the other end of the pipe can collaborate on the design of your application. Specifically, WSE does not generate WSDL definitions that reflect how particular protocols are being used. The reason for this is simple: there are not yet standard ways to convey the service requirements of either a client or a service. How do you specify that a service wants request messages authenticated with a username and a hashed password, while a client wants response messages to be encrypted using the public key of from its digital certificate? (While you could write WSDL extensions that convey a server's requirements, you can't do the same thing for a client, which isn't described in WSDL.) In the absence of a generally accepted solution to this problem, WSE leaves it up to you. In short, Web Services Enhancements give you both a lot of power and a lot of responsibility.
More Details about WSE 1.0 http://msdn.microsoft.com/en-us/library/aa152931.aspx
No comments:
Post a Comment