SASANK@TECHNOMANIA

following content is a tutorial from service-architecture.com

Using the Web Services Description Language (WSDL)

The Web Services Description Language (WSDL) forms the basis for Web Services. The following figure illustrates the use of WSDL. At the left is a service provider. At the right is a service consumer. The steps involved in providing and consuming a service are:

1. A service provider describes its service using WSDL. This definition is published to a directory of services. The directory could use Universal Description, Discovery, and Integration (UDDI). Other forms of directories can also be used.
2. A service consumer issues one or more queries to the directory to locate a service and determine how to communicate with that service.
3. Part of the WSDL provided by the service provider is passed to the service consumer. This tells the service consumer what the requests and responses are for the service provider.
4. The service consumer uses the WSDL to send a request to the service provider.
5. The service provider provides the expected response to the service consumer.

More on Web Services Description Language (new window).

Using Universal Description, Discovery, and Integration (UDDI)

The directory shown in the above figure could be a UDDI registry. The UDDI registry is intended to eventually serve as a means of "discovering" Web Services described using WSDL . The idea is that the UDDI registry can be searched in various ways to obtain contact information and the Web Services available for various organizations. How much "discovery" will be used in the early days of Web Services is open to discussion. Nevertheless, even without the discovery portion, the UDDI registry is a way to keep up-to-date on the Web Services your organization currently uses. More on Universal Description, Discovery, and Integration (new window). An alternative to UDDI is the ebXML Registry (new window).

Using SOAP

All the messages shown in the above figure are sent using SOAP. (SOAP at one time stood for Simple Object Access Protocol. Now, the letters in the acronym have no particular meaning .) SOAP essentially provides the envelope for sending the Web Services messages. SOAP generally uses HTTP , but other means of connection may be used. HTTP is the familiar connection we all use for the Internet. In fact, it is the pervasiveness of HTTP connections that will help drive the adoption of Web Services. More on SOAP and Messaging (new window).

The next figure provides more detail on the messages sent using Web Services. At the left of the figure is a fragment of the WSDL sent to the directory. It shows a CustomerInfoRequest that requires the customer's account to object information. Also shown is the CustomerInfoResponse that provides a series of items on customer including name, phone, and address items.

At the right of this figure is a fragment of the WSDL being sent to the service consumer. This is the same fragment sent to the directory by the service provider. The service consumer uses this WSDL to create the service request shown above the arrow connecting the service consumer to the service provider. Upon receiving the request, the service provider returns a message using the format described in the original WSDL. That message appears at the bottom of the figure.

Using XML with WSDL

WSDL uses XML to define messages. XML has a tagged message format. This is shown in the above figure. The tag has the value of Burnsville. And is the ending tag indicating the end of the value of city. Both the service provider and service consumer use these tags. In fact, the service provider could send the data shown at the bottom of this figure in any order. The service consumer uses the tags and not the order of the data to get the data values. More on the use of XML tags and a comparison of XML to using fixed record formats can be found in chapter 3 of Web Services and Service-Oriented Architectures: The Savvy Manager's Guide.

Simplified Web Services notation

For other figures on this site, a simplified notation will be used for Web Services. This is shown below. In the simplified notation, the directory is implicit in the wide rectangle labeled "Web Services" at the top of this figure. You could think of Web Services much like the bus in a PC in which you plug various circuit boards. Other middleware solutions appear similar and use the same "bus" concept. See Prior Service-Oriented Architecture specifications (new window).

Another important concept in service-oriented architectures is that any service provider could also be a service consumer. This is why the figure below shows only services at the bottom of the figure under the Web Services bus rather than a "service provider" and a "service consumer".

At the heart of Web services today are SOAP and WSDL, so it’s important that you have a good understanding of them and how they’re used. That said, memorizing the details of SOAP and WSDL is not critical. While these technologies are central to Web services, in many cases you may not deal with them directly, as they will be hidden in the communication and deployment layer of the J2EE Web Services platform.

SOAP

SOAP was originally an acronym for Simple Object Access Protocol. (Now it’s just a name.) SOAP 1.1 is the standard messaging protocol used by J2EE Web Services, and is the de facto standard for Web services in general. SOAP’s primary application is Application-to-Application (A2A) communication. Specifically, it’s used in Business- to-Business (B2B) and Enterprise Application Integration (EAI).

Despite all the hoopla, however, SOAP is just another XML markup language
accompanied by rules that dictate its use. SOAP has a clear purpose: exchanging
data over networks. Specifically, it concerns itself with encapsulating and encoding
XML data and defining the rules for transmitting and receiving that data. In a
nutshell, SOAP is a network application protocol.

A SOAP XML document instance, which is called a SOAP message,1 is usually
carried as the payload of some other network protocol. For example, the most
common way to exchange SOAP messages is via HTTP (HyperText Transfer Protocol),
used by Web browsers to access HTML Web pages. The big difference is that
you don’t view SOAP messages with a browser as you do HTML. SOAP messages
are exchanged between applications on a network and are not meant for human consumption. HTTP is just a convenient way of sending and receiving SOAP
messages.


The Basic Structure of SOAP

As you now know, a SOAP message is a kind of XML document. SOAP has its own
XML schema, namespaces, and processing rules. This section focuses on the structure
of SOAP messages and the rules for creating and processing them.

A SOAP Message That Contains an Instance of Purchase Order Markup

Amazon.com
923

AMAZON.COM
1850 Mercer Drive
Lexington
KY
40511


J2EE Web Services
300
24.99

This message is an example of a SOAP message that contains an arbitrary XML
element, the purchaseOrder element. In this case, the SOAP message will be One-
Way; it will be sent from the initial sender to the ultimate receiver with no expecta-
tion of a reply. Monson-Haefel Books’ retail customers will use this SOAP message
to submit a purchase order, a request for a shipment of books. In this example,
Amazon.com is ordering 300 copies of this book for sale on its Web site.


The Structure of a SOAP Message

SOAP Namespaces

XML namespaces play an important role in SOAP messages. A SOAP message may
include several different XML elements in the Header and Body elements, and to
avoid name collisions each of these elements should be identified by a unique name-
space. For example, a SOAP message that contains the purchaseOrder element as
well as message-id and XML digital-signature header blocks would include no
fewer than six different namespaces

11d1def534ea:b1c5fa:f3bfb4dcd7:-8000

…




…