Connecting with Web Services

In the previous section, you saw how you can use .NET Remoting to connect the Java platform and .NET Framework with runtime bridges. However, .NET Remoting is closely linked to the .NET Framework and you may need an interoperability solution that is platform neutral.

There is currently a lot of interest in the computer industry around Web services, and Web services offer you additional choices as part of an interoperability solution. It is worth looking at what Web services are and what they offer.

A high-level definition of a Web service would be a programmable application component accessible through standard Internet protocols. Many more detailed definitions of Web services exist, and they all seem to contain the following elements in the description:

• Web services expose useful functionality through standard Internet protocols. In most cases, this protocol is SOAP over HTTP.

• Web services describe their interfaces in enough detail to allow a user to build a client application to talk to them. An XML document named a Web Services Description Language (WSDL) document contains this description.

• Users can search for available Web services in some form of registration database. Universal Description, Discovery and Integration (UDDI) is the most common way to implement this.

Because Web services are standards-based and platform independent, they provide a natural fit when it comes to getting applications in different platforms to interoperate with each other. This partially explains the alacrity with which so many vendors have endorsed the Web services standards. From this book’s perspective, Web services can provide a useful mechanism for connecting the .NET Framework and J2EE. Specifically, Web services address three main interoperability issues:

• Protocol standards — HTTP and HTTPS are the most common implementations, but Web services have the flexibility to use any transport protocol.

• Type definitions — Web services always expose strongly typed data, so if a Web service exposes a type, another Web service can understand and consume that type regardless of the underlying language or platform.

• Multiple levels of support — The ability to implement Web services in any language on any platform and using any vendor’s toolkit, hence a consumer does not need to be aware of the platform that a particular service runs on.

Both .NET Framework and Java offer implementations of Web services, with varying degrees of integration into the underlying platform. In fact, one of the central tenets of the .NET Framework is its high degree of integration with Web services. Web services are well-suited to providing a wide variety of services over the Internet, and they are a promising technology for enterprise application integration.

However, while Web services provide a very powerful technology, they are not suitable for all applications and interoperability scenarios. Because SOAP is text based, Web service calls may be too slow for applications that require frequent, fast, and fine-grained communications.

Service-oriented interfaces such as Web services are also unsuited for conventional object-oriented models. Although you can think of a service as a single persistent server activated object, client-activated objects such as ones that the new operator constructs, and access requests to static methods are not generally supported. Similarly, if your application needs to access a wide variety of objects and classes, a Web service is not generally suitable. Again, if you need to link to a rich object-oriented set of Java APIs from .NET Framework, Web services are probably not the solution.

In addition to the preceding issues, Web services do not support callbacks in the same manner as local object-oriented architectures. Finally, there may be problems returning rich custom Java objects to .NET Framework through a Web service. In such cases, look at alternatives to Web services such as JNBridgePro and Ja.NET.

Understanding Web Services

In a typical Web services scenario, a client application can learn about what functionality a Web service provides and how to call this functionality by querying the service’s WSDL file. Next, the client sends a request to the service at its given URL using the SOAP protocol over HTTP. The service receives the request, processes it, and returns a response. The request and the response are XML formatted using the SOAP protocol.

It is worth examining the protocols and specifications (or stack) that make Web services possible. The Web services stack consists of five layers, as Figure 4.8 illustrates.

Figure 4.8: The five-layer model of the Web services stack

These layers consist of the following elements:

• Transport (HTTP)

• Encoding (XML)

• Standard structure (SOAP)

• Description (WSDL)

• Discovery (UDDI)

The next sections describe each of these elements.

Transport (HTTP)

At the lowest level, two components in a distributed architecture must agree on a common transport mechanism. Because of the near universal acceptance of port 80 as a less risky route through a firewall, HTTP became the standard for the transport layer. However, Web services implementations can run on other transport protocols such as FTP and SMTP, or even other network stacks, such as Sequenced Packet Exchange (SPX) or non-routable protocols such as NetBEUI. Changing from the dependence on HTTP or HTTPS (for encrypted connections) is possible within the bounds of the current specification.

Encoding (XML)

After agreeing on the transport, components must deliver messages as correctly formatted XML documents. This XML dependence ensures the success of the transfer, because both provider and consumer know to parse and interpret the XML standard.

Standard Structure (SOAP)

Although XML defines message encoding, it does not cover the structure and format of the document itself. To guarantee interoperability, both provider and consumer must know what to send and what to expect. SOAP is a lightweight, message-based protocol built on XML (XSD version 2) and standard Internet protocols, such as HTTP and SMTP. The SOAP protocol specification defines an XML structure for messages (the SOAP envelope), data type definitions, and a set of conventions that implement remote procedure calls and the format of any returned data (the SOAP body).

Description (WSDL)

The description layer provides a mechanism for informing interested parties of the particular bill of fare that a Web service offers. Web Services Description Language (WSDL) provides this contract, setting out for each exposed component:

• Component name

• Data types

• Methods

• Parameters

This WDSL description enables a developer for a remote component to query your Web service and find out what the service can do and how to get it to do it. The WSDL file is an XSD-based XML document that defines the details of your Web service. It also stores your Web service contract. The WSDL file is usually the first point of entry for any client attaching to your Web service so that the client knows how to use it.

Discovery (UDDI)

Discovery attempts to answer the question “Where.” If you want to connect to a Web service at an Internet location (for example, www.nwtraders.msft/services/WeatherService.aspx), you can enter the URL manually. However, URLs are somewhat unwieldy and not very user friendly, so it would be better if you could just request the NWTraders Weather Web Service. To do this, NWTraders could publish their weather service on a Universal Description, Discovery and Integration (UDDI) server. Finding their weather service is now just a question of connecting to the UDDI server using an agreed message format to locate the URL for the service.

Figure 4.9 shows the how the basic architectural elements of a typical Web service work together.

Figure 4.9: Typical architectural elements from a Web service

Now that you understand the individual parts of a Web service, it is easier to create a more precise definition. Hence a Web service is an application component that does the following:

• Communicates using open protocols (such as HTTP and SMTP).

• Processes SOAP framed XML messages.

• Describes its messages through the XML Schema.

• Uses WSDL to provide a service description.

• Enables discovery through UDDI.

Web Services Interoperability Organization

The protocols Web services depend on are platform independent. This suggests that interoperability between Web services on different application platforms should be automatic. Unfortunately, this is not necessarily the case.

While most of these protocols are generally accepted specifications, many of the Web services draft standards have not received full ratification from any of the common Web standards bodies, such as the World Wide Web Consortium (W3C) or Organization for the Advancement of Structured Information Standards (OASIS). Not surprisingly, many vendors have their own implementations of these specifications. As a result, interoperability between different vendors’ Web services is not guaranteed.

Because many vendors were so enthusiastic about Web services, it became imperative to start an independent organization dedicated to maintaining standards and providing direction. Without this body, it would be impossible to ensure that Web services implementations were truly interoperable. From this requirement arose the Web Services Interoperability Organization (WS-I). The initial membership was 170, consisting of vendors, enterprise customers, system integrators and independents all working together to define the implementation of Web services.

Any organization or individual who wants to contribute to supporting and furthering the cause of Web services interoperability can join the WS-I. The WS-I targets developers and provides a framework and guidelines for the following areas:

• Profiles — These are specifications that define technology standards.

• Samples — These highlight interoperability concepts and demonstrate the features of the profiles.

• Implementation guidelines — These show a best practices approach to design solutions that require interoperability with Web services.

• Tools — These include a sniffer and analyzer to monitor and log interactions with Web services, including identifying errors and warnings for implementations that do not meet the profile guidelines.

For more information about the WS-I, see the Web Services Interoperability Organization Web site (http://www.ws-i.org/).

Implementing the Web Services Basic Profile

The most important publication to date from the WS-I is the Basic Profile 1.0. This profile provides a group of named Web services specifications, together with a series of recommendations for implementing each standard. Basic Profile 1.0 covers four areas:

• Messaging (HTTP, XML 1.0, XSD 1.0, SOAP 1.1)

• Description (WSDL 1.1)

• Discovery (UDDI 2.0)

• Security (HTTPS)

  Note

  WS-I does not control the individual specifications within Basic Profile 1.0, so it acts as a unifying intermediary for Web services. The XBikes sample application does not fully support the WS I Basic Profile 1.0.

Implementing Web Services

Implementing Web services in .NET Framework and on the J2EE platform are different processes, due to the levels of support that each provides. Because .NET Framework includes built-in support for Web services, you do not require any additional components. Visual Studio .NET lets you create Web services implementations from a project template. With J2EE, you currently need to add a third-party Web services implementation.

Whether you implement your Web service in .NET Framework or in Java, there are certain common architectural elements, as Figure 4.9 shows.

There are two main stages to implementing Web services:

• Creating the Web service.

• Creating the Web service client.

The following two sections look at how you do this on the two platforms.

Creating Web Services in .NET Framework

Web services are tightly integrated into the .NET Framework. This makes it very easy to use the Visual Studio .NET IDE to design and create a Web service in .NET Framework. The .NET Web services implementation uses the same page framework as ASP.NET, consisting of the following:

• An addressable Web service entry point (.asmx file).

• The code that implements the Web service’s functionality (typically kept in a .asmx.cs code-behind file).

To create Web services using Visual Studio .NET, your developer workstation needs access to a Web server configured for ASP.NET applications. If your server is running a version of Windows Server 2003, you must install IIS from the Application Server options and include support for ASP.NET applications.

Note

The Windows Server 2003 family does not include IIS in a default installation. This is a change from Windows 2000.

Visual Studio .NET lets you create an ASP.NET Web service project in any of the supported Visual Studio languages using the Web service project templates. After you create the Web service project in Visual Studio, the Component Designer appears. The Component Designer is the design surface for your Web service. You can use the Design view to add components to your Web service, and the Code view to view and edit the associated code.

When you create an ASP.NET Web service project in Visual Studio, it constructs a Web application project structure on the Web server and a Visual Studio solution file on your local computer. The solution file (.sln) contains the configuration and build settings and keeps a list of files associated with the project. In addition, Visual Studio automatically creates the necessary files and references to support a Web service. When completed, Visual Studio displays the .asmx file in Design view.

By default, Visual Studio uses code-behind files, such as Service1.asmx.vb (for Visual Basic) or Service1.asmx.cs (for C#), when you create a Web service using one of the ASP.NET Web service project templates. The code-behind file contains the code that implements the functionality of the Web service. In this file, you implement the methods you want your Web service to expose.

Note

By default, Solution Explorer hides the code-behind file. When you look at the .asmx file in Code view, you see the contents of this code-behind file. The .asmx file itself contains a processing directive, WebService, which indicates where to find the implementation of the XML Web service.

You implement the Web service’s functionality the same as you would with any other class in the .NET Framework. To make a method available through the Web service, you mark the method with a [WebMethod] attribute before its public declaration. Private methods cannot serve as the entry point for a Web service, although they can be in the same class and the Web service code can call them.

When you build a Web service, ASP.NET automatically provides the infrastructure and handles the processing of Web service requests and responses, including the parsing and creation of SOAP messages. The compiled output is a .dll file in the project’s Bin folder.

Chapters 7 and 8 of this book show detailed examples of how to implement Web services in the .NET Framework as part of the XBikes sample application. For additional reading on Web services, see the References section at the end of this chapter.

Exposing an Existing Class as a Web Service

A common scenario is where you want to expose the functionality of an existing .NET Framework class as a Web service so that other applications (such as Java applications) can access it. To do this, you can create a new Web service that acts as a service interface to the existing class. The new Web service should implement the same interface as the existing class, with each of its methods simply calling the methods of the existing class. This solution is known as the Service Interface pattern.

For more information about the Service Interface pattern, see the References section at the end of this chapter.

Component Services for Windows Server 2003 can use the built-in SOAP activation feature to expose a ServicedComponent through a SOAP endpoint which you can then access through a WSDL document. SOAP activation involves the automatic generation and hosting of a SOAP endpoint through IIS. This SOAP endpoint can then accept SOAP requests over HTTP.

It could be argued that because you can access this SOAP endpoint through a WSDL document, it is a Web service. Unfortunately, this may not always be the case because although you used SOAP, HTTP, and WSDL to build the endpoint, the WSDL document generated from the SOAP activation is not XSD compliant and contains .NET Remoting-specific data types.

Only clients that understand .NET Remoting can access SOAP-activated ServicedComponents. Therefore, by default, non-.NET Framework Web service clients cannot connect. To overcome this, you can do the following:

• Use a Java client with a runtime bridge installed to consume any exposed methods from the ServicedComponent’s SOAP endpoint. This works because the runtime bridges understand .NET Remoting.

• Create a new Web service to accept incoming Web service requests and pass them on to the ServicedComponent as in the Service Interface pattern described earlier in this chapter.

Whichever technique you chose, you should now have a functioning Web service and can look at creating a client application.

Creating the Web Services Client

After you create your Web service, you then need to have client applications to access it. There are several ways of doing this, depending on the protocols that your Web service supports.

If your Web service supports the HTTP-GET protocol, you can access it from a Web browser. By default, Web services that you create in Visual Studio using the ASP.NET Web service project template support HTTP-GET, HTTP-POST, and HTTP-SOAP commands.

Note

The WS-I Basic Profile 1.0 does not support the HTTP-GET and HTTP-POST protocols. It is recommended that you disable the use of HTTP-GET and HTTP-POST to make your Web service WS I Basic Profile 1.0 compliant.

.NET Framework provides two Help techniques for when you do not know how to address a Web service. Calling the Web service’s .asmx file directly from a browser without parameters generates a Help page, as shown in the following example.

 http://localhost/WebService1/Service1.asmx 

The other way to discover information about the Web service is to query its WSDL properties. You can do this by calling the Web service’s .asmx file directly from a browser with “?WSDL” appended as a parameter.

 http://localhost/WebService1/Service1.asmx?WSDL 

These built-in Help systems can assist you both in the design and debugging phases of creating a Web services client.

Implementing a .NET Framework Web Service Client

A Web service client is any component or application that references and uses a Web service. This does not necessarily need to be a client-based application — in many cases your Web service clients might be other Web applications, such as Web Forms or even other Web services.

When accessing Web services in managed code, a proxy class and the .NET Framework handle all of the infrastructure coding. The proxy class implements the interface Web service’s interface and handles all communication between the Web service client and the Web service. Figure 4.10 shows the relationship of the proxy class to the Web service client and the Web service itself.

Figure 4.10: Web service client using a proxy class to communicate with a Web service

Note

You can create and manage proxy classes manually, or you can let Visual Studio .NET manage them for you through the automated Web References feature. The recommended approach is to use Web References.

To access a Web service from managed code in Visual Studio .NET

1. Add a Web reference to your project for the Web service you want to access. The Web reference creates a proxy class with methods that serve as proxies for each exposed method of the Web service.

2. Add the namespace for the Web reference.

3. Create an instance of the proxy class, and then access the methods of that class like you access the methods of any other class.

After you build the project, you should then be able to access the referenced Web service.

Locating an XML Web Service and Adding a Web Reference

Sometimes you may be both the provider and consumer of a Web service. In this case, you probably know the location and function of the Web service. At other times, you may be accessing a Web service provided by someone else. When this occurs, you may not even know if a Web service that suits your purposes in fact exists.

To simplify the coding model, applications written in managed code use a Web reference to represent each Web service locally. You add a Web reference to your project by using the Add Web Reference dialog box. To access the Add Web Reference dialog box, right-click the Web References folder in Visual Studio .NET’s Solution Explorer, and then click Add Web Reference. This dialog box makes it possible for you to browse your local server, the Microsoft UDDI Directory, and the Internet for Web services.

The Add Web Reference dialog box uses the process of Web service discovery to locate eligible Web services on Web sites that you navigate to in the dialog box. For a particular address, it interrogates the Web site using an algorithm designed to locate Discovery of Web service (DISCO) documents and ultimately, Web service description documents that adhere to the grammar of the Web Services Description Language (WSDL).

Generating a Proxy Class

After you locate a Web service for your application to access by using the Add Web Reference dialog box, clicking the Add Reference button instructs Visual Studio to download a copy of the service description to the local computer and then generate a proxy class for accessing the chosen Web service. The proxy class contains methods for calling each exposed Web service method both synchronously and asynchronously.

Note

This technique works only when the computer running Visual Studio has access to the Web service.

Alternatively, you can manually generate a proxy class using the same tool (Web services Description Language Tool, WSDL.exe) that Visual Studio uses to create a proxy class when adding a Web reference. This is necessary when you cannot access the Web service from the computer that Visual Studio is installed on, such as when the Web service is located on a network that the client is unable to access until run time. To generate a proxy file manually, run WSDL.exe from the command prompt with the URL of the target Web service’s WSDL file as a parameter. You then manually add the file that the tool generates to your application project.

Using the Proxy Class

The generated proxy class has its own namespace associated with it, and you must add that namespace to your client application before you can create an instance of the proxy class. As with any other class, you must first create an instance of it before you can call any of its methods. This process does not differ at all from creating an instance of any other class.

When using a proxy class that Visual Studio generated directly from the service description of a Web service, accessing a Web service in managed code is a relatively simple process. To access a Web service method, your client application invokes either the corresponding synchronous method or asynchronous methods of the proxy object. These methods do the necessary work to remote the call over the wire to call the desired Web service method. By default, the proxy class uses SOAP to access the Web service method because SOAP supports the richest set of data types of the three supported protocols (HTTP-GET, HTTP-POST, and HTTP-SOAP).

The proxy class that the Add Web Reference process generates derives from the System.Web.Service.Protocols.SoapHttpClientProtocol class, which contains several properties that you can use to control or customize the behavior of how this class accesses a Web service. For more information about the properties available in the SoapHttpClientProtocol class, see the .NET Framework SDK.

Note

When you update a Web reference, Visual Studio .NET automatically generates a new proxy file. The new file overwrites the old one, removing any customization you may have added to the original proxy file. Keep a backup copy of any customized proxy files to guard against this possibility. This does not happen if you manually generate a proxy file with the WSDL.exe tool.

Referencing with Dynamic and Static URLs

A Web reference can use either a static URL or a dynamic URL. The Web Reference URL property specifies the location of the Web service. By default, this property is the URL of the Web service you selected, which is a static URL.

If you leave the URL Behavior property set to the default value of Static, a hard-coded URL sets the proxy class’s URL property when you create an instance of that class. If you set the URL Behavior property of the Web reference to Dynamic, the application obtains the URL at run time from the <appSettings> section of your application’s configuration file.

 <appSettings>    <add key="myApplication.myServer.Service1"         value="http://myServer/myXmlWebService/Service1.asmx"/> </appSettings> 

When you create an instance of a proxy object, you can also programmatically set the URL property of the object in your application. Regardless of which URL the proxy uses, it must be for a Web service that conforms to a WSDL that matches the one you used when adding the Web reference. Otherwise, the proxy class that you generated earlier will not work with it.

Calling Web Service Methods

After adding a Web reference to a Web service, you can invoke the exposed methods of that Web service and access the results just as you would any other method of a component.

For examples of how to implement these techniques in the XBikes sample application, see Chapters 7 and 8.

Creating Web Services in J2EE

Implementing Web services in Java is currently not as straightforward as with Microsoft .NET Framework. At the time of this writing, the latest released version of the J2EE specification is version 1.3, and version 1.4 is currently in beta. In version 1.3 there is no native implementation of Web services. For example, there is no java.webservices package that you can import and use with the Java syntax.

However, there is considerable drive within the Java community to define and implement Web services. The Java Community Process defines the following Java Specification Requests (JSRs) that cover Web services:

• JSR 109 — Implementing Enterprise Web Services

• JSR 93 — Java API for XML Registries 1.0 (JAXR)

• JSR 67 — Java APIs for XML Messaging

• JSR 101 — Java APIs for XML based RPC

JSR 109 defines the Web services for J2EE architecture. It uses the J2EE component architecture to provide a familiar, portable, scalable and interoperable client and server programming model. JSR 109 builds upon JSR 67, JSR 93 and JSR 101.

Note

If a Java vendor’s Web services implementation complies with JSR-109, other JSR-109 compliant implementations should be able to interoperate with it.

JSR 93 defines how Java applications connect to XML registries, such as JNDI, ebXML and UDDI. This JSR provides mechanisms so that Web services can publish their interfaces and client applications can then discover these interfaces.

JSR 101 concentrates on XML RPC and the Java language. These include the following:

• Representing XML based interface definitions in Java.

• Defining interfaces with XML based interface definition languages such as SOAP.

• Implementing marshalling.

JSR 67 provides similar definitions for XML messaging.

Java Web Services Stacks

Currently, Web services support on the Java platform requires a Web services stack, of which there are several from which to choose. The most popular implementations are the following:

• Apache Axis is an open source implementation of Web services from the Apache Software Foundation.

• IBM has several Web service stacks available, such as WebSphere Application Server, Web Services Developer Kit (WSDK), and the Emerging Technologies Toolkit (ETTK). IBM also offers a UDDI Registry and Server product.

• WASP from Systinet provides a Web services stack for both C/C++ and Java Environments. Systinet also provide a separate UDDI Server.

• GLUE from The Mind Electric is a popular Web services stack. The Mind Electric (recently aquired by webMethods, Inc.) also provides a UDDI Server.

• WebLogic application server from BEA also has a Web service stack.

The decision on which Web stack you select is likely to reflect organizational preferences as well as technical requirements.

Creating a Web Service in Java

Creating a Web service in Java differs depending on which Web services stack you choose, and to some degree, which Java IDE you use. All vendors provide tutorials on how to build Web services in their documentation. However, the main steps for building a Web service are the same.

First, you need to identify which functionality you want to expose. With that information, you either need to create a new class exposing this functionality or identify an existing class that already does the job. Many Web service stacks allow you to expose an existing class or EJB as a Web service. From an architectural point of view, you should create a new class, even if it simply calls an existing one. This provides some protection against changes in the application.

After you decide the class you want to expose, you have to configure your Web service stack to expose this class. Most Java Web service implementations run as a servlet inside an application server.

Note

Some stacks, such as GLUE and WASP, provide their own container if an application server is not available.

You configure these servlets using various configuration files. To deploy a Web service, you need only modify these configuration files. Many vendors also supply a way of exposing Web services dynamically using an API, but this hard coding should be avoided.

For example, GLUE requires that you create an XML configuration file for your Web service. To expose this Web service, you just add your class to the configuration file. The GLUE servlet parses this file when it loads and creates the appropriate WSDL and schema documents based on the class.

For more information about how to create a Web service using GLUE, see the GLUE documentation. The XBikes sample application provides an example of implementing Web services for interoperability in Chapter 7, “Integrating .NET in the Presentation Tier.”

Consuming a Web Service in Java

Despite there being many different Java Web services vendors, consuming a Web service is a fairly simple task in nearly all vendor implementations. You can use a tool named WSDL2Java against a local or remote WSDL document, which then creates a Java proxy implementation. This is similar to the way in which .NET Framework consumes Web services, except the Java tools simply create an interface rather than an actual class. WSDL2Java usually creates a helper class, which creates an object based upon the URL endpoint. This object implements the interface that the WSDL2Java creates, which you can then use in your client application.

Chapters 7 and 8 provide examples of consuming a Web service on the Java platform.

Securing Web Services

Applications running in production environments usually require some form of authentication and authorization. This enables tracking of the users of a service and keeps their data separate from others.

The easiest way to implement authentication is to use the infrastructure built into HTTP to provide user names, passwords, and domains to the Web service. Web services published from .NET Framework can use HTTP authentication. Although this identifies a user, it is not secure, because HTTP packets are not safe from interception. Basic authentication sends user names and passwords in clear text, making it possible for an electronic eavesdropper to identify user names and passwords.

More advanced authentication methods such as Kerberos, NTLM, or Digest provide for encrypted authentication methods but these methods provide encryption for only the authentication process itself. Your Web service implementation may require a completely secure process with encryption applied to all client to server transactions. To do this, you have a choice of approaches:

• Transport level security.

• Application level security.

• Web Services Security (WS-Security).

Transport level security such as Secure Sockets Layer (SSL) encryption over HTTPS works at the protocol level and encrypts all the packets between the start point and endpoint of an individual Web service call. This works fine from the client (for example, an ASP.NET application in the Presentation tier) to a Web service in the Business tier. After the packets arrive at the Business tier, this is the SSL endpoint and the Business tier Web service decrypts the packets.

There is a problem when you want to keep the packets encrypted until they reach the Database tier, which stores the user names and passwords. Because SSL is a point to point encryption method, it is not suitable for keeping your data encrypted across multiple Web service calls in multi-tier environments.

Application level security involves developing some sort of custom security implementation. Although this technique can avoid the point to point issues with SSL by providing end to end encryption, it requires coding that would work only with clients that implement that custom security implementation. In Web services, this is counter to the idea of promoting accessibility.

The third option, WS-Security, provides application level security using a published specification. As long as the clients understand WS-Security, they can connect securely to the Web service.

WS-Security defines XML structures for security tokens, and clients use these security tokens as proof of identity. WS-Security tokens would typically include a user name, binary, and security token reference. WS-Security uses standard components, such as X.509 certificates, to endorse the identity of the client. WS-Security also provides encryption, either for the body of a SOAP message, the header, or both.

You control WS-Security settings through policy files, which are XML files with a .wsse file name extension. Implementing WS-Security involves creating the policy file and associating the file with your Web service. The Web service then checks both incoming and outgoing messages against the policy to ensure that they comply with the settings in force.

To access a secured Web service, you create a security policy file and associate it with the Web service control. The client policy settings must match those on the server.

Although the WS-Security standard is not fully ratified, a number of vendors have produced their own implementations, including the following:

• WSE (Web Services Enhancements) from Microsoft.

• IBM Web Services Toolkit from IBM.

• Weblogic Workshop from BEA Systems.

For more information about implementing WS-Security and WSE, see the References section at the end of this chapter.

Using Universal Description, Discovery, and Integration

UDDI is a standard specification for publishing and locating Web services. To implement UDDI, set up a UDDI server, and then register Web services URLs and descriptions with the service. You can think of UDDI as similar to Internet Locator Services (ILS), but dealing in Web services rather than people. Like ILS, UDDI servers can be public (a UDDI Business Registry or UBR), private (intranet based), or semi-private, for use between business partners. You can also compare UBR servers to telephone directories, with white pages listing businesses by name, yellow pages organizing them by function, and green pages describing the services they provide.

UDDI overcomes the issue that a simple URL is rarely very revealing. For example, it does not tell you very much about the service offering. Also, URLs have a habit of morphing into other URLs, preventing clients from connecting. UDDI uses a publish and subscribe model to enable consistency in connecting to Web services, independent of the vagaries of URL strings.

The UDDI directory database stores URLs or access points, associating them with the service offerings and the businesses involved. Business information can include contact details and the market sector in which the business operates, enabling flexible and efficient searches.

Major IT vendors such as Microsoft, IBM, SAP, Veritas, and NTT UDDI are part of the UDDI initiative, which is now at release 3.0. These five vendors also maintain the public UBR registries. For more information about UDDI, including details on white papers and best practices, see the UDDI Web site (http://www.uddi.org/).

Interoperability Benefits Using UDDI

UDDI provides major benefits for interoperability projects that involve Web services. Any Java or .NET Framework client that needs to make dynamic lookups for service offerings can make good use of UDDI. Other benefits include the following:

• Common Web service publication — UDDI provides a platform-independent view of Web services.

• Dynamic configuration — Any client application can use UDDI to configure a Web service proxy dynamically, removing the need for a hard coded URL. Additionally, dynamic rebinding allows multiple URL instances for a Web service. Similar to round-robin DNS, if one link fails to respond, applications can request another service instance from the same provider through UDDI.

• Web service re-use — Large organizations may have multiple departments working on development projects, often resulting in duplicated Web service offerings. UDDI lets development teams browse through a list of already published Web services, preventing departments from wasting time and money on providing a service that is already available.

• Location specific Web services — Improves performance and reduces network traffic by allocating a location to a Web service, enabling clients to bind to the closest service instance.

UDDI Registries

The central component of UDDI is the registry, which enables organizations to publish location information on available services. However, you do not have produce Web services for public consumption to benefit from UDDI.

Note

Microsoft, IBM, and SAP host test public registries that allow developers to test registration and publication processes.

Several vendors have implemented UDDI services on the latest operating systems:

• Microsoft includes UDDI as a core service in Windows 2003

• IBM have added a UDDI registry to WebSphere

• The Mind Electric package a UDDI server with GLUE

  Note

  If implementing UDDI internally, check for support of the 3.0 standard.

UDDI promises to be a major growth area in the future and offers significant benefits when implementing Web services. This next section considers a number of best practice recommendations to assist Web services and interoperability.

Implementing Web Services Interoperability Best Practices

Web services is still an emerging technology. The protocol specifications that Web services are based on are not yet officially ratified standards, so different vendors’ implementations may not be interoperable with each other. The WS-I Basic Profile should help improve Web services interoperability in the future. However, to give yourself the best chance of implementing Web services when interoperating between .NET Framework and Java, follow these best practice guidelines:

• Define data types first — If you plan to use complex data types over Web services, design your data types from a common XML schema using some of the strategies outlined in Chapter 3, “Interoperability Fundamentals.”

• Test your data types — Before you start to code your main application, use test applications that simply pass your data types back and forth in a proof of concept pilot that show your interoperability solution working.

• Use simple data types whenever possible — If you can implement a simpler data type, do so. Implement complex data types only for sound business reasons, rather than because you enjoy the challenge.

• Base all data types on XSD data types — This is especially important if you implement complex data types. As described in Chapter 3, “Interoperability Fundamentals,” this ensures that the data types in your complex data objects map to types in .NET Framework and Java.

• Store all data types centrally — Separating out the data types from the proxy file and storing them in a separate location is particularly useful when the .NET and Java assemblies require a single XML namespace for all types.

• Comply with WS-I Basic Profile 1.0 — This is an overriding factor if making your service publicly available. Make sure you keep up to date with revisions and new releases of the WS-I profile.

• Standardize on document/literal style rather than combinations involving SOAP or RPC encoding — Implementing SOAP encoding prevents validation against a schema and RPC encoding tends to be tightly coupled into the service and interface-driven.

  Note

  WS-I Basic Profile 1.0 actively promotes document/literal style.

• Use the latest Java Web services distribution — In the fast-moving world of Java distributions and associated tools, using the most recent distribution keeps you working with the latest specifications, improves reliability, and provides consistent interoperability.

• Use UDDI to discover Web services — UDDI is a powerful and effective way of discovering Web services either within an organization or as part of a public service offering.

• Apply abstraction through Interoperability Adapter/Service Interface patterns — This lets you add functionality to a Web service call without modifying the caller logic. The abstraction layer might be between the business logic and the ASP.NET Presentation tier making the call. Implementing an Interoperability Adapter/Service Interface pattern keeps the ASP.NET code clean of additional overhead, such as working out a URL from the UDDI registry. For more information about Interoperability Adapter/Service Interface patterns and example implementations, see Chapter 6, “Implementing Interoperability Design Elements.”

As with all best practice recommendations, there may be occasions when you need to implement a different solution. However, keeping to these guidelines should assist you to enable your applications to work together with the minimum of fuss.

Comparing .NET Remoting to Web Services

.NET Remoting with runtime bridges and Web services provide different approaches to application platform interoperability that provide flexibility in specifying the communication method between application components. Although sharing some similarities, .NET Remoting and Web services differ in a number of details. Table 4.4 summarizes the similarities and differences.

Table 4.4: Feature comparison between .NET Remoting and Web services

Feature	.NET Remoting	Web services
HTTP Channel
SOAP over HTTP
TCP Channel
XML Formatter
Binary Formatter
Pass by Value
Pass by Reference		Difficult to implement
Storing Session State	Easy	More complicated
Invoke single method on a stateless object
Invoke multiple methods on a stateful object
All clients can invoke methods on same server side object
Traverse Firewalls
Use IIS as host
Use custom host
Retrieve complete copy of complex object

Because there is considerable industry momentum behind Web services at present, you might be inclined to implement Web services as a matter of course. However, Table 4.4 shows that there are several areas where .NET Remoting shows notable advantages.

Because .NET Remoting incorporates a TCP channel, this removes the need for HTML headers. Combining this with a binary formatter usually provides a significant performance boost for large traffic volumes.

Implementing pass by value and pass by reference are possible for both methods, but they are significantly more difficult to implement in Web services. Also, session state management in .NET Remoting is less complicated than with Web services.

Other advantages of .NET Remoting over Web services include the following:

• Guaranteed interoperability.

• Support for client activation and lifetime control of remote objects (similar to DCOM).

• Support for callbacks and events.

• Support for additional context information specific to .NET Framework. In the future, such information will enable additional features such as distributed transactions and additional security levels.

• Support for type system fidelity, which means that there is a one-to-one mapping between the class and type hierarchy. Web services and SOAP do not support such an object-oriented mechanism for accessing remote objects.

Implement .NET Remoting within a tightly coupled intranet environment where you expect high transaction volumes and you control both sides of the communication. Use Web services for more loosely coupled systems, particularly those connecting across the Internet, or where you do not have control of both ends of the conversation.

Web services have advantages over .NET Remoting, mainly in the following areas:

• Platform independence — Web services use open and ubiquitous standards such as XML, SOAP, HTTP, and WSDL. Consequently, Web services offer genuine platform independence; you can invoke a Web service from any client platform, irrespective of the server platform or implementation technology of the Web service.

• Security — IIS is the standard host of choice for ASP.NET components, so Web services applications created using ASP.NET can automatically take advantage of the security features in IIS, such as support for Windows authentication, Secure Sockets Layer (SSL) encryption and logging. You can use IIS to host .NET Remoting components, in which case they can make use of the same security mechanisms. However, if you do not host your .NET Remoting components in IIS, you must implement authentication, authorization, and privacy mechanisms yourself.

• Caching — Hosting ASP.NET components in IIS also adds IIS caching support for Web services. Effective caching can significantly reduce the performance advantages of .NET Remoting, depending on the type of data that you want to cache. Caching is most effective for repeatedly requested public data, and decreases in effectiveness when caching private data or with dynamic data. .NET Remoting has no built in support for caching, even when IIS hosts the remoting components. Hence, like security, you have to build caching support manually.

• Ease of creation — Visual Studio .NET makes it easy to create and consume Web services. To create a Web service, create an ASP.NET Web service project and implement methods decorated with the [WebMethod] attribute. To consume a Web service, create any kind of project in Visual Studio .NET and add a Web reference to a Web service of your choice; Visual Studio .NET generates a client side proxy that simplifies access to the Web service.

If these factors are important to you, Web services might be a better choice than .NET Remoting to achieve point-to-point interoperability.