Web Services and RESTFul Services

Q# Describe the structure of a SOAP request/ response

The soap request/ response consists of a SOAP envelope. The soap envelope contains the soap header and soap body. The SOAP header gives you an option of putting some stuff in that would be evaluated before the body is processed. The SOAP header may contain authentication information, namespace and method-name invoked, etc. Soap body may contain request and response content.
http://java.sun.com/developer/technicalArticles/xml/webservices/ #Message Format
SOAP performs operations in the context of a standardized message format. The primary part of this message has a MIME type of “text/xml” and contains the SOAP envelope. This envelope is an XML document. The envelope contains a header (optional) and a body (mandatory). The body part of the envelope is always intended for the final recipient of the message, while the header entries may target the nodes that perform intermediate processing, such as endpoint. Attachments, binary or otherwise, may be appended to the body.
Headers, for example, may be used to provide digital signatures for a request contained in the body. In this circumstance, an authentication or authorization server could process the header entry — independent of the body — stripping out information to validate the signature. Once validated, the rest of the envelope would be passed on to the SOAP server, which would process the body of the message.

Q# How do you authenticate a SOAP request?

I have used weblogic.xml.crypto.wss.provider.CredentialProvider to set the user credentials that will be added to the request header after encryption. This information is stripped from the soap header to authenticate the request. The authorization data is passed to the server through the request header each and every time a request is made. The authorization policy is defined in an xml file that is kept in the META-INF folder of the SOAP war/ ear file. The policy.xml says that user should always send username/ password token. The request should then always contain username/ password token.
We implemented “Standard Web Services Security” using username and password tokens passed in the soap header and a policy xml was deployed on the server which executed an EJB that did authentication.
The method itself was exposed as a webservice using annotations in the javax.jws package which is implemented in weblogic jar. Also jboss-ejb3.jar.

Describe how you have created various web services

In one of our previous project we used ejb3 annotations to expose ordinary pojo methods with annotations such as

@WebService(serviceName = "SomeService", portName = "SomeServicePort", targetNamespace = "http://mattiz.com/calculateInterest")

which seems to be in the import javax.jws.WebService; package of weblogic.jar.
The wsdl was automatically created and client stubs were generated using the ant clientgen task.
http://java.sun.com/developer/technicalArticles/J2SE/jax_ws_2/ is a rather a simplistic introduction, but similar to one described above.
In another project we created the wsdl manually and generated stubs using something like wsconsume ant task. The generated stubs are used both client side and server side.

Q# What is the difference between restful services and soap?

From here http://stackoverflow.com/questions/19884295/soap-vs-rest-differences
REST is an architecture. REST is not restricted to HTTP alone. It can use any protocol that follows the URI scheme. SOAP on the other hand uses HTTP alone. The consumer need not know a lot about the services exposed by the Rest service provider. In case of SOAP any undocumented change on either server or client side will break the communication. i.e. Web Service client and server are more tightly coupled than REST. The soap client requires detailed previous knowledge of the web service provider. However, once the entry point is known in REST, the resources are supposed to return links that the client can follow. Rest has a much simpler request and can use JSON as well as XML. It does not have the soap envelope and the headers and can be used for protocols that don’t support these.

From my brief reading, it looks like the main difference between SOAP and RESTful webservices is :
* SOAP exposes a function (or a method call) as an HTTP web service. The method can contain complex business logic etc.
* RESTful web service provides pieces of data as an HTTP web service. Think of RESTful web service as exposing a bunch of getter methods as webservice. The client can invoke the getter functions to retrieve pieces of data and then do what it pleases with the retrieved data. The restful web service provides data similar to how a database would provide data. Each invocation is very light since the web service provider doesn’t have any logic. It just retrieves and sends data.
I found this article useful
“Instead of providing just one endpoint for a particular web service and having that endpoint perform various operations, you provide access to resources.” So the soap web service client can be thin – service provider has lot of logic and data access and does lot of work while in RESTful web service, the provider is very thin – just provides resources (e.g. data). The client can do whatever it likes with the data – complex logic etc. So thin server/ thick client model is implemented and separate uri’s for each resource (or piece of data) are in place. RESTful services looks different from SOAP. SOAP has a method call which takes params and returns params while RESTful service just has separate uri’s for each resource (piece of data).
Here’s an example of how a RESTful service would look different from soap:
A soap service could expose a service that looks like this String doComplexStuff(param1, param2, param3, param4) while a RESTful service would look like this http://blah/resource/param1, http://blah/resource/param12 where it is just giving the values asked for and the RESTful service will return param1 and param12 without doing complex processing.
The difference is not whether “light” or “heavy”; the difference is whether you are executing a method call or getting access to resources.Typically RESTful services are supposed to be “light” without complex logic though that’s not to say that it can’t access the db or that it can’t use hibernate.
Restful service provider can use any technique to provide access to resources. The “resource” could be a value retrieved from db using hibernate, DTO, or anything else. For example the client may ask for all a list of DTOs and is returned list of DTOs; its just getting a resource or a list of resources. You can access db resources and return a dto or list of dtos and that would still be RESTful. The difference between SOAP and RESTful services is whether you are exposing a method or exposing your resources. Restful means simply access to resources. You can ignore how the RESTful service is implemented, just focus on the interface exposed to the client. Soap service looks like this – String doComplexStuff(param1, param2, param3, param4) while RESTful service looks like this
It exposes multiple URI’s each URI exposing a single resource. For soap, each url would expose a method that performs some complex task and it’s not just exposing a resource. The difference is philosophical more of a design difference. We can use one technology on one end of a RESTful service and another at the consumer side, its just like a soap webservice – the mechanism is the same.


Because SOAP is a protocol, and REST is an architectural style. SOAP is its own protocol, and is a bit more complex by defining more standards than REST—things like security and how messages are sent. For many of the reasons SOAP is a good choice rarely apply to web services scenarios, which make it more ideal for enterprise-type situations that require more comprehensive features in the way of security, transactions, and ACID (Atomicity, Consistency, Isolation, Durability) compliance.
SOAP is a protocol. REST is an architectural style. An API is designed to expose certain aspects of an application’s business logic on a server, and SOAP uses a service interface to do this while REST uses URIs.
REST APIs access a resource for data (a URI); SOAP APIs perform an operation. REST is an architecture that’s more data-driven; SOAP is a standardized protocol for transferring structured information that’s more function-driven.
REST permits many different data formats including plain text, HTML, XML, and JSON, which is a great fit for data and yields more browser compatibility; SOAP only uses XML.
Security is handled differently. SOAP supports WS-Security, which is great at the transport level and a bit more comprehensive than SSL, and more ideal for integration with enterprise-level security tools. Both support SSL for end-to-end security, and REST can use the secure version of the HTTP protocol, HTTPS.
SOAP requires more bandwidth; REST requires fewer resources (depending on the API). There’s a little more overhead with SOAP out of the gate, on account of the envelope-style of payload transport. Because REST is used primarily for web services, its being lightweight is an advantage in those scenarios.
REST calls can be cached, SOAP-based calls cannot be cached. Data can be marked as cacheable, which means it can be reused by the browser later without having to initiate another request back to the server. This saves time and resources.
An API is built to handle your app’s payload, and REST and SOAP do this differently. A payload is data sent over the internet, and when a payload is “heavy,” it requires more resources. REST tends to use HTTP and JSON, which lighten the payload; SOAP relies more on XML.
SOAP is tightly coupled with the server; REST is coupled to a lesser degree. In programming, the more layers of abstraction between two pieces of technology, the less control you have over their interaction, but there’s also less complexity and it’s easier to make updates to one or the other without blowing up the whole relationship. The same goes for APIs and how closely they interact with a server. This is a key difference between SOAP and REST to consider. SOAP is very closely coupled with the server, having a strict communication contract with it that makes it more difficult to make changes or updates. A client interacting with a REST API needs no knowledge of the API, but a client interacting with a SOAP API needs knowledge about everything it will be using before it can even initiate an interaction.

Q# What is the difference between JAX-WS, JAX-RS,JAX-RPC and what is JAX-B?

From http://www.ibm.com/developerworks/webservices/library/ws-tip-jaxwsrpc/index.html
Web services have been around a while now. First there was SOAP. JAX-rpc
The industry was not merely doing RPC web services, they were also doing message-oriented web services. So “RPC” was removed from the name and replaced with “WS” (for web Services). Thus the successor to JAX-RPC 1.1 is JAX-WS 2.0 – the Java API for XML-based web services.
What is different between JAX-rpc and JAX-ws?
JAX-RPC and JAX-WS support SOAP 1.1. JAX-WS also supports SOAP 1.2.
The WSDL 1.1 specification defined an HTTP binding, which is a means by which you can send XML messages over HTTP without SOAP. JAX-RPC ignored the HTTP binding. JAX-WS adds support for it.
JAX-RPC maps to Java 1.4. JAX-WS maps to Java 5.0. JAX-WS relies on many of the features new in Java 5.0.
Java EE 5, the successor to J2EE 1.4, adds support for JAX-WS, but it also retains support for JAX-RPC, which could be confusing to today’s web services novices.
JAX-RPC has its own data mapping model, which covers about 90 percent of all schema types. Those that it does not cover are mapped to javax.xml.soap.SOAPElement.
JAX-WS’s data mapping model is JAXB. JAXB promises mappings for all XML schemas.
JAX-WS’s dynamic client model is quite different from JAX-RPC’s. Many of the changes acknowledge industry needs:
It introduces message-oriented functionality.
It introduces dynamic asynchronous functionality.
JAX-WS also adds a dynamic server model, which JAX-RPC does not have.
JAX-RPC handlers rely on SAAJ 1.2. JAX-WS handlers rely on the new SAAJ 1.3 specification.

Differences: JAX-RS and JAX-WS; and why JAX-RS is preferrred in modern web applications

Soap is service based while REST is resource based and lighter with less overhead since it doesn’t include authentication, security, transaction, message types and ACID (Atomicity, Consistency, Isolation, Durability) by defining more standards. Soap is resource intensive on the client side(thin client) while REST isn’t which makes REST useful on devices such as mobile phones. Rest is the preferred web service.

REST is particularly useful for limited-profile devices, such as PDAs and mobile phones. It’s not that JSON is so significantly smaller than XML by itself. It’s mostly that JAX-WS specification includes lots overhead in how it communicates. On the point about WSDL and API definitions, REST will more frequently use the URI structure and HTTP commands to define the API rather than message types, as is done in the JAX-WS. This means that you don’t need to publish a WSDL document so that other users of your service can know how to talk to your service. With REST you will still need to provide some documentation to other users about how the REST service is organized and what data and HTTP commands need to be sent. JAX-RS refers to Rest services while JAX-WS is related to web services.

Q# What web services have you used?
Lately I have used Apache CXF with Spring for creating WebServices using annotations – bottom up. Prior to this I used the EJB3 web services using annotations – bottom up. Apache Axis for both bottom up and top down web service creation. Top-down means you start with a WSDL and then create all the necessary scaffolding in Java all the way down. Bottom-up means you start with a Java method, and generate the WSDL from it.

About cuppajavamattiz
Matty Jacob - Avid technical blogger with interests in J2EE, Web Application Servers, Web frameworks, Open source libraries, Relational Databases, Web Services, Source control repositories, ETL, IDE Tools and related technologies.

Comments are closed.

%d bloggers like this: