Q1:Difference between concrete wsdl and abstract wsdl
Typically a wsdl contains – types, Messages, porttype, Binding and service
Using Types ,messages and porttype we can’t do anything with that.. which is abstract part. Binding and service has more info about the webservices. So it’s concrete.abstract wsdl is enough to consume a soap service … If we use a abstract wsdl and if we try to generate classes we will not be able to see the java files and only class files can be obtained …
Concrete wsdl can provide complete details about the service…

It is not safe to provide the concrete wsdl to the consumer if he is not to be trusted ..
Please Refer Here

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

protocol://host:port/partOfThePath

where

host=someIp
port=8080
partOfThePath=/some/service/path

serviceAEndpoint=http://host:port/some/service/path?dynamicParam=

Simple SOAP Request and Response

 package com.mugil.org;

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

import javax.jws.WebService;

@WebService
public class Products 
{
  List<String> arrProducts = new ArrayList<String>();
	
  public Products()
  {
	arrProducts.add("Books");
	arrProducts.add("EReader");
	arrProducts.add("PDF");	
  }
  
  public String getProduct(int index)
  {
	return arrProducts.get(index);  
  }
}

SOAP Request

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:org="http://org.mugil.com/">
   <soapenv:Header/>
   <soapenv:Body>
 
      <org:getProduct>
         <arg0>0</arg0>
      </org:getProduct>
   </soapenv:Body>
</soapenv:Envelope>

SOAP Request

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
      <ns2:getProductResponse xmlns:ns2="http://org.mugil.com/">
         <return>Books</return>
      </ns2:getProductResponse>
   </soap:Body>
</soap:Envelope>

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

Service

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

Porttype

 <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:operation>
  </wsdl:portType>

Binding

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

Types

 <wsdl:types>
      <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="unqualified" targetNamespace="http://org.mugil.com/" version="1.0">
         <xs:element name="getProduct" type="tns:getProduct" />
         <xs:element name="getProductResponse" type="tns:getProductResponse" />
         <xs:complexType name="getProduct">
            <xs:sequence>
               <xs:element name="arg0" type="xs:int" />
            </xs:sequence>
         </xs:complexType>
         <xs:complexType name="getProductResponse">
            <xs:sequence>
               <xs:element minOccurs="0" name="return" type="xs:string" />
            </xs:sequence>
         </xs:complexType>
      </xs:schema>

Message

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

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="MartProducts.com")
.
.
@WebMethod(action="fetch_products", operationName="fetchProducts")
.

name

<wsdl:portType name="MartCatalogue">
.
.

portName and serviceName

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

targetNamespace
Defines unique set of operations under namespace.Defaults to package name in java in reverse order
targetNamespace=”MartProducts.com”

targetNamespace

<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.

 

Challenges

  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.

Solution

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

Challenges

  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.

Solution

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.

Challenges

  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.

 

 

JAX-WS – is Java API for the XML-Based Web Services – a standard way to develop a Web- Services in SOAP notation (Simple Object Access Protocol).

Calling of the Web Services is performed via remote procedure calls. For the exchange of information between the client and the Web Service is used SOAP protocol. Message exchange between the client and the server performed through XML- based SOAP messages.

Clients of the JAX-WS Web- Service need a WSDL file to generate executable code that the clients can use to call Web- Service.

JAX-RS – Java API for RESTful Web Services. RESTful Web Services are represented as resources and can be identified by Uniform Resource Identifiers (URI). Remote procedure call in this case is represented a HTTP- request and the necessary data is passed as parameters of the query. Web Services RESTful – more flexible, can use several different MIME- types. Typically used for XML data exchange or JSON (JavaScript Object Notation) data exchange

SOAP REST
SOAP is a protocol. REST is an architectural style.
SOAP can’t use REST because it is a protocol. REST can use SOAP web services because it is a concept and can use any protocol like HTTP, SOAP.
Uses services interfaces to expose the business logic. Uses URI to expose business logic.
JAX-WS is the java API for SOAP web services. JAX-RS is the java API for RESTful web services.
SOAP standards should be strictly followed since it is protocol REST does not define too much standards like SOAP
requires more bandwidth and heavy requires less bandwidth and resource
SOAP defines its own security RESTful web services inherits security measures from the underlying transport.
SOAP permits XML data format only. REST permits different data format such as Plain text, HTML, XML, JSON etc.
SOAP is less preferred REST more preferred than SOAP

When to use SOAP?

  • Exposes operation over a logic – It aligns to enterprises application needs and goals
  • When using SMTP(Simple Mail Transfer Protocol) and JMS
  • It could be used when multiple systems are involved in Distributed Environment I.E. System A -> System B -> System C
  • In a complex system like banks WSDL serves as a agreed agreement for interpreting data over different system
  • SOAP uses two varieties,Synchronous Messaging over HTTP,Asynchronous Messaging over HTTP
    With synchronous messaging, the Requestor makes a request and the transport layer code blocks waiting for a response from the Provider. The Requestor receives the response on the same HTTP connection that the Requestor initially established to send the request. Synchronous exchange is usually easier to implement and requires that the Provider be able to generate a response in a short time, specifically in a time less than the HTTP timeout value(generally 120sec). [A single HTTP Connection is used that itself behaves Synchronously]
    With asynchronous messaging, the Requestor is able to release transport specific resources once the request is acknowledged by the responder, knowing that a response will eventually be received. When the Provider completes the processing of the message it sends a response back to the Requestor over a new HTTP connection. [Here we utilize two HTTP Connections to implement an asynchronous messaging]

    1. first HTTP Connection is used that for sending the Request and receiving an acknowledgement HTTP Response 200/OK
    2. second HTTP Connection is used for receiving the callback and responding HTTP Response 200/OK]
  • SOAP has a option for Service Registry where you can see who is registered for services and who could consume our services
  • Ideal for enterprise application where security(WS-Security), transaction(WS-AT) and reliability(WS-RM) are main concerns

When to use REST?

  • Exposes Resources over data – Simple point to pint communication between two systems System A -> System B
  • While working with synchronous environment
  • Could be used if you want to communicate over Stateless protocol like HTTP/HTTPS
  • It could be consumed by any Client simple by using AJAX and Javascript
  • Rest mostly uses resource as nouns and verbs like delete user, add user, edit user in its URI model
  • REST is purely an HTTP transport based call and you will receive a response say 200 OK. Synchronous messaging. The disadvantage is in order to
    have good scale-ability the architecture should be asynchronous
  • Ideal for mashup where datas are taken from various resources like twitter and less secured data communication