The services-based economy is characterized by industry leaders and thinkers as the next wave in the high-tech world or the Next Chapter of the Internet unfolds. Keep in mind that several software companies, including a few software giants, have invested in this space and developed technologies to promote open and standards-based service-centric computing.
In this chapter, we depict the competitive landscape portraying both the recognized leaders in this space as well as competing registry technologies. Since the registry and Web services technologies are evolving, currently no specific product or vendor can be pointed out as a clear winner or leader. That can happen only after the standards and technologies mature and companies strive to accommodate them. We provide only comparative analysis in this discussion.
Due to the close relationship between the UDDI registry and the Web services paradigm, several vendors include support technologies for both in their offerings. While surveying vendors, it is thus useful to compare the features for both these technology sets.
Microsoft and IBM are recognized as leading the effort for both furthering the Web services economy and providing technologies to support it. In this chapter, we primarily focus on the technologies provided by these companies.
Microsoft’s DOT NET (or .NET) is the first Web service technology mentioned in this chapter because Microsoft — along with IBM — has taken a leadership role in defining what Web services means and how to make them a reality. The DOT NET strategy is a significant change in the way software applications are constructed and deployed.
Microsoft’s DOT NET announcement was quickly followed by several white papers describing the Web services components, such as SOAP (Simple Object Access Protocol), the BizTalk 2.0 Framework, and UDDI (Universal Description, Discovery, and Integration). Microsoft also released software developer kits (SDKs) for DOT NET, UDDI, and BizTalk 2.0. This generated a lot of interest among the developer community as these components and related white papers explained Microsoft’s vision for Web services by providing developers with sample infrastructure components that would allow them to test-drive Web services and DOT NET concepts.
The early foundations for Microsoft’s DOT NET are SOAP (which began its life as XML-RPC) and the CLR (Common Language Runtime). CLR is Microsoft’s new Operating System (OS) infrastructure that allows software applications and components written in different languages to intercommunicate. It is like a virtual machine that can execute Visual Basic, Java, C#, C++, and other languages. At an architectural level, the CLR resembles Sun’s JVM (Java Virtual Machine). It provides garbage collection, namespaces, metadata, etc. But unlike Sun’s JVM, the Microsoft CLR integrates smoothly into the overall operational infrastructure that Microsoft provides, including: IIS, COM+, ASP+, and DOT NET Web services.
Although Microsoft’s CLR work may end up being extremely useful for advocates of multilanguage development and Java-like languages, the Web services portion of DOT NET does not really require much of the CLR infrastructure on the server side. And clients of DOT NET Web services can be written in any language — Microsoft CLR-compatible or not. In fact, a developer can easily connect a Perl client running on a Linux operating system to a Web service provider written using DOT NET software. And this is what Web services are all about. This flexibility has also assisted Microsoft in its ability to gain developer mindshare and strong support of the DOT NET platform.
DOT NET clients communicate with services by exchanging XML documents — usually via HTTP/S POST messages. XML documents that are exchanged contain no trace of what language was used to generate them. So, for example, Java Web services clients can easily communicate with COM+ Web services written in C#. The languages used to write the clients and servers just do not matter.
Note
At the core of the Web services vision lies the interoperability and the desire for platform/language independence. The important thing is that the client and the server can exchange XML documents with each other — and that both the client and server can interpret any “enveloping” that is used to wrap and transport those documents.
Developing clients and servers that can parse and create XML documents is rather simplistic at this point. The open source community provides a number of XML parsers and generators based on the Document Exchange Model (DEM) and Simple API for XML (SAX) standards. These parsers and generators exist for all the languages used to develop Internet-based applications today. Microsoft continues to provide up-to-date DOM- and SAX-based libraries that can be used from any Microsoft-supported language (such as C#, C++, Visual Basic, and JavaScript).
The tricky part of getting clients and servers to be able to communicate by exchanging XML documents is for there to be a universally agreed-upon “enveloping” technology used to wrap the XML business documents that are exchanged. Previously, the most likely candidate for transporting XML data between clients and servers was the XML-RPC standard — proposed by DevelopMentor. This was a standard that allowed clients to invoke methods synchronously on servers by sending the servers XML documents containing the name of the method to invoke and the parameters to pass into the method. Once a server received an XML-RPC message, it would invoke the requested method, then return the results of that method invocation (the return value — if any — from the method call) as an XML document. The XML-RPC request was sent by the client to the server in an HTTP POST, and the HTTP response to that post contained the XML-RPC response.
On the inside, XML-RPC defined an XML vocabulary representing an “envelope” that contained a “body.” Within that body was the XML payload that a client was sending to the server (and that the server returned to the client). The rules were that the transport-specific information should be contained in the HTTP POST message and the envelope part of the XML- RPC message, and the body of the XML-RPC message would contain the business document. Because XML-RPC was originally about making method calls, the business document transported within the body was actually an XML representation of either a method invocation (if you were a client sending the XML to the server) or an XML representation of the results of a method call (if you were a server returning a result to a client).
XML-RPC was a good starting point, but it was designed primarily for synchronous calls. This is not a very scalable solution when there are very many clients concurrently invoking services provided by a single server. A better solution would be an enveloping technology that allowed for synchronous or asynchronous communication of XML documents. On top of that, it would allow the XML business documents exchanged to be either XML representations of method invocations or full-blown business documents — such as purchase orders, invoices, and receipts. DevelopMentor worked with Microsoft to extend the definition of XML-RPC to include these new features. This work later was renamed SOAP. The SOAP specification has been submitted to the W3C (World Wide Web Consortium) for standardization.
Early SOAP toolkits provided client-side code and a listener Active Server Page (ASP) that assisted in creating Web services and invoked them from any Microsoft-supported language. At that time, because a standard for describing the “public interfaces” of Web services was not developed, this toolkit used Microsoft-proprietary Service Definition Language (SDL). This language was used both to generate the client-side proxy for calling a Web service and for configuring the server-side listener so that the listener knew the action to be performed when it received a Web service call.
The DOT NET Framework SDK was available soon after the SOAP toolkit. This SDK was much richer than the early SOAP toolkit. It provided a plug-in for Internet Information Server (IIS) that allowed IIS to understand when it was hosting a servlet containing a Web service. And the SDK provided a simpler-to-use client-side Application Programming Interface (API) for invoking Web services from Visual Basic or C#. In fact, this SDK provided a C# compiler and early release components of the CLR. With this new SDK, all a developer had to know to create a Web service were the extra ASP labels required to tag or denote the code as a Web service as explained in Chapter 3.
At around the same time that Microsoft released its DOT NET SDK, it also released its UDDI SDK. The UDDI SDK provides client-side libraries for registering and looking up services whose metadata is stored in a UDDI registry. This SDK is the focus of Chapters 7– 9.
At the same time that technology companies are doing a good job of attempting to define and implement the infrastructure for Web services, there are standards organizations, such as RosettaNet and ebXML, that are defining higher-level concepts that will be necessary in order for truly rich business-to-business (B2B) communications to work using Web services. And the more time that these standards organizations spend defining how businesses will intercommunicate, the more they are reaching down the technology stack and defining the standards for implementing their specifications.
So what this all means is that the Web services work being done by Microsoft, IBM, and the W3C is beginning to collide with standards being proposed by RosettaNet and ebXML. This collision of standards will likely help the entire industry to mature the direction of Web services. However, in the short term, what this means is that the standards are still in a great deal of flux.
Microsoft is building its DOT NET story from the ground up, slowly releasing the low-level technologies that implement parts of the overall strategy.
The goal for the BizTalk 2.0 Framework Specification is to provide an interoperability framework that allows servers to conduct business securely over the Internet. It basically adds the extra layers above SOAP that are required to provide an interoperability framework.
Microsoft’s BizTalk 2.0 Framework is the business infrastructure that rides on top of its lower level Web services infrastructure based on SOAP. BizTalk 2.0 evolved from an earlier version of BizTalk (1.0). BizTalk 2.0 takes into account Web services and makes sense in the context of Web services and Microsoft’s DOT NET initiative.
The BizTalk 1.0 Framework was announced prior to Web services (and thus DOT NET). It was basically a message routing and transformation technology that would allow businesses to front-end the backend transactions with a unified presentation layer. Clients could submit business documents to a BizTalk 1.0 server using Microsoft Message Queue (MSMQ), IIS, or Simple Mail Transport Protocol (SMTP). The server would then translate the message — if necessary — into the format that the backend service provider could understand. Then the BizTalk 1.0 server would send the message along to the Inbox (a real SMTP Inbox, a Uniform Resource Locator [URL], a message queue, etc.) of the service provider. So basically, BizTalk 1.0 was all about routing messages and transforming them.
The BizTalk 2.0 Framework is at least two additional things — a specification (that can theoretically be implemented in any language on any OS) and an implementation. The implementation is Microsoft’s BizTalk 2000 Server. The BizTalk 2.0 Framework Specification is straightforward and sensible. It builds on the simple method invocation roots of SOAP and extends SOAP — by introducing new subelements of the SOAP Header element — to provide a robust, reliable transport mechanism for conducting business over the Internet.
SOAP does not define any way to associate documents together into a conversation or sequence of related documents. SOAP does not specify how to guarantee that messages are delivered or that they are not stale (i.e., not too old). A robust transport and enveloping technology must take into consideration these issues and more. This is where the BizTalk 2.0 Framework comes in. The framework defines properties for business documents that are transported using SOAP. A BizTalk document is a SOAP 1.1 message in which the body of the message contains the business documents, and the header contains BizTalk-specific header entries for enhanced message-handling semantics. The following concepts apply to BizTalk documents and are specific definitions from the BizTalk 2.0 Specification:
Lifetime: The time period during which a document is meaningful. A document must not be sent, accepted, processed, or acknowledged beyond its lifetime.
Identity: A universally unique token used to identify a document. This identity is subsequently used during various transactions handling the document.
Acceptance: The act of being accepted for delivery by a receiver. A received document is accepted if it is recognized as being intended for an endpoint served by the receiver, including documents that are copies or duplicates of previously received documents (based on the identity). Acceptance does not mean that all header entries and the body have been inspected and their contents verified for any specific purpose.
Idempotence: The ability of a document to be transmitted and accepted more than once with the same effect as being transmitted and accepted once.
Receipts: BizTalk Framework includes end-to-end protocols that prescribe certain receipts to be sent by the receiver to ensure delivery semantics in some cases. These receipts are first-class BizTalk documents with a prescribed syntax. There are two receipt kinds defined in this specification:
Delivery: A receipt to acknowledge that the receiver accepted a given document for delivery.
Commitment: A receipt to acknowledge that, in addition to being accepted, a given document has been inspected at the destination endpoint, all header entries marked
mustUnderstand="1"have been understood, the correctness of their contents (as well as the contents of the body) have been verified, and there is a commitment to process the document.
In addition to specifying the headers required to guarantee a level of reliability and traceability, the BizTalk 2.0 Framework also discusses security techniques and the overall responsibilities for a BizTalk 2.0-compliant server. The most fundamental elements of a BizTalk 2.0 server are:
Interoperability: BizTalk servers need to be able to intercommunicate with each other using a wellknown transport and enveloping technology (SOAP). They also need to use standard Internet messaging technologies to transport SOAP messages. These include: HTTP/S, SMTP, and File Transfer Protocol (FTP), to name a few. The business documents that are exchanged need to be understandable by all intercommunicating nodes. Therefore, XML Schema and Data Type Definitions (DTDs) are used to provide metadata describing the content and meaning of XML business documents exchanged between BizTalk servers.
Service Description: BizTalk servers must provide metadata that describes service access points and their public interfaces. Microsoft’s first vocabulary for doing this was called Service Control Language (SCL). This later evolved into SDL. The industry as a whole is now converging on using WSDL.
Service Discovery: In 1999, the year that Web services made their debut, there were a number of possible technologies that could have been used for service discovery. At that time, X.500 directories and the Lightweight Directory Access Protocol (LDAP) were strong candidates. They provide a very simple technology for storing strings in a directory and for accessing those strings. Often, these directory technologies were used to store public phone book entries, public keys for Internet security, and other strings that might be useful across large distances but that could be administered within a federation of directory servers. These technologies came out of the box with a well- known and rigid schema. However, they would allow you to extend their schemas for your needs. At about this time, IBM proposed ADS (Advertisement and Discovery of Service) and Microsoft proposed DISCO (Discovery of Web Services).
In its beta form, the BizTalk 2000 Server did not communicate using SOAP. Instead, clients could communicate with it using HTTP POSTs of non-SOAP messages or they could use Microsoft’s MSMQ. But the BizTalk 2000 Server does introduce some concepts that are missing from the BizTalk 2.0 Framework Specification. These seem to be essential for real-world B2B communications to be enabled over aWeb services infrastructure. One of these concepts is that of a business process. Currently, the BizTalk word for business processes is XLANG schedules.
An XLANG schedule is a set of steps — just like a workflow — that are invocations of objects, sends of messages, and receives of messages. All of the steps together form abusiness process. In its current implementation, BizTalk Server comes with a version of Visio that allows you to draw these business processes. The processes are then described using an XML vocabulary invented by Microsoft and called XLANG. An XLANG document describes a business process, and a running instance of one of these business processes is called an XLANG schedule.
Along the lines of the business process is the concept of orchestration. Basically, orchestration is the runtime component of an architecture that executes XLANG schedules. It is the part of the infrastructure that remembers where you are in a business process with a business partner. And it knows what steps of that process you have already completed. Orchestration enables execution of long-lived business processes.
Microsoft is proposing XLANG as the preferred XML vocabulary to use to describe public business processes. However, in its current form, XLANG does not do a very clean job of differentiating between the public steps of a business process and the private ones. It simply combines them all together, just like most workflow engines do today. HP has submitted to the W3C an XML vocabulary called Web Services Conversation Language (WSCL) for describing public business processes. IBM has also announced a similar XML vocabulary called Web Services Flow Language (WSFL). Regardless of which vendor’s proposals influence the standards for describing business processes, the concept of a conversation or orchestration of messages flowing between business partners over the Internet is one of the primary contributions that the BizTalk 2000 Server has brought to the nascent Web services industry.
IBM is one of the industry leaders in the move to define and standardize Web services. It has been in this role since just about the time that Microsoft announced SOAP and IBM decided to support the SOAP specification.
IBM’s involvement seemed to be driven by its push in the early 1998 timeframe to support the open source movement and the Linux OS. Around this time, IBM started to invest heavily in open source and published its AlphaWorks Web site (http://www.alphaworks.ibm.com). This site allowed anyone to download technology previews of XML parsers, XML transforms, security components, and eventually, Web services technologies. In addition to maintaining the AlphaWorks web site, IBM also became active in the Apache Project — contributing many of its XML technologies to that effort. IBM’s path to Web service support and contribution is similar to Microsoft’s — both these companies have published several white papers and released Web service SDK components. However, it is not reinventing itself around the concept as Microsoft seems to be doing. Instead, IBM appears to be more of a large research and development organization that has been advancing the state of the art of Web services.
IBM envisions its product offering being folded into the WebSphere line of products. IBM’s Web server and application server technologies, therefore, will evolve into a tightly integrated yet open Web services infrastructure. It appears that whatever form WebSphere takes in the future, it will, as much as possible, be based on open Web services standards.
As mentioned above, the AlphaWorks Web site (and its content) has done a great service to help move the developer community toward the concepts of Web services. IBM led the introduction of WSDL as the de facto standard XML vocabulary for describing public interfaces of Web services. IBM has also been one of the primary forces behind establishing the UDDI organization. It is one of the initial three UDDI operators — those responsible for providing a highly available infrastructure of UDDI registries. (Microsoft and HP are the other two initial UDDI operators.) IBM’s contribution to UDDI and other Web services standards is very notable. But it has been involved in other areas as well. One of these areas is that of interenterprise transactions (transactions across the Internet). IBM, Microsoft, and BEA recently announced the Business Process Execution Language for Web services (BPEL).
Another XML vocabulary being championed by IBM is Web Service Flow Language (WSFL). This language competes with Microsoft’s XLANG. WSFL is a language that can describe the steps that comprise a Web service. The language also can be used to describe composed services: These are Web services that have a public interface (the service they provide) that is implemented by calls to a number of different services (behind the scenes). This concept is sometimes referred to as composed services. Clients of a composed service know about only its public interface — even though it is implemented by making calls to other Web services. WSFL fits into the area of Web services known as orchestration, choreography, or conversations.
It appears that WSFL may be useful behind the firewall, as well as in front of it. In front of the firewall, WSFL can describe the public interfaces of Web services. Behind the firewall, however, WSFL may be useful for describing workflows. IBM has a very successful workflow product called MQ Series, as well as a message routing and transformation product called MQ Series Integrator. WSFL may well be the glue that allows these behind-the-firewall technologies to be reachable across the Internet as Web services. If this is the case, IBM’s WebSphere, combined with WSFL and MQ Series Integrator, is in direct competition with Microsoft’s BizTalk 2000 Server and XLANG.
Although WebSphere and MQ Series Integrator are shipping products, IBM’s Web services technologies are primarily still a work in progress. The best way to understand the current state of its Web services work is to log onto the AlphaWorks Web site and download the current version of the Web Services Toolkit (WSTK). In the current version, there are a number of components, including a UDDI registry, a UDDI browser, an Axis server (Web services dispatcher that runs above a web server), an embedded version of WebSphere, many tools, and many helpful white papers.
In its current incarnation, IBM’s WSTK makes it very simple to create, deploy, and invoke Web services. For a deployment platform, you use your favorite open source Java Web Server (i.e., Jakarta/Tomcat), or you can use WebSphere. Then, you install the Axis server into your Java Web Server. The Axis server intercepts calls to Web services and invokes them on your behalf. In a sense, the Axis server does the same thing that Microsoft’s IIS plug-in does with the latest DOT NET SDK. Basically, both of these components are the interceptors that are invoked by the web server when it does not know what to do with the request. These components are able to determine that the request is an invocation of a Web service, and they invoke the appropriate Web service.
The IBM WSTK makes it very simple to implement, deploy, and call Web services. The UDDI4J Java API that comes with the toolkit allows developers to create applications easily that can register and find Web services by using UDDI registries. Although many of the Web services technology downloads that IBM has released are works in progress, they provide a very rich suite of components that could be used by early adopters to develop solutions that build upon Web services. As IBM integrates these technologies into its core product lines, it is very well positioned to make a significant impact on the world of Web services.
Along with Microsoft and IBM, several other companies have made forays into Web services and registry technologies. Of course, not all of them have a strong footprint in the marketplace. We focus on some of the strong industry participants in the following discussion. These companies are likely to make a significant impact on the development and adoption of Web services technologies.
Systinet, originally Idoox, Inc., was founded in March 2000 in an effort to capitalize on the service-based computing paradigm. The company, still in its infancy, has been involved heavily on the Web services technology development due to its focus. Systinet’s WASP suite of products provides a platform for developing and managing Web service development and deployment in both Java and C++. It also includes an implementation of UDDI registry.
Systinet provides a public UDDI registry. This registry is not part of the UBR cloud, but has the same capabilities available at the sites in the UBR cloud. Systinet’s UDDI implementation is also available as a free download, which is intended for use as a private registry.
Systinet has been active in the Web services initiatives and participates in UDDI, Web Services Interoperability (WS-I), and the Organization for the Advancement of Structured Information Standards (OASIS). Through its highly visible participation and contribution, Systinet stands to gain developer mind share.
While the flagship products of the Oracle Corporation continue to be its database and Enterprise Resource Planning (ERP) software, it has also developed application server capabilities. The latest version, Oracle 9iAS includes several features useful for Web services development. Besides the development tools such as the Integrated Development Environment (IDE), Enterprise Java Bean (EJB) server, Oracle 9iAS also includes an implementation of the UDDI specification.
Although Oracle is not part of the UBR, its implementation can be used as a public or private registry. This implementation is, of course, integrated with Oracle’s database software. Oracle is also an active participant in several Web services related standards bodies, including UDDI.
The WebLogic application server is BEA System’s hallmark software. In its latest incarnation, WebLogic includes Web services development capabilities in its application and integration framework. Like the Oracle application server, the WebLogic server also packs several capabilities such as portal foundations, business process management, personalization engine, and Web services.
BEA is also a participant in the UDDI effort, as well as other Web services initiatives such as WS-I and BPEL. It, however, does not have an implementation of the specification. But, due to its market share and participation in Web services standards initiatives, BEA will be very influential in the direction and development of registry technologies.
One of the most important components of any distributed computing solution is a registry that can be used by components and services to advertise themselves and by clients to discover existing components and services they can access. All distributed object middleware solutions have some form of registry that serves this purpose. And, as the computer industry is beginning to realize, any viable Web service solution will need a similar component. The below sections discuss distributed computing registry technologies that serve this purpose.
CORBA specified a number of CORBA services that are pervasive throughout an ORB network. One of those services is the CORBA Naming Service. This service is actually a network-visible registry with a hierarchical data model that looks just like a file system. What you would think of as a directory in a file system is called a Naming Context in the CORBA Naming Service. Each Naming Context can contain other Naming Contexts, as well as named references to running CORBA objects.
CORBA objects make themselves “visible” to CORBA clients by placing named references to themselves within the CORBA Naming Service (or the CORBA Trader Service, which is discussed next). Clients then can obtain the remote references to running CORBA objects by asking the CORBA Naming Service for the objects by name. The CORBA Naming Service can store only references to CORBA objects. It cannot be used to store references to other sorts of distributed objects, such as COM+ objects or RMI objects.
The CORBA Trader Service was proposed by the OMG long after the release of the initial CORBA 1.0 specification. This service, unlike the Naming Service, allows CORBA objects to advertise themselves with a set of associated properties, rather than by a hierarchical “path” name. When clients search for CORBA objects using the Trader Service, clients must specify the IDL interface name they are looking for (such as BankAccount) and may optionally specify a set of properties as well, such as BankLocation=SantaCruz AND StreetName=Pacific. The Trader Service, like the Naming Service, can be used to advertise and look up only CORBA objects. The CORBA Trader Service has clearly influenced the architecture of many other registry technologies, including the JINI Lookup Service, Universal Description, Discovery, and Integration (UDDI), and ebXML’s Registry.
Compared to UDDI, CORBA Trader Service provides a rather limited functionality. UDDI is designed as a generic service registry. It can be used to register electronic as well as physical services (where the binding information could be phone, fax, or email). It supports registration of services complying with several standards including SOAP, ebXML, CORBA, RMI, DCOM, FTP, and HTTP. A CORBA Trader Service in contrast is meant to be used to register and find a service compliant with the CORBA architecture.
Microsoft’s DCOM and COM+ have been quite a success — as is evident by the number of solutions based on these technologies and the fact that they are now embedded in all Microsoft operating systems (OSs). But interestingly, Microsoft has never provided an easy-to-use network-accessible registry for advertising and finding DCOM/COM+ objects. In fact, until the release of Active Directory, the only registry that was provided for storing location information for DCOM objects was the local Windows Registry. This meant that if you had a number of client machines that wanted to have access to DCOM objects running on a server, each and every one of their Windows Registries would have to be configured with the location and interface information for the DCOM objects.
With the release of Active Directory, it can be used as a registry to store references to COM+ objects. Although this is a very simple technology with no more power than the CORBA Naming Service, it does provide for a manageable solution for advertising and discovering COM+ objects.
The RMI Naming Service is simply an RMI-specific implementation of a registry that works just like the CORBA Naming Service. The only real difference is that you can store only RMI objects in the RMI Naming Service.
The JINI Lookup Service is like an RMI-specific implementation of the CORBA Trader Service. It is very similar to the CORBA Trader Service in that RMI objects are advertised into the JINI Lookup Service — and their advertisements have associated with them the Java interface of the object providing the service, as well as optional properties further defining the service being offered.
A major difference between the JINI Lookup Service and the CORBA Trader Service is that the JINI service uses IP multicasts and a special Join protocol and Discovery protocol for advertisement and lookup of services. Also, the client-side proxies for accessing services can be stored along with service advertisements published to the JINI Lookup Service. Of course, the same thing could not be done with the CORBA Trader Service because CORBA does not allow for streaming of objects over the network.
The Electronic Business eXtended Markup Language (ebXML) initiative focuses on developing standards for the global electronic markets wherein interactions happen through open, secure, and public XML-based infrastructures. The primary objective is to lower the barrier of entry to electronic business for small- and medium-sized enterprises. OASIS and the United Nations Centre Initiative for Trade Facilitation and Electronic Business (UN/CEFACT) jointly sponsor ebXML. The initiative includes several components:
ebXML Collaboration Protocol Profile and Agreement (CPPA)
ebXML Implementation, Interoperability, and Conformance
ebXML Messaging Services
ebXML Registry
The ebXML registry component is often compared with the UDDI registry. With similar sounding goals, there is a lot of debate regarding the capabilities provided by ebXML registry and UDDI and whether they are competing or complimentary standards. Since the two standards are still under development and not fully mature, it is difficult to predict which standard will prevail.
Note
A likely outcome is that the two standards will ultimately find a specific niche and not only coexist but through XML will also interoperate.
The following discussion is focused on the relative strengths and weaknesses of both these standards. Note that as newer versions of these specifications appear, some of the weaknesses may be adequately addressed. Note that this comparison is based on the UDDI Version 2.0 specification.
The vision behind the ebXML initiative goes far beyond what is envisioned by UDDI. UDDI solves the problem of providing the ability to store and retrieve pointers to services by specifying attributes — in the form of name/value pairs — of the services stored.
Like UDDI, it provides mechanisms for storing pointers to ebXML-compliant services. And it also allows association of properties with those pointers and retrieval of pointers to services by specifying properties of those services. But ebXML’s registry goes further. Its registry pays equal — if not more — attention to the many forms of metadata that describe Web services. In essence, ebXML is geared to store any kind of content, not just pointers. In fact, to store a pointer to a Web service within the ebXML registry, you first must have stored the following:
Metadata descriptions of any of the messages that can be exchanged with that Web service.
A metadata description of the business process that is implemented by that Web service.
The service provider’s CPP, which describes the service provider’s role in offering its service, as well as the technical details for how to access that service. When a CPP is stored within the ebXML registry, it is possible to associate a number of properties with it in order to classify it. This provides a mechanism whereby clients looking for a specific class of CPPs can query for and find the CPPs that meet their requirements.
When clients want to access Web services whose pointers are stored within the ebXML Registry, they begin by searching for those Web services whose CPPs promise to deliver the service they desire. Then clients use the CPP information to establish a connection with the Web service provider. Dynamically, the client and the service provider form a CPA which describes all the steps — and technical endpoints — that comprise the complete business transaction they will carry out.
The ebXML registry has a much richer set of lifecycle management APIs than those provided by UDDI. ebXML’s Registry provides an extensible information model through the concept of slots. Slots are extra pockets of data that can be inserted into registry entries in order to store more information. ebXML Registry clients can use the Add Slot and Remove Slot APIs to perform schema modifications and add/remove data stored in slots.
Another feature that is unique to the ebXML Registry is rich support for categories and subcategories and sub-subcategories, etc. Categories are extremely useful properties to associate with Web services — they allow clients to “drill into” and “drill up from” areas of interest so that they can easily retrieve the service(s) they are interested in.
The querying and result-filtering features provided by the ebXML Registry are far richer than those provided by UDDI. Of course, this is necessary because there are so many different attributes that can be associated with ebXML services, such as categories, slots, business documents, business processes, and CPPs. Queries and result filters can be specified by using the ebXML data structures described in the ebXML Registry Information Model document. The ebXML Registry Services Specification also states that compliant registries can offer an interface whereby clients can query the registry using Structured Query Language (SQL) syntax.
Just like with the UDDI registry, the ebXML Registry offers its services through XML messages that are exchanged between clients and the registry. In the case of ebXML, those messages are compliant with the ebXML Message Service Specification. It is expected that clients will use object-oriented APIs to access the ebXML registry so that they are not exposed to the low-level XML messages and ebXML message envelopes that will be exchanged between clients and the registry. Currently, there is a Java Specification Request — JSR 93 — which specifies a Java API that will allow Java programs to communicate with both UDDI and ebXML registries in a consistent manner.
In terms of adoption by the software industry, both standards are in their infancy. UDDI enjoys strong participation from Microsoft, which given its role in the overall Web service space can help in wider adoption. For example, the .NET server plans to provide a built-in UDDI registry.
One area generating much interest is that of registry topologies. In an enterprise environment, where high availability and complex business relationships is norm, different ways to connect multiple registries together that exchange information are essential. Some of these topologies are discussed in Chapter 10. Version 3 of both these specifications allows for designing multiple topologies.
In the next chapter, we survey the UDDI Version 3 Specification and illustrate how the specification has evolved to provider greater sophistication in the UDDI technology.