Feature
News
2/21/2006
05:30 PM
Connect Directly
RSS
E-Mail
50%
50%

Crash Course: Get A Grip On Web Services Standards

As service-oriented architecture gains momentum, it's more important than ever to stay abreast of changing Web services standards. Here's an up-to-date look at what you need to know.

Service-oriented architecture continues to gain momentum as the new architectural model for both enterprise applications and packaged application infrastructures. With product suites supporting SOA development arriving daily and the barrage of SOA standards and information out there, enterprises are on SOA overload.

   

Whether you're developing custom software for your SOA initiative or purchasing a packaged application, wending your way through the ever-growing maze of Web Services standards is imperative to your success (see "A Guide to Web Services Specs and Standards"). There's a lot to learn. Some standards are necessary for building out a Web Services architecture--WSDL (Web Services Definition Language), SOAP (Simple Object Access Protocol) and WSS (Web Services Security)--but others, such as WS-Routing, aren't and have been superseded by one or more newer standards.

The Groups In Charge


Who's Who in Web Services
Click to enlarge in another window

Three organizations are primarily responsible for Web services standards and specifications: Web Services Interoperability Organization (WS-I), World Wide Web Consortium (W3C) and the Organization for the Advancement of Structured Information Standards (OASIS) (see "Who's Who in Web Services," left). All three formulate standards and specifications through technical committees comprised of representatives from Web Services-based product vendors and industry experts. These organizations are akin to the Internet Engineering Task Force in terms of their influence in the industry. As with the IETF's standards, vendor compliance with standards and specifications by these Web Services organizations isn't required, but it's expected, and encouraged. Even highly competitive vendors, such as Microsoft, IBM, Sun Microsystems and BEA Systems, agree on the importance of complying with these Web Services standards.


Web Services Specs and Standards
Click to enlarge in another window

The WS-I (www.ws-i.org) promotes interoperability between Web Services product implementations. WS-I is best known for its work on the WS-I Basic Profile (currently at version 1.1), a guideline of interoperability specifications for the core set of Web services standards: WSDL (Web Services Definition Language), UDDI (Universal Description, Discovery and Integration) and SOAP.

WS-I is also responsible for the WS-I Basic Security Profile which, like its sister guideline, details a set of interoperability guidelines for products implementing the OASIS WSS (Web Services Security) standard. Although compliance with these guidelines is promoted and supported by most Web Services vendors, it's not required. Compliance with the WS-I profile is more of a best practice adopted by vendors and enterprises in the industry.

The W3C (www.w3c.org) is the organization behind WSDL, UDDI and SOAP--the core set of Web services standards. W3C is also responsible for a number of XML-based specifications used to implement OASIS standards. Among them are XML Encryption, XML Signature and utility standards such as XSL (Extensible Stylesheet Language), XSLT (XSL Transformations), XPath and XQuery.

Meanwhile, most standards relating to Web Services--ones that enable specific business or IT functionality--come out of OASIS technical committees. OASIS (www.oasis-open.org) is the most prolific and influential of the three organizations working on Web Services standards. Its standards have given rise to entire markets of products, such as WSS (Web Services Security). OASIS is home to a wide variety of WS-* standards including WSS, WS-Addressing and WS-Reliability. OASIS' standards and specifications cross IT boundaries from transaction support to management. Standards such as WS-Policy are meant to encompass a large number of "subset" standards, such as WS-SecurityPolicy and others to come in the future.

The OASIS specifications are based heavily on object-oriented principles. As with principles of inheritance, they are easily extensible. Elements defined in "child" specifications are specific to the child specification, regardless of their meaning in the parent specification (think polymorphism). WS-* also allows for common use "objects," such as the endpoint reference element, which carries along information about the endpoint (including its address). That's a nice way of saying it's a URI, which necessarily carries along the protocol used to contact the endpoint (such as mailto, HTTP or FTP).

The endpoint reference element is then used to describe endpoints and clients in a variety of specifications: Both WS-Addressing and WS-Policy rely heavily on it, as do derived-domain specific specifications like WS-SecurityPolicy.

Understanding commonly referenced elements, such as the endpoint reference element, will give you a head start when you research a new WS specification. WS-Policy assertions and requirements are consistent across subspecifications, which gives policy engines the flexibility to interpret attributes and elements according to specific domains rather than inventing new protocol definitions to represent domain-specific processing instructions. That means a single, extensible, policy engine can handle multiple specifications, which can reduce the overhead and expense of deploying policy engines on a per-domain basis.

Previous
1 of 2
Next
Comment  | 
Print  | 
More Insights
IT's Reputation: What the Data Says
IT's Reputation: What the Data Says
InformationWeek's IT Perception Survey seeks to quantify how IT thinks it's doing versus how the business really views IT's performance in delivering services - and, more important, powering innovation. Our results suggest IT leaders should worry less about whether they're getting enough resources and more about the relationships they have with business unit peers.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Must Reads Oct. 21, 2014
InformationWeek's new Must Reads is a compendium of our best recent coverage of digital strategy. Learn why you should learn to embrace DevOps, how to avoid roadblocks for digital projects, what the five steps to API management are, and more.
Video
Slideshows
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
A roundup of the top stories and trends on InformationWeek.com
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.