XML, as a language, is defined in a specification but is also used as the language through which practically all XML and Web services specifications are expressed. This common thread is a tribute to the fact that despite how vast the specifications landscape may grow, it continues to share a common root.
Whether or not you are required to directly work with these extensions, their existence and evolution will continue to affect any service-oriented solutions you build. Knowledge of how and why specifications and standards come to be is therefore relevant to acquiring a complete understanding of the world of SOA.
4.2.1. "Standards" vs. "Specifications" vs. "Extensions"
These terms are often used interchangeably, but manyespecially those involved with standards organizationsmake a clear distinction. A specification is a document that proposes a standard. It is not officially an industry standard until the specification is submitted to, accepted by, and released as such by a recognized standards organization.
Still, specifications released by vendors (especially collaborating vendors) and subsequently implemented by the vendors' platforms often go on to become unofficial industry standards simply because they become so commonplace.
To avoid confusion, this book defines these terms as follows:
4.2.2. Standards organizations that contribute to SOA
As we know, standards are what drive SOA. Previous architectural platforms were realized within vendor-specific boundaries; environments in which the only standards that mattered were proprietary. With the promise of a vendor-neutral communications framework comes the non-negotiable requirement that the standards defining this framework be vendor-neutral as well.
How exactly these standards are produced, though, is not always that clear. Internet standards organizations have existed for some time now, but their respective agendas are not always distinct and sometimes even overlap. Further complicating the issue is the fact that the primary contributors to these vendor-neutral standards are the vendors themselves. Microsoft, IBM, Sun Microsystems, and many others have played increasingly significant roles in not only formalizing Web services specifications, but also in accelerating the implementation of these specifications as industry standards.
How vendors contribute to and influence the standards development process is explained in the subsequent section. Let's first learn more about the three most prominent standards organizations. Collectively, they are responsible for seeing through the evolution of XML and Web services architectures.
The World Wide Web Consortium (W3C)
Originally founded by Tim Berners-Lee in 1994, the W3C has been hugely responsible for furthering the World Wide Web as a global, semantic medium for information sharing. It began with the release of HTML, one of the most popular technical languages the IT industry has ever produced. When the use of the Internet broadened to include eBusiness initiatives, the W3C responded by producing key foundation standards based on XML, such as XML Schema and XSLT.
Four separate working groups made significant contributions to W3C Web Services Activity projects, resulting in the development of important base standards for Web services. First-most are the SOAP and WSDL standards, which have now become the signature specifications associated with Web services. More recently, the W3C has produced the Web Services Choreography Description Language (WS-CDL), a specification that governs standardized inter-service exchange patterns. Also worth noting is the Web Services Architecture document itself. Though this document continues to undergo changes, it remains a reference point, and one of the few platform-neutral Web services architecture documents available.
The W3C is known for its formal and rigorous approach to standards development. Its process requires that specifications be subjected to numerous review and revision stages, with each new version being published to their public Web site. The thoroughness of its process comes at the cost of time. Standards can take two to three years to be completed.
Organization for the Advancement of Structured Information Standards (OASIS)
Originally established in 1993 as the SGML Open, OASIS changed its name five years later to represent a shift in focus from SGML to XML-related standards. With thousands of members from over 600 organizations, OASIS is a recognized international standards producing organization.
OASIS assumed ownership of the prominent WS-BPEL specification and is also known for its development of ebXML (a specification that aims to establish a standardized means of B2B data interchange) and its contributions to the UDDI specification, one of the core standards associated with the first-generation Web services platform.
The OASIS group has been instrumental in furthering the development of XML and Web services security extensions. Both the Security Assertion Markup Language (SAML) and the Extensible Access Control Markup Language (XACML) provide important features in the areas of single sign-on and authorization. However, the most important security-related project is being carried out by the Web Services Security (WSS) technical committee. This group is entrusted with further developing and realizing the important WS-Security framework.
Whereas the W3C focuses on establishing core, industry-agnostic standards, the OASIS group's primary interests lie in leveraging these standards to produce additional specifications that support various vertical industries. Further, the standards development processes used by OASIS are noticeably shorter.
The Web Services Interoperability Organization (WS-I)
The primary objective of the WS-I is not to create new standards, but to ensure that the ultimate goal of open interoperability is realized. Established in 2002, this consortium has rapidly grown to gain the support of nearly 200 organizations, including all major SOA vendors.
The WS-I is best known for releasing the Basic Profile, a recommendation-based document that establishes which of the available standards should be collectively used to form the most desirable interoperability architecture. By formally positioning specific versions of WSDL, SOAP, UDDI, XML, and XML Schema, the Basic Profile has become an important document within the IT community. Those organizations wanting to ensure that the SOAs they develop are fully interoperable with others can guarantee a high-level of acceptance with compliance to the Basic Profile.
More recently, the WS-I developed the Basic Security Profile. Essentially the same concept as the Basic Profile, this document establishes the most important collection of Web services and XML security technologies. The WS-I has announced that it plans to continue releasing Profiles for each major aspect of Web services-related interoperability, including reliable messaging, Web service management, and orchestration.
In addition to establishing a base interoperability architecture, Profiles are supplemented with sample implementations and best practices on how the standards are to be used together to achieve a quality level of interoperability. Further, the WS-I provides a series of testing tools that can be used to ensure compliance with Profiles. Many vendors also provide their own variation of these tools, such as validity checkers that use Basic Profile conformance as part of the validation criteria.
The WS-I strives to provide a level playing field when it comes to receiving contributions from its members. While its membership includes significant SOA vendors, no one company has more clout than another, regardless of its size or market share.
Although the W3C recently rejected an invitation to become an associate member of the WS-I, working group members from the WS-I continue to contribute to W3C and OASIS initiatives by directly participating in their respective working groups. The role of these WS-I representatives is to provide continual feedback relating to interoperability issues.
How they compare
Table 4.1 provides a summary-level overview of how the three organizations we discussed in this section compare to each other.
W3C |
OASIS |
WS-I |
|
---|---|---|---|
Established |
1994 |
1993 as the SGML Open, 1998 as OASIS |
2002 |
Approximate membership |
400 |
600 |
200 |
Overall goal (as it relates to SOA) |
To further the evolution of the Web, by providing fundamental standards that improve online business and information sharing. |
To promote online trade and commerce via specialized Web services standards. |
To foster standardized interoperability using Web services standards. |
Prominent deliverables (related to SOA) |
XML, XML Schema, XQuery, XML Encryption, XML Signature, XPath, XSLT, WSDL, SOAP, WS-CDL, WS-Addressing, Web Services Architecture |
UDDI, ebXML, SAML, XACML, WS-BPEL, WS-Security |
Basic Profile, Basic Security Profile |
4.2.3. Major vendors that contribute to SOA
Though standards organizations have their own culture and philosophies around how standards should be developed, they are all heavily influenced by the commercial market. And so they should be, as that is what they are there to support. Even though these organizations exist as independent entities, their membership includes pretty much all major software vendors. And these same vendors supply a significant portion of the contributors that actually end up developing the standards.
Some of the companies that have participated in the standards development processes include Microsoft, IBM, BEA Systems, Sun Microsystems, Oracle, Tibco, Hewlett-Packard, Canon, Commerce One, Fujitsu, Software AG, Nortel, Verisign, and WebMethods. The dynamics resulting from the interaction between vendors, their various alliances, and the standards organizations is pretty interesting and worth discussing further.
Why standards are being developed in support of SOA
No one person or organization owns or controls SOA. Having evolved from proprietary platforms into an architecture that promotes and supports open standards and vendor-neutral protocols, SOA will likely remain an important architecture for as long as the major software vendors choose to support it.
That is because the benefits of SOA can only be realized as long as it continues to receive the global acceptance it does now. What would be the point of building interoperable applications if only a portion of the solutions out there supported the technology used for cross-application communication?
Regardless, SOA today is foremost on every major software organization's priority list. Non-compliance with SOA is not even being considered, as it would mean cutting yourself out of an ever-growing market. For now and the foreseeable future, SOA is it.
The vendor influence
Even though no one exclusively controls SOA, everyone has an opinion as to how its underlying technology platform should be shaped. To that end, the vendor's influence in the standards development process has turned the evolution of SOA into a battle of agendas.
Each vendor has its own vision as to how it plans to advance its line of products. IBM has laid out a technology path for increasing support of SOA within its WebSphere platform. Microsoft is not only increasing SOA features within the .NET technology framework, but is also building Web services technology directly into the Windows operating system.
Though Web services standards are meant to remain non-proprietary, a vendor who can help shape a standard might be motivated to do so with proprietary technology considerations in mind. This isn't necessarily devious or even manipulative. One could argue that since these standards are intended to support implementation by common products, they should be influenced by the requirements of the vendors that represent product lines with larger market shares. The challenge, however, is getting all vendors to agree on how one standard should be designed.
Vendor alliances
Past battles between the more established vendors have led to a great deal of distrust. Now, when asked to collaborate on specifications intended to foster interoperability between vendor platforms, these suspicions surface and turn into obstacles. This issue, coupled with how closely aligned some vendors' requirements are for the contents of a particular specification, has led to some companies forming loose alliances.
Forming an alliance allows vendors to join forces in order to attain common goals. Generally, the lifespan of an alliance is centered around the development cycle of a particular specification. However, the most noticeable team of repeat-collaborators (IBM, Microsoft, and BEA) have persisted their working relationship to push forward a series of WS-* extensions.
One of the more talked about examples of alliances playing a significant role in standards development is the creation of the WS-ReliableMessaging specification. Originally, the need for a reliable messaging mechanism was being addressed by an OASIS technical committee. Its contributors included Sun Microsystems and Oracle, and the specification was titled WS-Reliability. However, only weeks after its release, Microsoft, IBM, and others announced their own specification, called WS-ReliableMessaging.
The specifications are very similar and address the same overall requirements. However, even though it was released later and had not been developed through (or even submitted to) a standards organization, the WS-ReliableMessaging extension became an immediate contender. This is simply due to the fact that the vendors that developed it collectively held a larger market share of the Web services technology platform. Incidents such as this not only reflect the volatile state of the Web services industry, they also reveal a lack of authority held by standards organizations.
Choosing a standards organization
Generally, though, it is to a vendor's benefit to have specifications formalized through a standards organization. It officially establishes that the specification's purpose is to support an open standard and subjects it to a process that is generally open to the public.
However, sometimes the choice of standards organization can have implications. Another dynamic within the standards development arena is directly related to market demand. Vendors have market-driven goals fueled by pressures to deliver product releases that meet customer demands and match or outdo what the competition is offering (or planning to offer). Given that the W3C relies on a longer standards development process, it is tempting for vendors to submit their standards to OASIS instead.
Although having organizations develop similar specifications may seem redundant, one always seems to rise to the top. And despite the fact that opposing motives may seem counter-productive to fostering a collection of platform-neutral technology standards, the quality of what's been delivered so far has been adequate for furthering the cause of SOA.
Why you should care
In the Common pitfalls of adopting SOA section of Chapter 3 we discussed the importance of staying in tune with developments around product and standards releases. Let's conclude this section by reiterating this point and listing some specific reasons as to why you should keep an eye on what is happening in the standards development landscape.
SUMMARY OF KEY POINTS |
---|
|
Introduction
Case Studies
Part I: SOA and Web Services Fundamentals
Introducing SOA
The Evolution of SOA
Web Services and Primitive SOA
Part II: SOA and WS-* Extensions
Web Services and Contemporary SOA (Part I: Activity Management and Composition)
Web Services and Contemporary SOA (Part II: Advanced Messaging, Metadata, and Security)
Part III: SOA and Service-Orientation
Principles of Service-Orientation
Service Layers
Part IV: Building SOA (Planning and Analysis)
SOA Delivery Strategies
Service-Oriented Analysis (Part I: Introduction)
Service-Oriented Analysis (Part II: Service Modeling)
Part V: Building SOA (Technology and Design)
Service-Oriented Design (Part I: Introduction)
Service-Oriented Design (Part II: SOA Composition Guidelines)
Service-Oriented Design (Part III: Service Design)
Service-Oriented Design (Part IV: Business Process Design)
Fundamental WS-* Extensions
SOA Platforms
Appendix A. Case Studies: Conclusion