What Is an XML Web Service? | Microsoft .NET and J2EE Interoperability Toolkit (Pro-Developer)

Component-based programming is a widely accepted practice used to help develop distributed systems. As these systems become more complex, distributing an application across a number of remote machines becomes an attractive option. During the past few years , a number of technologies have emerged to help build these types of distributed systems within the enterprise:

Distributed Component Object Model (DCOM) Microsoft's approach to allow components written to the COM specification to be distributed and called on remote machines.
Common Object Request Broker Architecture (CORBA) A specification released by the Object Management Group (OMG) to unify distributed system technology across a number of vendors .
Java Remote Method Invocation (RMI) Formed part of the Java v1.1.x core specification. Allows components written in Java to be distributed to remote machines and processes.

The release of these standards allowed a large number of enterprises to benefit from developing distributed applications that spanned many processes, machines, and servers. But in general, the concept of distributed computing rarely left the data center ”and if it did, it tended to stay within the boundaries of the organization as a whole.

A large portion of this was due to the technology itself. Early releases of the technology didn't lend themselves well to working with multiple organizations across the Internet. This was largely due to the ports and protocols to which these organizations were bound. As organizations joined the race to get online and security became a more controlled issue, many developers and architects found themselves restricted to using only ports 80 and 443 ”the ports for HTTP and HTTPS, respectively. Existing applications that used distributed components and were destined to reside in the perimeter network (also known as DMZ, demilitarized zone, and screened subnet) of an extranet were difficult to deploy and maintain or were generally unstable.

Microsoft and Sun Microsystems made attempts at fixing some of these problems by releasing versions of their respective component technologies that passed only HTTP requests and responses across the wire. Microsoft released COM Internet Services (CIS), which tunneled an existing DCOM solution across port 80. The Java specification grew to include RMI over Internet Inter- Orb Protocol (IIOP) to tie in the RMI specification with CORBA. Unfortunately, for various reasons, neither platform fully convinced enterprise architects to run a distributed architecture across the Internet.

Given the history of the products that were already available, Web services were not a new, groundbreaking concept. The introduction and formalization of Web services had more to do with applying the existing technologies and lessons learned to a set of new standards.

To be accepted, Web services must address these three key issues:

Internet standards The lowest common denominator for intercommunication with most organizations is HTTP and HTTPS. This is mainly because of firewall restrictions that have been applied and the fact that these protocols tend to be used to promote an organization through a Web site. HTTP and HTTPS must be the initial underlying protocols for Web services to succeed, but the technology should be flexible enough to allow any transport protocol to be used.
Type definitions Data types that were exposed by Web services must use strongly typed XML. A type that's exposed by using one Web service must be understood and consumed regardless of the underlying language or platform.
Multiple language, platform, and vendor support Web services must not be tied to a particular platform, language, or vendor. This is necessary to allow one consumer of Web services to work on a different platform and in a different language from another Web services consumer.

So, that's a little history, but you're probably still wondering what makes up a Web service. In other words, how can you define a Web service based on the technology that it uses? Five components make up the definition of a Web service, as shown in Figure 5.1.

Figure 5.1: The five components of a Web service.

Let's examine these components:

Transport (HTTP) For any distributed component architecture to work, the two machines (sender and receiver) must agree on a transport. As mentioned previously, in many organizations, HTTP tends to be a standard that's widely accepted as a gateway through the firewall. However, this doesn't mean that Web services are tied to HTTP. Web services can potentially run on Simple Mail Transfer Protocol (SMTP), Sequenced Packet Exchange (SPX), NetBIOS Extended User Interface (NetBEUI), and even a custom sockets implementation if needed. For now, the generally accepted transport is HTTP (with HTTPS for secure connections), but the transport protocol independence of the Web service specifications means that the dominance of HTTP could change sometime in the future without requiring a rewrite of the specification.
Encoding (XML) Regardless of the transport used to carry it, the message must be correctly formatted as a valid XML document. We touched on this a little in Chapter 3, where XML was used in a number of ways to exchange data between .NET and Java. The result was that both platforms knew how to parse and interpret the XML standard. The same is true of using Web services.
Standard Structure (SOAP) XML defines how the message is encoded but doesn't dictate the structure or format of the document. With XML, you're free to choose your own element and attribute names , types, and labels, but for true interoperability, both platforms need to know what to send and what to expect. SOAP is a three-part definition that specifies an XML structure for the framework of a message (known as a SOAP envelope ), the data types that are defined, and a convention for representing RPCs and the data returned from them (all of which are placed in a SOAP body).
Description (WSDL) Suppose you create a component for a distributed architecture. So far, we know that XML and SOAP can be used to correctly construct a message that can be understood by different platforms. However, we lack a way to describe which services exist (can be consumed) on the remote system. You need a contract or complete description that says these are the components being exposed and gives the names, data types (using XML Schema Definition), methods , and parameters required to call them. This contract is known as a Web Services Description Language (WSDL) document and is normally one of the first points of contact to determine how a Web service will be called.
Discovery (UDDI) This is the last of the five pieces of the Web services puzzle. The first four pieces enable you to create self- described services using SOAP and XML over an agreed-upon transport, but the invocation of these services still requires you to know the exact location, or URL. For example, suppose you know that a remote system exposes a Web service. To call that Web service, you'd use the exact URL (such as http://server1/services/WebService1.asmx ). But how do you get that URL? Just as the phone book uses telephone numbers , we need a way of associating something a little more descriptive with the previous URL ”for example, the name Woodgrove's Stock Quote Web service. Universal Description, Discovery, and Integration (UDDI) provides us this functionality. Again, by using an agreed-upon message format, you can issue requests to a UDDI server to locate the exact URL for a published Web service.

Now that I've given you the basics of Web services ”and possibly a refresher in some terminology that you already might have known ”let's dive deeper into the topic of interoperability using Web services.

More Info

For further reading on what Web services are comprised of, see Scott Short's book, Building XML Web Services for the Microsoft .NET Platform (Microsoft Press, 2002).

The Web Services Landscape

Before you see some samples, I want to describe today's Web services landscape (actually, the landscape in existence at the time of this writing). This should highlight the organizations that are helping to develop and promote Web services as a standard. This description isn't meant to be a comparison of vendors ”the frequency with which new product releases reach the market often means that the information becomes quickly out of date. Instead, use the list to gain an understanding of the commitment many vendors have to Web services technology as a whole.

Microsoft Microsoft's public embracement of Web services coincided with the release of .NET. The main integration of Web services can be found in the Microsoft .NET Framework, designer support in Microsoft Visual Studio .NET, server support in a number of .NET server products, and additional support in desktop applications such as Microsoft Office XP. In December 2002, Microsoft released version 1.0 of Microsoft Web Services Enhancements (WSE), which includes support for a number of the latest Web services specifications. (We'll cover these specifications in Part IV of the book, "Advanced Interoperability.") UDDI services can be found as an integral part of Microsoft Windows Server 2003.
Apache The Apache Software Foundation provides support for a community of open -source projects, the majority of which are written in Java. These have included Tomcat and Struts. Within the Apache Web Services Project, Axis (the successor to Apache SOAP) can be used as a framework to build Web services.
IBM IBM was one of the first organizations to wrap a number of value-added services around the Apache Axis implementation. Its offering, IBM Web Services Toolkit (WSTK) provides support for creating Web services for Apache Tomcat and IBM WebSphere server products. In addition, IBM also has its own public UDDI registry and server product.
The Mind Electric (TME) TME has a vendor-neutral approach to delivering Web services for the Java platform. TME's Web services product, GLUE, allows the creation and hosting of Web services either through a standalone hosting environment or by creating a deployment compatible with most Java 2 Enterprise Edition (J2EE) application servers. TME also packages a UDDI server with its offering.
Systinet Systinet WASP is another good example of a third-party Web services toolkit that provides support for both C/C++ and Java environments. As with GLUE, WASP includes a number of add-ins to compliment and extend existing integrated development environments ( IDEs ). Systinet also offers a UDDI server.

In addition to these toolkits, a number of J2EE application server vendors are integrating Web services into their platform. An extensive list of J2EE application servers, with appropriate links for more information, can be found at http://www.theserverside.com/reviews/matrix.jsp .

Web Services and the J2EE Specification

You might be wondering whether and how Web services are used within the J2EE specification. An API for Web services doesn't exist within the J2EE 1.3 specification. As a result, there currently is no javax. webservices package that can be imported and used as part of the Java syntax language.

At the time of this writing, however, support does exist for a number of underlying APIs used to create Web services on the Java platform, known as the Java APIs for XML (JAX) pack. This pack, in turn , is used by a number of vendors for their toolkits. Chapter 3 already mentioned one of the APIs: Java Architecture for XML Binding (JAXB). Here's a list of the JAX pack members :

Java API for XML Processing (JAXP) Contains implementations of Document Object Model (DOM), Simple API for XML (SAX), and XML Stylesheet Language Transformations (XLST) for manipulating and working with XML documents.
Java API for XML Binding (JAXB) Binds an XML document to an object graph. This is based on the same serialization principles covered in Chapter 3.
Java API for XML Registries (JAXR) Abstracts a number of registries, namely UDDI and Electronic Business XML (ebXML), that can contain descriptions for Web services.
Java API for XML Messaging (JAXM) Specifies an abstraction of the SOAP message infrastructure.
Java API for XML-based RPC (JAX-RPC) This specification is similar to JAXM but focuses on RPC-style calls, whereas JAXM is intended for both RPC-style and document-style formatting.

The JAX pack provides the underpinnings of Web services for the Java platform but can be lacking in the level of its implementation. To help address this, in February 2003, Sun Microsystems announced that the next version of the J2EE specification (v1.4, due for release in the summer of 2003) will fully support Basic Profile 1.0, one of the first guidelines released from a body named the Web Services Interoperability Organization (WS-I).

The Web Services Interoperability Organization (WS-I)

With so many vendors committed to and enthused by Web services technology, some direction is needed to ensure interoperability between all the flavors and standards of Web services. The Web Services Interoperability Organization ( http://www.ws-i.org ) is an open-industry effort to drive Web services interoperability across platforms, toolkits, applications, and vendors. The community that makes up WS-I today comprises approximately 170 vendors (including Microsoft, Sun, and IBM), systems integrators, enterprise customers, and others with a sincere interest in ensuring that Web services remain interoperable.

Deliverables

The organization's charter is to target developers to ensure that Web services and the underlying protocols conform to a published and agreed-upon set of standards and guidelines. To enable this, WS-I is tasked with providing the following:

Profiles Sets of specifications that define technology standards.
Samples Sets of samples to show interoperability concepts and demonstrate the features of the profiles.
Implementation guidelines Show a best-practices approach to design solutions that require interoperability with Web services.
Tools A sniffer and analyzer to monitor and log interactions with Web services, including identifying errors and warnings for implementations that do not meet the profiles guidelines.

Basic Profile 1.0

One of the first deliverables from the WS-I was the Basic Profile version 1.0, which is published via the WS-I Web site. A profile is a named group of version- specific Web services specifications. Basic Profile 1.0 outlines recommendations for how these Web services specifications should be used together to achieve consistency within each implementation and, therefore, to promote interoperability. The four building blocks that make up the Basic Profile are messaging, description, discovery, and security. This covers XML 1.0, XSD 1.0, SOAP 1.1, WSDL 1.1, UDDI 2.0, and the use of HTTP and HTTPS.

Do We Need Another .org?

One of the important things to recognize with the WS-I is the strong relationship it has with the Organization for the Advancement of Structured Information Standards (OASIS) and other standards organizations. As proof of this, each of the four specifications that make up the Basic Profile come from and are controlled by other organizations. This demonstrates that the role of the WS-I isn't to serve as just another governing standards body but to embrace the relationships and ensure consistency among other organizations.

Joining the WS-I

WS-I membership is open to any individual or business that wants to make a contribution in supporting Web services interoperability. To join the organization, you must pay an annual fee and participate in a number of working groups. Membership checklists and instructions can be found on the WS-I Web site.

Web Services Toolkit Selection

In the samples in this chapter and throughout the rest of the book, we'll use GLUE 4.0.1 Professional from The Mind Electric. GLUE is based on the standards and specifications of the WS-I Basic Profile.

Given the current plans for J2EE v1.4 and the contents of a number of books on the topic, you might be wondering why I chose to use GLUE for the book's samples instead of relying on the existing Java Specification Requests (JSRs), JAX packs , and draft. The reasons are fourfold:

This book's aim is to demonstrate how to use Web services to achieve interoperability between .NET and Java ”not how to build Web services for either .NET or J2EE. That said, GLUE delivers an implementation of Web services for the Java platform without the necessity of explaining the underlying required APIs. Because GLUE is based on the WS-I Basic Profile, it should align well when implementations of J2EE v1.4 are available.
Both the Electric XML and GLUE libraries are vendor neutral. The samples in this book should work on any J2EE application server, regardless of the vendor. Because I cannot predict which application server each reader will use, I thought it important to create code samples that could be run by anyone .
The XML formatting, Schema, and serialization implementations used by GLUE for Web services are provided by the same libraries as the XML classes that are discussed in Chapter 3. Thus, there will be parity between the .NET and Java implementations.
The Mind Electric was one of the first adopters of the latest Web services specifications, adopting these specifications as part of their toolkit offerings. This is important in the context of this book because in Part IV, "Advanced Interoperability," you'll see actual implementations of these specifications in the samples.

Configuring GLUE

GLUE is installed in the C:\Interoperability\Tools\Glue directory as part of the samples installation. This directory contains a full implementation of GLUE 4.0 Professional, including required libraries, binaries, and documentation.

Configuration of GLUE is performed by using a config.xml file. The location of this file is determined as follows :

If the electric.config environment variable is set, the configuration file is loaded from the specified path .
If this environment variable is not set, the CLASSPATH is searched for a suitable config.xml file that can be used.
If no config.xml file is found, the default-config.xml file (which is included as part of the glue-all.jar file) is used.

Most of the samples in this chapter and Chapter 6 apply configuration settings in GLUE by using statements within the code. This allows you to see what settings are required for a new installation of the product. In a production environment, it's recommended that you apply configuration settings by using an XML file as described earlier. You saw an example of this in the "Generating an XSD from an Existing Class in Java" section in Chapter 3.