dineshonjava

SOAP Example

A SOAP Example

In the example below, a GetStockPrice request is sent to a server. The request has a StockName parameter, and a Price parameter that will be returned in the response. The namespace for the function is defined in "http://www.example.org/stock".

A SOAP request:

POST /InStock HTTP/1.1
Host: www.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Body xmlns:m="http://www.example.org/stock">
  <m:GetStockPrice>
    <m:StockName>IBM</m:StockName>
  </m:GetStockPrice>
</soap:Body>

</soap:Envelope> 
The SOAP response:

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Body xmlns:m="http://www.example.org/stock">
  <m:GetStockPriceResponse>
    <m:Price>34.5</m:Price>
  </m:GetStockPriceResponse>
</soap:Body>

</soap:Envelope> 


References
1. Wikipedia for SOAP

 



<<Previous <<   || Index ||   >>Next >>

SOAP Transport

  • SOAP is not tied to any one transport protocol.
  • SOAP can be transported via SMTP, FTP, IBM's MQSeries, or Microsoft Message Queuing (MSMQ).
  • SOAP specification includes details on HTTP only.
  • HTTP remains the most popular SOAP transport protocol.


SOAP via HTTP

Quite logically, SOAP requests are sent via an HTTP request and SOAP responses are returned within the content of the HTTP response. While SOAP requests can be sent via an HTTP GET, the specification includes details on HTTP POST only.
Additionally, both HTTP requests and responses are required to set their content type to text/xml.
The SOAP specification mandates that the client must provide a SOAPAction header, but the actual value of the SOAPAction header is dependent on the SOAP server implementation.
For example, to access the AltaVista BabelFish Translation service, hosted by XMethods, you must specify the following as a SOAPAction header.
urn:xmethodsBabelFish#BabelFish
Even if the server does not require a full SOAPAction header, the client must specify an empty string (""), or a null value. For example:
SOAPAction: ""
SOAPAction:
Here is a sample request sent via HTTP to the XMethods Babelfish Translation service:
POST /perl/soaplite.cgi HTTP/1.0
Host: services.xmethods.com
Content-Type: text/xml; charset=utf-8
Content-Length: 538
SOAPAction: "urn:xmethodsBabelFish#BabelFish"

<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:BabelFish
xmlns:ns1="urn:xmethodsBabelFish"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<translationmode xsi:type="xsd:string">en_fr</translationmode>
<sourcedata xsi:type="xsd:string">Hello, world!</sourcedata>
</ns1:BabelFish>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Note the content type and the SOAPAction header. Also note that the BabelFish method requires two String parameters. The translation mode en_fr will translate from English to French.
Here is the response from XMethods:
HTTP/1.1 200 OK
Date: Sat, 09 Jun 2001 15:01:55 GMT
Server: Apache/1.3.14 (Unix) tomcat/1.0 PHP/4.0.1pl2
SOAPServer: SOAP::Lite/Perl/0.50
Cache-Control: s-maxage=60, proxy-revalidate
Content-Length: 539
Content-Type: text/xml

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<namesp1:BabelFishResponse xmlns:namesp1="urn:xmethodsBabelFish">
<return xsi:type="xsd:string">Bonjour, monde!</return>
</namesp1:BabelFishResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

SOAP responses delivered via HTTP are required to follow the same HTTP status codes. For example, a status code of 200 OK indicates a successful response. A status code of 500 Internal Server Error indicates that there is a server error and that the SOAP response includes a Fault element.


SOAP HTTP Binding

A SOAP method is an HTTP request/response that complies with the SOAP encoding rules.

HTTP + XML = SOAP

A SOAP request could be an HTTP POST or an HTTP GET request.
The HTTP POST request specifies at least two HTTP headers: Content-Type and Content-Length.



Content-Type

The Content-Type header for a SOAP request and response defines the MIME type for the message and the character encoding (optional) used for the XML body of the request or response.

Syntax


Content-Type: MIMEType; charset=character-encoding

Example


POST /item HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8




Content-Length

The Content-Length header for a SOAP request and response specifies the number of bytes in the body of the request or response.

Syntax


Content-Length: bytes

Example


POST /item HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 250

References
Wikipedia for SOAP

 



<<Previous <<   || Index ||   >>Next >>

SOAP Encoding

SOAP includes a built-in set of rules for encoding data types.This enables the SOAP message to indicate specific data types, such as integers, floats, doubles, or arrays.
  • SOAP data types are divided into two broad categories: scalar types and compound types.
  • Scalar types contain exactly one value, such as a last name, price, or product description.
  • Compound types contain multiple values, such as a purchase order or a list of stock quotes.
  • Compound types are further subdivided into arrays and structs.
  • The encoding style for a SOAP message is set via the SOAP-ENV:encodingStyle attribute.
  • To use SOAP 1.1 encoding, use the value http://schemas.xmlsoap.org/soap/encoding/
  • To use SOAP 1.2 encoding, use the value http://www.w3.org/2001/12/soap-encoding
  • Latest SOAP specification adopts all the built-in types defined by XML Schema. Still SOAP maintains its own convention for defining constructs not standardized by XML Schema, such as arrays and references.


Scalar Types

For scalar types, SOAP adopts all the built-in simple types specified by the XML Schema specification. This includes strings, floats, doubles, and integers.
Following table lists the main simple types, excerpted from the XML Schema Part 0: Primer
http://www.w3.org/TR/2000/WD-xmlschema-0-20000407/
Simple Types Built-In to XML Schema
Simple Type Example(s)
string Confirm this is electric
boolean true, false, 1, 0
float -INF, -1E4, -0, 0, 12.78E-2, 12, INF, NaN
double -INF, -1E4, -0, 0, 12.78E-2, 12, INF, NaN
decimal -1.23, 0, 123.4, 1000.00
binary 100010
integer -126789, -1, 0, 1, 126789
nonPositiveInteger -126789, -1, 0
negativeInteger -126789, -1
long -1, 12678967543233
int -1, 126789675
short -1, 12678
byte -1, 126
nonNegativeInteger 0, 1, 126789
unsignedLong 0, 12678967543233
unsignedInt 0, 1267896754
unsignedShort 0, 12678
unsignedByte 0, 126
positiveInteger 1, 126789
date 1999-05-31, ---05
time 13:20:00.000, 13:20:00.000-05:00
For example, here is a SOAP response with a double data type:

<?xml version='1.0' encoding='UTF-8'?>;
<SOAP-ENV:Envelope
    xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
    <ns1:getPriceResponse
    xmlns:ns1="urn:examples:priceservice"
    SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
    <return xsi:type="xsd:double">54.99</return>
    </ns1:getPriceResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>


Compound Types

SOAP arrays have a very specific set of rules, which require that you specify both the element type and array size. SOAP also supports multidimensional arrays, but not all SOAP implementations support multidimensional functionality.
To create an array, you must specify it as an xsi:type of Array. The array must also include an arrayType attribute. This attribute is required to specify the data type for the contained elements and the dimension(s) of the array.
For example, the following attribute specifies an array of 10 double values:
arrayType="xsd:double[10]"
In contrast, the following attribute specifies a two-dimensional array of strings:
arrayType="xsd:string[5,5]"
Here is a sample SOAP response with an array of double values:
<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope
    xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
    <ns1:getPriceListResponse
    xmlns:ns1="urn:examples:pricelistservice"
    SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
    <return
    xmlns:ns2="http://www.w3.org/2001/09/soap-encoding"
    xsi:type="ns2:Array" ns2:arrayType="xsd:double[2]">
    <item xsi:type="xsd:double">54.99</item>
    <item xsi:type="xsd:double">19.99</item>
    </return>
    </ns1:getPriceListResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Structs contain multiple values, but each element is specified with a unique accessor element. For example, consider an item within a product catalog. In this case, the struct might contain a product SKU, product name, description, and price. Here is how such a struct would be represented in a SOAP message:
<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope
   xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
      <ns1:getProductResponse
   xmlns:ns1="urn:examples:productservice"
   SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
   <return xmlns:ns2="urn:examples" xsi:type="ns2:product">
   <name xsi:type="xsd:string">Red Hat Linux</name>
   <price xsi:type="xsd:double">54.99</price>
   <description xsi:type="xsd:string">
         Red Hat Linux Operating System
   </description>
   <SKU xsi:type="xsd:string">A358185</SKU>
   </return>
   </ns1:getProductResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
NOTE: Please you take care of proper indentation while you write your SOAP code.

Each element in a struct is specified with a unique accessor name. For example, the message above includes four accessor elements: name , price , description , and SKU. Each element can have its own data type; for example, name is specified as a string , whereas price is specified as a double.



References
1. Wikipedia for SOAP

 



<<Previous <<   || Index ||   >>Next >>

SOAP Fault Element

When an error occurs during processing, the response to a SOAP message is a SOAP fault element in the body of the message, and the fault is returned to the sender of the SOAP message.
The SOAP fault mechanism returns specific information about the error, including a predefined code, a description, the address of the SOAP processor that generated
  • A SOAP Message can carry only one fault block
  • Fault element is an optional part of SOAP Message
  • For the HTTP binding, a successful response is linked to the 200 to 299 range of status codes;
  • SOAP fault is linked to the 500 to 599 range of status codes.
The SOAP Fault element has the following sub elements:

Sub Element Description
<faultcode> A code for identifying the fault
<faultstring> A human readable explanation of the fault
<faultactor> Information about who caused the fault to happen
<detail>
Holds application specific error information related to the Body element

SOAP Fault Codes

The faultcode values defined below must be used in the faultcode element when describing faults:
Error Description
VersionMismatch Found an invalid namespace for the SOAP Envelope element
MustUnderstand An immediate child element of the Header element, with the mustUnderstand attribute set to "1", was not understood
Client The message was incorrectly formed or contained incorrect information
Server There was a problem with the server so the message could not proceed

SOAP Fault Example

The following code is a sample Fault. The client has requested a method named ValidateCreditCard , but the service does not support such a method. This represents a client request error, and the server returns the following SOAP response:
<?xml version='1.0' encoding='UTF-8'?>

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
  xmlns:xsd="http://www.w3.org/1999/XMLSchema">
   <SOAP-ENV:Body>
     <SOAP-ENV:Fault>
     <faultcode xsi:type="xsd:string">SOAP-ENV:Client</faultcode>
     <faultstring xsi:type="xsd:string">
          Failed to locate method (ValidateCreditCard) in class
          (examplesCreditCard) at /usr/local/ActivePerl-5.6/lib/
            site_perl/5.6.0/SOAP/Lite.pm line 1555.
        </faultstring>

      </SOAP-ENV:Fault>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>


References
1. Wikipedia for SOAP

 



<<Previous <<   || Index ||   >>Next >>

SOAP Body Element

The SOAP Body element contains the actual SOAP message.


The SOAP Body Element

The required SOAP Body element contains the actual SOAP message intended for the ultimate endpoint of the message.
Immediate child elements of the SOAP Body element may be namespace-qualified.

Example

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Body>
  <m:GetPrice xmlns:m="http://www.w3schools.com/prices">
    <m:Item>Apples</m:Item>
  </m:GetPrice>
</soap:Body>

</soap:Envelope> 
The example above requests the price of apples. Note that the m:GetPrice and the Item elements above are application-specific elements. They are not a part of the SOAP namespace.

A SOAP response could look something like this:
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Body>
  <m:GetPriceResponse xmlns:m="http://www.w3schools.com/prices">
    <m:Price>1.90</m:Price>
  </m:GetPriceResponse>
</soap:Body>

</soap:Envelope> 


References
1. Wikipedia for SOAP

 



<<Previous <<   || Index ||   >>Next >>

SOAP Header Element

The SOAP Header element contains header information.


The SOAP Header Element

The optional SOAP Header element contains application-specific information (like authentication, payment, etc) about the SOAP message.
If the Header element is present, it must be the first child element of the Envelope element.
Note: All immediate child elements of the Header element must be namespace-qualified.
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Header>
  <m:Trans xmlns:m="http://www.w3schools.com/transaction/"
  soap:mustUnderstand="1">234
  </m:Trans>
</soap:Header>
...
...
</soap:Envelope> 
The example above contains a header with a "Trans" element, a "mustUnderstand" attribute with a value of 1, and a value of 234.
SOAP defines three attributes in the default namespace ("http://www.w3.org/2001/12/soap-envelope"). These attributes are: mustUnderstand, actor, and encodingStyle.
The attributes defined in the SOAP Header defines how a recipient should process the SOAP message.


The mustUnderstand Attribute

The SOAP mustUnderstand attribute can be used to indicate whether a header entry is mandatory or optional for the recipient to process.
If you add mustUnderstand="1" to a child element of the Header element it indicates that the receiver processing the Header must recognize the element. If the receiver does not recognize the element it will fail when processing the Header.

Syntax

soap:mustUnderstand="0|1"

Example

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Header>
  <m:Trans xmlns:m="http://www.w3schools.com/transaction/"
  soap:mustUnderstand="1">234
  </m:Trans>
</soap:Header>
...
...
</soap:Envelope> 

The actor Attribute

A SOAP message may travel from a sender to a receiver by passing different endpoints along the message path. However, not all parts of a SOAP message may be intended for the ultimate endpoint, instead, it may be intended for one or more of the endpoints on the message path.
The SOAP actor attribute is used to address the Header element to a specific endpoint.

Syntax

soap:actor="URI"

Example

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Header>
  <m:Trans xmlns:m="http://www.w3schools.com/transaction/"
  soap:actor="http://www.w3schools.com/appml/">234
  </m:Trans>
</soap:Header>
...
...
</soap:Envelope> 

The encodingStyle Attribute

The encodingStyle attribute is used to define the data types used in the document. This attribute may appear on any SOAP element, and it will apply to that element's contents and all child elements.
A SOAP message has no default encoding.

Syntax

soap:encodingStyle="URI"




References
1. Wikipedia for SOAP

 



<<Previous <<   || Index ||   >>Next >>


SOAP Envelope Element

The SOAP Envelope element is the root element of a SOAP message.

The SOAP Envelope Element

The required SOAP Envelope element is the root element of a SOAP message. This element defines the XML document as a SOAP message.

The SOAP envelope indicates the start and the end of the message so that the receiver knows when an entire message has been received. The SOAP envelope solves the problem of knowing when you're done receiving a message and are ready to process it. The SOAP envelope is therefore basic ally a packaging mechanism
SOAP Envelope element can be explained as:
  • Every SOAP message has a root Envelope element.
  • Envelope element is mandatory part of SOAP Message.
  • Every Envelope element must contain exactly one Body element.
  • If an Envelope contains a Header element, it must contain no more than one, and it must appear as the first child of the Envelope, beforethe Body.
  • The envelope changes when SOAP versions change.
  • The SOAP envelope is specified using the ENV namespace prefix and the Envelope element.
  • The optional SOAP encoding is also specified using a namespace name and the optional encodingStyle element, which could also point to an encoding style other than the SOAP one.
  • A v1.1-compliant SOAP processor will generate a fault when receiving a message containing the v1.2 envelope namespace.
  • A v1.2- compliant SOAP processor generates a VersionMismatch fault if it receives a message that does not include the v1.2 envelope namespace.
Example for v1.2 is given below-
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
  ...
  Message information goes here
  ...
</soap:Envelope> 
The xmlns:soap Namespace

Notice the xmlns:soap namespace in the example above. It should always have the value of: "http://www.w3.org/2001/12/soap-envelope".

The namespace defines the Envelope as a SOAP Envelope.

If a different namespace is used, the application generates an error and discards the message.
The encodingStyle Attribute

The encodingStyle attribute is used to define the data types used in the document. This attribute may appear on any SOAP element, and applies to the element's contents and all child elements.

A SOAP message has no default encoding.

Following example illustrates the use of a SOAP message within an HTTP POST operation, which sends the message to the server. It shows the namespaces for the envelope schema definition and for the schema definition of the encoding rules. The OrderEntry reference in the HTTP header is the name of the program to be invoked at the www.dineshonjava.com Web site.
POST /OrderEntry HTTP/1.1
Host: www.dineshonjava.com
Content-Type: application/soap; charset="utf-8"
Content-Length: nnnn
<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope"
SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
  ...
  Message information goes here
  ...
</SOAP-ENV:Envelope>



References
1. Wikipedia for SOAP

 



<<Previous <<   || Index ||   >>Next >>

Web Service Tutorial - Web Service Introduction

In this section we will give all introduction about Web Service Tutorial .
A web service is a method of communication between two electronic devices over the World Wide Web. A web service is a software function provided at a network address over the web or the cloud, it is a service that is "always on" as in the concept of utility computing.

The W3C defines a "Web service" as:

"a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards."

The W3C also states:
We can identify two major classes of Web services:
  1. REST-compliant Web services(JAX-RS), in which the primary purpose of the service is to manipulate XML representations of Web resources using a uniform set of "stateless" operations; and
  2. arbitrary Web services(JAX-WS), in which the service may expose an arbitrary set of operations.
Web Service Tutorial

Web services are browsers and operating system independent service, which means it can run on any browser without the need of making any changes. Web Services take Web-applications to the Next Level.

The World Wide Web Consortium (W3C) has defined the web services. According to W3C, “Web Services are the message-based design frequently found on the Web and in enterprise software. The Web of Services is based on technologies such as HTTP, XML, SOAP, WSDL, SPARQL, and others.

Why you need to learn web services?
Reuse already developed(old) functionality into new software:
Lets understand with very simple example.Lets say you are developing a finance software for a company on java and you have old .net software which manages salary of employees.So rather then developing new software for employee part,you can use old software and for other parts like infrastructure you can develop your own functionalities.
 

Usability :
Web Services allow the business logic of many different systems to be exposed over the Web. This gives your applications the freedom to chose the Web Services that they need. Instead of re-inventing the wheel for each client, you need only include additional application-specific business logic on the client-side. This allows you to develop services and/or client-side code using the languages and tools that you want.
 

Interoperability :
This is the most important benefit of Web Services. Web Services typically work outside of private networks, offering developers a non-proprietary route to their solutions.Web Services also let developers use their preferred programming languages. In addition, thanks to the use of standards-based communications methods, Web Services are virtually platform-independent.
 

Loosely Coupled:
Each service exists independently of the other services that make up the application. Individual pieces of the application to be modified without impacting unrelated areas.
 

Ease of Integration:
Data is isolated between applications creating ’silos’. Web Services act as glue between these and enable easier communications within and across organizations.

Deployability :
Web Services are deployed over standard Internet technologies. This makes it possible to deploy Web Services even over the fire wall to servers running on the Internet on the other side of the globe. Also thanks to the use of proven community standards, underlying security (such as SSL) is already built-in.

Some Terminologies used in Web services:
 

Simple Object Access Protocol(SOAP):
SOAP is a protocol specification for exchanging structured information in the implementation of Web services in computer networks. It relies on XML as its message format.
 

Web Service Description Language(WSDL):
WSDL stands for Web Service Description Language. It is an XML file that describes
the technical details of how to implement a web service, more specifically the URI,
port, method names, arguments, and data types. Since WSDL is XML, it is both
human-readable and machine-consumable, which aids in the ability to call and bind to
services dynamically.
 

Elements of WSDL are:

Description:
It is the root element of a WSDL 2.0 file. It usually contains a set of name space declarations which are used throughout the WSDL file.

Types:
The WSDL types element describes the data types used by your web service. Data types are usually specified by XML schema.It can be described in any language as long as your web services API supports it.

Binding:
The WSDL binding element describes how your web service is bound to a protocol. In other words, how your web service is accessible. To be accessible, the web service must be reachable using some network protocol. This is called "binding" the web service to the protocol.

Interface:
The WSDL interface element describes the operations supported by your web service.It is similar to methods in programming language.Client can only call one operation per request.

Service:
It describes the endpoint of your web service. In other words, the address where the web service can be reached.

Endpoint:
The endpoint element describes the address of the web service. The endpoint binding attribute describes what binding element this endpoint uses.i.e. protocol with which you will access web service. The address attribute describes the URI at which you can access the service.

Message:
The message element describes the data being exchanged between the Web service providers and consumers.


<!--
 Published by JAX-WS RI at http://jax-ws.dev.java.net. RI's version is JAX-WS RI 2.2.7-b01  svn-revision#${svn.Last.Changed.Rev}. 
-->
<!--
 Generated by JAX-WS RI at http://jax-ws.dev.java.net. RI's version is JAX-WS RI 2.2.7-b01  svn-revision#${svn.Last.Changed.Rev}. 
-->
<definitions xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsp="http://www.w3.org/ns/ws-policy" xmlns:wsp1_2="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://ws.dineshonjava.com/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.xmlsoap.org/wsdl/" targetNamespace="http://ws.dineshonjava.com/" name="HelloWorldImplService">
    <types/>
    <message name="sayHelloWorld"/>
    <message name="sayHelloWorldResponse">
       <part name="return" type="xsd:string"/>
    </message>
    <portType name="HelloWorld">
       <operation name="sayHelloWorld">
           <input wsam:Action="http://ws.dineshonjava.com/HelloWorld/sayHelloWorldRequest" message="tns:sayHelloWorld"/>
           <output wsam:Action="http://ws.dineshonjava.com/HelloWorld/sayHelloWorldResponse" message="tns:sayHelloWorldResponse"/>
       </operation>
     </portType>
     <binding name="HelloWorldImplPortBinding" type="tns:HelloWorld">
         <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="rpc"/>
         <operation name="sayHelloWorld">
             <soap:operation soapAction=""/>
             <input>
                  <soap:body use="literal" namespace="http://ws.dineshonjava.com/"/>
             </input>
             <output>
                 <soap:body use="literal" namespace="http://ws.dineshonjava.com/"/>
             </output>
       </operation>
    </binding>
    <service name="HelloWorldImplService">
      <port name="HelloWorldImplPort" binding="tns:HelloWorldImplPortBinding">
            <soap:address location="http://localhost:8181/sdnext/hello"/>
      </port>
    </service>
</definitions>

Universal Description, Discovery and Integration(UDDI):
UDDI stands for Universal Description, Discovery and Integration. It is a directory service. Web services can register with a UDDI and make themselves available through it for discovery.

Web service design approaches:
 

Contract last or Bottom up approach:
When using contract last approach, you first write your java code then you create web service contract(WSDL) .There are various kinds of tools which can generate WSDL on the basis of java code.
 

Contract first or Top Down Approach :
It is reverse of contract first. Here you first define web service contract.You define all the elements of WSDL first then after that you create your java logic.





Contents-
1. Types of Web Services
2. Creating a Simple Web Service and Clients with JAX...
3. Why Contract First?
4. Writing Contract First Web Service 



SOAP Message Structure

SOAP Message Structure

A SOAP message is an ordinary XML document containing the following elements.

  • Envelope: ( Mandatory )
    Defines the start and the end of the message.

  • Header: ( Optional )
    Contains any optional attributes of the message used in processing the message, either at an intermediary point or at the ultimate end point.

  • Body: ( Mandatory )
    Contains the XML data comprising the message being sent.

  • Fault: ( Optional )
    An optional Fault element that provides information about errors that occurred while processing the message

All these elements are declared in the default namespace for the SOAP envelope:
http://www.w3.org/2001/12/soap-envelope
and the default namespace for SOAP encoding and data types is:
http://www.w3.org/2001/12/soap-encoding

NOTE: All these specifications are subject to change. So keep updating yourself with the latest specifications available W3 website.


Syntax Rules

Here are some important syntax rules:
  • A SOAP message MUST be encoded using XML
  • A SOAP message MUST use the SOAP Envelope namespace
  • A SOAP message MUST use the SOAP Encoding namespace
  • A SOAP message must NOT contain a DTD reference
  • A SOAP message must NOT contain XML Processing Instructions
A SOAP Message Structure-
<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope"
SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<SOAP-ENV:Header>
  ...
  ...
</SOAP-ENV:Header>

<SOAP-ENV:Body>

  ...
  ...
  <SOAP-ENV:Fault>
    ...
    ...
  </SOAP-ENV:Fault>
</SOAP-ENV:Body>

</SOAP_ENV:Envelope>



References
1. Wikipedia for SOAP

 



<<Previous <<   || Index ||   >>Next >>

What is UDDI?

UDDI is a directory service where companies can register and search for Web services.

  • UDDI stands for Universal Description, Discovery and Integration
  • UDDI is a directory for storing information about web services
  • UDDI is a directory of web service interfaces described by WSDL
  • UDDI communicates via SOAP
  • UDDI is built into the Microsoft .NET platform

SOAP Tutorial - What is SOAP?

In this section we discuss all about SOAP Tutorial.

SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks. It relies on XML Information Set for its message format, and usually relies on other Application Layer protocols, most notably Hypertext Transfer Protocol (HTTP) or Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission.
 

SOAP Tutorial

SOAP is an XML-based protocol to let applications exchange information over HTTP.
Or more simple: SOAP is a protocol for accessing a Web Service.
  • SOAP stands for Simple Object Access Protocol
  • SOAP is a communication protocol
  • SOAP is a format for sending messages
  • SOAP is designed to communicate via Internet
  • SOAP is platform independent
  • SOAP is language independent
  • SOAP is based on XML
  • SOAP is simple and extensible
  • SOAP allows you to get around firewalls
  • SOAP is a W3C standard

Although SOAP can be used in a variety of messaging systems and can be delivered via a variety of transport protocols, the initial focus of SOAP is remote procedure calls transported via HTTP.

SOAP enables client applications to easily connect to remote services and invoke remote methods.

Other frameworks, including CORBA, DCOM, and Java RMI, provide similar functionality to SOAP, but SOAP messages are written entirely in XML and are therefore uniquely platform- and language-independent.

Why SOAP?

It is important for application development to allow Internet communication between programs.

Today's applications communicate using Remote Procedure Calls (RPC) between objects like DCOM and CORBA, but HTTP was not designed for this. RPC represents a compatibility and security problem; firewalls and proxy servers will normally block this kind of traffic.

A better way to communicate between applications is over HTTP, because HTTP is supported by all Internet browsers and servers. SOAP was created to accomplish this.

SOAP provides a way to communicate between applications running on different operating systems, with different technologies and programming languages.
 

History

SOAP was designed as an object-access protocol in 1998 by Dave Winer, Don Box, Bob Atkinson, and Mohsen Al-Ghosein for Microsoft, where Atkinson and Al-Ghosein were working at the time. The SOAP specification is currently maintained by the XML Protocol Working Group of the World Wide Web Consortium.

SOAP originally stood for 'Simple Object Access Protocol' but this acronym was dropped with Version 1.2 of the standard. Version 1.2 became a W3C recommendation on June 24, 2003. The acronym is sometimes confused with SOA, which stands for Service-oriented architecture, but the acronyms are unrelated.

After SOAP was first introduced, it became the underlying layer of a more complex set of Web Services, based on Web Services Description Language (WSDL) and Universal Description Discovery and Integration (UDDI). These services, especially UDDI, have proved to be of far less interest, but an appreciation of them gives a more complete understanding of the expected role of SOAP compared to how web services have actually evolved.


Contents of SOAP-
What is SOAP ?
This chapter explains what is SOAP and why SOAP is useful.

SOAP Message Structure
This chapter describes the structure of a complete SOAP message.

SOAP Envelope
This chapter describes the SOAP Envelope element of SOAP message.

SOAP Header
This chapter describes the SOAP Header element of SOAP message.

SOAP Body
This chapter describes the SOAP Body element of SOAP message.

SOAP Fault
This chapter describes the SOAP Fault element of SOAP message.

SOAP Encoding
This chapter describes the built-in set of rules for encoding various data types.

SOAP Transport
This chapter describes the transport protocols for SOAP to exchange the messages.

SOAP Examples
This chapter has given a simple SOAP example to illustrate the concepts.

SOAP Standards
This chapter gives links to latest standards related to SOAP. 




References
1. Wikipedia for SOAP

 



<<Previous <<   || Index ||   >>Next >>


Creating a Simple Web Service and Clients with JAX-WS

This section shows how to build and deploy a simple web service and an application client.

Creating a Simple Web Service and Clients with JAX-WS
The starting point for developing a JAX-WS web service is a Java class annotated with the javax.jws.WebService annotation. The @WebService annotation defines the class as a web service endpoint.

A service endpoint interface or service endpoint implementation (SEI) is a Java interface or class, respectively, that declares the methods that a client can invoke on the service. An interface is not required when building a JAX-WS endpoint. The web service implementation class implicitly defines an SEI.

You may specify an explicit interface by adding the endpointInterface element to the @WebService annotation in the implementation class. You must then provide an interface that defines the public methods made available in the endpoint implementation class.

Here’s a guide to show you how to deploy JAX-WS web services on Tomcat servlet container. See following summary steps of a web service deployment.
  1. Create a web service(WebService).
  2. Create a sun-jaxws.xml, defines web service implementation class.
  3. Create a standard web.xml, defines WSServletContextListener, WSServlet and structure of a web project.
  4. Build tool to generate WAR file.
  5. Copy JAX-WS dependencies to “${Tomcat}/lib” folder.
  6. Copy WAR to “${Tomcat}/webapp” folder.
  7. Start It.
Directory structure of this example, so that you know where to put your files.
Creating a Simple Web Service and Clients JAX-WS

1. WebServices-Create a Web Service Endpoint Interface
A simple JAX-WS hello world example.
File : HelloWorld.java
package com.dineshonjava.ws;

import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;

/**
 * @author Dinesh Rajput
 * Service Endpoint Interface
 */

@WebService
@SOAPBinding(style = Style.RPC)
public interface HelloWorld {
 @WebMethod 
 String sayHelloWorld();
}
Create a Web Service Endpoint Implementation
File : HelloWorldImpl.java
package com.dineshonjava.ws;

import javax.jws.WebService;

/**
 * @author Dinesh Rajput
 * Service Implementation Bean
 */

@WebService(endpointInterface = "com.dineshonjava.ws.HelloWorld")
public class HelloWorldImpl implements HelloWorld {

 @Override
 public String sayHelloWorld() {
  return "Hello World!! Dinesh on Java!!";
 }
}
Create a Endpoint Publisher-
package com.dineshonjava.endpoint;

import javax.xml.ws.Endpoint;

import com.dineshonjava.ws.HelloWorldImpl;

/**
 * @author Dinesh Rajput
 * Endpoint publisher
 */
public class HelloWorldPublisher {

 /**
  * @param args
  */
 public static void main(String[] args) {
  Endpoint.publish("http://localhost:8181/sdnext/hello", new HelloWorldImpl());
 }

}
2. sun-jaxws.xml
Create a web service deployment descriptor, which is also known as JAX-WS RI deployment descriptor – sun-jaxws.xml.
File : sun-jaxws.xml
<?xml version="1.0" encoding="UTF-8"?>
<endpoints  xmlns="http://java.sun.com/xml/ns/jax-ws/ri/runtime" version="2.0">
  <endpoint name="HelloWorld" implementation="com.dineshonjava.ws.HelloWorldImpl"
      url-pattern="/hello"/>
</endpoints>
When user access /hello/ URL path, it will fire the declared web service, which is HelloWorldImpl.java.

3. web.xml
Create a standard web.xml deployment descriptor for the deployment. Defines WSServletContextListener as listener class, WSServlet as your hello servlet.
File : web.xml
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" id="WebApp_ID" version="3.0">
  <display-name>WebService</display-name>
  <listener>
        <listener-class>
               com.sun.xml.ws.transport.http.servlet.WSServletContextListener
        </listener-class>
    </listener>
    <servlet>
        <servlet-name>hello</servlet-name>
        <servlet-class>
         com.sun.xml.ws.transport.http.servlet.WSServlet
        </servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>hello</servlet-name>
        <url-pattern>/hello</url-pattern>
    </servlet-mapping>
    <session-config>
        <session-timeout>120</session-timeout>
    </session-config>
 </web-app>
4. WAR Content
Use Ant, Maven or JAR command to build a WAR file to include everything inside. The WAR content should look like this :

WEB-INF/classes/com/dineshonjava/ws/HelloWorld.class
WEB-INF/classes/com/dineshonjava/ws/HelloWorldImpl.class
WEB-INF/web.xml
WEB-INF/sun-jaxws.xml
OR
right click to project and export as war file with name "WebService.war" and deploy it to tomcat web server.

5. JAX-WS Dependencies
By default, Tomcat does not comes with any JAX-WS dependencies, So, you have to include it manually.
1. Go here http://jax-ws.java.net/.
2. Download JAX-WS RI distribution.
3. Unzip it and copy following JAX-WS dependencies to Tomcat library folder “{$TOMCAT}/lib“.
jaxb-impl.jar
jaxws-api.jar
jaxws-rt.jar
gmbal-api-only.jar
management-api.jar
stax-ex.jar
streambuffer.jar
policy.jar
ha-api.jar

6. Deployment

Copy the generated WAR file to {$TOMCAT}/webapps/ folder and start the Tomcat server.
For testing, you can access this URL : http://localhost:8181/sdnext/hello, if you see following page, it means web services are deploy successfully.

Simple Web Service and Clients with JAX-WS

you can access this URL : http://localhost:8181/sdnext/hello?wsdl, if you see following page


Simple Web Service and Clients
wsdl

Web Service Clients
Ok, web service is deployed properly, now let’s see how to create web service client to access to the published service.
1. Java Web Service Client
Without tool, you can create a Java web service client like this :
package com.dineshonjava.client;

import java.net.MalformedURLException;
import java.net.URL;

import javax.xml.namespace.QName;
import javax.xml.ws.Service;

import com.dineshonjava.ws.HelloWorld;

/**
 * @author Dinesh Rajput
 *
 */
public class HelloWorldClient {

 /**
  * @param args
  */
 public static void main(String[] args) {
  URL url;
  try {
   url = new URL("http://localhost:8181/sdnext/hello?wsdl");
   
         //1st argument service URI, refer to wsdl document above
   //2nd argument is service name, refer to wsdl document above
         QName qname = new QName("http://ws.dineshonjava.com/", "HelloWorldImplService");
  
         Service service = Service.create(url, qname);
  
         HelloWorld hello = service.getPort(HelloWorld.class);
  
         System.out.println(hello.sayHelloWorld());
  } catch (MalformedURLException e) {
   e.printStackTrace();
  }
 }

}

Output:
output


2. Java Web Service Client via wsimport tool
Alternative, you can use “wsimport” tool to parse the published wsdl file, and generate necessary client files (stub) to access the published web service.

Where is wsimport?
This wsimport tool is bundle with the JDK, you can find it at “JDK_PATH/bin” folder.

Use the following command for parsing the WSDL file...

 wsimport -keep http://localhost:8181/sdnext/hello?wsdl

wsimport

It will generate necessary client files, which is depends on the provided wsdl file. In this case, it will generate one interface and one service implementation file.
1. HelloWorld.java
package com.dineshonjava.ws;

import javax.jws.WebMethod;
import javax.jws.WebResult;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.xml.ws.Action;


/**
 * This class was generated by the JAX-WS RI.
 * JAX-WS RI 2.2.2 in JDK 7
 * Generated source version: 2.2
 * 
 */
@WebService(name = "HelloWorld", targetNamespace = "http://ws.dineshonjava.com/")
@SOAPBinding(style = SOAPBinding.Style.RPC)
public interface HelloWorld {


    /**
     * 
     * @return
     *     returns java.lang.String
     */
    @WebMethod
    @WebResult(partName = "return")
    @Action(input = "http://ws.dineshonjava.com/HelloWorld/sayHelloWorldRequest", output = "http://ws.dineshonjava.com/HelloWorld/sayHelloWorldResponse")
    public String sayHelloWorld();

}
2. HelloWorldImplService.java
package com.dineshonjava.ws;

import java.net.MalformedURLException;
import java.net.URL;
import javax.xml.namespace.QName;
import javax.xml.ws.Service;
import javax.xml.ws.WebEndpoint;
import javax.xml.ws.WebServiceClient;
import javax.xml.ws.WebServiceException;
import javax.xml.ws.WebServiceFeature;


/**
 * This class was generated by the JAX-WS RI.
 * JAX-WS RI 2.2.2 in JDK 7
 * Generated source version: 2.2
 * 
 */
@WebServiceClient(name = "HelloWorldImplService", targetNamespace = "http://ws.dineshonjava.com/", wsdlLocation = "http://localhost:8181/sdnext/hello?wsdl")
public class HelloWorldImplService
    extends Service
{

    private final static URL HELLOWORLDIMPLSERVICE_WSDL_LOCATION;
    private final static WebServiceException HELLOWORLDIMPLSERVICE_EXCEPTION;
    private final static QName HELLOWORLDIMPLSERVICE_QNAME = new QName("http://ws.dineshonjava.com/", "HelloWorldImplService");

    static {
        URL url = null;
        WebServiceException e = null;
        try {
            url = new URL("http://localhost:8181/sdnext/hello?wsdl");
        } catch (MalformedURLException ex) {
            e = new WebServiceException(ex);
        }
        HELLOWORLDIMPLSERVICE_WSDL_LOCATION = url;
        HELLOWORLDIMPLSERVICE_EXCEPTION = e;
    }

    public HelloWorldImplService() {
        super(__getWsdlLocation(), HELLOWORLDIMPLSERVICE_QNAME);
    }

    public HelloWorldImplService(WebServiceFeature... features) {
        super(__getWsdlLocation(), HELLOWORLDIMPLSERVICE_QNAME, features);
    }

    public HelloWorldImplService(URL wsdlLocation) {
        super(wsdlLocation, HELLOWORLDIMPLSERVICE_QNAME);
    }

    public HelloWorldImplService(URL wsdlLocation, WebServiceFeature... features) {
        super(wsdlLocation, HELLOWORLDIMPLSERVICE_QNAME, features);
    }

    public HelloWorldImplService(URL wsdlLocation, QName serviceName) {
        super(wsdlLocation, serviceName);
    }

    public HelloWorldImplService(URL wsdlLocation, QName serviceName, WebServiceFeature... features) {
        super(wsdlLocation, serviceName, features);
    }

    /**
     * 
     * @return
     *     returns HelloWorld
     */
    @WebEndpoint(name = "HelloWorldImplPort")
    public HelloWorld getHelloWorldImplPort() {
        return super.getPort(new QName("http://ws.dineshonjava.com/", "HelloWorldImplPort"), HelloWorld.class);
    }

    /**
     * 
     * @param features
     *     A list of {@link javax.xml.ws.WebServiceFeature} to configure on the proxy.  Supported features not in the features parameter will have their default values.
     * @return
     *     returns HelloWorld
     */
    @WebEndpoint(name = "HelloWorldImplPort")
    public HelloWorld getHelloWorldImplPort(WebServiceFeature... features) {
        return super.getPort(new QName("http://ws.dineshonjava.com/", "HelloWorldImplPort"), HelloWorld.class, features);
    }

    private static URL __getWsdlLocation() {
        if (HELLOWORLDIMPLSERVICE_EXCEPTION!= null) {
            throw HELLOWORLDIMPLSERVICE_EXCEPTION;
        }
        return HELLOWORLDIMPLSERVICE_WSDL_LOCATION;
    }

}
Now, create a Java web service client which depends on the above generated files.

package com.dineshonjava.client;

import com.dineshonjava.ws.HelloWorld;
import com.dineshonjava.ws.HelloWorldImplService;

/**
 * @author Dinesh Rajput
 *
 */
public class HelloWorldClient {

 /**
  * @param args
  */
 public static void main(String[] args) {
  HelloWorldImplService helloService = new HelloWorldImplService();
  HelloWorld hello = helloService.getHelloWorldImplPort();
 
  System.out.println(hello.sayHelloWorld());
 }

}
Here’s the output
out ws

Download SourceCode
WebService.zip



References
Wikipedia for Web Service

 



<<Previous <<   || Index ||   >>Next >>

WSDL Service Element

  • The <service> element defines the ports supported by the Web service. For each of the supported protocols, there is one port element. The service element is a collection of ports.
  • Web service clients can learn from the service element where to access the service, through which port to access the Web service, and how the communication messages are defined.
  • The service element includes a documentation element to provide human-readable documentation.
Here is a piece of code from Example Session:
<service name="HelloWorld_Service">
      <documentation>WSDL File for HelloWorldService</documentation>
      <port binding="tns:HelloWorld_Binding" name="HelloWorld_Port">
         <soap:address
            location="http://www.dineshonjava.com/SayHelloWorld/">
      </port>
   </service>
The binding attributes of por element associate the address of the service with a binding element defined in the Web service. In this example this is HelloWorld_Binding
<binding name="HelloWorld_Binding" type="tns:HelloWorld_PortType">
   <soap:binding style="rpc"
      transport="http://schemas.xmlsoap.org/soap/http"/>
   <operation name="sayHelloWorld">
      <soap:operation soapAction="sayHelloWorld"/>
      <input>
         <soap:body
            encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
            namespace="urn:examples:helloworldservice"
            use="encoded"/>
      </input>
      <output>
         <soap:body
            encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
            namespace="urn:dineshonjava:helloworldservice"
            use="encoded"/>
      </output>
   </operation>
   </binding>




References
Wikipedia for WSDL

 



<<Previous <<   || Index ||   >>Next >>


WSDL Ports Element

A <port> element defines an individual endpoint by specifying a single address for a binding.
  • The port element has two attributes - the name attribute and the binding attribute.
  • The name attribute provides a unique name among all ports defined within in the enclosing WSDL document.
  • The binding attribute refers to the binding using the linking rules defined by WSDL.
  • A port MUST NOT specify more than one address.
  • A port MUST NOT specify any binding information other than address information.
Here is the piece of code from Example session:
<service name="HelloWorld_Service">
      <documentation>WSDL File for HelloWorldService</documentation>
      <port binding="tns:HelloWorld_Binding" name="HelloWorld_Port">
         <soap:address
            location="http://www.dineshonjava.com/SayHelloWorld/">
      </port>
   </service>



References
Wikipedia for WSDL

 



<<Previous <<   || Index ||   >>Next >>


WSDL Binding Element

  • The <binding> element provides specific details on how a portType operation will actually be transmitted over the wire.
  • The bindings can be made available via multiple transports, including HTTP GET, HTTP POST, or SOAP.
  • The bindings provide concrete information on what protocol is being used to transfer portType operations.
    The bindings provide information where the service is located.
  • For SOAP protocol, the binding is <soap:binding>, and the transport is SOAP messages on top of HTTP protocol.
  • You can specify multiple bindings for a single portType.
The binding element has two attributes - the name attribute and the type attribute.
<binding name="HelloWorld_Binding" type="tns:HelloWorld_PortType">

The name attribute defines the name of the binding, and the type attribute points to the port for the binding, in this case the "tns:HelloWorld_PortType" port.
SOAP Binding

WSDL 1.1 includes built-in extensions for SOAP 1.1. This enables you to specify SOAP specific details, including SOAP headers, SOAP encoding styles, and the SOAPAction HTTP header. The SOAP extension elements include:

soap:binding
This element indicates that the binding will be made available via SOAP. The style attribute indicates the overall style of the SOAP message format. A style value of rpc specifies an RPC format.

The transport attribute indicates the transport of the SOAP messages. The value http://schemas.xmlsoap.org/soap/http indicates the SOAP HTTP transport, whereas http://schemas.xmlsoap.org/soap/smtp indicates the SOAP SMTP transport.

soap:operation
This element indicates the binding of a specific operation to a specific SOAP implementation. The soapAction attribute specifies that the SOAPAction HTTP header be used for identifying the service.
soap:body
This element enables you to specify the details of the input and output messages. In the case of HelloWorld, the body element specifies the SOAP encoding style and the namespace URN associated with the specified service.

Here is the piece of code from Example section:

<binding name="HelloWorld_Binding" type="tns:HelloWorld_PortType">
   <soap:binding style="rpc"
      transport="http://schemas.xmlsoap.org/soap/http"/>
   <operation name="sayHelloWorld">
      <soap:operation soapAction="sayHelloWorld"/>
      <input>
         <soap:body
            encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
            namespace="urn:examples:helloworldservice"
            use="encoded"/>
      </input>
      <output>
         <soap:body
            encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
            namespace="urn:dineshonjava:helloworldservice"
            use="encoded"/>
      </output>
     </operation>
   </binding>


References
Wikipedia for WSDL

 



<<Previous <<   || Index ||   >>Next >>

WSDL portType Element

The <portType> element combines multiple message elements to form a complete oneway or round-trip operation.
For example, a <portType> can combine one request and one response message into a single request/response operation. This is most commonly used in SOAP services. A portType can define multiple operations.
Lets take a piece of code from the Example Session:
<portType name="HelloWorld_PortType">
      <operation name="sayHelloWorld">
         <input message="tns:SayHelloRequest"/>
         <output message="tns:SayHelloResponse"/>
      </operation>
   </portType>
  • The portType element defines a single operation, called sayHelloWorld.
  • The operation itself consists of a single input message SayHelloRequest
  • The operation itself consists of a single output message SayHelloResponse

Operation Types

The request-response type is the most common operation type, but WSDL defines four types:
Type Definition
One-way The operation can receive a message but will not return a response
Request-response The operation can receive a request and will return a response
Solicit-response The operation can send a request and will wait for a response
Notification The operation can send a message but will not wait for a response

One-way :
The service receives a message. The operation therefore has a single input element. The grammar for a one-way operation is:
<wsdl:definitions .... > <wsdl:portType .... > *
        <wsdl:operation name="nmtoken">
        <wsdl:input name="nmtoken"? message="qname"/>
        </wsdl:operation>
    </wsdl:portType >
</wsdl:definitions>
Request-response:
The service receives a message and sends a response. The operation therefore has one input element, followed by one output element. To encapsulate errors, an optional fault element can also be specified. The grammar for a request-response operation is:
<wsdl:definitions .... >
    <wsdl:portType .... > *
        <wsdl:operation name="nmtoken" parameterOrder="nmtokens">
           <wsdl:input name="nmtoken"? message="qname"/>
           <wsdl:output name="nmtoken"? message="qname"/>
           <wsdl:fault name="nmtoken" message="qname"/>*
        </wsdl:operation>
    </wsdl:portType >
</wsdl:definitions>
Solicit-response:
The service sends a message and receives a response. The operation therefore has one output element, followed by one input element. To encapsulate errors, an optional fault element can also be specified. The grammar for a solicit-response operation is:
<wsdl:definitions .... >
    <wsdl:portType .... > *
        <wsdl:operation name="nmtoken" parameterOrder="nmtokens">
           <wsdl:output name="nmtoken"? message="qname"/>
           <wsdl:input name="nmtoken"? message="qname"/>
           <wsdl:fault name="nmtoken" message="qname"/>*
        </wsdl:operation>
    </wsdl:portType >
</wsdl:definitions>
Notification :
The service sends a message. The operation therefore has a single output element. Following is the grammar for a notification operation:
<wsdl:definitions .... >
   <wsdl:portType .... > *
        <wsdl:operation name="nmtoken">
          <wsdl:output name="nmtoken"? message="qname"/>
          </wsdl:operation>
    </wsdl:portType >
</wsdl:definitions>




References
Wikipedia for WSDL

 



<<Previous <<   || Index ||   >>Next >>