A lot of people ask me which is better for Web services: .NET or Java. My usual answer is yes. Both .NET and Java are excellent platforms for developing Web services. .NET is easier to use, and Java offers more options and versatility. As with any situation, you need to select your platform based on the requirements of your project. Chapter 9 provides guidelines to help you choose a platform.

Your most basic decision factors are your programming language and your deployment platform. If your application is written in Visual Basic and runs on Windows 95, you need to use a Web services platform that supports Visual Basic on Windows 95. If your application is written in Java and runs in WebLogic Server on Solaris, you need to use a Web services platform that supports Java running in WebLogic Server on Solaris. If your application is written in Python and runs on Linux, you need to use a Web services platform that supports Python on Linux.

Most organizations use a variety of programming languages on a variety of platforms, and therefore most organizations will use multiple Web services platforms. This is one of the beautiful things about Web services. You don't need to rely on a single product or a single vendor.

The .NET Framework provides the foundation for Microsoft's latest generation of operating systems. .NET essentially replaces the COM-based infrastructure introduced in Windows 95 and Windows NT. Figure 8-3 shows an overview of the .NET Framework.

Figure 8-3. The .NET Framework includes a runtime environment, an extensive set of class libraries, and three interface modules that support programmatic access (Web services), browser clients (WebForms), and rich desktops (WinForms).

At its core, the .NET Framework is based on the runtime environment for the C# programming language. This runtime environment is called the Common Language Runtime (CLR). .NET supports any number of programming languages, but at compile time, all these languages get compiled into the Common Intermediate Language (CIL).^[2]

The .NET Framework includes a number of useful features to support rapid application development. It includes a core set of C# classes as well as classes for manipulating data and XML. It also provides three complementary interface modules, which support programmatic access (Web services), browser clients (WebForms), and rich desktop clients (WinForms). The Web services and WebForms modules rely on ASP.NET to support Web access. ASP.NET is Microsoft's Web application server environment that runs in Internet Information Services (IIS). WinForms applications can be deployed on any Windows desktop.

From an architectural perspective, the .NET Framework is very similar to the Java platform. You write applications and compile them into intermediary code, and then you deploy and execute the intermediary code in a virtual machine. In Java terminology, the intermediary code is called Java bytecode, and the virtual machine is called a Java Virtual Machine (JVM), which is part of a Java Run time Environment (JRE). In .NET terminology, the intermediary code is called CIL, and the virtual machine is called the Virtual Execution System (VES), which is part of the CLR.

Although the platforms are very similar, there are important differences between them. Table 8-1 summarizes the most pertinent differences.

One of the most basic differences between .NET and Java lies in the programming languages you can use. .NET permits you to use almost any language except Java.^[3] For practical purposes, the only programming language that you can use with Java is Java. Interestingly, this distinction is based on a marketing decision rather than a technical limitation.

Although .NET is fundamentally based on C#, Microsoft has chosen from the outset to promote the .NET Framework as a multilanguage environment. Nearly any language syntax can be compiled into CIL. Microsoft provides a number of CIL language compilers in Visual Studio .NET, allowing you to develop .NET applications using various languages, such as Visual Basic, Visual C++, Visual J#, and Visual FoxPro. When you use the Visual Studio .NET development environment, all these languages compile into CIL and can run in the CLR. Other language vendors also provide CIL language compilers. For example, Borland makes CIL compilers for Delphi and C++ Builder, and Fujitsu makes a CIL compiler for COBOL. Any component or application compiled to CIL can be easily integrated into other CIL-based applications.

The Java platform has the same ability to support multiple language syntaxes, but Sun has never promoted this idea. Just as with CIL, almost any language syntax can be compiled into Java bytecode. Although most people view Java as a single-language environment, you can find bytecode compilers for other language syntaxes, such as Ada, Basic, C, C++, COBOL, Fortran, Lisp, Perl, PL/SQL, Python, Rexx, and Smalltalk. Very few people use these alternative syntaxes for production applications, though, so for most practical purposes, the only language that you can use with the Java platform is Java.

Another basic differentiator is in terms of vendor and platform options. As of this writing, .NET is available only from Microsoft, and it runs only on Windows. Java is available from many vendors, and it runs on any platform.

The .NET Framework is available for Windows CE, Windows XP Embedded, Windows 98, Windows ME, Windows NT 4.0, Windows 2000, Windows XP, and Windows Server 2003. It is not available for Windows 3.1 or Windows 95.

At some point in the future you may be able to deploy .NET applications on UNIX and Linux. Two open source efforts are under way to develop portable implementations of the core .NET environment for UNIX and Linux systems. The Mono project is sponsored by Ximian, and the DotGNU project is sponsored by the Free Soft ware Foundation and the GNU Project. As of this writing, these projects are still a work in progress.

These groups are building their platforms based on the ECMA Common Language Infrastructure (CLI) specification, the standard specification for Microsoft's CLR. These systems will be able to execute C# applications (and any application compiled into CIL). Keep in mind, though, that .NET is more than just the CLR. The CLI specification doesn't include the higher-level class libraries used to build Web services, browser applications, and rich desktops. .NET Web services on UNIX will also require the equivalent of ASP.NET, which isn't part of the CLI standard.

Many vendors supply implementations of the Java platform, and you can run Java applications on almost every computing platform. Web services platforms for Java are available from more than a dozen organizations, including Apache, BEA, Borland, Cape Clear, Enhydra, IBM, IONA, Killdara, Macromedia, Novell, Oracle, SAP, Sun, Systinet, Sybase, The Mind Electric, and Wingfoot.

The number of available vendors has one crucial ramification. With .NET you have only one vendor. As a result, you have one very tidy, very coordinated, very integrated environment. With Java you have many vendors, and each implementation is slightly different from the others. You have different tools, different services, different feature sets, and different runtime configurations. As a result, the Java environment looks much less integrated and standardized. But the truth is that there are more standards in the Java environment than there are in the .NET environment. The Java community has defined standard Java APIs and standard data mappings between Java types and XML types. You don't need the equivalent standards in .NET because you have only one vendor.

Another distinction between .NET and Java is in the way each supports XML and Web services. .NET provides native support for XML and Web services. Java adds support for these technologies through a set of standard Java extensions.

As mentioned earlier, the .NET Framework provides class libraries for manipulating data and XML. From a developer's perspective, XML is a first-class data format that's as integrated into the environment as relational data. This integration makes it easy for developers to work with XML. .NET also includes the Web services interface module, which has full support for SOAP, WSDL, and UDDI.

As explained in Chapter 4, Java supports XML manipulation and Web services through a new set of APIs, often referred to as the JAX APIs. Although these APIs provide complete support for XML and Web services, they aren't as tightly integrated into the platform as their counterparts are in .NET.

The final key differentiator focuses on technology ownership and management. This issue is political rather than technical, and it may not be of interest to you unless you are a software vendor or you would like to participate in the management of the technology. This issue has two aspects. The first is whether you (or anyone else) can exert any influence over the future of the technology. The second is whether the licensing requirements for the technology might restrict its use.

Both Microsoft and Sun claim that their platforms are managed through a formal standards process. Thus you should have the ability to participate in the development of the technology. Although these claims are true, it's a bit complicated. Both vendors support an open standardization process, but they both retain tight control of their technologies.

Sun developed the original specifications for the Java programming language, the Java APIs, and the JRE. Since 1995 the Java platform has been developed and maintained by the Java Community Process (JCP), a quasi-standards organization sponsored and managed by Sun.

In 1997 Sun initiated an effort to contribute Java to a formal standards body. At first the company tried to work out a deal with the International Standards Organization (ISO), and, when that didn't work out, it turned to ECMA. Sun wanted to get the endorsement of a standards organization, but it really wasn't willing to relinquish control of the technology. After two years of failed negotiation, Sun decided to make do with the JCP. Many Java licensees weren't particularly happy with the decision, and eventually Sun revamped the JCP to make it more open.

Anyone can participate in Java development. More than 500 corporate, academic, and individual member organizations participate in the JCP. Companies that have participated in the development of the Web services APIs for Java include Apache, ATG, BEA, Cisco, Commerce One, EDS, Encoda, Extol, Fujitsu, HP, IBM, IONA, Macromedia, Novell, NTT, Oracle, Progress, SAP AG, Software AG, Sonic Software, Sterling Commerce, Sun, Sybase, Systinet, Vitria, and webMethods.

But the other side of the coin is licensing. Sun maintains tight control of the licensing rights to the Java specifications and to the Java brand. Although the development process is quite open, you must pay Sun for the right to implement a product based on a Java specification. Even if you participate in the development of a new Java API, you may still need to obtain a license.

Microsoft also wanted the endorsement of a standards body for .NET, but Microsoft took a slightly different tack. Rather than try to contribute all of .NET, Microsoft elected to standardize only the lowest level of the platform. Microsoft won big points when it submitted C# to ECMA in 2000. The ECMA committee—consisting of representatives from Fujitsu, HP, Intel, IBM, ISE, Microsoft, Monash University, Netscape, OpenWave, Plum Hall, and Sun Microsystems—polished the specifications and submitted them to ISO. The C# specifications are formal international standards. Anyone can implement an international standard. No Microsoft license is required.

Keep in mind, though, that the ISO standards cover only the C# language and the CLI. The higher-level class libraries and services that make up the remainder of the .NET platform—including the interface modules, the Web services class libraries, the development tools, and ASP.NET—are not part of the standard. These technologies are owned and managed by Microsoft. So although C# is managed by a standards organization, you really don't have much influence on the future of the .NET platform.

As with any debate between Microsoft platforms and the Java platform, you must decide between an integrated solution with limited portability versus a best-of-breed solution with wide portability. If you use Java, you have more homework to do. There are about a dozen product-quality SOAP implementations for Java to choose from. Each has its own best-of-breed specialty features, such as developer productivity, performance, security, or legacy integration. When choosing a platform, you should evaluate multiple products to determine which works best for your specific requirements. Chapter 9 provides guidelines to help you with your evaluation.

Table 8-2 shows an overview of the features that come with a Web services platform. These features and services vary widely from vendor to vendor, so this table is a generalization.

At a minimum, a Web services platform provides a set of runtime libraries that implements support for the SOAP specification. Each client and server application that communicates using SOAP needs access to a SOAP runtime system. A Web services platform also supplies a programming API that developers use to access the SOAP runtime libraries. This programming API supports a specific programming language, so you must have a different platform for each language you use. That's no problem, and in fact it's expected that you use multiple runtime libraries from multiple vendors on your various systems. Remember, heterogeneous interoperability is one of the major features of Web services.

Almost all Web services platforms include support for WSDL. Most SOAP tools can generate WSDL descriptions for your services, and they can use WSDL descriptions to generate client code. Many SOAP implementations use WSDL descriptions at runtime to help interpret and process the SOAP messages and to enable dynamic interaction. But not all platforms support WSDL, particularly some of the antique platforms, such as Apache SOAP and Sun's JAXM reference implementation.

I caution you against using a platform that doesn't support WSDL. You need WSDL to get the most from Web services. Without WSDL you lose most of your dynamic capabilities. More important, clients need WSDL descriptions to figure out how to access a service.

I recommend that you stick with the more modern platforms that provide integrated support for WSDL. If you use a platform that doesn't support WSDL, you probably want to find a third-party WSDL editing tool, such as Altova xmlspy or Kamiak's OmniOpera, to help you create your WSDL files.

Support for UDDI varies widely. Some Web services platforms include a UDDI registry as part of the platform. Others include a comprehensive set of UDDI wizards and utilities, but the UDDI registry server is sold separately. Still others do not provide any direct support for UDDI, although they work easily enough with third-party UDDI registries and tools.

From my perspective, a private UDDI registry service should be viewed as a separate product; in fact, I classify it as an infrastructure-level Web service rather than as a piece of the basic platform. A business is likely to need many licenses for many Web service platforms, but only one or two UDDI registries. A Web service platform should provide or make available the tools needed to access a UDDI registry, but it makes sense to obtain the registry separately.

A few Web services platforms provide advanced middleware functionality, such as security and management frameworks, reliable messaging, asynchronous communications, and cluster support. If you are using a platform that does not include these capabilities, you can augment your environment using a Web services management extension, described later in this chapter.

Most platforms supply management and administration tools designed for your operations staff. These tools are distinct from the development and deployment tools that are designed for your developers. You probably don't want your developers to be responsible for the runtime operations of your production systems.

In addition to the runtime libraries, a Web services platform must give you development and deployment tools. You use the development tools to generate SOAP code for your clients and services. You use the deployment tools to package and configure the runtime settings for your applications.

Most Web services platforms provide command line tools, which will appeal to your advanced developers. Command line tools are extremely powerful but cryptic. Some platforms have associated but separate visual tools. These tools give you a graphical design environment, numerous wizards, and drag-and-drop editors. Your novice developers will no doubt find these tools beneficial. Some platforms make their tools available as modules that plug in to popular IDEs. These plug-in modules transparently add Web services development capabilities to popular code development environments, such as Borland JBuilder, Eclipse, IBM WebSphere Studio Application Developer (WSAD), Microsoft Visual Studio .NET, NetBeans, and Sun ONE Studio.

Most Web services platforms include development tools based on WSDL. A WSDL file is a machine-readable description of a Web service, and it can be compiled into application code.^[4] As shown in Figure 8-4, a developer can use these tools to generate WSDL descriptions from application code or to generate application code from WSDL descriptions.

Figure 8-4. A developer uses WSDL tools to generate SOAP code. Your tool should support the language you're using.

The development of clients is typically separated from the development of services. The tools and platforms you use to build your clients can be different from those you use to build your services. The WSDL description is the point of integration.

There are generally two approaches to building Web services. In the first case, the developer builds a new service from scratch. In the second case, the developer creates a Web service interface for an existing application.

If you want to build a new Web service, you may want to build the service based on an existing service type. In this case, you must find the WSDL description that describes the service type. Some platforms provide UDDI browser utilities that can help you find an appropriate WSDL description.

After you have found the WSDL description, you can use a WSDL compiler to generate an application template for the service. This template consists of a set of functions that map to the operations defined in the WSDL description. You then fill in the template by writing the code that implements the functions. In some cases the service-side code generator produces generic code that can work with any SOAP runtime that supports the same language, but I wouldn't count on this type of tool to be portable across vendor implementations. Most generated templates contain code that is unique to a specific SOAP implementation.

You implement the service's business functions using normal language components and constructs. For example, a Java developer would build a service using Java classes, JavaBeans components, and Enterprise JavaBeans (EJB) components. You should always follow the traditional best practices for SOA application development.

If you have an existing application, you can use a tool to generate a WSDL description from your existing code. In a Java environment, this type of tool is usually called something like java2wsdl. A WSDL generator tool is fairly generic, so if you are using a platform that doesn't provide a WSDL generator, you should be able to use a tool from a different platform to generate your WSDL file. You may need to tweak the generated description, though.

After you've generated the WSDL file, many SOAP implementations will let you take your existing application and simply deploy it into the Web services runtime container. Presto! Your application now has a Web API. In many cases you don't have to write a single line of new code.

One word of caution about this approach: If the existing application has a highly granular, low-level API, you probably don't want to expose this interface directly. Instead you probably want to build a wrapper that presents a higher-level business interface to the application's functionality. You would use this wrapper to generate your Web API.

For example, let's say that you have an interactive order-entry application that displays an interface that lets users add items to the order one product at a time. This type of interface is quite reasonable for an interactive application, but it isn't particularly appropriate for a Web services application. It would require an excessive number of message exchanges, causing poor performance. When building Web service interfaces, you want to design the interface to reduce the number of message exchanges, as shown in Figure 8-5.

Figure 8-5. If your Web service has a highly granular, low-level interface (top), you should build a new, higher-level interface to the application functionality (bottom).

In some cases you may need to build a Web services adapter for a legacy application. As described in Chapter 1, an adapter acts as a mediator between an open API and a proprietary API. A Web services adapter maps SOAP requests to the proprietary API supported by the legacy application. As with the business interface scenario, you would use the adapter code to generate your Web API. Many EAI vendors provide adapter frameworks that support Web APIs.

In addition to the Web API and the business logic, you may need to develop a few other routines. When you send and receive SOAP messages, the SOAP runtime system translates the messages between XML and your application's native data format. In some cases the developer may need to provide serialization routines that tell the runtime system how to map between the two formats. Some platforms perform this data mapping automatically. Other platforms can perform automatic mappings as long as the application objects are relatively simple and are constructed according to certain conventions. Some platforms provide visual tools to help you design the data mappings and then generate the serialization routines. Other platforms require that you write custom serialization routines. All serialization tools are tied to a particular runtime.

You may need to write specialized routines to handle middleware functions, such as security, reliability, version control, message transformation, and transactions. These routines are known as interceptors or header processors. The middleware information is usually passed using SOAP headers, and you may need to supply the code to process the SOAP header information. Some platforms provide built-in support for many of these middleware functions, so you don't necessarily need to write your own header processors. The mechanisms you use to implement header processors are unique to each specific runtime.

After you have developed the serialization routines and header processors, you are ready to configure the Web service and create a deployment package. Figure 8-6 shows an overview of the deployment steps. Most SOAP implementations use some type of deployment descriptor to define the runtime configuration of the service. This deployment descriptor maps a particular WSDL operation to a particular application program, and it specifies any additional information that the runtime system needs to know. For example, it specifies the name of any serialization routines and header processors associated with the service. As of this writing, there are no standards for deployment descriptors, so each SOAP implementation uses a unique format, and the mechanism you use to create the deployment descriptor and deploy your service is unique to each particular runtime server. This issue should be resolved for Java applications at some point in the future as the JCP develops container standards for Web services.

Figure 8-6. When deploying a service, you first configure the service and then create a deployment package to deploy it. You may also want to register the service in a UDDI registry.

After you have deployed your service, you probably want to advertise it to your potential consumers. For example, you may want to advertise it in a private or public UDDI registry. Some platforms provide UDDI registration wizards that automatically register a new service in a public or private UDDI registry.

When building a client, a developer obtains the WSDL description for the service and uses a WSDL compiler to generate a client proxy. The client uses the proxy to talk to the service. The proxy contains code that interfaces with the SOAP runtime. The proxy does quite a bit of work for the client application:

The client proxy always contains code that is unique to a specific SOAP implementation, so the tool you use to generate the proxy determines which SOAP runtime your client will use. As mentioned before, you can use different SOAP runtimes for your clients and services.

In addition to the client proxy, you must provide serialization routines and header processors for your client. If you are using the same SOAP runtime on both client and server, you can use the same serialization routines and header processors. If you are using different SOAP runtimes, you must supply different routines.

Web services can run on almost any size computer—anything from a massive mainframe or multiprocessor server, to a desktop machine, to a PDA, to an embedded processor in a light switch. A few platforms, such as EXOR eSOAP, kSOAP, and Wingfoot, are designed to support tiny-footprint devices. For the most part, though, you'll find that most Web services are deployed on servers, and most Web services platforms are designed to support that configuration.

Figure 8-7 shows a typical runtime environment for Web services. Here you see a client application talking to a Web service. The client application can be any type of application, including a corporate application (such as your inventory control system), a desktop application (such as a spreadsheet tool), a wireless device (such as a RIM Blackberry pager), or a Web portal (such as your employee HR portal). The client uses a proxy to communicate with the service. The proxy is generated from the service's WSDL description. The proxy uses its associated SOAP runtime libraries to construct, send, and interpret SOAP messages.

Figure 8-7. A client application communicates with a Web service using a proxy generated from the Web service's WSDL description. The Web service runs in a SOAP runtime server, which usually executes in a Web server or application server.

A Web service is deployed in a SOAP runtime server. You'll notice in Figure 8-7 that the Web service has a WSDL description and a deployment descriptor associated with it. The WSDL description provides the information that a client needs to communicate with the service. The deployment descriptor provides the information that the SOAP runtime server needs to process the request.

When the client issues a SOAP request, the proxy converts the request into a SOAP message, establishes a connection to the SOAP runtime server, and sends the message. A SOAP runtime server consists of a SOAP message processor and a runtime container.

A SOAP message processor is responsible for interpreting the request and directing it to the appropriate application. The SOAP message processor listens for requests, and, for each request received, it processes the SOAP message. It uses the deployment descriptor to figure out how to process the message. The deployment descriptor indicates how to process any SOAP headers that may be present, and it specifies how to translate the XML into program language objects. It also specifies which application program should be called to process the request. When the program completes its work, it returns a response to the SOAP message processor, which converts the response into a SOAP message and sends it back to the client.

The application program normally executes within the runtime container in the SOAP runtime server. A runtime container manages the lifecycle of an application. The container is responsible for loading the program into memory, allocating the system resources that the program needs, and removing the program when it's complete. A runtime container may provide a number of optimization services, such as multithreading support and resource pooling, that can increase the performance and scalability of the environment.

The Web service application running in the container may contain the business logic that implements the service, or it may instead contain a wrapper service. A wrapper service is an application adapter that calls an external application to perform the actual business logic. The external application could be any type of application, such as an SAP R/3 function or a CICS transaction. The wrapper service communicates with the legacy application using the legacy application's native API.

A SOAP runtime server usually runs in a Web server or application server. A Web server, such as Microsoft IIS and Apache HTTP Server, provides support for HTTP, the most common protocol used to transfer SOAP messages. An application server, such as Apache Tomcat or BEA WebLogic Server, is a Web server that has been extended to support Web applications. An application server usually supplies one or more runtime containers that provide lifecycle management for various types of Web applications.

I'm sure you've noticed that most J2EE application server vendors—including BEA, Borland, IBM, IONA, Macromedia, Novell, Oracle, and Sun—have added Web services to their products. You may also be aware that a number of other SOAP providers and vendors—such as Apache, Cape Clear, Killdara, Systinet, The Mind Electric, and Wingfoot—provide Web services platforms for Java that don't require a full J2EE application server. IONA, Novell, and Sun provide stand-alone platforms as well as J2EE-based platforms. So let's spend a moment talking about Java application servers.

As shown in Figure 8-8, J2EE defines two types of containers to support Web applications: a servlet engine and an Enterprise JavaBeans (EJB) container. A servlet engine hosts servlets and JavaServer Pages (JSPs). An EJB container hosts EJB components. According to Sun's best practices blueprints, you should use servlets and JSPs to implement presentation logic and use EJBs to implement complex business logic.

Figure 8-8. A J2EE application server provides an HTTP server and two kinds of application containers to support dynamic Web applications. A servlet engine hosts servlets and JSPs, which perform presentation logic. An EJB container hosts EJB components, which perform business logic.

Servlets and JSPs are lightweight Java components that communicate using HTTP. For the most part these components are designed to perform Web-based presentation logic. You normally invoke a servlet from a Web page by clicking on a link within your browser. The link tells the HTTP server to invoke the servlet, which is a Java application that dynamically creates an HTML page. I refer to servlets as lightweight, but they can do pretty much anything you want them to do. They can execute business logic, access databases, call legacy applications, and perform transactions. A servlet engine gives you a number of optimization features that support high performance and scalability. However, a servlet engine generally doesn't provide support for distributed transactions.

EJB components are industrial-strength, secure, transactional business components. EJB components are designed to support complex business logic, distributed transactions, and extensive data manipulation. The EJB container is a runtime framework that automatically manages distributed transactions and access control facilities. An EJB container optimizes resources a little differently than a servlet engine does. These EJB optimizations impose more overhead but result in better overall performance and scalability when you're dealing with complex transactions. For relatively simple applications, though, a servlet engine is often adequate and offers better performance.

Unlike servlets, EJB components cannot communicate using HTTP. They can communicate only via RMI. You cannot invoke an EJB component from a Web page through an HTTP connection, so for Web applications, you must invoke an EJB component through an HTTP-enabled component, such as a servlet or a Web service.

A Web service is a third kind of component that executes in yet another type of container. Figure 8-9 shows a J2EE environment with an added Web services container. Web services provide an alternative type of interface to your backend business applications. They are similar to servlets in that you communicate with them using HTTP, but they are different in that they are designed to serve application clients rather than human clients. Servlets return HTML, and Web services return XML.

Figure 8-9. A Web service offers an alternative programmable interface to your business applications. A Web service container offers performance characteristics comparable to those of a servlet engine.

As with servlets, it's perfectly legitimate to implement your business logic entirely within the Web service, particularly if the application is relatively simple. A Web services container offers performance characteristics comparable to those of a servlet engine. If your application is simple and doesn't require complex transactions, you can run your Web services using a lightweight servlet engine.

If your application requires complex transactions, you'll probably want to implement your business logic using EJB components. EJBs use a complex, low-level API, so you'll definitely want to build a business interface for these applications. You would deploy the business interface in the Web service container.

A Web service adapter for a legacy application might run entirely within the Web service container, or it might call a JCA adapter running in the EJB container. The J2EE Connector Architecture (JCA) defines a standard plug-in architecture for application adapters in J2EE application servers.

As mentioned earlier, quite a few Java SOAP implementations don't require a full J2EE application server. Most of these products have built the SOAP server as a servlet, and this means that the SOAP container actually runs in the servlet engine. This architecture ensures that the SOAP server is portable across multiple application servers. The SOAP server can also use the existing HTTP processing services, as well as clustering and load balancing capabilities, offered by the servlet engine.

A number of free or low-cost, lightweight application servers—such as Apache Tomcat, Caucho Resin, and Jetty—support servlets. Most of the independent Java SOAP implementations will run in any of these servlet engines, so you can use these application servers to host your Web services.

Still, there are many reasons you might prefer to deploy your Web services in a full-fledged J2EE application server. You may already have a J2EE application server. You may implement your business logic as EJB components. You may prefer to use commercial products rather than open source technology, or you may need the increased performance, reliability, availability, and scalability provided by an industrial-strength product.

If you decide to use a J2EE application server, you can use the built-in Web services container that comes with the server, or you can use one of the portable third-party Web services platforms. The third-party platforms offer a number of competitive features that aren't available with most built-in containers. Also, services written for the built-in container generally can run only within that particular J2EE application server. If you need portability across application servers, you'll want to use a third-party platform. See Chapter 9 for platform evaluation guidelines.

A middleware extension augments a basic Web services platform with advanced middleware functionality, such as load balancing, content-based routing, version control, reliable message delivery, and security.

Perhaps because there are no standards for middleware extensions, these products often operate using an intermediary architecture, as shown in Figure 8-10. When you send a message, the management framework intercepts the message before it reaches the SOAP runtime. The framework can monitor messages, execute security policies, redirect a message, or transform a message according to the capabilities and policies defined by the framework.

Figure 8-10. A middleware extension intercepts messages and adds extended functionality in transit.

Middleware extension frameworks—such as those from AmberPoint, Blue Titan, Confluent, Digital Evolution, Flamenco Networks, Talking Blocks, and WestGlobal—intercept and process SOAP messages in transit and take appropriate action based on content. Each of these vendors focuses on its own set of capabilities. For example, Talking Blocks focuses on message routing and transformation, and WestGlobal focuses on performance management.

Nearly all middleware extensions provide some type of security framework. Some vendors, such as Hitachi Quadrasis, Reactivity, Vordel, and WestBridge, focus exclusively on security. These security frameworks enable a variety of security functions, such as authentication, authorization, encryption, auditing, and key management. You'll also find that many of the traditional security vendors, such as Netegrity and VeriSign, offer products in this space. Netegrity has extended its products to encompass Web services security. VeriSign has developed a series of toolkits specifically to support Web services security.

These middleware frameworks are especially helpful if you are using a Web services platform that doesn't provide a lot of advanced middleware capabilities. You can use these systems to augment the capabilities of your core Web services platform to make it more secure and robust.

Although these products provide tremendous incremental value to the current crop of Web services platforms, I must caution you about overhead. As mentioned earlier, most of these products run as an intermediary that intercepts and processes the SOAP messages in transit. This intermediary can run as a filter in your Web server or as a separate proxy server. In either configuration I refer to this architecture as “the big fat proxy.” SOAP message processing can constitute as much as 90 percent of a Web services message exchange. If you add a SOAP processing intermediary to the message path, it can nearly double the invocation response time.

Rather than run as an intermediary, a middleware extension can instead run as an interceptor in the SOAP runtime server. In this architecture the message is processed only once by the SOAP message processor in the SOAP runtime server, which calls out to the middleware extension at the appropriate moment to perform the requested functions. From a performance perspective, it's much more efficient to perform all middleware functions in the SOAP runtime server rather than in an intermediary.

To support the runtime interceptor architecture, a vendor must build a unique interceptor for each Web services platform; as a result, many vendors may elect to support only the most popular platforms. The JAX-RPC API defines a standard interceptor model called JAX-RPC handlers, so a vendor can build a generic interceptor for all Java platforms that support JAX-RPC.

I tend to think of middleware extensions as a stopgap solution, though. Over time many of the Web services platform vendors will provide built-in support for features such as security, load balancing, transactions, and version control. A number of platforms already have quite a few advanced features, and they implement them in the SOAP processing layer.

A monitoring framework is closer in nature to a traditional systems management framework. The reason that the middleware extension products are associated with the term “management” is that most of them also provide monitoring facilities. A monitoring framework monitors SOAP message traffic to give you visibility into your runtime environment.

These monitoring frameworks are aimed at two audiences: your operations staff and your business analysts. From an operations perspective, these frameworks provide critical information needed by your operations staff to keep your systems up and running. Products such as Actional SOAP station Adjoin SOMMA and Service Integrity SIFT focus on this operations perspective. These systems capture SOAP message traffic as it streams by and actively analyze the information in an out-of-band process, imposing very little overhead. The analyzers identify trends, define thresholds, and take action when unusual conditions arise. For example, if the average message response time exceeds a threshold, the framework can page an administrator or send an alert to HP OpenView. Monitoring frameworks can also collect information needed for metering and billing purposes and can monitor conformance to service level agreements. I view this type of monitoring framework as a critical piece of your core Web services infrastructure.

The monitoring frameworks also give you the opportunity to analyze the SOAP message traffic for business purposes. You can archive the captured message traffic and perform statistical and heuristic analysis of it. For example, you can identify business trends, track regional sales fluctuations, and predict traffic peaks and valleys.

A reliable network provider (RNP), such as Flamenco Networks and Grand Central, provides an infrastructure-level Web service that supports reliable message delivery. These companies supply ASP-style services that ensure that your SOAP messages get delivered reliably to their intended target.

When an application sends a message, as shown in Figure 8-11, the SOAP runtime system routes the message through an RNP proxy, which takes responsibility for delivering the message via the reliable network. The proxy stores the message in a persistent file before sending it on. It then monitors the delivery of the message and automatically resends it if it goes astray. An RNP may also offer additional services, such as authentication and authorization checks, message encryption, message auditing, and service level monitoring.

Figure 8-11. An RNP proxy intercepts SOAP messages and routes them through a reliable network.

RNPs are particularly useful when you need reliable messaging but can't dictate a proprietary networking environment. For example, they are popular for B2B applications and e-marketplaces. Many Web services platforms provide basic support for reliable message delivery by using a reliable transport, such as IBM WebSphereMQ or JMS. But this choice restricts your options. If you use a MOM technology as a transport, everyone that wants to talk to you must also use that MOM technology. The RNP services isolate the users from the proprietary network.

A UDDI registry is an infrastructure-level service. You are likely to use a variety of UDDI registries, including the public UBR, a private e-market registry, your partners' registries, and your own internal private registries.

Many Web services platforms include a lightweight UDDI service for development and testing purposes, although you may find that these systems aren't sufficient for production use. If you intend to use a private UDDI in production, you might want to look for an implementation that has extended features to support security, administration, and taxonomy management.

You're likely to use a number of trust services in your service grid, including a single sign-on service, an entitlement service, a key management service, and a digital signature processing service. These trust services make it easier to implement global security policies for your environment.^[6]

A single sign-on (SSO) service helps facilitate the authentication process within your Web services infrastructure. A user can sign on to the SSO service and obtain an identity credential. Your SOAP runtime can then pass this credential in a SOAP header on all subsequent requests, alleviating the need to repeatedly perform authentication tests. SAML defines a standard XML format for authentication credentials. Many of the traditional security companies, such as Netegrity and Oblix, are extending their current single sign-on products to support SAML.

An entitlement service provides a central coordination point to implement access control policies. An entitlement service may support one or more of the developing OASIS security standards, including SAML, XACML, and XrML. Most traditional access control vendors, such as IBM and Netegrity, are enhancing their systems to support access control for Web services.

If you plan to use digital signatures in your environment, you may want to deploy trust services to help manage signature creation and verification as well as key registration and retrieval. PKI management is notoriously arduous. The OASIS DSS and W3C XKMS specifications show some promise for making the technology more accessible.

Some infrastructure-level Web services come packaged as a hardware appliance. For example, DataPower and Forum Systems supply appliances that give you application-level XML security in a box. Using hardware acceleration technology, these appliances support high-performance XML encryption and XML signature services.

A metering and billing service keeps track of a user's service utilization and accrues billing information. You'll need this type of service if you intend to charge users to use your services. As of this writing, few vendors or service providers are working in this area. Metra Tech and Schemantix are early entrants. A number of companies provide ASP-style billing presentment and payment services, and perhaps these services will be adapted to support Web services.