The State of Standards
Do they help us do our job, or do they just get in the way?
Apr. 26, 2005 10:00 AM
There is an old saying among standards wonks: "The most wonderful thing about standards is that there are so many of them." And this truism is more applicable today than ever before. There are so many WS-* specifications, I've started referring to them as WS-Vertigo.
But there is a reason that there are so many of them. The Web Services Framework (WSF) relies on a composable architecture. One of the primary tenets of the WSF is to keep things as simple as possible. Therefore, if an application doesn't require security, reliability, or transactions, you shouldn't clutter up the infrastructure with these capabilities. But at the same time, if the application does require security, reliability, and/or transactions, then you should be able to add support for the specific set of capabilities you need.
Refactoring SpecificationsIn order to enable a pick-and-choose, plug-and-play infrastructure environment, the WSF architects approached the problem using refactoring techniques. Refactoring is a way of restructuring a software system to make it clearer, cleaner, simpler, and more elegant. The basic idea is that if you have two components within a system that do the same thing, you want to refactor the duplicate functionality into a separate component. (See Refactoring: Improving the Design of Existing Code by Martin Fowler, ISBN 0201485672, for more information on refactoring.)
The WSF architects have refactored infrastructure functionality into its most basic constituent parts, and as a result, there is a different specification for each bit of functionality. Figure 1 shows an overview of the WSF architecture, depicting a set of broad functional components. There are three categories of functionality: the core, the extensions, and management, represented by the colors blue, pink, and green, respectively. The core provides the foundation for the framework, the extensions provide pluggable infrastructure functionality, and the management components enable control of the environment. Figure 2 maps a number of WS-Vertigo specifications to each functional component.
Notice that many of the functional components support a variety of capabilities, and each capability requires a separate specification. For example, in the security component, there is a basic security framework (WS-Security), bindings for various types of security tokens (Username, X.509, SAML, REL, Kerberos, etc.), trust services for obtaining and exchanging tokens (WS-Trust), security session management (WS-SecureConversation), and security federation (WS-Federation). There are a bunch of other specifications related to security not listed in Figure 2 (such as SSL/TLS, XML Encryption, XML Signature, XKMS, XACML, etc.), but these other specification are general purpose specifications that apply to many different domains, not just to the WSF; so they aren't included in the WSF architecture. Nonetheless, the WSF security specifications often interact with or depend on these general-purpose security specifications, and unfortunately, at this stage in the game, a developer needs to be cognizant of most of them.
Also notice that in some cases, more than one specification addresses a particular capability. For example, there are three competing specifications for attachments:
Other areas of contention include event notification (WS-Eventing versus WS-BaseNotification), reliable message delivery (WS-ReliableMessaging versus WS-Reliability), transaction management (WS-Transactions versus WS-Composite Application Framework), and service management (WS-Management versus WSDM).
To Be or Not to Be a StandardAmong all of the specifications that make up the WSF, only a handful of them are formal standards. In fact, the two most basic specifications in the WSF (SOAP 1.1 and WSDL 1.1) are not formal standards. Standardization is an important process because it involves analyzing, vetting, and testing the specification to ensure that it is consistent and that it can actually be implemented. The SOAP 1.1 and WSDL 1.1 specifications have not been through this vetting process, and it shows. These two specifications contain a number of inconsistencies, ambiguities, and errors, which have beenthe source of many interoperability issues.
The WSF specifications that have been standardized include:
So What's a Developer to Do?The plethora of WSF specifications is enough to make a developer's head spin. But the average developer doesn't really need to concern herself with each and every specification. Instead, I recommend that developers stick with the basics and follow the guidelines defined in the WS-I profiles.
A WS-I profile is not yet another specification. A WS-I profile takes an existing specification and goes through it with a fine-toothed comb and finds any possible ambiguity - any place where the specification says MAY or SHOULD rather than MUST - or any place where some important behavior isn't completely specified, and it then constrains the specification and says, "Do it this way."
This type of profiling is particularly important when dealing with non-standardized specifications, such as SOAP 1.1 and WSDL 1.1, because these specifications have a lot of ambiguities. However it's also necessary with more formal standards, such as WS-Security, which offer a broad spectrum of options and choices, or with UDDI, which provides a basic registry, but doesn't define a standard model for registering services. The WS-I Basic Profile (BP) says register services this way. The WS-I Basic Security Profile (BSP) says secure your services using this constrained set of options.
Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week