Java and Web Services Primer
Pages: 1, 2
A WSDL Example
<element name="tickerSymbol" type="string"/>
<element name="price" type="float"/>
<part name="body" element="xsd1:TradePriceRequest"/>
<part name="body" element="xsd1:TradePrice"/>
<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteBinding">
We now know how to pass data, and how to define interfaces, but we've neglected the client and how it finds and binds to a service. Enter UDDI and ebXML.
Universal Discovery and Description Integration (UDDI)
In order to actually use a service, a client must first find that service, retrieve information about how to use the service, and understand who might provide the service. The Universal Discover and Description and Integration specification, or UDDI, defines a number of lookup services aimed at allowing clients to look up and retrieve the required information to access a Web Service.
UDDI actually provides three specific services:
- Traditional White Pages for looking up a Web Service by name.
- Traditional Yellow Pages for looking up a Web Service by topic.
- Green Pages for more generic searches based on the characteristics of a Web Service.
Vendors who provide UDDI services typically operate a service known as a UDDI Business Registry, or UBR, which can be accessed to both publish and request information about a given Web Service.
Connecting It All Together With the Simple Object Access Protocol
We now understand three things: how a Web Service is defined, and where it can be published and accessed. But we've left out one crucial aspect of the puzzle: how do we actually access the service once we've found it? Web Services become accessible using a protocol known as the Simple Object Access Protocol, or SOAP. In fact, you normally access a UDDI registry using well-defined SOAP calls! But what is SOAP? SOAP, at its simplest, is a protocol for encapsulating a request as an XML payload using standard communications protocols such as HTTP. The power of SOAP comes from the fact that is simple, easy to implement, and well supported in the industry.
Typically, a SOAP call is packaged as the body of an HTTP request. The listing below, from the W3C SOAP specification, shows an example of a SOAP call to access a service known as
GetLastTradePrice as an HTTP server might receive it.
A SOAP Example
POST /StockQuote HTTP/1.1
Content-Type: text/xml; charset="utf-8"
<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope" >
SOAP supports both synchronous and asynchronous call semantics; that is, standard RPC as well as message-based, and can be used with a variety of protocols other than HTTP.
ConclusionsIn this article, we examined the basic concepts behind Web Services. We looked at past Distributed Computer Environments and examined how Web Services takes these types of services to a new level. The Web Service of today is still in its infancy. Web Services using UDDI and SOAP provide simple, straightforward mechanisms for accessing distributed services.
The first practical Web Services will be one-to-one, client/service provider-style interactions. The Web Services of tomorrow will be complete mutli-participant systems requiring security, transactions supporting very complex interactions. In our next article we will example the various Java APIs for using Web Services in a J2EE-compliant application server and begin developing our own custom Web services.
Al Saganich is BEA Systems' senior developer and engineer for enterprise Java technologies, focused on Java integration and application with XML and Web services.
Return to ONJava.com.