Two Types of Web service
--->
Servlet
-->Apache Axis
-->Web service Development Package(j2ee server)
--->
Ejb
-->Ejb 1.0(not Support Web service)
-->Ejb 1.2(not Support Web service)
-->Ejb 2.0(not Support Web service)
-->Ejb 2.1(Web service Support)
WSDL
Web Services Description Language (WSDL) i
s an XML grammar that defines the functionality
offered by a Web service and the format of
messages sent and received by the Web service.
A Web service's WSDL document defines what services are available in the Web service.
The
Web Services Description Language is an
XML-based language that provides a model for describing
Web services.
Wsdl
--->Type
--->Message Type
--->Port Type
--->Binding Info
--->SOAP
--->SOAP TYPE
Style | Usage
--->RPC
---> literal
---> Encoding
--->Document
---> literal
---> Encoding
---->Service
RPC vs. Document type (or "style") is actually only 1 of 2 factors that
one needs to consider for this topic. The other is "usage" (aka "usage"
or "encoding"), which can be "literal" or "encoded". The combination of
style and usage therefore yields 4 possible combinations, only 2 of
which are really considered in practice. Style can have the values
"document" or "RPC." "Document" implies that the messages contain a
document (such as a purchase order), while "RPC" implies that the
messages contain parameters and return values (think of a
request/response query-type operation).
Usage can have the values "literal" or "encoded". "Literal" implies
that the information in the messages is *literally* what the XML schema
for the types in the messages dictates. "Encoded" implies that the
information in the messages is further encoded by the SOAP encoding
rules (which are found at http://www.w3.org/2002/06/soap-encoding for
SOAP 1.2), or other encoding rules.
So in using the document/literal combination, one literally defines the
structure of the message using an XML schema; this means that a
resulting SOAP message can be validated using the schema definition
(obviously an advantage in data exchange scenarios). In using the
rpc/encoded combination, SOAP encoding rules are used to construct the
message based on abstract type descriptions - therefore, a type
definition must be provided. However, an XML schema definition of the
message is not provided, which means that the resulting SOAP message
cannot be validated using an XML schema (it of course may be validated
in a sending/receiving system through other means).
The WS-I Basic Profile 1.0 [1] prefers the use of literal, non-encoded
XML - it therefore disallows the use of SOAP encoding and favors
document/literal style.
WSDL FORMAT
<?xml version="1.0"?>
<definitions name="StockQuote"
targetNamespace="http://example.com/stockquote.wsdl"
xmlns:tns="http://example.com/stockquote.wsdl"
xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
xmlns:xsd1="http://example.com/stockquote/schema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<schema targetNamespace="http://example.com/stockquote/schema"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<complexType name="TimePeriod">
<all>
<element name="startTime" type="xsd:timeInstant"/>
<element name="endTime" type="xsd:timeInstant"/>
</all>
</complexType>
<complexType name="ArrayOfFloat">
<complexContent>
<restriction base="soapenc:Array">
<attribute ref="soapenc:arrayType" wsdl:arrayType="xsd:float[]"/>
</restriction>
</complexContent>
</complexType>
</schema>
</types>
<message name="GetTradePricesInput">
<part name="tickerSymbol" element="xsd:string"/>
<part name="timePeriod" element="xsd1:TimePeriod"/>
</message>
<message name="GetTradePricesOutput">
<part name="result" type="xsd1:ArrayOfFloat"/>
<part name="frequency" type="xsd:float"/>
</message>
<portType name="StockQuotePortType">
<operation name="GetLastTradePrice" parameterOrder="tickerSymbol timePeriod frequency">
<input message="tns:GetTradePricesInput"/>
<output message="tns:GetTradePricesOutput"/>
</operation>
</portType>
<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetTradePrices">
<soap:operation soapAction="http://example.com/GetTradePrices"/>
<input>
<soap:body use="encoded" namespace="http://example.com/stockquote"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
</input>
<output>
<soap:body use="encoded" namespace="http://example.com/stockquote"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
</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>
Creating Web Service Clients
Now, let's create a client that accesses the math service you have just deployed. A client invokes a web service in the same way it invokes a method locally. There are three types of web service clients:
- Static Stub: A Java class that is statically bound to a service endpoint interface. A stub, or a client proxy object, defines all the methods that the service endpoint interface defines. Therefore, the client can invoke methods of a web service directly via the stub. The advantage of this is that it is simple and easy to code. The disadvantage is that the slightest change of web service definition lead to the stub being useless... and this means the stub must be regenerated. Use the static stub technique if you know that the web service is stable and is not going to change its definition. Static stub is tied to the implementation. In other words, it is implementation-specific.
- Dynamic Proxy: Supports a service endpoint interface dynamically at runtime. Here, no stub code generation is required. A proxy is obtained at runtime and requires a service endpoint interface to be instantiated. As for invocation, it is invoked in the same way as a stub. This is useful for testing web services that may change their definitions. The dynamic proxy needs to be re-instantiated but not re-generated as is the case with stub.
- Dynamic Invocation Interface (DII): Defines
javax.xml.rpc.Call object instance for dynamic invocation. Unlike stub and proxy, it must be configured before it can be used. A client needs to provide: operation name, parameter names, types, modes, and port type. As you can tell, much more coding is involved here. The major benefit is that since Call is not bound to anything, there is no impact of changes on the client side (whenever the web service definition changes). The DII client is outside the scope of this article.
