JAX WS WebService - Yash-777/SteamingServlet GitHub Wiki
Welcome to JAX-WS Tutorial. Web Services work on client-server model where they communicate over the network. Server side component provides the endpoint URL where service is located and client application can invoke different methods.
This WebService can be called by a Software Application using SOAP or HTTP protocol.
There are two types of web services:
- SOAP Web Services - Supports only (XML)
- Restful Web Services - Supports (XML, JSON, Text, Multipart (
Images,*.xml, *.pdf
), YAML, XOP, Atom, etc.)
Web services are stateless so we can’t maintain user sessions in web services.
Journaldev
- REST: Easy Tutorial with Eclipse and Tomcat,
Jersey Java Tutorial
- SOAP Webservices in Java Example using Eclipse,
RPC
andAXIS2 Web Services Tutorial
- Web Services Interview Questions – SOAP, RESTful
REST is the acronym for REpresentational State Transfer. REST is an architectural style for developing applications that can be accessed over the network. REST architectural style was brought in light by Roy Fielding in his doctoral thesis in 2000.
REST is a stateless client-server architecture where web services are resources and can be identified by their URIs. Client applications can use HTTP GET/POST methods to invoke Restful web services. REST doesn’t specify any specific protocol to use, but in almost all cases it’s used over HTTP/HTTPS. When compared to SOAP web services, these are lightweight and doesn’t follow any standard. We can use XML, JSON, text or any other type of data for request and response.
Some of the important JAX-RS annotations are:
-
@Path
: used to specify the relative path of class and methods. We can get the URI of a webservice by scanning the Path annotation value. -
@GET, @PUT, @POST, @DELETE and @HEAD
: used to specify the HTTP request type for a method. -
@Produces, @Consumes
: used to specify the request and response types. -
@PathParam
: used to bind the method parameter to path value by parsing it.
Some implementations of JAX-RS API.
- Jersey: Jersey is the reference implementation provided by Sun. For using Jersey as our JAX-RS implementation, all we need to configure its servlet in web.xml and add required dependencies. Note that JAX-RS API is part of JDK not Jersey, so we have to add its dependency jars in our application.
- RESTEasy: RESTEasy is the JBoss project that provides JAX-RS implementation.
- Swagger
Some of the advantages of REST web services are:
- Learning curve is easy since it works on HTTP protocol
- Supports multiple technologies for data transfer such as text, xml, json, image etc.
- No contract defined between server and client, so loosely coupled implementation.
- REST is a lightweight protocol
- REST methods can be tested easily over browser.
Some of the disadvantages of REST are:
- Since there is no contract defined between service and client, it has to be communicated through other means such as documentation or emails.
- Since it works on HTTP, there can’t be asynchronous calls.
Sessions can’t be maintained.
SOAP
SOAP stands for Simple Object Access Protocol. SOAP is an XML based industry standard protocol for designing and developing web services. Since it’s XML based, it’s platform and language independent. So our server can be based on JAVA and client can be on .NET, PHP etc. and vice versa.
We can create SOAP web services using JAX-WS API, however some of the other frameworks that can be used are Apache Axis and Apache CXF. Note that they are not implementations of JAX-WS API, they are totally different framework that work on Servlet model to expose your business logic classes as SOAP web services.
WSDL
WSDL stands for Web Service Description Language. WSDL is an XML based document that provides technical details about the web service. Some of the useful information in WSDL document are: method name, port types, service end point, binding, method parameters
etc.
Some of the different tags in WSDL xml are:
-
xsd:import
namespace and schemaLocation: provides WSDL URL and unique namespace for web service. -
message
: for method arguments -
part
: for method argument name and type -
portType
: service name, there can be multiple services in a wsdl document. -
operation
: contains method name -
soap:address
for endpoint URL.
UDDI
UDDI is acronym for Universal Description, Discovery and Integration. UDDI is a directory of web services where client applications can lookup for web services. Web Services can register to the UDDI server and make them available to client applications.
There are two ways to create web service:
Contract first or Top Down Approach: In this approach, we first create the web service contract i.e. WSDL file and then create the implementation for it.
In Top Down approach first WSDL document is created to establish the contract between web service and client and then code is written, it’s also termed as contract first approach. This is hard to implement because classes need to be written to confirm the contract established in WSDL. Benefit of this approach is that both client and server code can be written in parallel.
Contract last or Bottom up approach: In this approach we first create the implementation and then generate the WSDL file from it. Our implementation fits in this category.
In Bottom Up approach, first web service code is written and then WSDL is generated. It’s also termed as contract last approach. This approach is easy to implement because WSDL is generated based on code. In this approach client code have to wait for WSDL from server side to start their work.
SOAP web service style
- DOCUMENT or literal (wrapped) -
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT)
- RPC or encoded -
@SOAPBinding(style = SOAPBinding.Style.RPC)
We can create SOAP web services in RPC style or Document style. We can use any of these styles to create web services, the different is seen in the way WSDL file is generated.
RPC style generate WSDL document based on the method name and it’s parameters. No type definitions are present in WSDL document. Document style contains type and can be validated against predefined schema.
<!-- SOAPBinding.Style.RPC -->
<types/>
<message name="sayHello">
<part name="arg0" type="xsd:string"/>
</message>
<message name="sayHelloResponse">
<part name="return" type="xsd:string"/>
</message>
<!-- SOAPBinding.Style.DOCUMENT -->
<types>
<xsd:schema>
<xsd:import namespace="https://service.jaxws.journaldev.com/" schemaLocation="https://localhost:8888/testWS?xsd=1"/>
</xsd:schema>
</types>
<message name="sayHello">
<part name="parameters" element="tns:sayHello"/>
</message>
<message name="sayHelloResponse">
<part name="parameters" element="tns:sayHelloResponse"/>
</message>
Open schemaLocation URL in browser and you will get below XML. schemaLocation.xml
<?xml version='1.0' encoding='UTF-8'?>
<!-- Published by JAX-WS RI (https://jax-ws.java.net). RI's version is JAX-WS RI 2.2.10 svn-revision#919b322c92f13ad085a933e8dd6dd35d4947364b. -->
<xs:schema xmlns:tns="https://service.jaxws.journaldev.com/" xmlns:xs="https://www.w3.org/2001/XMLSchema" version="1.0" targetNamespace="https://service.jaxws.journaldev.com/">
<xs:element name="sayHello" type="tns:sayHello"/>
<xs:element name="sayHelloResponse" type="tns:sayHelloResponse"/>
<xs:complexType name="sayHello">
<xs:sequence>
<xs:element name="arg0" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="sayHelloResponse">
<xs:sequence>
<xs:element name="return" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
So here WSDL document can be validated against the schema definition.
What is sun-jaxws.xml file? This file is used to provide endpoints details when JAX-WS web services are deployed in servlet container such as Tomcat. This file is present in
WEB-INF
directory and contains endpoint name, implementation class and URL pattern. For example;
sun-jaxws.xml
<?xml version="1.0" encoding="UTF-8"?>
<endpoints xmlns="https://java.sun.com/xml/ns/jax-ws/ri/runtime" version="2.0">
<endpoint
name="PersonServiceImpl"
implementation="com.journaldev.jaxws.service.PersonServiceImpl"
url-pattern="/personWS"/>
</endpoints>
Just run the below program and your web service will be published at the given endpoint in the program. We can access it’s WSDL document by adding ?wsdl
to the endpoint url.
public class SOAPPublisher {
public static void main(String[] args) {
Endpoint.publish("https://localhost:8888/ws/person", new PersonServiceImpl());
}
}
You can change the WSDL document name but it’s good to have it with implementation class name to avoid confusion later on.
We can use wsimport utility to generate the client stubs. This utility comes with standard installation of JDK. Below image shows what all java classes we get when we run this utility.