Understanding SOAP, WSDL, and UDDI and Their Place in WebLogic Workshop

Before you begin developing Web services, you should understand exactly what's going on behind the scenes with SOAP, WSDL, and UDDI.

SOAP

All Web services use SOAP v1.1, a lightweight XML-based protocol optimized for use in distributed environments. SOAP v1.1 is designed to provide the necessary infrastructure and definition to support XML-based Remote Procedure Calls.

SOAP v1.1 provides the following:

• An envelope for encapsulating a SOAP message ” This envelope might be an HTTP MIME-encoded message provided to WebLogic Server or another application server via HTTP, HTTPS, JMS, SMTP, FTP, or in some other way. A SOAP envelope typically wraps not only the method request, but also its parameters. An example might be a request to invoke a credit grant along with the user who should get the credit and the credit limit.

• A set of well-defined data and parameter encoding rules ” Because SOAP messages might be consumed by Web services written in any number of languages, a common set of data-encoding rules ”for example, specifying strings, integers, and the like ”is required. Using the same credit request example, the name might need to be provided as a string and the credit limit as an integer.

• A set of rules for describing methods ” As with data encoding, a predefined method interface is required to make sure that both the requester and the supplier of information understand and agree on what a call means. Examples of which could be the actual method name and argument list are described by the encoding rules.

WSDL

WSDL is the underpinning of how Web services are described to the outside world. Created by Microsoft and IBM in 2000, WSDL defines an XML grammar for describing network services and serves as a recipe for automating the details in application communication. Typically, WSDL describes a Web service's methods, inputs, and contact mechanism.

These are the most important aspects of WSDL:

• The methods provided by a Web service.

• The inputs, outputs, and faults (errors) the defined methods return.

• The mechanism used to contact the service.

Web services are defined in terms of the endpoint, or service, that actually acts on or processes the Web service's request. These endpoints represent the actual methods being implemented and how they can be called. In reality, there are only two mechanisms for communicating with a Web service: one-way and bidirectional, depending on who originated the message.

The WSDL specification defines four specific types of requests a Web service can support:

• One-way ” In a one-way message, a service receives a message and may or may not act on it. The client might get nothing back or might receive a result later in some unknown fashion.

• Request/response ” In a request/response message, the service receives a request, processes it, and returns a response.

• Solicit/response ” In a solicit/response message, the end point sends a message and receives a response.

• Notification ” In a notification message, the Web service sends a message.

In fact, the only difference between one-way versus notification messages and request/response versus solicit/response messages is who generates and sends the message. For example, in a one-way message, the client makes a request, and the Web service acts on it without returning a status. In a notification message, the Web service makes a call back to the client without waiting for a response.

As you shall see shortly, WebLogic Workshop provides mechanisms for quickly and easily developing Web services that support each request type.

Although understanding WSDL is important, what's most important is knowing how WebLogic Workshop can build controls to access external Web services based on WSDL and generate WSDL based on controls.

UDDI

UDDI provides a mechanism for Web services developers to publish new and updated Web services and a mechanism for clients to find and access published Web services. UDDI enables businesses to publish and advertise the services they offer and describe how these services should be used.

Web service functionality, as with most service-based functionality, is provided through a programming interface specified in WSDL. In a publish-and-find scenario, a developer publishes the existence of a service along with its definition, often referred to as a binding template . In a picture-printing service, for example, any number of companies could offer a service to print digital pictures. Binding templates contain one or more instances of a tModel , which represents interfaces supported by the service. The tModel might have been uniquely published by the service provider, with information on the interfaces and URL references to the WSDL document.

At a minimum, a Web service must publish its business name and service information via business registry entries. A business registry can contain the following:

• Business identification ” Name, description of the business, contact information, and other descriptive information.

• Categories ” Standard categorization information, such as Dun & Bradstreet's Data Universal Numbering System (DUNS) numbers .

• Service description ” Names and descriptions of the service given in the binding template and custom category definitions given in the tModels, which contain binding information for accessing the service at runtime to determine who actually implements a service.

UDDI also supports a wide variety of other information about the service, such as compliance with a set of existing standards, usage details, transaction capabilities, and so forth.

WEBLOGIC SERVER 8.1 UDDI SERVER

WebLogic Server provides an embedded UDDI server that's fully compliant with UDDI v2.0. Using the server is a simple matter of editing the uddi.properties file and restarting WebLogic Server. For complete documentation on the UDDI server, see http://e-docs.bea.com/wls/docs81/webserv/uddi.html.