Webservices

Webservices is a distributed technology, using web services you can communicate among heterogenous Applications to achieve the interoperability. Webservices System mainly has 3 components: > SOAP(Simple Object Access Protocol) > WSDL(Web Services Description Language) > UDDI (Universal Description Discovery Integration) Two Roles in Webservices are: 1.Web Service Provider 2.Web Service Consumer

Service oriented architecture

What is SOAP?

SOAP stands for Simple Object Access Protocol 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 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

SOAP versions

SOAP versions Soap 1.0 Soap 1.1 Soap 1.2 JAX-RPC implementation uses Soap 1.1 JAX-Ws implementation uses Soap 1.2

SOAP Communication Model

1.RPC Communication Model 2.Messaging Communication Model RPC: -RPC is function centric -RPC has tight coupling b/w the message and the implementation Messaging: -Messaging is Data centric -Messaging has loose coupling b/w the message and the implementation

SOAP Message Model

A SOAP message consists of an envelope containing: - An optional header containing zero or more header entries. The name space identifier for the elements and attributes are defined in this section: http://schemas.xmlsoap.org/soap/envelope/ <s:envelope xmlns:s=http:// schemas.xmlsoap.org/soap/envelope >

Header Header entries may be tagged with the following optional SOAP attributes: actor :which specifies the intended recipient of the header entry in terms of a URI, and mustUnderstand: which specifies whether or not the intended recipient of the header entry is required to process the header entry. Message Elements:The classes which represent SOAP messages form a class hierarchy based on the MessageElement class which takes care of namespaces and encodings. The SOAPHeaderElement class looks after the actor and mustUnderstand attributes.

Deserialization

During deserialization, a parse tree is constructed consisting of instances of the above classes in parent-child relationships as shown below.

SOAP Fault: The SOAP fault element is used to carry error and/or status information within a SOAP message. The SOAP fault element MUST appear as a body entry and MUST NOT appear more than once within a Body element. Soap Fault element defines the following four subelements: Fault code: Fault element is used by software to provide an algorithm mechanism for identifying the fault. Fault string: Fault String element is used to provide human readable explanation of the fault and is not for the algorithmic processing. Fault actor: fault actor element is used to provide information about who caused the fault to happen within the message path.

SOAP Request
The request body describes: - The name of the method to invoke. Optional arguments to pass to that method may be identified by order or by name <s:envelope xmlns:s=http://schemas.xmlsoap.org/soap/envelope> <s:header/> <s:body> <ns2:getMessage xmlns:ns2=http:jaxws.xyz.com/> <name>Mahendra</name> </ns2:getMessage> <s:body> </s:envelope>

SOAP Response
The Response body describes: The return values from the method or soap fault. <s:envelope xmlns:s=http://schemas.xmlsoap.org/soap/envelope> <s:body> <ns2:getMessageResponse xmlns:ns2=http:jaxws.xyz.com/> <return>Hello Mahendra Welcome to World of Web services. </return> </ns2:getMessageResponse> </s:body> </s:envelope>

What is WSDL?

WSDL is an XML-based language for locating and describing Web services. WSDL stands for Web Services Description Language WSDL is based on XML WSDL is a W3C standard WSDL Describes Web Services and exposes the services

The main structure of a WSDL document:

<definitions> <types> definition of types........ </types> <message> definition of a message.... </message> <portType> definition of a port....... </portType> <binding> definition of a binding.... </binding> </definitions>

WSDL Ports

The <portType> element is the most important WSDL element. > It describes a web service, the operations that can be performed, and the messages that are involved. > The <portType> element can be compared to a function library (or a module, or a class) in a traditional programming language.

WSDL Messages

The <message> element defines the data elements of an operation.

> Each message can consist of one or more parts. The parts can be compared to the parameters of a function call in a traditional programming language.

WSDL Types

The <types> element defines the data types that are used by the web service. For maximum platform neutrality, WSDL uses XML Schema syntax to define data types.

WSDL Bindings
The

<binding> element defines the message format and protocol details for each port.

WSDL Example

This is a simplified fraction of a WSDL document: <message name="getTermRequest"> <part name="term" type="xs:string"/> </message> <message name="getTermResponse"> <part name="value" type="xs:string"/> </message> <portType name="glossaryTerms"> <operation name="getTerm"> <input message="getTermRequest"/> <output message="getTermResponse"/> </operation> </portType>

In this example the <portType> element defines "glossaryTerms" as the name of a port, and "getTerm" as the name of an operation. The "getTerm" operation has an input message called "getTermRequest" and an output message called "getTermResponse". The <message> elements define the parts of each message and the associated data types. Compared to traditional programming, glossaryTerms is a function library, "getTerm" is a function with "getTermRequest" as the input parameter, and getTermResponse as the return parameter.

Operation Types

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

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

Three Specification by sun to develop webservices are

JAX-RPC JAX-WS JAX-RS JAX-RPC (java API for XML Remote procedure Calling) This specification has implemented by Apache Following are various implementation of JAX-RPC these are used to develop webservices IBM SOAP Apache SOAP AXIS 1.4(Apache extensible interaction System)

Developing Web Services using JAX-RPC

Apache Soap

Apache is a runtime environment to receive the webservice client request, invoking business defined methods in the webservice and sending the response to the webservice client. Apache Soap is based on JAX-RPC specification. You should enable soap engine or soap runtime environment in any of your servers

Enabling the Apache soap engine

Steps to enable soap engine in tomcat: 1.copy soap.war into Tomcat5.0\webApps 2.copy following jar files to Tomcat5.0\common\lib soap.jar activation.jar mail.jar xerces.jar tools.jar >set the classpath for the above files & Start the server Type the following url: http://localhost:8080/soap/servelet/rpcrouter To see what services are running into the server http://localhost:8080/soap Now soap Engine is ready in Tomcat.

Example
Public class Hello{ Public String getMessage() { return Welcome to Apache SOAP web services; } } Create jar file and copy into lib \common\lib folder Deployment Descriptor: HelloDD.xml <?xml version=1.0> <mk: service xmlns:mk=http:// xml.apache.org/xmlsoap/deployment id=urn:HelloService> <mk:provider type=java scope=Application methods=getMessage> <mk:java class=com.soap.Hello static=false/> </mk:provider> <mk:faultListener>org.apache.soap.server.DOMFaultListener </mk:faultListener> </mk:service>

Register the web service with soap engine from command line

java org.apache.soap.server.servicemanagerClient http://localhost:8080/soap/servlet/rpcrouter deploy HelloDD.xml

To undeploy the web service from command line: java org.apache.soap.server.servicemanagerClient http://localhost:8080/soap/servlet/rpcrouter undeploy HelloDD.xml

Client:
import java.net.*; import org.apache.soap.*; import org.apache.soap.rpc.*; Public class HelloClient{ Public static void main(String args[]) throws Exception { String endpoint= http://localhost:8080/soap/servlet/rpcrouter; Call call=new Call(); call.setTargetObjectURI(urn:HelloService); call.setMethodName(getMessage); URL url=new URL(endpoint); Response res=call.invoke(url,); If(res.generatedFault()){ Fault f=res.getFault(); System.out.println(Fault Code+f.getFaultCode() ); System.out.println(Fault String+f.getFaultString()); }else{ Parameter pm =res.getReturnValue(); System.out.println(pm.getValue()); } } }

Architectural Overview of Axis 1.2

Axis consists of several subsystems working together Handlers and the Message Path in Axis :

Axis is all about processing Messages. When the central Axis processing logic runs, a series of Handlers are invoked in order. The particular order is determined by two factors deployment configuration and whether the engine is a client or a server. The object which is passed to each Handler invocation is a MessageContext.

A MessageContext is a structure which contains several important parts: 1) a "request" message, 2) a "response" message, and 3) a bag of properties. There are two basic ways in which Axis is invoked: As a server, a Transport Listener will create a MessageContext and invoke the Axis processing framework. As a client, application code will generate a MessageContext and invoke the Axis processing framework.

Message Path on the Server

The server side message path is shown in the following diagram. The small cylinders represent Handlers and the larger, enclosing cylinders represent Chains

A message arrives (in some protocol-specific manner) at a Transport Listener. Listener's job to package the protocolspecific data into a Message object and put the Message into a MessageContext. The MessageContext is also loaded with various properties by the Listener The Transport Listener also sets the transportName String on the MessageContext Once the MessageContext is ready to go, the Listener hands it to the AxisEngine

Message Path on the Client

The Message Path on the client side is similar to that on the server side, except the order of scoping is reversed, as shown below.

The service Handler, if any, is called first - on the client side, there is no "provider" since the service is being provided by a remote node, The service request and response Chains perform any service-specific processing of the request message on its way out of the system, and also of the response message on its way back to the caller.

AXIS1.4

Apache extensible interaction system. Axis1.4 is based on JAX-RPC specification. Apache soap also for implementing RPC based web services but apache soap has various drawbacks related to performance.

Java Bindings for Web Services

Java platform provides effective binding tools. JAXB binding to XML JAX-WS binding to WSDL and SOAP JAX-RS binding to HTTP

JAXB - Binding Java code to XML Schema

JAX-WS - Binding Java code to WSDL

JAX-WS - Binding Java code to SOAP

JAX-RS - Binding Java code to HTTP

Code First and Contract First With JAX-WS: Code First:

Annotate Your Code Deploy it in a container that supports JAX-WS, JAX-RS The JAX-WS runtime will: Generate WSDL. Translate SOAP request to a Java technologybased method invocation. Translate method return into a SOAP response. The JAX-RS runtime will: Translate HTTP request to a Java technologybase method invocation. Translate method return into HTTP response.

Contract First:

Compile the WSDL for the service that you would like to deploy. wsimport reads the WSDL and generates and interface for each portType. Create a class that implements each interface. The business logic of these classes implements your Web services. Deploy these Service Endpoint Implementation classes to a JAX-WS container.

Developing Web Services using JAX-WS:

JAX-WS stands for Java API for XML Web Services. JAX-WS is a technology for building web services and clients that communicate using XML. JAX-WS allows developers to write message-oriented as well as RPC-oriented web services. In JAX-WS, a remote procedure call is represented by an XML-based protocol such as SOAP. The SOAP specification defines the envelope structure, encoding rules, and conventions for representing remote procedure calls and responses. These calls and responses are transmitted as SOAP messages (XML files) over HTTP.

With JAX-WS clients and web services have a big advantage:

The platform independence of the Java programming language. In addition, JAX-WS is not restrictive: a JAX-WS client can access a web service that is not running on the Java platform, and vice versa. This flexibility is possible because JAX-WS uses technologies defined by the World Wide Web consortium (W3C): HTTP, SOAP, and the Web Service Description Language (WSDL). WSDL specifies an XML format for describing a service as a set of endpoints operating on messages.

Creating a Simple Web Service and Client with JAXWS:

Basic steps for creating the webservice and client with Jax-ws

Code the implementation class. Compile the implementation class. Deploy the WAR file. The tie classes (which are used to communicate with clients) are generated by the Application Server during deployment. Code the client class. Use wsimport to generate and compile the stub files. Compile the client class. Run the client.

Service Endpoint Implementation Class

package helloservice.endpoint; import javax.jws.WebService; @WebService("http://localhost:8080/helloservice/hello) public class Hello { private String message = new String ("Hello, "); public void Hello() { } @WebMethod() public String sayHello(String name) { return message + name + "."; } }

package simpleclient; import javax.xml.ws.WebServiceRef; import helloservice.endpoint.HelloService; import helloservice.endpoint.Hello; public class HelloClient { @WebServiceRef(Targetendpoint="http://localhost:8080/helloservice/hello? wsdl") static HelloService service; public static void main(String[] args) { try { HelloClient client = new HelloClient(); client.doTest(args); } catch(Exception e) { e.printStackTrace(); } } public void doTest(String[] args) { try { System.out.println("Retrieving the port from the following service: " + service); Hello port = service. getHelloPort(); System.out.println("Invoking the sayHello operation on the port."); String name; if (args.length > 0) {name = args[0];} else {name = "No Name"; } String response = port.sayHello(name); System.out.println(response); } catch(Exception e) {

JAX-RS

JAX-RS is more like Code First than Contract First No WSDL contract. However, XML Schema may provide a contract for the XML payload. Annotations are used to map Java code to REST endpoints (URIs) and to HTTP operations.

@Path(/somepath/orderManager) public class OrderManager { @POST @PATH(/{ordNum}) @ConsumeMime(application/xml) public void submitOrder( @PathParam(ordNum") String ordNum, Source order) { } }

and also to map Java code to HTTP operations

REST - Representational State Transfer

Representational state transfer (REST) with Java (JAX-RS) using Jersey REST is a architectural style for an application which is highly based on web-standards and the HTTP protocol. REST was first described by Roy Fielding in 2000. The most important concept in REST is resources, which are identified by global IDs typically using URIs.

In a REST based architecture everything is a resource. A resource is accessed via a common interface based on the HTTP standard methods. In an REST architecture you typically have a REST server which provides access to the resources and a REST client which accesses and modify the REST resources. REST allows that resources have different representations, e.g. text, xml, etc. The rest client can ask for specific representation via the HTTP protocol (Content Negotiation).

HTTP methods

The HTTP standards methods which are typical used in REST are PUT, GET, POST, DELETE. GET: defines a reading access of the resource without side-effects. The resource is never changed via a GET request. PUT: creates a new resource or updates an existing resource. DELETE: removes the resources. The operations are idempotent, they can get repeated without leading to different results. POST: updates an existing resource. The base/root URI for the Web service such as http://host/<appcontext>/resources. The MIME type of the response data supported, which are JSON/XML/ATOM and so on.