Java WebServices

SOA
    It is collection of architectural principles to design and implement our software applications in such a way they are composed of several software services that have simple and well defined interfaces and can use each other in a loosely coupled manner.

Webservices is a way to implement SOA priciples. There are 2 types of webservice technologies. SOAP & REST. Standard for SOAP in java world is Jax-WS. Similarly Jax-Rs for Rest.

SOA (service oriented architecture) is a set of architectural principles to build loosely coupled applictions. It is maintained by open bodies like W3C
webservices is a way to implement those principles in our applications that we create

Service: According to SOA, it is implementation of business logic  that operates independent of state of an other service.  

Web services are Consumer/Provider applications that communicate on Network thru HTTP protocol. They exchange messages or data as XML, SOAP, JSON.

• They provide interoperability between software applications.(Platform independent)
• Loosely couple applications(Switch to any other services which provides same service)
• Extensibility
• Reusability 
• Scalability - Deploy on multiple servers
• Availability - Available even if one of the servers is down
• Mashups - Build mashup application by consuming several different services that are available out there with in enterprise OR over internet.

Types of webservices(webservice technologies)
   - SOAP based- communicates using soap xml and Uses HTTP Post for message exchange. Follows JAX-WS standards
   - RESTful services - Uses HTTP methods to the full & supports multiple data formats for data exchange. Follows JAX-RS standards

In Java world

• JAX-WS(Java api for XML based webservices) is the standard for implementing SOAP based webservices
•  JAX-RS(Java api for  RESTful webservices) is a standard for implementing Restful webservices

Webservice is a specification.  It is a set of rules and guidelines to share data between 2 interoperable applications.

• soW3C & OASIS defines and maintains the specification or principles 

Components suggested by webservice to support communication are:
  wsdl -> Webservice description language
  uddi(optional) -> universal
  skeleton
  stub
  soap protocol
  http protocol

WSDL sections:

Soap Bindings: Effect the way wsdl gets generated. Suppose for following method def
public void myMethod(int x, float y);

1. RPC/encoded (types are defined directly in message). They do not go to xml xsd of wsdl types.

Strengths:

• WSDL is straight forward
• Operation name appears in the message, 

Weaknesses:

• type encoding is overhead in SOAP message. 
• not WSI compliant
•  

RPC /literal:

 

 

Strenghts:

• Type encoding eliminated
• WS-I compliant

Weakness

• Cannot easily validate from schema

 Document/Encoded - No body follows and not WS-I compliant

 Document/Literal -

 

•   Strengths
• No type encoding
• WS-i compliant with restrictions.
• can validate message with any XML validator
• Weakness
• WSDL is bit more complicated
• Operation name in message body is not available. 
• Operation name is gone. Engines will have tough time to dispatch the request.

 Document/Literal Wrapped: Preferred style

2. RPC/literal ()




DOCUMENT/encoded
DOCUMENT/literal

wsdl contains name of service class, name of method, # of parameter and parameter types.
wsdl is uploaded uddi registry with a unique name.
Clint will download wsdl from uddi, and generate stub using stub generation tool. The methods available in service class will be available in stub also.
Stub will create SOAP request and send it to server using HTTP protocol
Server will hand over the request to the skeleton. Skeleton invokes the actual api on the service class and receives the result value. It prepares SOAP response and sends it back to stub.
Stub in turn returns the value to client program.

SUN has provided 4 APIS. JAX-RPC, JAX-M(xml messaging), JAX-WS, JAX-RS
They contain wsdl generation tools, skeleton and stub generation tools. We can develop both client and service.
SAX-M is used for asynchronous web service while others are for synchronous web service. 

Service development and communication works in the following manner:
Service provider
1. A service class(POJO class) is created and deployed on a webserver
2. Generate wsdl using wsdl generation tool
3. upload the wsdl to uddi or share it to client directly

Client
4. Client- download wsdl from uddi
5. Client- generate stub using stub generation tool
6. Create Client application  - instantiate stub class and call required method on it

Communication:
7. Client application calls method on stub object.
8. Stub generates SOAP requests with parameter values and sends to server using HTTP protocol
8. Server receives the SOAP request and forwards to skeleton.
9. Skeleton invokes the actual method on the service class
10. Skeleton receives the return value
11. Skeleton prepares SOAP response with return value and sends it to stub
11. stub receives the return value and sends it over to client program.

JAX-RPC- Java API for xml- Remote procedure call. It is a specification given by SUN as part of jdk1.4. This API can be used to develop both SOAP based web services or SOAP based web service client
 implementations:
             jax-rpc-si  (sun implementation) - not part of jdk. need to be downloaded separately
             Axis1 - Apache foundation
             weblogic implementation - bea/oracle - part of weblogic software
             websphere - IBM
              jboss - RedHat

All the above should provide wsdl generation tool, skeleton and stub generation tools

JAX-WS- Implementations -
      JAX-WS-RI (reference implementation) - SUN - available in jdk1.6
      METRO - full implementation -  SUN - download separetely
      Axis2 - Apache foundation
      Apache CXF - supports Spring integration where as Axis2 is not
      weblogic implementation
      websphere
       jboss
      glassfish - sun - it internally refers to Metro implementation

JAX-RS- implementations: specification is part of jdk1.6
  Java api for xml - restful services
     Jersey - sun - need to download separately
     RESTEASY - REDHAT
     RESTLET -
     APACHE CXF - Supports String integration
     APACHE WINK - doesn't Supports String integration

Webservice example using Axis1 implementation Manually
Axis1 is Jax-RPC implementation
1. Download Axis1 jar
2. Create a webappliction, copy axis1 jar files into WEB-INF/lib folder and then configure skeleton(org.apache.axis.transport.http.AxisServlet in web.xml)
3. In WEB-INF/classes folder create HelloService.java(service class)
4. Set axis1 jar files in the classpath and generate wsdl file

   java org.apache.axis.wsdl.Java2WSDL -o HelloService.wsdl -n http://www.hello.com
           -l http://localhost:8080/<skeleton url pattern>  <unique service class name>
5. Provide unique name to Service class in server-config.wsdd file
6. deploy the webservice

Webservice example using Axis1 implementation in Eclipse
1. Create dynamic web project
2. Create service class
3. Follow steps to convert the service class into webservices using axis1 implementation.
right click on the service class -> new -> others -> webservices->  webservice-> select server & webservice runtime options -> finish.

(Eclipse internally will create required files like wsdl, configures skeleton in web.xml with some url pattern, creates server-config.wsdd in WEB-INF folder and copies axis1 jar files to lib folder.
 Also deploys the application to server.)

Now the service is ready. Open browser and use end point url (from wsdl file) appended with ?wsdl
eg: http://localhost:8081/HelloService/services/HelloServ?wsdl

if the service provider, provides the wsdl, then the service is successfully deployed and running on to server.

Webservice client using Axis1 implementation in Eclipse
Types of webservice clients
 1. Proxy based client (Client generates stubs and uses them to invoke the service)
 2. DII client -> Dynamic invocation interface client (webservice implementation provider classes are used to invoke the webservice)

In both the types, client requires wsdl file or wsdl url to create webservice client
(wsdl contains service class details + end point url(Location where service is running))

1. Create a java project.
2. Copy wsdl file into client java project root directory
3. Generate stubs/proxies.  src folder -> new -> others-> webservices -> webservice client
-> provide wsdl, select server and webservice runtime options.
This step will copy axis jars to build/class patch. In src it will generate stubs.
Stubs will have the methods that are available in SERVICE class with a different implementation.

4. Create TestHello.java with main method and use generated stubs in main method to invoke webservice

    public static void main(String[] args) throws Exception {
          java.net.URL endpointurl= new java.net.URL("http://localhost:8081/HelloService/services/HelloServ");
        org.apache.axis.client.Service service = new org.apache.axis.client.Service();
        HelloServSoapBindingStub stub = new HelloServSoapBindingStub(endpointurl, service);
        String str=stub.hello("venkat.....");
        System.out.println(str);
    }

Webservice example using Axis2 implementation in Eclipse
Eclipse has the Axis2 plugins but not Axis2 jar files
1. Download Axis2 jars and extract downloaded zip file
2. Add Axis2 jars to eclipse (Windows-> preferences -> webservices -> Axis2 preferences -> add root directory of axis2 extracted folder)
3. Create dynamic webproject
4. Create HelloServ2.java in src folder.
5. Convert HelloServ2.java into webservice using Axis2
(Eclipse internally will create required files like wsdl, configures skeleton in web.xml with some url pattern, creates server-config.wsdd in WEB-INF folder and copies axis1 jar files to lib folder.
 Also deploys the application to server.)
6. Open browser and enter http://localhost:8081/<project name>. Go to services and copy the end point url
6. Test whether service is deployed or not.
http://localhost:8081/HelloAxis2/services/HelloServ2?wsdl

Webservice client using Axis2 implementation in Eclipse

1. Create a dynamic web project(2.5 version).

2. Generate stubs/proxies.  src folder -> new -> others-> webservices -> webservice client
-> provide wsdl, select server and webservice runtime options.
This step will copy axis jars to build/class patch. In src it will generate stubs.

4. Create TestHello.java with main method and use generated stubs in main method to invoke webservice

For every SERVICE class method, stub will have respective method & an inner classes(request & response). The method parameters are declared as class members with setters/getters.

Invoke the service method on STUB by passing inner class object as parameter.

    public static void main(String[] args) throws Exception {
        HelloServ2Stub stb = new HelloServ2Stub();
        HelloServ2Stub.Hello params= new HelloServ2Stub.Hello();
        params.setStr("venkat,,.");
        HelloServ2Stub.HelloResponse res=stb.hello(params);
        System.out.println(res.get_return());
    }


Why REST is light weight compared to SOAP?

• SOAP is XML only, while REST allows you to send any payload, such as JSON which is less verbose and simpler than XML. Generally speaking, it takes less memory and less bandwidth to deal with JSON than XML.
• On another level, using SOAP you typically describe everything as services. So, you need to define a message schema/structure for each verb and noun i.e. "CreateOrder". In REST, you use the predefined HTTP methods such as POST and put the noun/"resource" in the URI which uses already existing constructs on the HTTP level - not reinventing them in XML.
• Then there is the effort it takes to adapt to change. A small change in SOAP requires you to redefine the schema, redefine the wsdl and handle versions. In rest, in the best of worlds, there is a degree of dynamic coded into the API (links to referenced resources, among other things), so that some changes can be implemented and takes effect directly.
• All the heavy weight strictness of SOAP of course has a valid reason for existence. It's less likely two implementations have different interpretations of the API, than in a loosely defined REST API. SOAP also allows you to implement skeleton code in various languages based on a WSDL. In some complex scenarios, this is actually almost the only productive way to work with SOAP. Marshalling and unmarshalling between objects and serialized XML is rather heavy and adds to the heavyness of SOAP.
• REST will return only data structure defined by XSD (DataContract) but the SOAP will wrap the structure into SOAP envelope. The complexity of SOAP envelope is based on used message version and additional WS* protocols.
• SOAP was designed for a distributed computing environment where as REST was designed for a point to point environment
• SOAP(using WSDL) is a heavy-weight XML standard that is centered around document passing. The advantage with this is that your requests and responses can be very well structured, and can even use a DTD. The downside is it is XML, and is very verbose. However, this is good if two parties need to have a strict contract(say for inter-bank communication). SOAP also lets you layer things like WS-Security on your documents. SOAP is generally transport-agnostic, meaning you don't necessarily need to use HTTP.
  REST is very lightweight, and relies upon the HTTP standard to do it's work. It is great to get a useful web service up and running quickly. If you don't need a strict API definition, this is the way to go. Most web services fall into this category. You can version your API so that updates to the API do not break it for people using old versions(as long as they specify a version). REST essentially requires HTTP, and is format-agnostic(meaning you can use XML, JSON, HTML, whatever).