WSDL(Web Services Definition Language) – A WSDL is an XML document that describes a web service.WSDL tells about the functions that you can implement or exposed to the client. For example: add, delete, subtract and so on.

UDDI(Universal Description, Discovery and Integration)- It is directly that is used to publish and discover public web services. UDDI is an obsolete failure that is almost never used in practice.UDDI works just like a telephone directory where a business can be registered as per its name, geography and the web services it publishes.UDDI registers the WSDL address URL of a web service. A client of the web service searches and finds the WSDL in the UDDI registry. Once received the WSDL can be invoked by using the URL.

SOAP(Simple Object Access Protocol) – SOAP is an XML-based protocol that lets you exchange info over a particular protocol (can be HTTP or SMTP, for example) between applications. It stands for Simple Object Access Protocol and uses XML for its messaging format to relay the information.

WSDL: When we go to a restaurant we see the Menu Items, those are the WSDL’s.

Proxy Classes: Now after seeing the Menu Items we make up our Mind (Process our mind on what to order): So, basically we make Proxy classes based on WSDL Document.

SOAP: Then when we actually order the food based on the Menu’s: Meaning we use proxy classes to call upon the service methods which is done using SOAP

SEI(service endpoint interface):The endpoint is a connection point where HTML files or active server pages are exposed. .A web service endpoint is the URL that another program would use to communicate with your program. To see the WSDL you add ?wsdl to the web service endpoint URL.

Parts of WSDL
Definitions – variables – ex: myVar, x, y, etc.

Types – data types – ex: int, double, String, myObjectType

Operations – methods/functions – ex: myMethod(), myFunction(), etc.

Messages – method/function input parameters & return types

ex: public myObjectType myMethod(String myVar)
Porttypes – classes (i.e. they are a container for operations) – ex: MyClass{}, etc.

Example of a Endpoint URL





Simple SOAP Request and Response


import java.util.ArrayList;
import java.util.List;

import javax.jws.WebService;

public class Products 
  List<String> arrProducts = new ArrayList<String>();
  public Products()
  public String getProduct(int index)
	return arrProducts.get(index);  

SOAP Request

<soapenv:Envelope xmlns:soapenv="" xmlns:org="">

SOAP Request

<soap:Envelope xmlns:soap="">
      <ns2:getProductResponse xmlns:ns2="">

Di-section of WSDL

  1. service – Contains the port which defines the Endpoint URL, port number
  2. portType – Contains input and output for an operation.Though there are multiple input and output arguments they would be bundled together as one message
  3. binding – Defines how the SOAP service could be accessed like over http,https
  4. types – Type defined as complex type defines the Input and output
  5. message – Kind of input and output taken as argument, mostly represented as Message


 <wsdl:service name="ProductsService">
  <wsdl:port binding="tns:ProductsServiceSoapBinding" name="ProductsPort">
   <soap:address location="http://localhost:8096/WebService1/Products"/>


 <wsdl:portType name="Products">
   <wsdl:operation name="getProduct">
    <wsdl:input message="tns:getProduct" name="getProduct"></wsdl:input>
    <wsdl:output message="tns:getProductResponse" name="getProductResponse"></wsdl:output>


<wsdl:binding name="ProductsServiceSoapBinding" type="tns:Products">
      <soap:binding style="document" transport="" />
      <wsdl:operation name="getProduct">
         <soap:operation soapAction="" style="document" />
         <wsdl:input name="getProduct">
            <soap:body use="literal" />
         <wsdl:output name="getProductResponse">
            <soap:body use="literal" />


      <xs:schema xmlns:xs="" elementFormDefault="unqualified" targetNamespace="" version="1.0">
         <xs:element name="getProduct" type="tns:getProduct" />
         <xs:element name="getProductResponse" type="tns:getProductResponse" />
         <xs:complexType name="getProduct">
               <xs:element name="arg0" type="xs:int" />
         <xs:complexType name="getProductResponse">
               <xs:element minOccurs="0" name="return" type="xs:string" />


 <wsdl:message name="getProduct">
      <wsdl:part element="tns:getProduct" name="parameters" />
   <wsdl:message name="getProductResponse">
      <wsdl:part element="tns:getProductResponse" name="parameters" />

Service(Class name with @WebService Annotation) 
Port(has Binding which defines portType)
    PortType(defines Operations)
Operations(defines input and output Type)

Annotations for WebService

@Webservice(name="MartCatalogue", portName="MartCataloguePort", serviceName="ProductsService", targetNamespace="")
@WebMethod(action="fetch_products", operationName="fetchProducts")


<wsdl:portType name="MartCatalogue">

portName and serviceName

wsdl:port binding="tns:productServiceSoapBinding" name="productPort">
  <soap:address location="http://localhost:8096/WebService1/productService"/>

Defines unique set of operations under namespace.Defaults to package name in java in reverse order


<wsdl:operation name="fetchProducts">
 <wsdl:operation name="fetchProducts">
      <soap:operation soapAction="fetch_products" style="document" />

WS-Addressing is useful in situations where the SOAP response can’t be served immediately. Either the resources to form the response are not available right away or the result itself takes a long time to be generated. There are times where your business takes time.something which needs manually intervention, something to be approved, whatever, but it takes days to do it. keeping the connection opened all that time and waiting for the response would be inefficient.notification process comes to rescue in these kind of scenarios.The client makes a requests but does not wait for the response. It instead instructs the server where to send the response by use of a “reply to” address. Once the response is available, the server connects to that address and sends the response.Instead of relying on network-level transport to convey routing information, a message utilizing WS-Addressing may contain its own dispatch metadata in a standardized SOAP header.WS-Addressing you are not tied to that. You can demand the response on another type of channel. Request comes on HTTP for example, but you can instruct the server to send the response back over SMTP, for example.

Scenario – Asynchronous Web Services

Implement a web service to make two systems communicate. The “client” system is interested in events that are generated on the “server” system. But the “client system” is itself a server for a different app. The server is Java (WAR in tomcat). The client is .Net.

  1. Server is running.Client initiates conversation, “registers” to the server, and requests some initial data.
  2. Server keeps a list of registered clients’ endpoints
  3. In the server there is a listener that is notified when certain events happen. It will then go through the list of registered clients and forwards the event to each of them
  4. At some point, the client can “unregister” no notify the server that it doesn’t want to receive events any more.



  1. SOAP/HTTP communication path for requests from server-to-client – not guaranteed when firewalls exist
  2. The client needs to be aware of your notification schema – in fact the client needs to act as a Service endpoint to recieve the SOAP notification request.
  3. Many clients are “just clients” – they might not have a HTTP server to accept SOAP requests.So both sides need to servers and both need to publish their SOA interfaces. Alternatively, you can pull the notification to the client. The client can use a notification request to the server that is either blocking or polling. The server can respond with the notification or nothing or error.


An async callback mechanism is defined in JAX-WS 2.0, where the service obtains the endpoint reference of the client. SOAP payload schemas and message exchange pattern should
be custom developed as per requirement.

Incase of Arbitrary anonymous client SOAP would not be a appropriate solution. But with few changes and challenges it could be customized as below


  1. HTTP servers (i.e. the SOAP server) do not support blocking requests, as a rule, meaning you must poll
  2. the client needs to be aware of your notification schema – in fact the client needs to act as a Service endpoint to recieve the SOAP notification request. That’s two very big assumptions for an arbitrary anonymous client – that’s not something SOAP “just supports” both ends need to design all this in detail. In fact to do this in a service typesafe manner, the client should actually declare it’s own service WSDL interface so that you can invoke it.


Other options for above scenario

WS-addressing data in SOAP headers to inform either side of the other’s endpoint address.WS-addressing addresses will help you intelligently route SOAP messages to the right URL address, but no more.

WS-notification WS-BaseNotification sub-standard would meet your needs. It provides WSDL port definitions for notification producers and consumers. It provides a WS- standards compliant solution for subscription from a consumer to a producer, and a notification from producers to consumers.


  1. It does NOT define the format of notification payloads. The Notification payload is application-domain specific (proprietary design). The standard does not define any “standard” or “built-in” notification situations or messages.
  2.  It has the same problems with HTTP notifications passing through firewalls as mentioned above.
  3. WS-Notification is not a supported standard of Java EE/JAX-WS

Use a Message queuing solution (e.g. JMS) with traffic encapsulated in HTTP This requires proprietary design of payloads passing between client and server and back – forming contracts between the two sides. An advantage is that the client can be a pure client, with a message listener invoked in a thread when a message is recieved.It has the same problems with HTTP notifications passing through firewalls as mentioned above and do-it-yourself implementation.