Demystifying Web Services Through Java EE
Web Service is typically a business logic located somewhere in the Internet, accessible through standard Internet based protocol such as HTTP or SMTP. Then HTML or Servlet? Well, they also provide some service in the web but “web service” per se has a different connotation particularly associated with Service Oriented Architecture (SOA). In the case of “web service”, application components can inter-operate seamlessly in a platform-neutral, language-neutral fashion. This interoperability actually incorporates heterogeneity (which is also the crux of the distributed computing model), where a consumer/client is able to invoke services using a self-explanatory interface. This simple interface describes available business methods. The consumer/client does not have to bother about its underlying implementation, which may be written in a variety of languages (Java, Visual Basic, C++, C#, C etc.) at the producer/server end.
If you want your application to get the list of books available in amazon.com, you can only access the list of books if amazon.com provides a web services delivering book list. It doesn't matter in which language the bookList web service is written. This can be done in two ways in Java as discussed below.
Web Service in Java
There are primarily two different types of web service supported in Java. Both are popular and extensively used.
- JAX-WS: Based on SOAP (Simple Object Access Protocol).
- JAX-RS: Based on REST (Representational State Transfer).
SOAP uses XML as a means of loosely coupled communication. SOAP web service registers its interface into the UDDI (Universal Description Discovery and Integration) registry, from where consumer knows the interface of the service and the message format. Consumer then sends a request to the service producer and receives a response.
WSDL (Web Service Description Language) is a standardized XML format for describing network services. The description provides the name of the service, the location of the service and ways to communicate with the service. It defines the protocol, interface, message types and interaction between the consumer and the provider. UDDI is similar to Phone book. It can be used for storing and categorizing SOAP web service interfaces (WSDL).
Web 2.0 of Java EE7 is particularly suitable for RESTful web services. Unlike SOAP, which is protocol based, REST is an architectural based web service. RESTful services are stateless and can make use of HTTP cache and proxy servers, which can handle high load and scale better. Much simpler than SOAP, they are easy to build as no special toolkit or WSDL is required. RESTful web service uses WADL (Web Application Description Language) to expose interaction with the consumer. REST treats every piece of information as a resource and these resources are addressed using Uniform Resource Identifier(URI). This principle made RESTful applications to be simple, lightweight and to have high performance.
RESTful web services have a uniform interface (HTTP methods and URIs), once consumer knows where the resource (URI) is, one can invoke the HTTP method (GET, POST, etc.).
Choice Between SOAP and REST
They are not comparable architecturally because one is protocol-wise and another is architecture-wise but service-wise there are certain differences where each may outweigh the other in a particular circumstance.
- WS-Security: SOAP supports SSL (like JAX-RS). Apart from that it also supports WS-Security, a standard specification, which adds some enterprise security features.
- WS-Atomic Tranaction: This specification can be used when one needs ACID transaction over a service. While REST supports transaction, it isn't as comprehensive and isn't ACID compliant.
- WS-ReliableMessaging: REST doesn't have a standard messaging system and expects clients to deal with communication failures by retrying. SOAP has built-in success/retry logic and provides end-to-end reliability through SOAP intermediaries.
- Creating clients, developing APIs and understanding documents is much easier than SOAP.
- REST can work on a variety of data formats whereas SOAP only permits XML.
- JSON is a better fit for data in REST and parses very fast.
- REST reads can be cached, SOAP based reads cannot be cached.
- REST has better performance and scalability.
In the Enterprise arena both are quite popular though the trend is now more towards RESTful web services. The main reason is its simplicity and productive flexibility. Since most of the web services built until now are SOAP based, JAX-RS would not suffer the same fate as JAX-RPC which has almost fallen into oblivion from Java EE7. Web service in now the current buzzword to inter-operate between two or more technological implementations in a language neutral fashion.