An Overview of Web Services

I l @ ve RuBoard

Before we look at how to build and use Web services with Microsoft Visual J# .NET, let's briefly examine the technologies and principles that Web services are built on.

What Is a Web Service?

Generally speaking, the term Web service can have one of two related but distinct definitions:

• A set of standards and technologies that simplify integration of applications within and between organizations.

• The application of these standards and technologies to create a dynamic, online environment in which services can be discovered when they are required.

Much of the hype surrounding Web services is about the latter definition ”the grand vision of Web services. For example, suppose your car's computer system detects that the engine needs its 12,000-mile service and then looks up the nearest car dealerships in some form of online registry. The car's computer can then use Web services to contact these dealerships, get the most competitive quote, determine the available time slots, and then give you this information. If you accept a quote and agree to get your car serviced, the car's onboard computer can then book you some movie tickets, through the Web services offered by the nearest theater, so you can watch a film while you wait for the car to be serviced. All of this can happen without human intervention (although you do have to watch the film yourself ”you can't get Web services to do that for you).

The standards and technologies underlying Web services make this scenario possible, but you'd need to sort out many technical and business issues before this sort of interaction would be practical. As you'll see, even though Web services provide a useful integration mechanism, several key parts of the overall puzzle are missing, such as end-to-end security and transaction propagation. To address this, Microsoft and IBM have proposed a comprehensive architecture to enable the overall vision. This architecture, the GXA, will address such issues as security, transactions, value-added messaging, and business process flow.

While you're waiting for this brave new world of global Web services to emerge, you can use the Web service technologies available today to integrate existing applications. Web service interfaces are based on common standards, so you can integrate components with other Web service “based applications with far less effort than you would expend using many older mechanisms. This chapter and the next one will show you what you can do using the available Web service technologies delivered with Visual J# .NET.

Web Service Technologies

Chapter 1 provided a brief overview of Web services. Here, we'll take a whistle -stop tour of the technologies that underlie Web services.

HTTP

Most Web service traffic is propagated by the standard Web transport protocol Hypertext Transfer Protocol (HTTP). The advantage of using a common Web protocol such as HTTP is that it is already widely used. HTTP is often called "firewall friendly" because most firewalls will let HTTP pass through, although some will limit it to common HTTP ports such as 80, 8080, and 443. This is a great boon for the adoption of Web services, although some security issues remain unresolved .

At the protocol level, HTTP is a request/response protocol that carries a byte-encoded payload. The most common type of data that HTTP carries is text, such as an HTML document. The rest of the HTTP message consists of a header that defines, among other things, the type of content carried in the rest of the message. When a client sends an HTTP message, it is delivered to the server (which is usually listening on port 80), which processes the message and sends back a response over the same channel.

XML

We discussed XML and many of its uses in Chapter 5 and Chapter 6. In terms of Web services, XML is used for encoding the payload of Web service messages. The SOAP protocol specification defines a schema for XML messages that contains parameters and return values for Web service calls. The XML Schema standard provides type information in Web service calls. It defines a set of common types, such as strings and integers, and offers the ability to define your own compound or complex types. You can use XML to describe the operations offered by a Web service along with the types and numbers of parameters and return values. Using XML means that such a description will be independent of any particular platform or language.

MIME

XML is used to encode Web service requests and responses, but not everything can be described easily by using XML. In some cases, you might want to send binary data as part of a message, and mapping this into and out of XML can be a major undertaking. (The message would end up being very large, too.) In these cases, you can use Multipurpose Internet Mail Extensions (MIME) to attach binary data to an XML-based SOAP message. This makes transmitting and processing the data a lot more efficient.

MIME originated as a way of transmitting multimedia e-mail messages. You can use it with any text-based protocol that has a header, such as HTTP. To use MIME, you split a document into parts, each with its own section header. The section header defines the type of content held in that section, and the overall message is defined as having a content type of multipart/mime .

SOAP

SOAP originated from an effort to provide a Web-friendly transport mechanism for object-based remote procedure calls (RPCs). SOAP defines an XML message structure for encoding calls and their responses. A SOAP message can then be sent across any protocol that can carry XML. The most common protocol used is HTTP, although you can use other protocols as needed, such as Simple Mail Transfer Protocol (SMTP) for connectionless message exchange. The SOAP protocol employs MIME to attach non-XML data to SOAP messages. (This is sometimes called SOAP with attachments ).

A SOAP message is contained in a SOAP envelope. The SOAP envelope contains a SOAP header and a SOAP body. The header contains metainformation for the message, and the body contains details of the operation to be performed. Figure 17-1 shows the format of a SOAP message. We'll look more closely at the contents of a SOAP message later in the chapter.

Figure 17-1. A SOAP message, which consists of a SOAP header, a SOAP body, and optionally some non-XML attachments

WSDL

Web Service Description Language (WSDL) provides an XML description of a Web service. Conceptually, WSDL is similar to the Interface Definition Languages (IDLs) used by COM and CORBA to define the methods , parameters, and return values of RPCs. However, WSDL can contain additional information relating to the location of the service.

A WSDL document consists of three basic parts:

• The definition of the interface, which comprises a list of messages that can be sent and the responses to be expected. Each message definition includes the number and types of the parameters and return values. These messages are grouped into portType elements, which define a logical grouping of operations. (An operation is based on a message.) A portType is similar to a COM or CORBA interface.

• Data type definitions. The XML Schema definition and the SOAP specification provide a set of standard data types, but you might need specific complex types to describe parameters passed by the Web service. We'll discuss these in more detail later in the chapter.

• Transport and endpoint information, including how to pass messages over a specific transport, such as SOAP. A port defines the location of a "live" service that implements the interface defined in a portType . A service is a group of ports that are offered as part of a logical service.

The specifics of WSDL documents are discussed later in the chapter.

UDDI

Once you've created your Web service, you have to figure out how potential users will locate it. If the number of users is limited, you can let them know the location of your service through e-mail or a similar mechanism and send them the WSDL description. However, this process is not scalable or feasible for a large number of users.

Universal Description, Discovery, and Integration (UDDI) defines a way of registering Web service information so that it can be dynamically discovered. UDDI provides a business-oriented registry and technical descriptions of the services (such as WSDL). A Web service user can look up services and their descriptions in a UDDI registry and use them to contact the Web service and make requests. Some public UDDI registries are accessible via the Internet, whereas internal UDDI registries can be run within organizations. UDDI is discussed in more detail in Chapter 18.

New Technologies in the GXA

As mentioned previously, solutions to some of the outstanding issues relating to Web services will be addressed in the GXA. Various proposals might form part of the GXA:

• Web Service Flow Language (WSFL) and XLANG

  These two proposals define a multiple message exchange between a client and a Web service.

• Web Service Inspection Language (WSIL)

  This proposal addresses the need to examine the Web service capabilities of a particular site. (This is covered in more detail in Chapter 18, which covers the DISCO discovery protocol.)

• Web Services Referral Protocol (WS-Referral)

  This is a simple SOAP-based protocol for configuring instructions about the routing of SOAP messages.

• Web Services Routing Protocol (WS-Routing)

  This is a simple, stateless, SOAP-based protocol for routing SOAP messages in an asynchronous manner over a variety of transports such as TCP, UDP, and HTTP.

• Web Services Security (WS-Security)

  This defines a set of security measures to provide end-to-end security for SOAP messages.

• XML Digital Signature

  This provides the ability to sign an XML document to authenticate its origin.

• XML Encryption

  This defines how an XML document should be encrypted and decrypted for end-to-end privacy.

For more details about the GXA and how it is evolving, see the protocol overview at http://www.msdn.microsoft.com/library/en-us/dnglobspec/html/wsspecsover.asp.

Web Services in .NET

Web services are a core part of the Microsoft .NET platform. You can deliver a Web service under the .NET platform in two ways:

• By creating a Web service based on ASP.NET. This Web service will live in a virtual directory under the control of Microsoft Internet Information Services (IIS). Visual Studio .NET allows you to create an ASP.NET Web service in all supported languages, including J#. The creation of Web service clients under Visual Studio .NET is covered in Chapter 18.

• By providing a .NET Remoting server that uses the HTTP transport and the XML serializer. Such a server can expose its methods as an XML Web service. The creation of this type of server was covered in Chapter 11. The creation of clients for this type of Web service is covered in Chapter 18.

As mentioned, Web services created under Visual Studio .NET can be written in any supported language and will run as managed code under the common language runtime. As such, they'll have access to all of the functionality in the .NET Framework Class Library. Specific classes for Web service creation are defined under the System.Web.Services namespace.

I l @ ve RuBoard