Browse DevX
Sign up for e-mail newsletters from DevX


Behold WSE 2.0: Removing Another Layer of WS-Pain

To keep up with the flurry of emerging, re-emerging, and otherwise evolving standards for Web services, we need tools—good ones—and we need them all to play nice across platforms.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

he official release of Microsoft's Web services Enhancements (WSE) toolkit promises to help developers deal with at least some of the pain and suffering accompanying the emerging Web services' standards. Updated to support the OASIS WS-Security specification and a promising WS-Policy specification, developers will be able to build standards-compliant Web services in less time and with less code. If you've been trying to keep up with the flurry of emerging, re-emerging, and otherwise evolving standards for Web services, your head is probably spinning. It is a difficult task to keep track of which standard is the favorite for standardization, which standards body has taken on what standard, and what toolkits have stepped up to support them. It would be great if we could just drag, drop, point and click our way to a successful enterprise Web services implementation without reading another boring XML specification. For this to become a reality, we need tools, good ones, and we need them all to play nice across platforms so we can "not care" about the underlying XML.

If you thought I was going to say that WSE 2.0 solves all of this, dream on. However, it does bring us one step closer to a mouse-driven paradise. Developers still have a responsibility to understand how emerging Web services standards such as WS-Security, WS-Trust, WS-SecureConversation, WS-Policy and so on (WS*) can be applied to their business workflows, but with WSE 2.0 they have a tool that helps them implement .NET Framework solutions productively. In this article, I'll provide an overview of the key features that WSE 2.0 brings to the table, focusing on the applicability of WS-Security and WS-Policy standards as they sit today. I'll take you through building a Web service solution that requires a layered security model, writing as little code as possible, leveraging the WSE 2.0 VS.NET plug-in and its support for WS-SecurityPolicy to build the solution. I'll show you where I had to break down and write some code, wielding the extensibility of the WSE 2.0 pipeline to overcome some of the issues not yet addressed through the tool.

Figure 1: Separate policy files can be configured for sending and receiving messages, each specifying one or more WS-Policy entries for specific service endpoints.
Applying Standards Gets Easier
The WSE 2.0 tool plugs in to the Visual Studio IDE just like WSE 1.0, through a set of tabbed dialog interfaces broken down by function. The new release continues to provide support for routing configuration, custom filters, and diagnostics. It also adds new support for publishing policy documents describing service requirements (see Figure 1) based on the WS-Policy specification, configuring support for signing and encrypting messages (see Figure 2) consistent with OASIS WS-Security, and configuring token issuance services based on WS-Trust and WS-SecureConversation standards. Modifications made through these interfaces update the appropriate application configuration files (web.config or app.config) to enable features of the WSE run time, but this new tool also automatically generates policy cache files compliant with the WS-Policy specification. Developers can quickly generate policies to enforce the security requirements of a Web service, without writing a single line of code. This is indeed one of the most exciting new features of WSE 2.0).

Figure 2: Security is extensible through custom security token managers.
The WSE 2.0 configuration tool does not replace a fundamental understanding of Web services standards, but it certainly helps. For example, I can point and click my way to a basic WS-SecurityPolicy that requires message signing and encryption; this generates compliant WS-Policy XML that can be shared with clients. Some functionality is not exposed through the tool interface, yet is supported by the Microsoft.Web.Services object model. For example, WS-Policy provides XML grammar for signing multiple parts of a message, and with some skillful hand-editing of the policy file, the run time happily supports this policy (see Signing Multiple Message Parts later in this article). In cases where specification elements are not supported by WSE 2.0, or its built-in run-time filters, you can create your own components to plug-in to the message processing pipeline.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date