| Sign In/My Account | View Cart |
Java and Web Services Primer
Pages: 1, 2
<?xml version="1.0"?>
<definitions name="StockQuote"
targetNamespace="http://example.com/stockquote.wsdl"
xmlns:tns="http://example.com/stockquote.wsdl"
xmlns:xsd1="http://example.com/stockquote.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<schema targetNamespace="http://example.com/stockquote.xsd"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>
<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>
<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePrice"/>
</message>
<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
</portType>
<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
<soap:operation soapAction="http://example.com/GetLastTradePrice"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteBinding">
<soap:address location="http://example.com/stockquote"/>
</port>
</service>
</definitions>
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.
|
Related Reading
|
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:
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.
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.
POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "http://example.org/2001/06/quotes"
<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope" >
<env:Body>
<m:GetLastTradePrice
env:encodingStyle="http://www.w3.org/2001/06/soap-encoding"
xmlns:m="http://example.org/2001/06/quotes">
<symbol>DIS</symbol>
</m:GetLastTradePrice>
</env:Body>
</env: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.
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.