After you've made the decision to develop applications using Web services, how do you go about selecting products? There is no one product that is best for all situations. In fact, you'll almost certainly need multiple products. As a rule, you should always select your products based on the requirements of each application. This chapter provides basic guidelines that you can follow to help you select the right products for your application.
Appendix A provides a list of many, although not all, of the available Web services platforms and UDDI registries. I have not included all the open source and academic implementations, and I'm sure that I've missed some commercial implementations, too. As you can see from the list, you have quite a few products to choose from.
Before you try to select a product, you first need to understand the requirements of your project. Are you developing a new application, or extending an existing application? Is the application for internal or external use (or both)? Are you building a corporate application, or will you sell the application to others? Will you sell it as packaged software, or as a service? Which programming languages will you use? Which operating systems will the service run on? Will it run on a server, or do you prefer to embed it in an application or device? If it will be server-based, what Web server or application server do you prefer to use? What about the client environment? Keep in mind that you may implement your clients using a different Web service platform from the one you use to implement your servers.
In particular, you need to characterize the environment that will host your Web service. Technically, a Web service is simply an interface to an application. The application runs in a specific environment, which I refer to as its operating platform. You must find a Web services platform that fits with this operating platform.
Your operating platform is an amalgam of infrastructure technologies. Even if you have the luxury of writing a brand new application from scratch, you will probably need to link the application with many parts of your existing operating platform. Key components of your operating platform are as follows:
Operating system
Programming language
Web server
Application server
Database server
Directory server
Security infrastructure
Management infrastructure
Workflow systems
Business rule engines
Transaction management infrastructure
You also need to consider a number of nontechnical factors. What is your budget? Do you have existing license agreements with certain vendors? Do you prefer integrated solutions or best of breed? How does your company feel about working with startups? How does your company feel about open source? These factors can definitely affect your product selection.
Appendix B provides a questionnaire that can help you characterize the key attributes of your project. These attributes will help you understand your requirements, which in turn will help you determine which products best fit your project.
Start your selection process by identifying your available options. Invariably, you want to make your first cut based on language and operating system. You also should consider licensing and support issues.
A Web services platform supports a limited set of languages and operating systems. For example, the Microsoft .NET Framework runs on Windows 98, Windows ME, Windows 2000, Windows XP, Windows XP Embedded, Windows CE, and Windows Server 2003. .NET is not available for Linux or UNIX systems, nor does it run on Windows 3.1 or Windows 95. It supports services developed using any of the Visual Studio .NET languages, but it cannot host services developed using Java or previous versions of the Visual Studio languages, such as Visual Basic 6.0. You can deploy .NET services in the IIS Web server and the ASP.NET application server, but you cannot deploy them in a Java application server, such as WebLogic or WebSphere, even if it is running on a Windows operating system.
The .NET platform is compatible with, but not the same as, Microsoft's previous operating system infrastructure, which was based on the Component Object Model (COM). If you would like to create a Web API for an application running on Windows 95 or an application written using Visual Basic 6.0 or Visual C++ 6.0, then you must use a Web service platform that supports COM. For example, you could use Microsoft SOAP Toolkit or Simon Fell's PocketSOAP.
If you want to create a Web API for an application running on a non-Windows platform, then you need a platform that supports your application programming language on that operating system. For example, if your application is written in COBOL and runs in CICS on OS/390, you must find a Web services platform that supports CICS/COBOL on OS/390. In this situation you might consider using IBM WebSphere Studio Enterprise Edition or Software AG EntireX Communicator, which can generate Web service adapters for CICS COBOL applications.
If your application is written in C++ and runs on UNIX, you must find a Web services platform that supports C++ on UNIX. For example, Systinet WASP Server for C++, Rogue Wave LEIF, and the open source gSOAP project support C++ on UNIX.
If your application is written in Java, you have a much wider array of choices. There are more than two dozen Web services platforms for Java. Although all of them support the Java programming language, each has its platform support limits. You must find a Web services platform that supports Java on your preferred operating platform.
Most J2EE application server vendors—including BEA, Borland, IBM, IONA, JBoss, Macromedia, Novell, Oracle, SAP, Sun, and Sybase—provide integrated support for Web services. These Web services platforms are nicely integrated with the application server, but most also have a hard dependency. For example, BEA WebLogic Workshop is designed to work with BEA WebLogic Server. BEA WebLogic Workshop supports only Web services developed with Java, and these Web services can be deployed only within BEA WebLogic Server.
Although your J2EE platform comes with Web services support, you may prefer to install a third-party Web services platform on your application server. These platforms—from organizations such as Apache, Cape Clear, Indiana University, IONA, Sun, Systinet, The Mind Electric, and Wingfoot—can run in a variety of J2EE application servers. If you have a requirement to support multiple application servers, one of these systems might be best for you. You can also use these platforms with J2EE application servers that don't provide a built-in Web services container, such as Orion Application Server.
You may find that the independent commercial platforms from Cape Clear, IONA, Novell, Systinet, and The Mind Electric offer better tools as well as better performance, scalability, management, and security facilities compared with most of the bundled platforms. Given that these platforms tend to be moderately priced, they are often well worth the added investment.
If you don't already have a J2EE server, you don't need to get one just to run Web services. The third-party platforms run as a servlet, so you can also deploy them in a lightweight Web server or application server containing only a servlet engine, such as Apache Tomcat, Caucho Resin, Jetty, and Zeus Web Server.
Some of these platforms permit you to embed a Web services platform in your application so that you don't need any type of Web server or application server. If you are building an application for wide distribution that requires simple administration, you might find this feature very appealing.
You'll notice that most Web services platforms for Java require a fairly modern version of Java. Most platforms require at least Java 1.3.1. Some platforms require Java 1.4. If your applications have been developed using an older version of Java, you must use a Web services platform that supports the version you are using.
If you intend to deploy a Web service client or service in a small device, such as a PDA or a mobile handset, then you may need to find a Web services platform that supports the Java 2 Micro Edition (J2ME) platform. In this situation you also want to look for implementations that have a very small footprint.
If you'd like to deploy a Web service client or server on an even smaller device, or if you don't have a JVM available for your embedded application, you'll need a SOAP implementation that supports that target platform. For example, EXOR International's eSOAP implementation is designed to run in very constrained environments in real-time operating systems (RTOSs), such as eCos and QNX. eSOAP supports Web services clients and servers written in C++, and clients written in Java.
You can build Web services using almost any programming language on any operating system. See Appendix A for a lengthy list of products organized by supported languages. You can use this list to determine which products match your language and platform requirements. You should consider performing evaluation tests on all products that make this first cut.
As part of your initial selection process, you also should consider licensing and support issues. Licensing issues can be particularly important if you are building a commercial product. Also, your company might have policies regarding open source licensing. The product list in Appendix A includes licensing information.
For the most part, you'll find that Web services infrastructure is not very expensive. Many Web services platforms are available as open source or free software. Some platforms are bundled with other products, such as an operating system, a language platform, an application server, or an application development tool. Other platforms are sold as separate commercial software products. The high-end commercial Web services platforms generally sell for less than $5,000 per CPU on the server. In contrast to other middleware technologies, most vendors don't charge for client runtime systems.
If you intend to create a product based on Web services, you could create your own Web services platform, or you could build a derivative product based on an existing platform. I don't recommend that you build your own platform unless you have extensive expertise in distributed computing technologies. Building a Web services platform requires a significant investment in time and resources. Consider for a moment the amount of effort that has been invested in the Apache Axis project. Apache Axis is an open source project sponsored by the Apache Software Foundation. This project started in February 2001. More than 30 software engineers from companies such as Borland, CA, IBM, Macromedia, Sonic Software, and Systinet have contributed to this project, and many of these people have worked full-time on Axis. Quite a few of them had previous experience building other Web services platforms. Even with this large and experienced team, it took 19 months to complete the v1.0 release.
In general, I recommend that you build on top of an existing platform. Keep in mind, though, that if you build a derivative product, you must obtain a license to redistribute the platform software.
By definition, you can redistribute any software that is licensed using an open source license. Apache Axis, Apache SOAP, PocketSOAP, White Mesa, gSOAP, XSOAP, kSOAP, and most of the scripting implementations are licensed using an open source license. You should review the terms of each open source license. Some open source licenses, such as the GNU General Public License (GPL), impose strict rules on how you can license your derivative products. Other open source licenses, such as Apache Source License, Artistic License, BSD License, CNRI Python License, and MIT License, don't impose the same licensing scheme on derivative products.
Many, but not all, free software products permit you to redistribute the software. You should always verify the terms of the free software license. In some cases you may need to get a separate OEM license to redistribute the software.
If you use open source or free software, you must be prepared to support the software yourself. Open source projects rarely provide formal support facilities. Users can ask questions on an e-mail discussion list, but no one is paid to answer those questions. Your developers will need to rely on the kindness and dedication of the user community to get answers. If you prefer to have a more structured and dependable support facility, you should consider licensing a Web service platform from a commercial vendor.
After you have made your initial cut, you now want to start evaluating products based on your project requirements. I like to start with performance and scalability. Make sure that you understand what your requirements are for these characteristics. How many concurrent clients will you need to support? What is the maximum acceptable response time? Make sure that you account for both average and peak requirements.
You'll find that there can be an enormous difference in performance among the various platforms. For example, among the current crop of products, the independent commercial Java platforms from Cape Clear, IONA, Novell, Systinet, and The Mind Electric perform about an order of magnitude faster than those from Apache Axis and Sun JWSDP. The discrepancy becomes more pronounced as you scale up the number of concurrent users. You'll get your best possible performance from the portable C++ implementations.
The deployment configuration of an individual product can also affect performance and scalability. For example, Systinet WASP Server for Java achieves its best raw performance (measured as messages per second with one user) when configured as a stand-alone server, but it delivers its best scalability (messages per second with many users) when installed in a cluster-enabled application server.
I strongly recommend that you perform internal benchmarks. Don't just accept the vendors' published benchmarks. Run your own benchmarks, simulating the requirements of your production applications. SOAP processing performance varies dramatically based on the length and complexity of the messages you exchange. Your benchmarks should test the various products with a variety of messages, in a variety of configurations, with a variety of user load levels. Also, ask your vendors for customer testimonials. Find out from them how well the performance claims match up to real experience.
Web services support cross-platform integration. Chances are extremely high that you will not have a homogenous Web services environment. You want to make sure that your Web services platforms interoperate easily with other platforms. Therefore you want to look for platforms that fully support the Web services standards. The most critical standards to look for are SOAP 1.1, WSDL 1.1, and XML Schema 1.0.[1] A Web services platform should support all features of these specifications. The XML Schema standard can be especially tricky. Early SOAP implementations predated the formal W3C XML Schema Recommendation that was published in May 2001, and these implementations may use older, prestandard versions of XML Schema rather than the final recommendation. For example, Apache SOAP uses the 1999 XML Schema draft specification. Apache SOAP also does not support WSDL 1.1. If you intend to use UDDI, you should make sure that your platform supports UDDI V2 (or later).
Even if a Web services platform fully supports the specifications, you still might have trouble with interoperability. The SOAP 1.1 and WSDL 1.1 specifications contain a number of ambiguities that cause integration headaches. WS-I[2] has defined a Basic Profile that provides guidance to ensure interoperable Web services based on SOAP 1.1, WSDL 1.1, and UDDI 2.0. The WS-I Basic Profile prohibits the use of the SOAP Encoding style. You must use Document/Literal or RPC/Literal rather than RPC/Encoded SOAP messaging. As of this writing, a number of platforms still use RPC/Encoded by default, and some of them provide limited or no support for Document/Literal and RPC/Literal. Make sure that the platform supports the WS-I profile.
You're very likely to encounter integration headaches when using complex data structures. Mapping complex types is by far the most challenging part of cross-language interoperability. There are no formal standards that specify how to map a complex programming language structure, such as a linked list or a hash table, to the XML Schema type system, so each vendor must design its own mapping system. Unfortunately WS-I has not yet attempted to tackle this interoperability issue. The complex programming language structures are referred to as collections. A corresponding XML Schema type structure is referred to as a container. The interoperability issue comes into play when one Web services platform cannot properly interpret the containers generated by another Web services platform. In particular, Apache Axis uses containers that are incompatible with those of Microsoft .NET. Developers are forced to write custom serialization routines, and that greatly reduces their productivity. Look for platforms that provide container types that enable compatibility with both Apache Axis and Microsoft .NET.
Most Web services platforms provide a basic communications environment that supports simple Web services. Going forward you'll almost certainly want to start using a few advanced features, such as security, transactions, asynchronous invocations, alternative transport facilities, message correlation, reliable delivery, message transformation, and version control. As mentioned in Chapter 3, SOAP provides a built-in extension mechanism that allows you to add extended middleware functionality to the message processing system. But the SOAP specification doesn't define how a Web services platform should implement these extensions. When you're evaluating a platform, determine which facilities it offers to let you extend the environment. Platforms generally support extensibility using proxies and message processing interceptors.
As mentioned in Chapter 8, you can use a Web services management extension to add extended middleware functionality to a Web services platform. These systems work with most core platforms, and they tend to be easy to configure. They allow you to add security, reliability, load balancing, transactions, and version control functionality.
In their simplest configuration, these extensions operate as a proxy that intercepts messages in transit between the client and the service. As mentioned in Chapter 8, this configuration imposes significant overhead. These systems operate outside the core platform's SOAP message processing system, and this means that your SOAP messages must be processed twice: once by the management extension and again by the core platform. SOAP message processing is the most time-consuming part of Web services communications, so double processing will impact your performance and scalability.
Many of these systems also allow you to configure the framework to work within the application server that hosts the SOAP server. For example, you can configure the interceptor to work as a servlet filter. This configuration is more optimized than the proxy interceptor because it removes an additional network hop, but it still imposes double message processing. A more efficient way to add extended middleware functionality is to use a extension that can plug right in to the core system's message processing system. To use this type of configuration, the core SOAP system must support message processing interceptors.
A message processing interceptor interrupts the SOAP runtime's standard message processing system and allows you to add custom functionality to the process. Many platforms give you a mechanism to intercept a message at three or more stages as it passes through the SOAP message processor. At each interception point, you can take the message and perform a variety of functions in a predetermined chained sequence; then you hand it back to the SOAP processor to continue processing. Among other things, an interceptor can authenticate messages, validate and transform them, compress and decompress them, reject messages that exceed a certain size, and gather statistics about messages. An interceptor can also perform functions such as message header processing and custom serialization of message contents. This interception methodology is defined as part of the JAX-RPC API specification, so many Java platforms use it.
Some platforms extend the basic interceptor model with a slightly friendlier interception API that supports specific types of interceptors. A typed API passes the message to a specific message handler at a specific point in the message processing sequence. A typed API makes it much easier for the developer or administrator to define and manage the chained sequence of interception handlers. A typed API also makes it easier for the developer to obtain the specific bits and pieces of the message that the handler needs to process. For example, if you are developing a header processor, a typed header processor API allows the developer to quickly and easily pull the required header element from the SOAP message. Without a typed API, the developer would have to write code to parse the entire message to find the specific header to process.
The SOAP specification requires only one transport protocol, and that is HTTP. For that reason some Web services platforms support only HTTP. Yet the SOAP specification allows you to use any transport protocol to exchange messages. Quite a few SOAP platforms now support SMTP, JMS, and other transports. Although JMS limits your interoperability, it gives you increased reliability. Keep this point in mind as you evaluate products, especially if you anticipate that you may need to use other transports. Evaluate how much effort is involved in switching from one transport to another.
As mentioned in Chapter 5, the industry is making great progress in defining security standards for Web services. Although Web services security hasn't yet been fully standardized, that doesn't mean you can't build secure, interoperable Web services. Most Web services platforms provide basic security features. If you need a secure environment, you can use almost any platform to do it. The question is whether you have enough control to suit your requirements.
There are five basic security functions: confidentiality, integrity, nonrepudiation, authentication, and authorization. You can implement these functions at three levels within the infrastructure: transport level, application level, and XML level. As you move up the stack, you get much finer control over security.
Almost every Web services platform provides support for security at the transport level. First, you can encrypt your messages using HTTPS and SSL. Encryption ensures message confidentiality and integrity.
You can also use the transport to perform authentication. HTTP provides two popular authentication mechanisms: HTTP Basic and HTTP Digest. HTTP Basic offers minimal security because it passes user and password information in clear text. You should always use SSL when using HTTP Basic. HTTP Digest doesn't require SSL because it encrypts the authentication information. If you are using SSL, you can also use public key authentication, which is the strongest transport-level authentication mechanism.
For the most part, transport-level security works. It is very easy to use. It operates completely transparently to the client, the service, the developer, and the administrator. The only problem you might encounter is in terms of the authentication mechanisms supported. Microsoft uses HTTP Digest by default. A number of Java platforms support only HTTP Basic. For easiest interoperability, choose a platform that supports multiple authentication mechanisms.
Although transport-level security is easy, it doesn't give you very much control. In particular, transport-level security really doesn't support authorization. To implement different access control policies for different groups of users accessing different services, you must also perform security at the application level.
Application-level security augments transport-level security. In addition to the transport-based authentication mechanisms, application-level security supports a number of very strong authentication mechanisms, including Kerberos, X.509 certificates, biometric authorization, and XML tokens.
Regardless of the mechanism used for authentication, the application-level security system associates each authenticated user with a principal security identifier. This principal enables authorization. A principal represents a user, and it provides a reference key that can be used to verify the rights and privileges that have been granted to the user. Each time a user makes a request, the application-level security system can check to see whether the user is authorized to perform the action. You can delegate actions using principals—in effect passing the principal information as you route a request through a series of steps and services. Delegation becomes critical when you're using proxies and intermediaries or linking multiple services into a workflow. Application-level security also permits you to define trust domains, which simplify security administration.
Many of the commercial Web services platforms now provide application-level security features. Compare and contrast the capabilities of each of your prospective platforms. How well does the Web services security management system fit in with your security infrastructure? Make sure that the Web services platform can work with your corporate security information store, such as LDAP, Active Directory, or Netegrity SiteMinder.
XML-level security allows you to implement security at the message level. For example, you can use XML-level security to encrypt and digitally sign the entire message or a portion of the message and to pass security authentication and authorization assertions. The evolving Web services security standards, including WS-Security and SAML, operate at this level. These standards are critical for comprehensive security in heterogeneous communications. Look for vendors that support WS-Security and SAML.
If your preferred platform doesn't provide the built-in security facilities you need, you can use a third-party Web services management extension, an XML firewall, or a hardware XML security appliance to add these capabilities. These solutions tend to be a bit more expensive than most Web services infrastructure products.
Each Web services platform offers its own assortment of development, deployment, administration, and management tools. As I've said before, the tools are tied to a specific platform, so your platform selection determines which tools you can use.
Most platforms include a basic set of class libraries and command line tools. The class libraries contain the APIs and the code that a developer uses to build Web services. The command line tools consist of code generators, WSDL compilers, build utilities, deployment tools, and message monitoring tools. The Java platforms usually provide a set of Apache Ant tasks. Ant is the most popular Java build utility.
The capabilities and the amount of automation supplied by these tools vary from product to product. Pay particular attention to how well the tools handle complex type mapping. Some tools can automatically generate all your serialization routines, regardless of the complexity of the data structures. Others can generate serialization routines only for simple structures or for structures that conform to certain conventions (such as JavaBeans). Also evaluate how well the tools support Document/Literal bindings versus RPC/Encoded bindings. Some tools generate serialization routines only for RPC/Encoded bindings.
Although an advanced developer often prefers to work with command line tools, some of your less experienced developers might find them a bit cryptic. These developers would probably prefer to use a visual programming tool. Some Web services platforms include visual development tools. Other vendors sell separate visual development tools. Still other vendors provide free plug-in tools that work with one or more popular integrated development environments. The IDE plug-ins add integrated support for Web services to the developer's native development environment. I prefer this last option, but that's my opinion. What counts is how your developers feel about it.
If you intend to use UDDI, you should look for platforms that include UDDI browsers, wizards, and utilities. These tools make it easy for developers to query a UDDI registry looking for service information or to publish service information to a registry. In particular, you should look for tools that include a UDDI browser that can view both public and private UDDI registries. You should also look for a UDDI registration utility that can generate UDDI registrations from a service's WSDL description. The OASIS UDDI-spec Technical Committee has published a set of WSDL-to-UDDI best practice documents that define a standard methodology to map WSDL descriptions to UDDI. Look for tools that automatically register services according to this methodology.
All Web services platforms provide some basic deployment and administration tools that you use to deploy and configure your Web services. Be aware that some platforms package the administration tools with the development tools, and they don't really distinguish between the developer role and the administrator role.
As your efforts with Web services scale up, you'll need a reasonable way to manage and coordinate your Web services. Take a look at the administrative capabilities of each platform. It's nice if you can administer all your Web services across multiple platform servers from a single console. You should be able to start and stop platform servers. You should be able to deploy, undeploy, and redeploy services without restarting the server. You should be able to manage and administer service deployment options, such as interceptors, header processors, serialization routines, transformation routines, session management, and security access options. You should be able to see the status of all running services, and you should be able to turn on tracing and logging facilities for individual services. You'll find that commercial products tend to have much better administration facilities than the open source and free software products.
If you intend to deploy a private UDDI registry, you should go through the same evaluation process as you do for your Web services platform. You should always select a product based on your requirements. In this situation, though, there are fewer options to evaluate. As of this writing, there are only 10 product-quality UDDI registries on the market.[3]
Acumen, IBM, Select, and Systinet sell their UDDI registries as separate commercial products. Microsoft includes its registry with Windows Server 2003. Cape Clear, IONA, Oracle, and The Mind Electric bundle their registries with their Web services platforms, and they are not available as separate products. BEA and Pramati include Acumen AUDDI with their respective platforms. Sun provides a UDDI registry as part of JWSDP, although Sun's license prohibits you from using it for commercial purposes. Two open source registries are available, including Novell Nsure UDDI server (product quality) and jUDDI (not product quality).
As with a Web services platform, I suggest you start your selection process based on platform considerations. A UDDI registry server is an infrastructure-level Web service. It is an application that runs within a specific Web services platform on a specific operating system. It manages and provides access to UDDI registry information, which it stores in some type of data storage facility. The registry's underlying platform influences its performance and scalability. For optimum performance, you want to select a registry based on a fast Web services platform and an industrial-grade database.
Most UDDI registries are implemented in Java, and they can run on Windows, Linux, and UNIX. Novell Nsure also runs on NetWare. Two products are limited to Windows: Microsoft's Enterprise UDDI Services is implemented using .NET and runs only on Windows Server 2003, and Select UDDIServer is implemented using Visual Basic and C++ and runs on all Windows platforms.
Acumen, Novell, Select, and Systinet built their products as stand-alone applications. For the most part, you don't really see the Web services platform if you don't want to. Systinet gives you the option of deploying WASP UDDI in a wide choice of application servers if you prefer. IBM sells its registry separately from the WebSphere platform, but you must deploy it in WebSphere. Obviously, the embedded registries from Cape Clear, IONA, Oracle, and The Mind Electric are designed to run in their associated Web services platforms.
A UDDI registry uses some type of data store to manage and maintain the registry data. Because of the relational nature of the UDDI registry information, most implementations use a relational database management system (RDBMS). IBM requires that you use DB2. Oracle requires that you use Oracle 9i. Microsoft lets you use the Microsoft Data Engine or SQL Server. Cape Clear, jUDDI, and Systinet let you use any JDBC-compatible RDBMS. Select uses an object repository. Sun JWSDP and The Mind Electric GLUE use an XML database. Novell Nsure uses an LDAP directory. IONA can use either Cloudscape or LDAP.
Some folks argue that it makes sense to consolidate UDDI with LDAP because both are directories of resources. But this idea makes about as much sense as storing your HR data in LDAP because they are both directories of employees.
A UDDI registry is much more than a directory. It is a complex, multidimensional index of information about businesses, services, and service types. It contains a tremendous amount of relational information.
LDAP is a hierarchical directory and thus is not especially suited to this relational information. LDAP doesn't provide some of the basic capabilities that you need to manage relational data, such as multistep transactions, referential integrity, and query joins. You can make LDAP host this information, but I don't see the point. It's not as if you are really integrating the information. You still need to use two different programming APIs and two different browsing utilities to see UDDI data versus LDAP data. I see no advantage to consolidating the information.
Some argue that LDAP provides better retrieval performance than a relational database, but this argument doesn't hold water in this situation. Many UDDI queries involve complex joins, and LDAP doesn't support joins. The registry application must implement this functionality, and its performance can't compare to that of a relational database.
I also caution you against overburdening your production LDAP directory with this much relational work. I do think that it's a good idea to use LDAP (or Active Directory) to manage the security aspects of your UDDI registry and your Web services. For more on this idea, see the section on security later in this chapter.
All the UDDI registries that I've mentioned support UDDI V2 or later. I suggest that you not even consider a UDDI V1 registry. The UDDI V2 specifications define two programming APIs (inquiry and publication), an operators specification, and a replication specification. All UDDI registry servers should fully support the UDDI V2 inquiry and publication APIs.
The operators specification defines the behavior and operational parameters required of node operators in the public UDDI Business Registry (UBR). It doesn't apply to private registries. The replication specification describes the data replication process and programmatic interface used to replicate data across nodes in the UBR. You could use the replication specification to implement a replicated multinode private registry, but there are much more efficient ways to manage a replicated registry. (My first choice would be to use the database replication services supplied by a commercial database system.) You cannot use the replication specification to replicate data from the UBR to a private registry. UDDI V2 does not support this capability. To my knowledge, no private UDDI implementations support replication.
UDDI V3 adds a number of valuable features. In particular, it adds a subscription API, which allows a user (or registry) to subscribe to changes made in a UDDI registry. You can use the subscription API to keep two nodes synchronized. You can also use it to notify service users of any change to a service.
UDDI V3 also allows you to publish information across multiple registries. For example, a binding template in one registry can reference a tModel in another registry. You also can move a registry entry from one registry to another. For example, you can promote a business service from a test registry to a production registry.
Perhaps most important of all, UDDI V3 adds support for security policies. The security architecture permits you to define and enforce policies for authentication, access control, data integrity, publication limits, and more.
As of this writing, only Systinet WASP UDDI supports the UDDI V3 subscription API. Select UDDIServer supports the UDDI V3 inquiry and publish APIs. None of the implementations supports the UDDI V3 cross-registry publishing and security APIs. UDDI V3-compliant products should appear in 2003.
Applications communicate with a UDDI registry using the UDDI inquiry and publication SOAP APIs. You can construct those SOAP messages using any SOAP implementation, but the UDDI SOAP APIs are fairly complex. Therefore most UDDI registries include a UDDI client programming interface that automatically generates the appropriate UDDI SOAP APIs on behalf of the client. Microsoft and Select provide APIs for COM and .NET clients. The other vendors provide APIs for Java. You'll also find that many Web services platforms include a UDDI client API. Some vendors provide JAXR-compliant APIs. Most UDDI client APIs are free or open source. Because you can use any UDDI V1 or V2 client API to talk to any UDDI V2 registry, the client API isn't a particularly important selection factor. Have your developers experiment with the various APIs to see which one they like best.
The only reason you might want to consider the client API is if the vendor provides proprietary extensions to the basic API to improve usability and performance. In all cases, these extensions are optional, so you are never forced to use them. Keep in mind, though, that the extensions work only with the associated UDDI registry. You must make a judgment call as to whether you're willing to use proprietary extensions in order to take advantage of these features.
Most UDDI registries provide a Web interface to support interactive access to the registry. You can use this interface to query or publish information to the registry. The UDDI browser should let you browse taxonomies. As mentioned earlier, many visual Web services development tools provide UDDI wizards to help developers browse the registry and publish services. These wizards don't usually come with the UDDI registry, though.
All registries should provide a set of administrative utilities. The UDDI specification does not define standards for UDDI administration, so each implementation will be unique. These administration utilities should let you manage the UDDI application, its database, and the Web services hosting environment.
Custom taxonomies are a critical part of a private UDDI. You'll want to develop a number of taxonomies to help you properly categorize your services and service types. Without taxonomies, your UDDI registry is really nothing more than a directory.
A private UDDI registry should give you administration tools to help you manage and maintain your taxonomies. A UDDI registry should let you define custom taxonomies and specify valid values for them. You should be able to maintain the taxonomies either within the registry or in an external taxonomy service. You also need a validation service that can perform validation checks at runtime.
The last area to evaluate in a UDDI registry is its support for security. All UDDI V2.0 registries must support transport-level security. According to the specification, the UDDI inquiry API communicates over HTTP, and the UDDI publication API communicates over HTTPS. If you are operating a private registry, though, you should be able to establish your own transport security policies. For example, you could require HTTPS for the inquiry API.[4]
Every UDDI registry must also support authentication. The UDDI publication API requires that a user obtain an authentication token before storing any information to the database. The UDDI specification doesn't mandate any particular mechanism to manage and maintain user information, though, so each implementation uses a different method. For example, Microsoft uses Active Directory, and Novell uses LDAP. Some systems maintain a simple user/password database. There are obvious advantages to a system that supports your existing user account management system.
Authentication gives you only the simplest form of access control. Either users are authorized to access the registry, or they aren't. It gives you no control over what the user can do. Many registries permit you to assign users to user groups and then to assign privileges to those groups. You can use the groups to establish and enforce coarse-grained control policies. For example, you can say that members of a particular group can register no more than 10 services. Most UDDI registries give you this level of access control for administrative functions and the publication API. Acumen, Oracle, and Select give you more fine-grained control for update functions. These implementations permit you to define update rights by user for every element in the registry.
As of this writing, only two registry implementations provide granular access control facilities that apply to both update and query operations: Novell Nsure and Systinet WASP. These two products give you the ability to define specific access rights, by user or group, for every element in the registry. For example, suppose you want to set up a UDDI registry for your distributor network. You can offer different services to your different distributors based on geographic location, sales volume, or some other criteria. With inquiry-based access control facilities, you can segregate your services automatically. A user from one distributor would be able to find only the services that pertain to that distributor. When selecting a product, consider your access control requirements.
To build Web services, you need to select some products. I wouldn't be surprised if you found the blizzard of Web services products intimidating. Fortunately, you don't need a lot of products for your pilot project. At a minimum you need Web services platforms for the client and server environments. Depending on your integration needs, you may need an adapter framework to help you build application adapters. You might also find it helpful to use some XML tools and testing and diagnostic tools.[5]
When you begin to deploy multiple systems, you'll start to need a few more pieces. I strongly recommend that you get an operations-oriented Web services management extension. Your operations staff will certainly appreciate it. I also recommend that you set up a private UDDI registry to help manage your service assets, although not necessarily immediately. UDDI becomes more important as your portfolio of services increases and when you want to start offering these services to a wider constituency.
I can't stress enough how important it is that you select your products based on your project requirements. Before you start your product evaluation process, make sure that you understand your requirements, including factors such as operating platform, performance, scalability, reliability, availability, security, asynchrony, and transactions. Don't forget to characterize your nontechnical requirements, too. These requirements will influence your core platform selection. They will also help you determine whether you need any additional middleware-oriented management extensions or infrastructure-level services.
Some of the most basic characteristics that I look for in a Web services platform are as follows:
Standards support. Standards compliance ensures easier interoperability. At a minimum a platform should support SOAP 1.1, WSDL 1.1, UDDI 2.0, and XML Schema 1.0. Also look for WS-I Basic Profile compliance. If you're investigating solutions for Java, look for JAX-RPC compliance.
Performance and scalability. You need to make sure that the platform will support your requirements. Run benchmarks that represent realistic applications and loads.
Security. Figure out what your immediate security requirements are. Also consider what your future requirements might be. Investigate which security features are built into the platform, and which options are available to extend those features. For maximum flexibility, you'll want support for multiple authentication mechanisms and application-level authorization services. Determine what it would take to integrate the supplied security features with your security infrastructure. Look for support for WS-Security and SAML.
Extensibility. Extensibility allows you to add functionality to the platform. I always assume that at some point I'm going to want to make the system do more than originally expected. Figure out which mechanisms the platform has that will help you extend or enhance the platform. How easy is it to write and configure interceptors and header processors? What's in volved in adding support for emerging standards, such as SOAP 1.2, WSDL 1.2, WS-Security, WS-RM, WSDM, and others? What transports does the platform support beyond HTTP?
Development. Make sure that your developers feel comfortable with the environment. What kinds of tools does the platform supply? How well do they fit with your developers' usual toolbox? How much of the development effort is automated? How often does a developer have to tweak the generated code to make the applications work in real world scenarios?
Management and administration. Make sure that your operations staff feels comfortable with the administrative tools supplied. What facilities are available to manage the Web services runtime using your traditional system management framework?
Don't just blithely believe the vendor claims. Run your own tests and benchmarks. Experiment with multiple products. Most vendors will give you a free evaluation period. Get feedback from both your development staff and your operations staff. Make your vendors give you references. It's especially nice if these organizations are doing projects somewhat similar in scope to yours. Take advantage of these contacts to learn whatever you can. Join user groups. Participate in discussions. Make the effort to get educated.
I hope this book has been helpful to you and that you are now prepared to start your voyage. My advice is that you take it easy and start slowly. Identify a noncritical but reasonably visible project. For your first pilot, I suggest that you choose a simple point-to-point integration project. It will give you a chance to learn the basics about the technology. Make sure that you constrain the scope of the project. Break it into attainable tasks, and chart your course.
Don't build Web services just because they're cool. Make sure that you have a viable business model to go with the service. As a rule, your Web services should support or augment your existing business model. Web services should do things such as enhance sales, improve customer relationships, simplify customer or partner interaction, and streamline business processes.
Don't get distracted by the software-as-a-service business model. If you don't have a viable ASP-style business model today, Web services won't help you create one. If you do have a viable ASP-style business model, you should definitely use Web services technology to provide programmable Web APIs to the business service. Just keep in mind that you are selling a business service, not the Web service. The Web service is simply one of many mechanisms you provide to your customers to use the business service. The technology and the business model are separate things.
For the time being, I recommend that you focus on integration. First and foremost, Web services help you integrate applications. And they do so at a fraction of the cost of traditional middleware technology.
After you get comfortable with the concepts, you can start tackling some really high-payoff initiatives.[6] Here are examples:
Use Web services to support collaboration, allowing your people to more effectively share information so that they can be better and more efficient at their jobs.
Use Web services to give your staff a 360-degree view of your customers, resulting in higher productivity, stronger customer relationships, and lowered attrition rates.
Use Web services to integrate your business process across departmental and organizational boundaries, eliminating friction, reducing costs, and improving quality.
Use Web services to provide programmable access to your business process for your customers and business partners, making it easier for them to do business with you and producing higher sales.
Use Web services to consolidate redundant application systems, resulting in substantial savings from streamlining systems operations and increasing process efficiencies.
Use Web services to make it easier to manage your legacy application assets, significantly lowering the total cost of ownership of these systems.
Use Web services to coordinate your portal initiatives, making it easier for your staff, your partners, and your customers to interact with you. Web services also make it easier for your portal to support multiple user access channels such as IVR and the wireless Web.
I'm sure you can think of other ways to exploit Web services. They have enormous potential. Web services simplify integration. Integration helps your business operate better. Think of Web services as lubrication for your business.