Web service interview Question and Answer

Web service is a way of communicationthat allows interoperability between different applications on different platforms, for example, a java based application on Windows can communicate with a .Net based one on Linux. The communication can be done through a set of XML messages over HTTP protocol.

Web services are browsersand OS independent service, which means it can run on any browser without the need of making any changes. Web Services take Web-applications to the Next Level.

Let’s say, you are a java developer and you can publish your functions on internet or LAN through java web service so any other developer (let’s say .Net developer) can access your function.

Universal Description, Discovery and Integration (UDDI):

Directory where any publisher can publish their web services and consumer can get access to all web services. Web services can register with a UDDI and make themselves available through it for discovery.

Simple Object Access Protocol (SOAP)

SOAP is a standard protocol specification for message exchange based on XML.
Communication between the web service and client happen using XML messages. SOAP is a XML format used to encode and decode different messages across network so that irrespective of technology it can understand each other.

Simple web service architecture has two components:

·Client

·Service provider

So in order to communicate client must know some information for e.g.

·Location of web services server

·Functions available, signature and return types of function.

·Communication protocol

·Input output formats

Service provider will create a standard XML file which will have all above information. So if this file is given to client then client will be able to access web service. This XML file is called WSDL.

What is WSDL?

WSDL stands for Web Service Description Language. It is an XML file that describes the technical details of how to implement a web service, more specifically the URI, port, method names, arguments, and data types. Since WSDL is XML, it is both human-readable and machine-consumable, which aids in the ability to call and bind to services dynamically. Using this WSDL file we can understand things like

•     Port / Endpoint – URL of the web service
•     Input message format
•     Output message format
•     Security protocol that needs to be followed
•     Which protocol the web service uses

WSDL describes web services in an xml format so that different technologies can understand

Ways to access web service:

There are two ways to access web service.

• SOAP: - If Service provider knows client: If service provider knows its client then it will provide it’s wsdl to client and client will be able to access web service.

• REST: - Service provider register its WSDL to UDDI and client can access it from UDDI: Web services can register with a UDDI and make themselves available through it for discovery

1.Service provider registers with UDDI.

2.Client searches for service in UDDI.

3.UDDI returns all service providers offering that service.

4.Client chooses service provider

5.UDDI returns WSDL of chosen service provider.

6.Using WSDL of service provider, client accesses web service.

In the web services terms, Representational State Transfer (REST) is a stateless client-server architecture in which the web services are viewed as resources and can be identified by their URIs.
It consists of two components REST server which provides access to the resources and a REST client which accesses and modifies the REST resources.

In the REST architecture style, clients and servers exchange representations of resources by using a standardized interface and protocol. REST isn't protocol specific, but when people talk about REST they usually mean REST over HTTP.

Difference between REST web services and SOAP web services

SOAP	REST
	REST is more simple and easy to use as it is based on use of nouns and verbs (better readability)
SOAP uses XML	REST uses HTTP protocol for producing or consuming web services
The SOAP WS is transport protocol neutral. Supports multiple protocols like HTTP(S), Messaging, TCP, UDP SMTP, etc	REST is transport protocol specific. Supports only HTTP or HTTPS protocols.
	REST is lightweight as compared to SOAP and preferred choice in mobile devices and PDA's.
	REST does not need XML parsing, no message header (to and from), hence less bandwidth
SOAP only supports XML.	REST supports different format like text, JSON and XML
SOAP based reads cannot be cached.	REST based reads can be cached.
SOAP: can have user defined error	REST: requires HTTP error handling
SOAP supports both SSL security and WS-security, which adds some enterprise security features like maintaining security right up to the point where it is needed, maintaining identities through intermediaries and not just point to point SSL only, securing different parts of the message with different security algorithms, etc.	The REST supports only point-to-point SSL security. The SSL encrypts the whole message, whether all of it is sensitive or not.
The SOAP has comprehensive support for both ACID based transaction management for short-lived transactions and compensation based transaction management for long-running transactions. It also supports two-phase commit across distributed resources.	The REST supports transactions, but it is neither ACID compliant nor can provide two phase commit across distributed transactional resources as it is limited by its HTTP protocol.
The SOAP has success or retry logic built in and provides end-to-end reliability even through SOAP intermediaries	REST does not have a standard messaging system, and expects clients invoking the service to deal with communication failures by retrying

Difference between top-down and bottom-up approach of developing web services

In top-down approach, first WSDL document is created and then Java classes are developed based on WSDL contract, so if WSDL contract changes you got to change your Java classes.

In bottom up approach, you first create Java code and then use annotations like @WebService to specify contract or interface and WSDL field will be automatically generated from your build.

How would you decide what style of Web Service to use? SOAP WS or REST?

In general, a REST based Web service is preferred due to its simplicity, performance, scalability, and support for multiple data formats. SOAP is favoured where service requires comprehensive support for security and transactional reliability.

The answer really depends on the functional and non-functional requirements. Asking the questions listed below will help you choose.

·    Does the service expose data or business logic? (REST is a better choice for exposing data, SOAP WS might be a better choice for logic).

·   Do the consumers and the service providers require a formal contract? (SOAP has a formal contract via WSDL)

·   Do we need to support multiple data formats? (REST supports multiple data formats)

·   Do we need to make AJAX calls? (REST can use the XMLHttpRequest)

·   Is the call synchronous or asynchronous? (REST only supports synchronous)

·   Is the call stateful or stateless? (REST is suited for stateless CRUD operations)

·   What level of security is required? (SOAP WS has better support for security)

·   What level of transaction support is required? (SOAP WS has better support for transaction management)

·    Do we have limited band width? (SOAP is more verbose)

·   What’s best for the developers who will build clients for the service? (REST is easier to implement, test, and maintain)

What are the pros and cons of each approach, and which approach would you prefer?

Contract-first Web service/top-down approach
PROS:

·  Clients are decoupled from the server; hence the implementation logic can be revised on the server without affecting the clients.

·   Developers can work simultaneously on client and server side based on the contract both agreed on.You have full control over how the request and response messages are constructed -- for example, should "status" go as an element or as an attribute? The contract clearly defines it. You can change OXM (i.e. Object to XML Mapping) libraries without having to worry if the "status" would be generated as "attribute" instead of an element. Potentially, even Web service frameworks and tool kits can be changed as well from say Apache Axis to Apache CXF, etc 

CONS:More upfront work is involved in setting up the XSDs and WSDLs. There are tools like XML Spy, Oxygen XML, etc. to make things easier. The object models need to be written as well. Developers need to learn XSDs and WSDLs in addition to just knowing Java.

Contract-last Web service/bottom-up approach

PROS: Developers don't have to learn anything related to XSDs, WSDLs, and SOAP. The services are created quickly by exposing the existing service logic with frameworks/tool sets. For example, via IDE based wizards, etc. 

·  The learning curve and development time can be smaller compared to the Contract-first Web service.

CONS:

·         The development time can be shorter to initially develop it, but what about the ongoing maintenance and extension time if the contract changes or new elements need to be added? In this approach, since the clients and servers are more tightly coupled, the future changes may break the client contract and affect all clients or require the services to be properly versioned and managed.

·         In this approach, The XML payloads cannot be controlled. This means changing your OXM libraries could cause something that used to be an element to become an attribute with the change of the OXM.

Overview of SOAP Message Handlers

Some Web services need access to the SOAP message, for which you can create SOAP message handlers. A SOAP message handler provides a mechanism for intercepting the SOAP message in both the request and response of the Web service.

A simple example of using handlers is to access information in the header part of the SOAP message. You can use the SOAP header to store Web service specific information and then use handlers to manipulate it.

You can also use SOAP message handlers to improve the performance of your Web service. After your Web service has been deployed for a while, you might discover that many consumers invoke it with the same parameters. You could improve the performance of your Web service by caching the results of popular invokes of the Web service(assuming the results are static) and immediately returning these results when appropriate, without ever invoking the back-end components that implement the Web service. You implement this performance improvement by using handlers to check the request SOAP message to see if it contains the popular parameters

JWS Annotations Used To Configure SOAP Message Handler Chains:

JWS Annotation	Description
javax.jws.HandlerChain	Associates the Web service with an externally defined handler chain. Use this annotation when multiple Web services need to share the same handler configuration, or if the handler chain consists of handlers for multiple transports.
javax.jws.soap.SOAPMessageHandlers	Specifies a list of SOAP handlers that run before and after the invocation of each Web service operation. Use this annotation (rather than @HandlerChain) if embedding handler configuration information in the JWS file itself is preferred, rather than having an external configuration file. Note; This annotation works with JAX-RPC Web services only.
javax.jws.soap.SOAPMessageHandler	Specifies a single SOAP message handler in the @SOAPMessageHandlers array.

Understanding WSDL

·   WSDL (Web Services Description Language) as the name suggests is a language which describes the web services.

·   It is service contract written in XML based language. It specifies the operations (or methods) the service exposes, format (structure/data types) of messages exchanged and the location of the service.Client application relies on WSDL document to access the service. As the document defines requirements for service provider and service requestor, it represents a contract between both. The server agrees to use exposed services if client sends a message in a pre-agreed XML messaging format. Client uses this document to format a XML request to be sent to the server. Server executes the requested operation (or service) and sends the result back to client in a pre-agreed XML messaging format.

WSDL Document Structure

WSDL document can be partitioned into two sections:

The abstract sections define SOAP messages in a platform and language independent manner. They don’t contain any machine or language specific elements. The abstract elements are types, message and portType

The concrete sections are site-specific, machine-specific or language-specific. The concrete elements are binding and service.

A WSDL document describes a web service using below major elements:

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

·         definitions: Must be the root element of all WSDL documents. It defines the name of the web service, declares namespaces used throughout the document and contains all other elements described ahead.

·         types: The <types> element defines the data types that are used by the web service.

·         message: 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.

·         portType: 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

·         binding: The <binding> element defines the data format and protocol for each port type.

·         service: service element that makes it possible to group together the definitions of several web services in one single WSDL document.

Difference between an XML Schema and WSDL?

·    XSD defines a schema which is a definition of how an XML document can be structured. You can use it to check that a given XML document is valid and follows the rules you've laid out in the schema.

·   WSDL is an XML document that describes a web service. It shows which operations are available and how data should be structured to send to those operations.

·   WSDL documents have an associated XSD that show what is valid to put in a WSDL document

SOAP Envelope

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Header>
</soap:Header>

<soap:Body>
                <soap:Fault>

                </soap:Fault>
</soap:Body>
</soap:Envelope>

	What is XML-RPC?
	XML-RPC is a protocol that uses XML messages to perform Remote Procedure Calls. Requests are encoded in XML and sent via HTTP POST; XML responses are embedded in the body of the HTTP response.

What types of Operations available in WSDL?

·   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 are the different standards protocols for Web Service?

·   XML-RPC is a remote procedure call (RPC) protocol which uses XML to encode its calls and HTTP as a transport mechanism. In XML-RPC objects or structures are exchanged between 2 applications.

·    JAX-RPC: Java API for XML-based RPC, JAX-RPC refers to Java API for XML-based RPC. It specify java technology for for web-based services and clients using RPC or remote procedure calls which are based on XML based protocol like SOAP.

·   JAX-WS: Java API for XML Web Services, which is part of Java EE Platform & Glassfish Project. It also provides annotation based Web Service.

·   JAX-RPC vs. JAX-WS:  JAX-WS replaced the JAX-RPC API in Java Platform, Enterprise Edition 5.It provides enhancement over JAX-RPC.

What is the difference between HTTP POST and PUT requests in REST?
POST is used to create whereas PUT is used to (update, if does not exist create it)/ Replace.

How does SOAP work?

·   SOAP is used to provide a UI that can be achieved from the client object and the request that it sends, goes to the server that can be achieved by using the server object.

·   The UI creates some files or methods that consists of server object and the name of the interface to the server object. It also consists of other information like name of the interface and method.

·   It uses HTTP to send the XML to the server using the POST method. The server parses the method and send the result to the client side.

·  The server creates more XML that consists of responses of the user interface’s request that is used using HTTP.

Describe the SOAP mustUnderstand attribute?

The SOAP mustUnderstand attribute can be used to indicate whether a header entry is mandatory or optional for the recipient to process. 

If you add mustUnderstand="1" to a child element of the Header element it indicates that the receiver processing the Header must recognize the element. If the receiver does not recognize the element it will fail when processing the Header.
Syntax>  soap:mustUnderstand="0|1"

What is the difference between a fault and exception in Apache SOAP?

The difference lies in where the error occurs - on the client side (during the generation of the soap request or the unmarshalling the response) - or on the server side (when un marshalling the request, processing the message or marshalling the response).

The client side raises an exception whereas the server side sends a SOAP response to the client indicating an error occurred on the server side.

Describe the SOAP encodingStyle Attribute?

The encodingStyle attribute is used to define the data types used in the document.

Explain about the actor element?

A SOAP message has to travel a very long distance between its client and server but during the process a part of the message may be intended to be deployed to another destination which is made possible by the SOAP elements actor attribute which address the header element to a particular location.

What happens if RestFull resources are accessed by multiple clients? Do you need to make it thread-safe?
Since a new Resource instance is created for every incoming Request there is no need to make it thread-safe or add synchronization. Multiple clients can safely access RestFull resources concurrently.