STANDARDS FRAMEWORK

As discussed, Web services are implemented by using a collection of standards. These standards, when considered together, form what is widely referred to as the “Web services stack.” Figure 2.2 illustrates the seven distinct layers of the Web services stack, which should be read from bottom to top.

Figure 2.2: Web services stack.

The Web services stack can be thought of as a set of layered building blocks, each layer supported and enabled by the preceding layers. As illustrated, we have grouped the layers of the stack into three distinct levels— each level indicates a level of maturity for the layers it contains. The three levels are: enabling standards, evolving standards, and emerging standards. These levels represent a framework that can be used to evaluate the maturity of Web services standards today, and can also be used to monitor how Web services standards progress over the medium to long term. Figure 2.3 illustrates the maturity of Web services standards, from the enabling standards at one end of the spectrum to the emerging standards at the other.

Figure 2.3: Spectrum of enabling to emerging standards.

Four characteristics should be considered when evaluating a standard to determine its relative position as enabling, evolving, or emerging. These are described below.

1. Industry Support —The number of key industry players that support the standards (for example, IBM, Microsoft, BEA, Sun Microsystems, and so on). Where many key players support a specific standard and there is little infighting and discord, it is likely that a standard will gain acceptance.

2. Standards Governance —Accepted governance by a recognized standards organization active in the Web services space. The two key organizations defining Web services standards are the World Wide Web Consortium (W3C) and Organization for the Advancement of Structured Information Standards (OASIS).

3. Update Frequency —The frequency at which new versions of a standard are published. Typically, high update frequency indicates an immature standard that is being enhanced to fill gaps in its capabilities.

4. Competing Standards —The existence and active promotion of competing standards. If competing standards exist and are being independently promoted by key industry players, it is likely that acceptance of a single standard will be inhibited. This very situation is occurring around the standards in the “Business Process Execution & Management” layer of the Web services stack, where Sun Microsystems is promoting the Business Process Management (BPM) standard, Microsoft, IBM, and BEA systems are promoting the Business Process Execution Language for Web Services (BPEL4WS) and the Business Process Management Initiative organization (BPMI.org) is promoting the Business Process Modeling Language (BPML).

Figure 2.4 illustrates how the four characteristics are applied to determine at which level a standard should be placed.

Figure 2.4: Enabling, evolving, and emerging standards.

As firms begin implementing Web services, it is critical that they consider the maturity of the standards they will be using. Standards in the enabling level are well understood and are widely used in mission-critical systems. Conversely, standards in the emerging level are fluid, with the existence of competing standards, and are used for tactical, nonmissioncritical applications.

Given the rapid pace at which Web services standards are introduced, along with the unprecedented level of collaboration between key industry players such as IBM, Microsoft, BEA, and Sun in moving from proprietary technologies to jointly developed standards, it is advisable to regularly revisit the standards framework. As you do, consider the following dynamics:

• Adding Standards —Are there any emerging standards that should be added to the radar screen?

• Progressing Standards —Have the existing standards gained greater acceptance, and do they need to be considered for progress from the emerging to evolving level or evolving to enabling level?

• Retiring Standards —Looking at the emerging level, have any existing standards been superceded or merged? For example, have Sun, Microsoft, IBM, and BEA systems agreed on a single specification for standards in the Business Process Execution & Management level?

By regularly updating the standards within this framework, firms can better decide which to incorporate into mainstream projects and which are better left to experimentation and “skunk works” initiatives.

Extreme caution should be exercised when considering the use of emerging standards for mainstream or mission-critical projects. The very real possibility exists that standards in this level will either fade away or be subsumed by competing standards. This situation would likely leave organizations in the unenviable position of incurring the cost, time, and effort to migrate systems to an alternate evolving or enabling standards in the near future. As Dana Gardner of the Aberdeen Group put it:

“I don’t think it’s too soon to step into the waters, but I think it’s important to realize that these standards are fresh, not fully cooked and there are needs for more standards. [You have to be careful] not to get too far into the technology. Web services are something you should try out and use in pilots [pilot programs] inside the firewall. But when it comes to mission critical activities, particularly those outside the corporate boundaries, [it’s not ideal]. It’s too soon to look beyond the firewall except if it’s something that couldn’t make or break your business.” ^[1]

^[1]www.internetnews.com, March 13, 2002, “Web Services Moving Beyond the Hype” by Thor Olavsrud.