Although you can build Web services with other technologies, SOAP, WSDL, and UDDI have become the de facto standards for Web services. For the remainder of this book I will focus on these technologies and their derivatives. SOAP, WSDL, and UDDI are the most widely accepted Web services technologies, and products supporting these technologies are available from dozens of vendors. Surprisingly, though, the SOAP-related technologies were not developed by an accredited standards organization. For the most part, these technologies were developed by IBM and Microsoft.
Considering how much has been accomplished based on these de facto standards, you might wonder whether it really matters if these specifications have some official seal of approval. But it does. For one reason, the existing specifications contain a number of ambiguities and inconsistencies that make it difficult to ensure interoperability among multiple SOAP implementations.[1] Second, these specifications address only basic Web services communication, and they don't provide standard facilities to support advanced functionality, such as security, transactions, and reliable delivery. Third, the intellectual property contained in the specifications is currently owned by the companies that wrote the specifications. Although Microsoft, IBM, and the other copyright holders are not likely to attempt to extract royalty fees from the people using SOAP, WSDL, or UDDI, they do have the right to do so. I, for one, would feel much more comfortable if this intellectual property were placed in the public domain.
Standards provide benefits to the industry at large by enabling consistency, interoperability, and vendor independence. Standards also enable a vibrant third-party market for software accessories and software applications. Moreover, a formal standardization effort promotes the development of open, interoperable technologies. A standards organization also provides a venue that gives any interested party, large or small, vendor or customer, an equal footing in the development of these technologies.
SOAP originated as a joint project started in 1998 by representatives from Microsoft, DevelopMentor, and Userland. Partway through the development process, Dave Winer of Userland published a simpler variation of SOAP called XML-RPC, which still has a strong following. Microsoft et al. published the SOAP 1.0 specification in late 1999. SOAP certainly wasn't the first XML messaging protocol, but because it offered an interesting, extensible design and had Microsoft's weight behind it, SOAP attracted more attention than previous XML messaging protocols. But at this point most people still viewed SOAP as a Microsoft-centric technology. In an effort to establish vendor-neutral credibility, Microsoft recruited representatives from IBM and Lotus to join the effort. These five companies then published the SOAP 1.1 specification in April 2000. The authors jointly submitted this specification to the W3C, garnering support from six other companies in the process. The W3C subsequently published the specification as a W3C Note. Although a W3C Note doesn't imply any endorsement from the W3C, publication of the Note lent significant credibility to the specification.
In May 2000, IBM released the first implementation of the SOAP specification, an open source implementation for the Java language called SOAP4J. IBM submitted this implementation to the Apache Software Foundation, and it then became known as Apache SOAP. Shortly afterward, Microsoft produced a Windows-based SOAP implementation for Visual Basic and Visual C++ called the Microsoft SOAP Toolkit. Then in July 2000 Microsoft launched the .NET initiative, much of which is based on Web services and SOAP. SOAP rapidly became a major force in the industry.
A number of other companies and individuals released independent SOAP implementations over the next few months, including Systinet's IdooXoap, Simon Fell's PocketSoap, and Paul Kulchenko's SOAP::Lite. These implementations support Java, Visual Basic, and Perl, respectively. By the end of 2000 there were more than 20 SOAP implementations available, supporting a multitude of programming languages. Other companies and individuals have since jumped on board, and by the end of 2002 there were more than 90 SOAP implementations.
Although SOAP 1.1 has enormous industry support and many implementations are available, SOAP users have uncovered significant interoperability issues. SOAP is designed to be vendor-neutral, but not all vendors interpret the specification in the same way. Some aspects of the specification are inaccurate, incomplete, contradictory, or open to interpretation. For one thing, the SOAP specification doesn't specify how application languages interface with SOAP. Although it is easy to get a Java client using Apache SOAP to talk to a Java server using Apache SOAP, or to get a Visual Basic client using Microsoft SOAP to talk to a Visual Basic server using Microsoft SOAP, it can be difficult to get a Java client using Apache SOAP to talk to a Visual Basic server using Microsoft SOAP or vice versa.
In 2001 many of the SOAP vendors joined together to create an informal group known as SOAPbuilders. The group has created a series of test suites that SOAP implementers can use to identify and resolve interoperability issues. The group communicates using an e-mail discussion group, and the members meet once per quarter for face-to-face “interop-athons.”
Through the SOAPbuilders' efforts, the SOAP vendors have dramatically improved many of the interoperability problems, and most implementations now support seamless interoperability as long as you keep your messages simple. But as soon as message structures become more complex, interoperability can still be very challenging.
More formal efforts are necessary to achieve seamless interoperability in a realistic business setting. Two formal efforts are under way: the Web Services Interoperability Organization (WS-I) and the formal standardization of Web services technologies.
In February 2002, Accenture, BEA, Fujitsu, HP, IBM, Intel, Microsoft, Oracle, and SAP launched the WS-I organization. WS-I's charter is to promote Web services interoperability across platforms, operating systems, and programming languages. Obviously the industry liked the idea of a formal venue for this work, because within a week more than 60 organizations had joined the consortium. The organization caused a bit of a flap at first because the founding members had not invited Sun to participate. Eventually everyone's feathers were smoothed out, and by late 2002, membership had grown to more than 150 companies, including Sun.
WS-I is defining a set of profiles and guidelines for Web services. The primary focus of current WS-I efforts is to enable interoperability. The profiles will help your IT organization understand what level of interoperability it can expect from various Web services technologies. The guidelines will help your developers build interoperable Web services. As long as you adhere to these guidelines, you can reasonably assume that any Web services you build can be accessed by service consumers using any platform language or tool. WS-I is also developing tools and test suites that you will be able to use to verify that your Web services comply with the guidelines.
WS-I's first deliverable is the WS-I Basic Profile. A draft of this document was first published in October 2002 and updated in April 2003.[2] It defines a profile based on the SOAP 1.1, WSDL 1.1, and UDDI 2.0 specifications, and it defines a set of constraints that you must follow to ensure interoperability using these technologies. If you build your Web services within the constraints defined by the Basic Profile, then you can claim conformance with the profile. Many vendors have pledged to implement support for the profile, something that also improves your chances for interoperability.
WS-I chose to address the interoperability issue by reducing the number of permitted options. SOAP and WSDL give you a fair amount of latitude in how you construct messages and describe services. Although this latitude gives you quite a bit of flexibility, it also makes it much more difficult to ensure interoperability. The WS-I Basic Profile reduces the number of options defined in the specifications. WS-I based its decisions on real world use cases and scenarios for Web services.
WS-I doesn't position itself as a standards body. WS-I is not developing new technologies. Instead it is focused on making the current technologies work better. In the course of its work, though, it has identified some of the most troublesome aspects of the current specifications and is feeding this information into the formal standardization efforts.
The formal standardization efforts are happening at the W3C and OASIS. In September 2000 the W3C launched the XML Protocol Activity to define a standard based on SOAP 1.1. More than 140 representatives from more than 65 W3C member companies have participated in the development of this standard XML protocol, now called SOAP 1.2.
SOAP 1.2 is a formal standard,[3] developed using an open, collaborative process. It is quite similar to the SOAP 1.1 specification, but it corrects many of the inaccuracies, omissions, contradictions, and ambiguities that appear in SOAP 1.1. The XML Protocol Working Group published a W3C Candidate Recommendation in December 2002, followed by a W3C Proposed Recommendation in May 2003. I expect the final W3C Recommendation to be approved in the second or third quarter of 2003. A number of SOAP implementations provide preliminary support for SOAP 1.2, including Apache Axis, BEA WebLogic Server, Microsoft .NET, SOAP::Lite, Systinet WASP, TIBCO Web Services SDK, and WhiteMesa Server.
In the early days of SOAP, IBM and Microsoft each developed a unique language to describe Web services for its SOAP toolkit. Developers using these early toolkits would define their services using these languages and then would compile the definitions to generate the SOAP communications routines for client and service applications. IBM's definition language was called Network Accessible Service Specification Language (NASSL). Microsoft's language was called SOAP Contract Language (SCL). Both languages performed essentially the same function, but they used two different XML vocabularies to represent information about the Web service contract, such as the method names and the input and output messages. There was no way to use a NASSL definition from the IBM toolkit to generate a client with the Microsoft toolkit, and no way to use an SCL definition from the Microsoft toolkit to generate a client with the IBM toolkit. It quickly became apparent that a common description language was needed to enable integration across multivendor implementations.
Following the successful collaboration that produced the SOAP 1.1 specification, IBM and Microsoft again joined forces to merge NASSL and SCL and develop a common description language. In September 2000, they published a unified description language called WSDL.
Over the next few months, IBM and Microsoft corrected a few inconsistencies in the original WSDL specification and then submitted the WSDL 1.1 specification to the W3C. The authors managed to recruit 23 other co-submitters, making it the largest submission team in the history of the W3C. The specification was published as a W3C Note in March 2001, and the industry adopted WSDL 1.1 with as much gusto as it had SOAP 1.1. In short order most SOAP implementations added support for WSDL.
But just as with SOAP 1.1, the WSDL 1.1 specification was never put through the rigorous analysis and review of a formal standardization process. It also contains a number of ambiguities and inconsistencies that contribute to the interoperability issues.
The WS-I profiles and guidelines make an effort to clarify the meaning of many of the ambiguities in WSDL, but they don't resolve the underlying issue that the WSDL specification needs improvements. Moreover, these improvements should occur under the auspices of an accredited standards body.
In March 2002, the W3C stepped up its efforts in Web services technologies. It launched a major Web Services activity consisting of multiple working groups and a coordination group. The XML Protocol Working Group was moved into this activity, and two other working groups were formed, including the Web Services Description Working Group and the Web Services Architecture Working Group. The Web Services Coordination Group acts as a liaison with related W3C activities, such as the XML Activity, the XML Signature Activity, the Semantic Web Activity, and the W3C Technical Architecture Group, as well as with other standards organizations such as the Internet Engineering Task Force (IETF) and OASIS.
The Web Services Description Working Group (WS-Desc) is working on a new and improved description language called WSDL 1.2. More than 40 representatives from more than 30 W3C member companies are contributing to this effort. The WS-Desc group published its third W3C Working Draft in March 2003. Based on current discussions, I anticipate that WSDL 1.2 will be quite different from WSDL 1.1. I expect the final version of the WSDL 1.2 specification to be published in late 2003 or early 2004.
The Web Services Architecture Working Group (WS-Arch) is defining a reference architecture for Web services.[4] This architecture defines the various functional components and technologies that are or might be required to implement applications based on Web services technologies. Examples of some of these functional components are message exchange, service description, service publishing and discovery, security, reliability, and choreography. More than 80 representatives from more than 50 W3C member companies have contributed to this effort. The group published its first Working Draft of the architecture in November 2002.
Some of the functional components identified in the Web Services Architecture are in the process of being standardized by other W3C working groups. For example, the XML Protocol group is developing a standard for message exchange (SOAP 1.2), and the WS-Desc group is developing a standard for service description (WSDL 1.2). Some functional components are in the process of being standardized by other standards organizations. For example, the OASIS UDDI Specification Technical Committee (UDDI-spec) is standardizing a method for service publishing and discovery (UDDI V2 and UDDI V3), and the OASIS Web Services Security Technical Committee is defining standards for security.[5] As part of the architectural definition process, the WS-Arch team is identifying functional areas that require standardization and is making recommendations for further working groups.
The first such group was formed in January 2003. At the request of the WS-Arch team, the W3C launched another working group within the Web Services Activity. The Web Services Choreography Working Group (WS-Chor) is developing a choreography language for creating composite services and for defining choreographed interchanges among multiple Web services.[6] The WS-Chor team may base its work on Web Services Choreography Interface (WSCI), a choreography language developed by BEA, Intalio, SAP, and Sun, which was contributed to W3C and published as a W3C Note in August 2002. Although BEA, IBM, and Microsoft have also developed a choreography language called Business Process Execution Language for Web Services (BPEL4WS), the WS-Chor team isn't using this specification as a source of input. Instead, the BPEL4WS authors launched a competing standardization effort at OASIS in April 2003 called Web Services Business Process Execution Language (WS-BPEL).
UDDI is a more complex technology than either SOAP or WSDL, so for this effort IBM and Microsoft invited the leading software and service vendors to participate in an informal consortium called UDDI.org. Ariba, IBM, and Microsoft published a draft of the UDDI 1.0 specification and launched UDDI.org in September 2000. The three founders then invited Accenture, Commerce One, Compaq, Equifax, Fujitsu, Hewlett-Packard, i2 Technologies, Intel, Oracle, SAP, Sun Microsystems, and VeriSign to join the UDDI Working Group. Representatives from these companies met once a month for approximately two years to work on the UDDI specifications. In addition to the core working group, more than 300 other companies joined the UDDI Advisory Group, providing input for the specification requirements and commenting on preliminary specifications.
The original UDDI 1.0 specification has very limited value. Its most blatant limitation is that it provides integrated support for only three industry taxonomies, and it makes no provision to support custom taxonomies. It also has no complex query facilities.
UDDI.org published the UDDI 2.0 specification in June 2001. This version adds support for custom taxonomies, making UDDI much more interesting and valuable. This version also adds support for business relationships, and it greatly enhances query capabilities.
The UDDI 3.0 specification was published in July 2002. This version adds more enhanced query facilities, internationalization support, security, subscription and notification services, and interregistry relationships. Following the publication of UDDI 3.0, UDDI.org submitted the specification to OASIS for formal standardization and shut the doors on the informal consortium. All subsequent work on the specifications now occurs at OASIS. The UDDI-spec committee published the UDDI V2 and V3 specifications as OASIS Committee Specifications in September 2002. The UDDI V2 specification was approved as an OASIS Standard in April 2003. The UDDI V3 specification requires a bit more work. It should become a formal OASIS standard in the second half of 2003.
Loosely associated with UDDI.org is a formal business partnership called the UDDI Operators Council. The members operate a public UDDI registry called the UDDI Business Registry (UBR). The public registry is available free of charge for anyone to advertise and discover public Web services.
The UBR was launched in September 2000 at the same time that UDDI.org was established. Initially the members of the UDDI Operators Council were Ariba, IBM, and Microsoft, the three founding members of UDDI.org. Ariba dropped out of the partnership in May 2001. Hewlett-Packard quickly stepped forward to take Ariba's place, and SAP and NTT joined the partnership in late 2001. Following the acquisition of Compaq, though, Hewlett-Packard decided to scale back its investments in Web services middleware and withdrew from the partnership. At the time of this writing, IBM, Microsoft, NTT, and SAP operated the UBR, implementing the UDDI 2.0 specification.
Each member of the UDDI Operators Council operates a UBR node. All nodes within the UBR contain identical information. All data registered in one node is replicated to all the other nodes within about an hour.
Any individual, business, or industry group can register services and service types in the UBR. Before you register any information, though, you must become a registered publication user of the registry node. Publication registration is free, but you must establish your credentials with the UBR node operator. Each UBR node operator uses a different mechanism to set up credentials. After you register information in a specific UBR node, that node becomes the custodian of the registration. Any subsequent modifications made to the registration must be made through the same UBR node. If for some reason you become dissatisfied with your UBR node operator, you can request that custody of your registration be transferred to a different operator.
Anyone can query the UBR. You must be a registered query user, but the query credentialing process is much more relaxed than the publication credentialing process. Anyone with a valid e-mail address can query the UBR. All information in the UBR is available to the general public. Thus you shouldn't register any information in the UBR that you don't want to publish to the entire world.
Although UDDI.org at first touted the UBR as “a core element of the infrastructure that supports Web services,” it has not been a big hit with the industry. Very few businesses have registered services in the public registry. The UBR has been a victim of its own hype. It has been promoted as, among other things, the ultimate comparison shopping agent. One of the most hyped UDDI scenarios says that you can use the UBR to find a supplier that will give you the lowest price with the best delivery options. Unfortunately, this scenario depends on a lot of assumptions that just aren't real. The UBR can help you find a supplier that provides the goods you want, but it doesn't give you a facility to compare prices.
When you get past the unrealistic hype and look at UDDI for what it is, you soon realize that UDDI does in fact play an important role in Web services technology. Although you can easily develop and deploy Web services without UDDI, after you've deployed a few you'll find you need UDDI to help manage your environment. UDDI's value increases as the number of your Web services increases.
UDDI plays a much more valuable role in a private setting. A business or business community can set up a private UDDI registry to advertise and discover Web services within a secure and controlled environment. You can use a private UDDI registry to publish Web services within your own organization or to a select set of customers or business partners.
For example, you can use a private UDDI registry to help manage your corporate software assets. As departments and business units in your organization build reusable Web APIs for their application systems, you need a way to let other departments and business units know about the APIs. You can set up an internal private UDDI registry, and each time a developer deploys a new Web service for internal use, this Web service can be registered and categorized in the internal registry. You can set up your own custom taxonomies to indicate information such as the owning department, release version numbers, and internal charge-back policies. These custom taxonomies provide the real value of private UDDI.
Another popular way to use a private UDDI registry is to control redundant application functionality. The U.S. Navy manages tens of thousands of applications, and currently it's not uncommon to find multiple applications that perform essentially the same function. In an effort to reduce redundant systems, the Navy is establishing a process using UDDI that identifies duplicative applications before they are deployed.
All Navy application systems are accessed through a portal. Users can customize their portal layouts to view various applications in different sections or frames within the browser. A Navy application runs within one of these frames. An application consists of a portlet and a set of backend services. The portlet contains the presentation logic that displays the application interface in the frame. The backend services perform the actual application logic. A backend service might be a locally resident service, or it might be a remote function implemented by either the Navy or some other organization. For example, the portlet might call out to an FAA service to obtain a weather report. To add a new application to the portal, you must configure the portlet and register the backend services in UDDI. Registration requires comprehensive analysis and assessment of each new application to justify its purpose and determine its value. This process enables the Navy to identify duplicative applications and select best-of-breed solutions. Additionally, it allows developers to identify existing applications and Web services that can be leveraged to provide content for additional business processes in new applications.
A private UDDI registry can also simplify your extranet operations. Let's say, for example, that you would like to allow your distributors to place orders or submit forecasts electronically. You can do so by creating a set of Web services with simple Web APIs that can support any type of client application. But how do you tell your distributors about these APIs? You could assign one or more of your employees the task of contacting each of your distributors and locating the specific person responsible for developing the client interfaces and then relaying information about the location of the WSDL descriptions for each of your Web services. Or you could exploit the benefits of UDDI and register these services in your private extranet UDDI registry, letting your distributors know that the services are now available. Each distributor can then query the extranet UDDI registry to find the needed information.
A private UDDI registry is an invaluable asset in a Web services-based electronic marketplace. An e-marketplace brings together buyers and sellers and facilitates e-procurement. Generally you must be a member to use the marketplace facilities, and the registration process requires some level of due diligence to ensure the integrity of the member companies. By joining the marketplace, you get an instant, qualified list of buyers and suppliers. All that's left to do is to build the interfaces into your application systems to let you engage in electronic business. If the definitions of those interfaces are registered in a private UDDI registry, it makes it that much easier for you to integrate your systems.
Unlike other middleware systems, SOAP, WSDL, and UDDI do not define programming standards. These specifications simply define the communication protocols in terms of XML. They don't indicate how an application program written in, say, Java or Visual Basic should interact with Web services. The specifics of how applications interact with SOAP and WSDL have been left as an exercise to the application community.
Any application language can parse (syntactically analyze) and process XML, so, at a minimum, you can simply construct XML messages within your application, package them in a SOAP envelope, and exchange them with other applications. But such manual processing isn't conducive to developer productivity, and it doesn't exploit the fact that WSDL is machine-readable and therefore can be compiled into application code.
Most SOAP implementations provide tools that automatically generate the code necessary for your applications to send and receive SOAP messages. For the most part, you'll find that these tools can be used only with their associated SOAP implementation. Although the technology is standard, the way you use it isn't. This situation threatens to limit the potential long-term market for third-party software accessories and business applications. Standard programming interfaces can open up this market.
Microsoft has the ability to define its own standard programming interfaces for its development tools. The .NET framework provides a set of standard Web services class libraries and frameworks for the C# language, and Visual Studio .NET supplies visual tools and services for C#, Visual Basic, and the other .NET languages. The Microsoft SOAP Toolkit provides comparable tools for earlier versions of Visual Studio.
Similarly, other proprietary language vendors, such as Borland and Sybase, can develop their own standards for integrating SOAP with their languages. Borland has developed SOAP tools for C++Builder, Delphi, and Kylix, and Sybase is developing SOAP tools for PowerBuilder.
Java poses a slightly more challenging situation, though. No one vendor can establish standards for the Java community. More than two dozen SOAP implementations for Java are on the market, and until recently each of them provided its own programming interfaces and class libraries. Having a multitude of Java APIs for SOAP doesn't impact the capabilities of SOAP, but it does impact the productivity of your developers and the amount of vendor lock-in you experience. The concept of “Write Once, Run Anywhere” and cross-vendor portability are pretty much out of reach if you have different APIs for every SOAP implementation for Java.
In an effort to stave off industry fracture, the Java community has come together to define a set of standard Java APIs for Web services through the Java Community Process (JCP). In 2002, the JCP delivered five standard Java API specifications for Web services. More specifications are in development.
There are many different levels at which an application might like to work with SOAP. A lot of Java developers prefer to work strictly with Java constructs and not worry about parsing or manipulating XML. Other developers might prefer to work directly with the XML documents. And at times you may need to work directly with the SOAP constructs. Therefore the JCP has created three Java APIs for working with SOAP.
The Java APIs for XML based RPC (JAX-RPC) is a WSDL-aware, Java-centric, RPC-style programming interface that makes SOAP look and feel a lot like RMI. Although the name suggests otherwise, JAX-RPC can be used for both RPC-style and document-style Web services. A JAX-RPC tool provides a WSDL compiler that generates the code that maps the Web service's XML data structures to native Java objects. At runtime, JAX-RPC automatically performs all data translations between Java and XML, and it automatically constructs and interprets the SOAP messages according to the definitions in the WSDL description.
JAX-RPC provides full support for all the dynamic features associated with SOAP and WSDL. A JAX-RPC client application can use a development-time precompiled client proxy to access a specific service implementation. It can also select an implementation of a given service type at runtime, and JAX-RPC will generate a dynamic binding.
The Java API for XML Messaging (JAXM) is an XML-centric, message-oriented programming interface that doesn't rely on WSDL. You would use this API if you have an XML document, such as a purchase order, and you simply want to send it to another application.
JAXM hides the mechanics of SOAP messaging. JAXM uses a profile that defines a template for the SOAP message structure, and it automatically constructs the SOAP envelope, SOAP header, and SOAP body based on this template. The Java application simply adds the XML payload to the message.
JAXM is designed to be used with document-style SOAP messages rather than RPC-style messages, although a developer could use JAXM to build RPC-style messages. One of the primary distinctions between JAXM and JAX-RPC is that JAXM does not support WSDL. JAXM provides no facilities to automatically map Java objects to XML structures. Thus it's up to the developer to define the appropriate mappings and to ensure that the SOAP messages conform to the WSDL description.
JAXM was initially designed as an API for the ebXML Message Service (ebMS). When the ebXML initiative adopted SOAP 1.1 as its underlying XML protocol, the JAXM effort expanded its scope to also support SOAP messaging. When you're using the ebMS you usually send the message payload as an attachment to the SOAP message rather than within the SOAP body. An ebMS SOAP header holds security and reliability information about the message, and the SOAP body contains a manifest of the attachments to the message. An ebMS JAXM profile can automatically generate this basic SOAP message structure, and then the application adds the message payload as an attachment. The WSDL specification doesn't indicate how to specify the contents of an attachment, so WSDL doesn't play as important a role in this situation.
The SOAP with Attachments API for Java (SAAJ) provides a low-level programming interface that allows Java applications to work directly with the constructs of the SOAP message. SAAJ is used by both JAXM and JAX-RPC, so even when using these APIs, a developer can always drop down into the SAAJ API to access the SOAP envelope.
Under most circumstances, a Java application doesn't need to interact directly with a WSDL document. Usually a Java application uses JAX-RPC to interact with a SOAP service, and JAX-RPC manages all the WSDL manipulation for the application. The primary exception to this rule is an application that wants to dynamically discover and use a service, and hence it has no access to the WSDL document at development time. In this circumstance, the application needs access to the WSDL file at runtime.
For this situation, developers can use the Java API for WSDL (JWSDL), which is an API that allows a Java application to create, inspect, and manipulate a WSDL document. SOAP tools use JWSDL to compile a WSDL document into a SOAP communication routine. SOAP runtime systems use JWSDL to generate dynamic bindings. Java applications can use JWSDL to dynamically interpret the operations and messages supported by a service.
A UDDI registry is a Web service, so the standard way for an application to speak to UDDI is to send it SOAP messages. The Web service interfaces (there are two: inquiry and publish) are described by WSDL documents. So any application that can speak SOAP can access a UDDI registry. For example, a Java client application can use JAX-RPC to communicate with a UDDI service. Even so, the UDDI data model is fairly complex, and it's helpful to have a dedicated Java API that understands UDDI tModels, binding templates, and categorization schemes and automatically constructs valid UDDI SOAP messages for you.
Most UDDI vendors provide UDDI client APIs with their products. You can use any UDDI client API to talk to any UDDI registry as long as they both conform to the UDDI specifications. One of the most popular UDDI client APIs in the Java community is UDDI4J.
This API was first developed by IBM in 2001 and then released as open source. UDDI4J provides a direct mapping of the UDDI SOAP operations and data structures to Java methods and classes. For someone who's familiar with the UDDI data model, this API is very intuitive.
Despite UDDI4J's popularity, it is not the standard Java API for UDDI. The Java API for XML Registries (JAXR) is an API for both UDDI and the ebXML registry. This dual-purpose API is quite an achievement, given that the data structures in UDDI are different from those in ebXML. The JAXR data model is based on the ebXML data model, which is a bit more generic than the UDDI data model. The JAXR data model is business-oriented, and the API streamlines a number of operations.
One side effect of this higher-level data model is that JAXR's object names don't match the UDDI element names. For example, JAXR uses terminology such as “Concept” rather than “tModel,” and “ClassificationScheme” in place of “categoryBag.” For developers who are accustomed to UDDI terminology, the JAXR API takes a bit of getting used to. Some of your developers may prefer to work with a more UDDI-centric API. I suggest that you try both and determine which one you like better. If you plan to use both registries, you should definitely use the JAXR API.
The basic Web services technologies—SOAP, WSDL, and UDDI—did not start out as formal industry standards. IBM, Microsoft, and a few invited friends are responsible for launching this new approach to application integration. Now these technologies are well on the way to formal status. Table 4-1 summarizes the status of these standardization efforts.
Table 4-1. Summary of Standardization Efforts
Specification | Group | Status | Estimated Completion |
|---|---|---|---|
SOAP 1.2 | W3C | Proposed Recommendation: May 2003 | W3C Recommendation: Q2/Q3 2003 |
WSDL 1.2 | W3C | Working Draft: March 2003 | W3C Recommendation: Q4 2003/Q1 2004 |
UDDI 2.0 | OASIS | OASIS Specification: May 2003 | OASIS Specification: April 2003 |
UDDI 3.0 | OASIS | Committee Specification: September 2002 | OASIS Specification: Q4 2003 |
You may have noticed an interesting trend in the Web services standardization process. Nearly every technology advancement has been developed by a small number of companies working together to solve a problem. These companies publish a specification to the general public, and, if it gains traction, the authors submit the specification to W3C or OASIS. Shortly afterward, a working group or technical committee is created to develop a formal standard based on the submission. This process has proved to work quite successfully and is responsible for the rapid advancement of Web services technology.
[1] A SOAP implementation is a product that implements the SOAP specification. We discuss these products in Chapter 8.
[2] Obviously this information will become quite dated in a short period of time. Please visit http://www.bowlight.net for periodic updates.
[3] I refer to SOAP 1.2 as a formal standard, although I should point out that W3C and OASIS are not formal international standards organizations. They are vendor consortia. For practical purposes, though, the industry views their works as formal standards.