Emerging Standards

If we can point to what will be the single biggest factor in the successful adoption of Web services in the industry, it is standardization. For Web services to be successful, the majority of implementations must have a certain commonality to them. Otherwise, we have gained nothing over what we have through the proprietary distributed middleware solutions that have been available for years.

To validate this, we have to look no further than the Internet itself. Standards are how we have achieved our success on the Internet up to this point: TCP/IP, HTTP, HTML, SSL, DNS (Domain Name Services), and so on. If we are successful in defining standards that will be adopted for working with Web services, the closer we are to producing meaningful Web services.

Five years ago, we could have relied on this standardization process to guide us into this new paradigm of Web services, but times have changed. Recapturing the magic that gave us the Internet won't happen exactly as it did then because the standards process has seen a shift in recent years. Previously, a standards body typically consisted of academia and government researchers. With the incredible success of the Internet, companies have recognized the power of these bodies in dictating the future direction of technology. As a result, companies started playing a much more active role in specifying the emerging standards. Even more recently, companies have been developing technology on their own—or in partnership with one or a handful of other companies—and then looking for acceptance by a standards body. Clearly, the process has changed and will probably continue to do so.

Companies also seem to be aligning themselves with different standards bodies and their activities, which has lead to a segmentation of the industry's efforts. The three most prominent organizations with activities in the Web services space are the IETF (Internet Engineering Task Force), W3C (World Wide Web Consortium), and OASIS (Organization for the Advancement of Structured Information Standards). Although these organizations have on occasion cooperated on an activity, they are independent and often act as such.

For these reasons, standards probably need to be more scrutinized now than ever. Hopefully, these efforts in support of standards will still result in good, solid solutions, but many of the standards authors now have a vested interest in the standards they are creating. Tim Berners-Lee did not directly make money off of HTML, and he had no vested financial interest in how he designed the solution; he just wanted to develop a good method for connecting documents over a network.

This is not to say that these companies don't make valuable contributions. In fact, they certainly bring with them some of the best people available and the resources to devise better solutions more quickly because they are paid for their involvement. Hopefully, they will continue to produce great solutions that appropriately address the needs of the industry, but to do so requires the participants in these groups to balance a split allegiance that did not exist in past standards efforts.

In this chapter, we will take a look at the leading standards that exist and, in most cases, are continuing to evolve. These standards cover a wide range of areas that all affect Web services in one way or another, so it will be important to continue to follow their development as Web services mature. This chapter is intended as an overview to help you gain a high-level of understanding of what these technologies offer; it is not a detailed study that will enable you to start using them. In each section, I will list at least one reference where you can find further information on each topic.

XML-RPC (XML-Remote Procedure Call)

Currently defined as a specification and a series of implementations, XML-RPC was originally authored by Dave Winer of Userland in 1998. Dave worked with Don Box of DevelopMentor and Microsoft to develop the very first SOAP (Simple Object Access Protocol) specification, which was shelved by Microsoft. (You can read more about this in the "SOAP" section later in the chapter.) Dave then developed XML-RPC to solve the problem that a Userland application had in communicating with different instances of itself on Windows and Macintosh machines.

Not only was XML-RPC the first public attempt at standardizing the process of communicating over HTTP through XML documents, but it also happens to be one of the few successful standards developed outside of one of the major standards boards. From the outset, the goal of XML-RPC was to specify a standard format for making remote procedure calls using the standard HTTP protocol, keeping it as simple as possible. Along those lines, one of the appeals of XML-RPC is its consistency: the specification has not changed since 1999. It is nice to know that, when you design an application using XML-RPC, it's not likely to get revised before you deploy! At the very least, developers don't have to worry about learning a new version once they get comfortable with the present one.

Technically, each XML-RPC is defined through a single node called methodCall. Within this element are various others that define the method name and parameters for the call, as shown here:

 <?xml version="1.0"?> <methodCall>      <methodName>examples.getStateName</methodName>      <params>           <param>                <value><i4>41</i4></value>           </param>      </params> </methodCall> 

As you can see, this is similar to the approach we took in defining the pay-loads for our Web services in Chapters 6 and 7. XML-RPC provides a standard structure for defining each process call that ideally should allow you to have a generic listener that can take a request for a consumer and proxy that call to the service logic, returning the result set. A response to an XML-RPC request will then be structured similarly with a root node of methodResponse, as shown here:

 <?xml version="1.0"?> <methodResponse>      <params>           <param>                <value><string>South Dakota</string></value>           </param>      </params> </methodResponse> 

You might have noticed a lack of attributes in these tags. This is by design, not coincidence. The original authors believed that attributes were a redundant element in XML and unnecessary. We saw earlier in Chapter 3 how the same data can be presented in elements versus attributes, which would certainly support the redundancy opinion. XML-RPC takes a strict "all-element" approach to defining a service's interface.

XML-RPC includes support for various arrays and other user-defined structures that give the format quite a bit of extensibility. It also has a defined structure for the provider to communicate errors that occur in the process to consumers.

Although it isn't specified, XML-RPC calls and requests can be defined through DTD or XML Schemas, just as we did with the Web services we built in Chapters 6 and 7. Because these definition files have no special considerations, the use of these techniques will be unique per implementation and/or solution.

Using XML-RPC primarily has two perceived benefits: it provides a consistent format for exposing a service's functionality, and it allows generic functions for consumers and listeners to handle the XML-RPC calls and responses. Once a developer is familiar with the structure of XML-RPC calls, he or she should be able to analyze the entire service fairly quickly. However, the benefits from the latter decrease with the complexity of the Web service and the development of more-advanced parsers.

First, the standard structure of XML-RPC used "as is" comes with some inherent limitations (as any standard structure ultimately would.) For instance, every single value in an XML-RPC call must be a parameter in the method call or response. This means that any session or presentation data in the parameters is stored under the methodCall and methodResponse nodes, which results in a very flat structure that doesn't discern the nature of the data or its purpose. Although alternatives are available, using custom data types means that you lose much of the benefit from the standard structure because the generic listeners will need the logic necessary to interpret that data. Basically, if you have to build unique structures for defining your Web services interface, you have to start questioning the value in conforming to the XML-RPC specification.

Secondly, today's parsers are far more advanced than the parsers were in 1998, when parsing XML data was more problematic because the parsers did not contain the ability to validate XML data. This standard format provided a simple way of programmatically validating at least the top-level nodes within a call and response. Today, we have more options that allow us to validate directly against a DTD or XML Schema, which means much less work on our part to establish a trust in the data.

Also, the strides made by parsers in making XML data easier to manipulate makes any XML document much easier to work with. It can be argued that the difference between working with an XML-RPC call and a similarly structured but nonstandard document is minimal, especially if the XML-RPC call contains many new structures.

Regardless of whether XML-RPC is used, a service provider can still benefit from defining consistent interface documents, much as we did for the hotel reservation Web service. There we defined a single format that could contain any of the five requests or five responses, yet had a consistent root node, service variables, and payload defined.

We didn't concern ourselves then with making our interfaces standard between the calls and the workflow because they were very different processes with very different objectives. Making the weather checker and the hotel reservation Web services consistent with each other would have provided little benefit, and likely more overhead for each, because additional nodes would need to be added to encapsulate both processes in a consistent container.

Our reusability also didn't suffer as much from not using a consistent format across all services because we separated the listener and responder. We had one process working to receive and route the Web service call while the responder handled the parsing of the request and building of the response. This allowed us the flexibility of defining the most efficient and sensible XML document for our interface and yet gave us some reusability from service to service. If we added the logic to the listener for handling the various requests, it could easily be reused for other Web services.

Overall, the XML-RPC has some appealing features that make it a viable format for your Web services, especially Web services without workflow. Supporting the necessary processes for integrating a workflow will likely require more customization to the format than it may be worth.

Perhaps the biggest question with XML-RPC is its shelf life. As much as the industry tries to push technologies to the limits, a frozen specification is sooner or later going to get left behind. I suspect at some point that either the author will decide to revise the specification, or it will become obsolete. Dave Winer also contributed to the original SOAP specification (which we will look at shortly), and, although he says the two standards can coexist, he knows that there can be, by definition, only one de facto standard. In fact, he has started a grass-roots developer effort to bring SOAP back to a simpler standard through the Busy Developer's Guide (http://www.soapware.org/bdg), which is an attempt to repackage XML-RPC inside a SOAP envelope.

The community site for XML-RPC can be found at http://www.xmlrpc.com. There you will find the specification along with implementations for nearly every platform and environment. Also of interest is a book on XML-RPC by Simon St.Laurent, Joe Johnston, and Edd Dumbill titled Programming Web Services with XML-RPC (O'Reilly Internet Series).

SOAP (Simple Object Access Protocol)

SOAP was actually started back in 1998 by Don Box of DevelopMentor, Dave Winer of Userland, and Microsoft's COM/MTS team. Unfortunately, politics kept it from being publicly introduced until 1999. It's reemergence coincided with the release of Don Box's now infamous article "Lessons from the Component Wars: An XML Manifesto" (http://msdn.microsoft.com/workshop/xml/articles/xmlmanifesto.asp). In it, Don identified the issues inherent in communicating between different middleware technologies and identified XML as a potential solution.

After the release of SOAP 1.0 in 1999 by the original authors, IBM entered the picture and assisted with the fairly minor changes that were made prior to the 1.1 release in 2000. Although the objective was to maintain the simplicity of XML-RPC, they wanted something that could be more extensible. To accomplish this objective, the concept of a request and response model was exchanged for a more general envelope model with a header and body. The envelope and body are mandatory, and the header is optional. The code that follows is a sample SOAP request from the specification:

 <SOAP-ENV:Envelope   xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"   SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">    <SOAP-ENV:Body>        <m:GetLastTradePrice xmlns:m="Some-URI">            <symbol>DIS</symbol>        </m:GetLastTradePrice>    </SOAP-ENV:Body> </SOAP-ENV:Envelope> 

SOAP and XML-RPC

One of its distinctions with XML-RPC is SOAP's inclusion of additional TCP/IP header information. Whereas XML-RPC does specify values like Content-Type and User-Agent, it does not add attributes. SOAP adds the SOAPAction attribute, which is meant to communicate the intent of the request. This is intended as a hint to the HTTP server on the type of request being made. SOAPAction could allow for more efficient routing of the request without opening the entire message. Although this attribute inclusion is required for all requests according to the SOAP specification, the specification does not place a requirement on providers to utilize or resolve SOAPAction. The following example is of a valid TCP/IP header for a SOAP request:

 POST /StockQuote HTTP/1.1 Host: www.stockquoteserver.com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "myAppRequest" 

Another distinction with XML-RPC is its support for all Internet protocols, not just HTTP. As such, SOAP is not intended exclusively as a request-response mechanism so that it can utilize asynchronous protocols such as SMTP or UDP. However, HTTP is still likely to be the most common transport protocol for SOAP. For those cases in which HTTP or another round-trip protocol is utilized, a SOAP response will be contained in the same envelope structure. A sample SOAP response is shown here:

 <SOAP-ENV:Envelope   xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"/>    <SOAP-ENV:Body>        <m:GetLastTradePriceResponse xmlns:m="Some-URI">             <Price>34.5</Price>        </m:GetLastTradePriceResponse>    </SOAP-ENV:Body> </SOAP-ENV:Envelope> 

As you can see through both of these examples, namespaces is a major com-ponent of SOAP. Although this does add to the complexity of SOAP, it does help to ensure the integrity of the message for consumers and providers.

The SOAP Approach

The authors of SOAP were trying to make it a very extensible format, but this intent might be the specification's biggest drawback. Its many defined tags and values may be pure overhead for a simple Web service. Although they were designed with the best of intentions, without widespread support and adoption you may have to support SOAP specifications that you or your consumers never use. A good example of this is the SOAPAction TCP/IP header attribute that we discussed earlier. The usefulness of such a loosely defined attribute (and whether it should be included at all) has been the subject of some debate. Yet, even with this ambiguity, the attribute is a required component of a SOAP request.

Another example of ambiguous overhead is the global mustUnderstand attribute, which is required of all SOAP Web service providers to support. If the provider intends to ignore this piece of information, which could be any piece of data, the request should not be processed. Although there is definite value in a consumer needing to ensure that a Web services interface doesn't change on them, communicating a change or lack of support through the failure of a request seems a bit too late in the process to guarantee the integrity of the application consuming the service. This is like putting in the middle of a bridge a sign saying it isn't connected on the other side. Wouldn't you like to know the bridge isn't complete before you start to cross?

As explained by the authors of SOAP, the mustUnderstand attribute is also intended as a negotiation mechanism for the kind of features that the consumer would like the Web service to support. This seems a rather inefficient means for negotiating a partnership, but it probably looks good on paper.

The Status of SOAP

The current SOAP 1.1 specification was published in April 2000. In March 2001, SOAP was submitted to the W3C and became a component of the XML Protocol (XMLP) Working Group:

The goal of XML Protocol is to develop technologies which allow two or more peers to communicate in a distributed environment, using XML as its encapsulation language. Solutions developed by this activity allow a layered architecture on top of an extensible and simple messaging format, which provides robustness, simplicity, reusability and interoperability.

—XML Protocol Working Group (http://www.w3.org/Architecture/)

Along with SOAP, other initiatives in XMLP include data serialization and defining a more structured mechanism for the transport of data over HTTP. It is not clear yet what effect these efforts will have, but a final recommendation is targeted for the end of 2001, with the group dissolving in April of 2002.

The XML Protocol Working Group published the first working draft for version 1.2 in July 2001. As such, aside from some unnecessary overhead, the biggest obstacle to the successful widespread adoption of SOAP is its "moving target" status: not only is another revision in the works, but also a new process and new contributors are involved now that it has fallen under the W3C. Unlike revising a server, tool, or even a programming language, modifying a standardized communication vehicle for interoperability will keep widespread adoption from becoming a reality. At the very least, we will get little benefit from the common tools envisioned by the standardized protocol until some foundation is finalized.

These two shortcomings are also where XML-RPC, the main alternative standard, draws its strength: it is frozen and has a simpler structure that presents constraints instead of overhead. Although neither is an ideal situation for developers, the benefits of a standard are realized only with consistency in the industry. For that reason, I am still a strong believer in building a Web services infrastructure around TCP/IP and XML until these other technologies mature. Anything more will either limit you or beg for modifications due to continuing revisions; anything less is not warranted because all Web services standards and initiatives are based on these two core technologies. This approach will neither limit your ability to use these emerging standards nor send you down a potential dead end.

One thing SOAP does have right now is incredible momentum. The industry's largest players all recognize it as a suitable standard, which makes it a very powerful player in the future of Web services. Vendors have almost had to join in support of SOAP for the same reasons that they have supported XML rank and file. Namely, if you don't support it, your competitors could hold a significant advantage over you. However, I do believe that the true success of SOAP has, and will continue to have, more to do with the concepts behind it than the specification's details.

You can find more information on the SOAP specification as well as some implementations on DevelopMentor's site (http://www.developmentor.com/soap/). You can get more information on the XMLP activity at the W3C site (http://www.w3.org/2000/xp/Activity).

WSDL (Web Services Definition Language)

WSDL is the culmination of several independent efforts to provide a standard format for defining the interfaces of Web services. By the summer of 2000, IBM had developed the Network Accessible Service Specification Language (NASSL) and the Interface Definition Language for SOAP-RPC (XIDL), and Microsoft had developed the Services Definition Language (SDL) and the SOAP Contract Language (SCL). Realizing that the success of Web services depended upon one consistent format for defining Web services, these longtime rivals collaborated to standardize on the Web Services Definition Language.

A standard definition method for Web services is perhaps even more important than standardizing on the communication mechanism itself. After all, if you speak the same language (XML) and have a dictionary (WSDL), you can develop an understanding of any terms you might come across (such as methodRequest, methodCall, procedureCall, and so on). However, if you did not have a dictionary, saying the same word over and over will not aid in your understanding of what it represents. With a standard dictionary format, we can reach an understanding of the information that a Web service wants submitted and the information it will return, regardless of the semantic terms used to describe it.

Keeping with this same analogy, once a Web service and all of its data elements are defined, if it isn't expected to change, you no longer need the WSDL. However, some think that the consumption of Web services could be, or even should be, dynamic. In that case, the application would utilize the WSDL each time to build the request for the Web service. Although the practicality of this is limited due to HTTP latency and the logic necessary to make truly dynamic Web services calls, some developers are working on the standard with that nirvana in mind.

If you discount the need for dynamic calls, you leave the door open for what is actually necessary as an IDL for Web services. Is it a programmatically accessible set of data, or could it be a human-readable document with a consistent structure? Many people in the industry are pondering this thought, and a consensus will not likely be reached anytime soon.

Although WSDL is designed to be protocol independent, most implementation efforts have been invested in SOAP bindings. This is due to the simple fact that the technology drivers of WSDL are also the drivers behind SOAP. Bindings are also available for HTTP and MIME.

WSDL itself is composed of a structured XML document that effectively wraps the XML Schema documents defining the payloads for your Web service. The root node is a definitions element with child elements consisting of types, message, portType, binding, and service. Listing 9-1 is an example of what the WSDL for a stock quote service might look like, courtesy of the specification.

Listing 9-1: The WSDL file for a stock quote Web service

 <?xml version="1.0"?> <definitions name="StockQuote" targetNamespace="http://example.com/stockquote.wsdl"      xmlns:tns="http://example.com/stockquote.wsdl"      xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"      xmlns:xsd1="http://example.com/stockquote/schema"      xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"      xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"      xmlns="http://schemas.xmlsoap.org/wsdl/"> <types>      <schema targetNamespace="http://example.com/stockquote/schema"        xmlns="http://www.w3.org/2000/10/XMLSchema">           <complexType name="TimePeriod">                <all>                      <element name="startTime" type="xsd:timeInstant"/>                      <element name="endTime" type="xsd:timeInstant"/>                </all>           </complexType>           <complexType name="ArrayOfFloat">                <complexContent>                      <restriction base="soapenc:Array">                           <attribute ref="soapenc:arrayType" wsdl:arrayType=                              "xsd:float[]"/>                      </restriction>                </complexContent>           </complexType>      </schema> </types> <message name="GetTradePricesInput">      <part name="tickerSymbol" element="xsd:string"/>      <part name="timePeriod" element="xsd1:TimePeriod"/> </message> <message name="GetTradePricesOutput">      <part name="result" type="xsd1:ArrayOfFloat"/>      <part name="frequency" type="xsd:float"/> </message> <portType name="StockQuotePortType">      <operation name="GetLastTradePrice" parameterOrder="tickerSymbol        timePeriod frequency">           <input message="tns:GetTradePricesInput"/>           <output message="tns:GetTradePricesOutput"/>      </operation> </portType> <binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">      <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/        soap/http"/>           <operation name="GetTradePrices">                <soap:operation soapAction="http://example.com/                       GetTradePrices"/>                <input>                     <soap:body use="encoded" namespace="http://example.com/                       stockquote" encodingStyle="http://schemas.xmlsoap.org/                       soap/encoding/"/>                </input>                <output>                     <soap:body use="encoded" namespace="http://example.com/                       stockquote" encodingStyle="http://schemas.xmlsoap.org/                       soap/encoding/"/>                </output>           </operation>      </binding>      <service name="StockQuoteService">           <documentation>My first service</documentation>           <port name="StockQuotePort" binding="tns:StockQuoteBinding">                <soap:address location="http://example.com/stockquote"/>           </port>      </service> </definitions> 

In March 2001, WSDL version 1.1 was submitted to the W3C, where it awaits a working group to start working on the first W3C recommendation. This is an example of vendors developing a standard and handing it off to a standards group for acceptance. This specification is a long way from being finalized as a standard, but many are pressing on, believing that it is inherently tied to SOAP and its success.

You can find the current WSDL specification on the W3C site (http://www.w3.org/TR/wsdl).

UDDI (Universal Description, Discovery, and Integration)

To be able to consume a Web service, you have to know that it exists. UDDI is a consortium effort started by Ariba, IBM, and Microsoft to establish the next generation of yellow pages for the Internet. In technical terms, UDDI roughly acts as a DNS for Web services.

UDDI consists of two main components: the UDDI syntax, which specifies business and technical criteria, and the business registry, which contains the data in this syntax. The syntax is XML based and defines information about organizations and their services. The registry actually consists of three different components, which are identified as white pages, yellow pages (my earlier comment referring to the yellow pages was actually less of an analogy than you might have thought!), and green pages.

The white pages consist of company identification and contact information. The yellow pages categorize organizations based on a standard taxonomy, with geographic locations, product and service areas, and industry codes. The green pages expose technical information about the services provide by a company, such as WSDL and service guidelines. The UDDI business registry allows users to look up organizations, products, and services either through a browser at http://www.uddi.org/find.html (see Figure 9-1) or through tools that can programmatically interpret the UDDI syntax.

Figure 9-1: The UDDI business registry

There is currently no charge to either use this directory or list your organization on it. It is understood that this may change over time, however. It will be up to the operators of the different registry instances. Currently, the only two operators of UDDI registries are IBM and Microsoft. Theoretically, anyone can host a public or private registry.

The UDDI business registry specification also includes the logic for replicating information between various registries. This is important for maintaining failsafe registries with consistent information.

Although the momentum for UDDI has not been as high among the developer community, the business community can appreciate and understand the concepts and benefits behind UDDI better than it can WSDL's and SOAP's, which require more technical knowledge and understanding. In fact, large companies that look to UDDI to solve internal challenges have generated the most interest.

Many companies are so large that they have a variety of systems built on different technologies exposing different processes. UDDI is a potential solution for exposing these interfaces and their details across departmental boundaries. Through the business registry, they could expose the interfaces and contact information for systems across their entire organization. This feature may be the biggest selling point for such a directory concept: the time a developer has to spend on either understanding an interface or rewriting an existing, unknown interface should be minimized with the use of a standardized business registry.

The open draft for UDDI version 2.0 was released in June 2001, and the timeline calls for a version 3.0 by the end of the year. Eventually, the consortium intends to hand over UDDI to a standards board (potentially the W3C, the IETF, or both). At that point, IBM and Microsoft may also turn over the registries that they are currently hosting.

For information on the UDDI specification and the business registry, visit the community Web site (http://www.uddi.org).

ebXML (eBusiness XML)

ebXML is a collaboration of UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business) and OASIS to define a globally standard XML format. Its mission is explicitly defined:

To provide an open XML-based infrastructure enabling the global use of electronic business information in an interoperable, secure and consistent manner by all parties.

—ebXML Mission (http://www.ebxml.org/geninfo.htm)

The 18-month effort resulted in the first specification being approved in May 2001, but future revisions are already being discussed. This very broad and ambitious standard includes specifications for defining company profiles and processes, and discovering them through an ebXML repository. It attempts to be an end-to-end standard for an electronic marketplace, defined through multiple initiatives:

• Collaboration Protocol Profile and Agreement (CPPA)

• Implementation, Interoperability, and Conformance

• Messaging Services

• Registry/Repository

ebXML CPPA defined the Collaboration Protocol Profile (CPP) and the Collaboration Protocol Agreement (CPA) for documenting a company's capabilities and willingness to collaborate with partners electronically. The first version of this specification has been completed, but another version is likely forthcoming.

The Implementation, Interoperability, and Conformance initiative of ebXML facilitates the interoperability of infrastructures and applications that follow the ebXML specification. Its goal is to create a conformance plan, reference implementation guidelines, and baseline interoperability tests.

ebXML Messaging Services hold the most value to developers working with Web services. Although this started out as an independent initiative, ebXML incorporated the SOAP specification into its messaging services in the March 2001 specification. What this means is that the message format for ebXML transactions are SOAP compliant. This was somewhat of a coup for SOAP because ebXML was distancing itself from unrelated initiatives. It demonstrates how much support SOAP has managed to generate.

Note 

Although the specification does not address Web services explicitly, ebXML's view of business services can easily be carried over to Web services.

This group's approach to specifying standard business processes was to take advantage of the lessons learned through nearly 25 years of experience with EDI and define an EDI-like standard based on XML. Although EDI is used today for transferring data documents between partners, ebXML takes the concept further by defining some transaction-level details that could be utilized for Web services.

Much like EDI, ebXML has a very rigid format and tag-naming convention that can make the building and parsing of data complicated if done manually. However, this standardization would make it very easy for vendors to provide very reusable solutions that can work with ebXML. Here, in Listing 9-2, we see a sample transaction for creating an order:

Listing 9-2: An ebXML order transaction

 <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV=   'http://schemas.xmlsoap.org/soap/envelope/'   xmlns:eb='http://www.ebxml.org/namespaces/messageHeader'>      <SOAP-ENV:Header>           <eb:MessageHeader SOAP-ENV:mustUnderstand="1" eb:version="1.0">                 <eb:From>                       <eb:PartyId>urn:duns:123456789</eb:PartyId>                 </eb:From>                 <eb:To>                       <eb:PartyId>urn:duns:912345678</eb:PartyId>                 </eb:To>                 <eb:CPAId>20001209-133003-28572</eb:CPAId>                 <eb:ConversationId>20001209-133003-28572</eb:ConversationId>                 <eb:Service>urn:services:SupplierOrderProcessing</eb:Service>                 <eb:Action>NewOrder</eb:Action>                 <eb:MessageData>                       <eb:MessageId>[e-mail]                       </eb:MessageId>                       <eb:Timestamp>2001-02-15T11:12:12Z</eb:Timestamp>                 </eb:MessageData>                 <eb:QualityOfServiceInfo eb:deliverySemantics="BestEffort"/>           </eb:MessageHeader>      </SOAP-ENV:Header>      <SOAP-ENV:Body>           <eb:Manifest SOAP-ENV:mustUnderstand="1" eb:version="1.0">                 <eb:Reference xlink:href="cid:[e-mail]"                   xlink:role="XLinkRole" xlink:type="simple">                      <eb:Description xml:lang="en-us">Purchase Order 1                      </eb:Description>                 </eb:Reference>           </eb:Manifest>      </SOAP-ENV:Body> </SOAP-ENV:Envelope> 

This standardized structure would obviously prevent you from building custom interfaces for Web services, but, if you wanted to provide a Web service based on one of the defined business processes, ebXML might be a good solution for you. After all, many companies will want to be able to accept orders through a Web service, and the functionality that's standardized through ebXML might make it easier for consumers to use your service if they are following the same process and payload definition for other partners. Although ebXML will provide a lot of capabilities right out of the box, don't expect to tailor it for more specific needs.

ebXML's registry and repository initiative will develop and recommend the discovery and retrieval of business services utilizing the standard Registry Information Model (RIM). This follows the common approach of exposing information and metadata on products and services through a globally accessible directory. Through this directory, trading partners can access an assortment of data on companies, their processes, and the definition of their data elements through various libraries. Because the specification designates no hosting community or organization for these registries, it is assumed that any organization could host their own ebXML repository.

If ebXML catches on, it could potentially define many of the components necessary for the lifecycle of standard, business-related Web services: discovery, definition, and implementation. However, the main force working against it is vendor support. Although many vendors assisted with the specification, they did not have the participation level of many of the other standards efforts, and some have come right out to criticize the ebXML specification.

One of the main reasons used to justify the lack of vendor participation was the projected 18-month turnaround on the first specification (which it did take). This timeframe was perceived to be too long for vendors to wait on it to develop their strategies and solutions. Although it might seem ideal that vendors could have been provided an extended amount of time to develop their offerings in the Web services space, the reality is that vendors are much too concerned with gaining or losing a competitive edge over each other to take a patient approach to a new market. And, although waiting on ebXML might have slowed some development efforts, it could also be argued that vendors are not as far along with their Web services solutions as they would have anticipated at this point.

You can find out more about ebXML and its many components at the official Web site (http://www.ebxml.org).

XLANG

XLANG is a scheduling language created by Microsoft for the orchestration component of its BizTalk Server product. XLANG doesn't seem to stand for anything, but rather seems to just be the name given this language. The XML-based language is not a standard at this point, but Microsoft did release the XLANG specification for public comment in June of 2001.

XLANG is now being extended as a language to automate business processes between Web services. Although the process can be transactional, the transaction that is supported is decoupled, meaning it supports any action having an equally opposed action to reverse the step. (This is similar to the undo feature of, say, a word processing application.)

XLANG's biggest advantage is the working example of its capabilities within BizTalk Server. Nothing is more effective when selling technology than seeing it in action; most people agree it works well. The XLANG specification can be found at http://www.gotdotnet.com/team/xml_wsspecs/xlang-c.

XAML (Transaction Authority Markup Language)

XAML—developed by a consortium comprising Hewlett-Packard, Bowstreet, IBM, Oracle, and Sun—is a vendor-neutral standard to support transactions between Web services. This includes the traditional two-phase commit transaction as well as the compensatory action approach found in the XLANG specification.

XAML is obviously a competitive alternative to XLANG, at least on some levels, but there may be room for both to coexist primarily because XAML is focused on transactions and XLANG does stretch across the broader automation process category. XAML also hasn't produced a lot since its announcement in October 2000, whereas XLANG is used today within BizTalk's orchestration feature.

You can find out more about XAML at its community site (http://www.xaml.org/).

XKMS (XML Key Management Specification)

XKMS was established by VeriSign, Microsoft, and webMethods in November 2000 as a protocol for registering and distributing private keys using the XML standard. The specification was then submitted to the W3C in March 2001 and became part of the very broad XML Protocol Activity.

The specification comes in two different components: XML Key Information Service Specification (X-KISS) and XML Key Registration Service Specification (X-KRSS). X-KISS defines the protocol for trust services, and X-KRSS defines how Web services can accept public key information. With both implemented, a Web service will be able to integrate authentication, digital signature, and encryption services into their own processes and potentially the applications that consume them.

For more information on XKMS, you can get the specification at http://www.w3.org/TR/xkms/. You can get more information on the concepts behind XKMS from VeriSign's site (http://www.verisign.com/developer/xml/xkms.html).

SAML (Security Assertion Markup Language)

SAML is an effort by OASIS to provide a framework for exchanging authentication and authorization information via XML. SAML is actually the collaboration of the previously distinct but similar efforts behind S2ML (http://www.s2ml.org) and AuthXML (http://wwww.authxml.org). In early 2001, both organizations agreed to submit their specifications to OASIS to reduce duplicate efforts.

SAML would likely be an alternative to the XKMS standard in development at the W3C. OASIS's goal is to produce a specification for a vote by its membership in September 2001. You can check its status and get more information on the specification at the OASIS Web site (http://www.oasis-open.org/committees/security).

XML-SIG (XML Signature Syntax and Processing)

The purpose of XML-SIG is to develop a standard for digitally signing applications and documents via XML. This W3C-led effort could have the potential to serve as a security mechanism for trusting transmissions between Web services and their consumers.

XML-SIG was started in 1999 and reached candidate recommendation status at the W3C in April 2001. You can check its status and view the specification on the W3C XML-SIG site (http://www.w3.org/TR/xmldsig-core).