Web Services Interview Questions

Q. What is Web service?

A. Web service is a loosely coupled, reusable software component identified by a URI, whose public interfaces and bindings are defined and described using XML. Web services can be accessed using XML based messages using SOAP protocol. Web services are language independent services because of its XML based communication.

Q. What are the Advantages of Web service?
A.

• Programming language independent: Java, .Net, C, C++, Python, Perl, …
• Not based on a programming data model: Objects vs non-objects environments.
• Convergence of SOA (Service-Oriented Architecture) and Web.
• Based on web technologies like XML
• Do not need huge framework of memory
• Basic usage is b-to-b,remote controlled devices, internal external application communications

Q. What are the Web Services Components?
A.

• XML – eXtensible Markup Language – A uniform data representation and exchange mechanism
• SOAP – Simple Object Access Protocol – A standard way for communication
• UDDI – Universal Description, Discovery and Integration specification – A mechanism to register and locate WS based services
• WSDL – Web Services Description Language – A standard meta language to described the services offered

Q. What is SOAP?
A.

• SOAP is a protocol specification for exchanging structured information in the implementation of Web Services
•  It relies on XML Information Set for its message format, and usually relies on other Application Layer protocols, most notably Hypertext Transfer Protocol (HTTP) or Simple Mail Transfer Protocol(SMTP), for message negotiation and transmission.
• Soap is an XML vocabulary standard to enable programs on separate computers to interact across any network. SOAP is a simple markup language for describing messages between applications.

Q. What is JAX-RPC?

A. JAX-RPC is one of the Java XML programming APIs. It can be seen as Java RMIs over Web services. JAX-RPC 2.0 was renamed JAX-WS 2.0 (Java API for XML Web Services). JAX-RPC 1 is deprecated with Java EE 6. The JAX-RPC service utilizes W3C (World Wide Web Consortium) standards like WSDL or Web Service Description Language 

It works as follows:

1.  A Java program executes a method on a stub (local object representing the remote service)
2. The stub executes routines in the JAX-RPC Runtime System (RS)
3. The RS converts the remote method invocation into a SOAP message
4. The RS transmits the message as an HTTP request

The advantage of such a method is that it allows the Web Service to be implemented at server-side as a Servlet or EJB container. Thus, Servlet or EJB applications are made available through Web services

1. JAX-RPC hides this complexity from the application developer
2. On the server side, the developer specifies the remote procedures by defining methods in an interface
3. The developer also codes one or more classes that implement those methods
4. Client programs create a proxy, a local object representing the service, and then simply invokes methods on the proxy

Q. What are the Benefits of JAX-RPC?
A.

• Support for SOAP message processing model & extensions
• Secure web services
• Extensible type mapping
• Portable and interoperable web services
• Ease of development of web services endpoints & clients
• Support for open standards: XML, SOAP, WSDL
• Support for tools
• RPC programming model with support for attachments

Q. What is WSDL?

A. The WSDL describes all operations that the service provides, locations of the endpoints (i.e. where the services can be invoked), and simple and complex elements that can be passed in requests and responses.

In elaborated lines:

• WSDL stands for Web Services Description Language.
• WSDL is an XML standard for describing Web services. It allows developers to describe Web Services and their capabilities, in a standard manner.
• WSDL specifies what a request message must contain and what the response message will look like in unambiguous manner. In other words, it is a contract between the XML Web service and the client who wishes to use this service.
• In addition to describing message contents, WSDL defines where the service is available and what communications protocol is used to talk to the service.

Q. Can you explain WSDL Document Structure?
A.

• A WSDL document is just a simple XML document
• It defines a web service using these major elements
• Port type: The operations performed by the web service
• Operation: services offered by the web service
• Message: The messages used by the web service
• Types: The data types used by the web service
• Binding: The communication protocols used by the web service

Q. What is WSDL Ports?
A.

• The <portType> element is the most important WSDL element.
• It defines 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.

Q. Explain UDDI?
A.

• UDDI stands for Universal Description, Discovery and Integration.
• UDDI is a directory for storing information about web services, like yellow pages.
• UDDI is a directory of web service interfaces described by WSDL.

Q. What is the difference between SOA and a Web service? 

A. SOA is a software design principle and an architectural pattern for implementing loosely coupled, reusable and coarse grained services. You can implement SOA using any protocols such as HTTP, HTTPS, JMS, SMTP, RMI, IIOP (i.e. EJB uses IIOP), RPC etc. Messages can be in XML or Data Transfer Objects (DTOs).

Web service is an implementation technology and one of the ways to implement SOA. You can build SOA based applications without using Web services – for example by using other traditional technologies like Java RMI, EJB, JMS based messaging, etc. But what Web services offer is the standards based  and platform-independent service via HTTP, XML, SOAP, WSDL and UDDI, thus allowing interoperability between heterogeneous technologies such as J2EE and .NET.

Q. SOA (Service Oriented Architecture) versus WOA (Web Oriented Architecture)

A. SOA and WOA differ in terms of the layers of abstraction. SOA is a system-level architectural style that tries to expose business capabilities so that they can be consumed by many applications. WOA is an interface-level architectural style that focuses on the means by which these service capabilities are exposed to consumers. You can start out with a WOA and then grow into SOA. 

Q. When you can use traditional style middle-ware such as RPC, CORBA, RMI and DCOM verses Web services?

A. The traditional middle-wares tightly couple connections to the applications and it can break if you make any modification to your application. Tightly coupled applications are hard to maintain and less reusable. Generally do not support heterogeneity. Do not work across Internet. These can be more expensive and hard to use.

Web Services support loosely coupled connections. The interface of the Web service provides a layer of abstraction between the client and the server. Web Services present a new form of middle-ware based on XML and Web. Web services are language and platform independent. You can develop a Web service using any language and deploy it on to any platform, from small device to the largest supercomputer. Web service uses language neutral protocols such as HTTP and communicates between disparate applications by passing XML messages to each other via a Web API. Do work across internet, less expensive and easier to use.

Q. What are the different approaches to developing a SOAP based Web service? 

A. 2 approaches.

• Top down approach: where you define the interface first with XSD and WSDL and the generate the Java classes from the interface.
• Bottom up approach: where you define the Java classes first and then generate the interace, which is the WSDL file from the Java classes.

Q. How would you generate a sample SOAP payload from the WSDL?
A.

1. Open the soapUI tool. If not already installed, download the free version and install it.
2. Create a new soapUI project by clicking File --> New soapUI Project.
3. In the pop-up enter a project name and where it says initial WSDL/WADL point your WSDL file. It could be a local file or a URL pointing to your WSDL.For example, dealsforyou.WS_getAllDeals.wsdl
4. Say okay and you will have a soapUI project created with a sample request containing the SOAP payload under the operation "getAllDeals " subfolder. SoapUI will does rest for you with sample payload.

Q. What is REST and RESTful web service?

A. REST stands for REpresentational State Transfer (REST) it is a relatively new concept of writing web services which enforces a stateless client server design where web services are treated as resource and can be accessed and identified by their URL unlike SOAP web services which were defined by WSDL.

Web services written by apply REST Architectural concept are called RESTful web services which focus on System resources and how state of Resource should be transferred over http protocol to a different clients written in different languages. In RESTful web services http methods like GET, PUT, POST and DELETE can be used to perform CRUD operations.

Q. What are differences between RESTful web services and SOAP web services?

A. Though both RESTful web series and SOAP web service can operate cross platform they are architecturally different to each other, here is some of differences between REST and SOAP:

1) REST is more simple and easy to use than SOAP

2) REST uses HTTP protocol for producing or consuming web services while SOAP uses XML.

3) REST is lightweight as compared to SOAP and preferred choice in mobile devices and PDA's.

4) REST supports different format like text, JSON and XML while SOAP only support XML.

5) REST web services call can be cached to improve performance.

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

A. 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 where as SOAP WS is 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?

RESE supports text, JSON, HTML, XML etc. whereas SOAP supports XML only

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

Is the call synchronous or asynchronous?

REST calls can be asynchronous whereas SOAP calls are synchronous

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

Q. What is Restlet framework?

A. Restlet is leading RESTful web framework for Java applications is used to build RESTFul web services it has two part Restlet API and a Restlet implementation much like Servlet specification. There are many implementation of Restlet framework available. You just need to add their jar in your classpath to use them. By using Restlet web framework you can write client and server.

Q. Can you use Restlet without any web-container?

A. Yes, Restlet framework provides default server which can be used to handle service request if web container is not available.

Q. What is RESTEasy?

A. RESTEasy is another REST framework introduced in JBoss Application Server. This was rather easy REST interview questions. you can answer in detail only if you have used this or working in JBoss.

Q. What are the tools used for creating RESTFul web services?

A. Both Eclipse and NetBeans also supported development of RESTFul services.

Q. How to display custom error pages using RESTFul web services?

A. In order to customize error you need to extend StatusService and implement getRepresentation(Status, Request, Response) method with your custom code now assign instance of your CustomStatusService to appropriate "statusService property".

Q. Which HTTP methods are supported by RESTFul l web services?

A. In RESTFul web service each Resource supports GET, POST, PUT and DELETE http methods. GET is mapped to represent(), POST - acceptRepresentation(), PUT- storeRepresentation() and DELET for removeRepresentation().

Q. What is difference between top-down and bottom-up approach of developing web services?

A. 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 while in case of bottom up approach of web service development 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.

Q. What happens if RESTFul resources are accessed by multiple clients? do you need to make it thread-safe?

A. 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 RESTFul resources concurrently.

Q. SOAP versus RESTful Web service

A. 

Key Area	SOAP based Web service	RESTful Web service
Specification/Platform Fundamentals (SF/PF)	Transport is platform & protocol neutral. Supports multiple protocols like HTTP(S), Messaging, TCP, UDP, SMTP, etc. Permits only XML data format, hence language neutral. You define operations, which tunnels through the POST or GET. The focus is on accessing the named operations and exposing the application logic as a service. Defines the contract via WSDL.	Transport is protocol specific. Supports only HTTP or HTTPS protocols. Permits multiple data formats like XML, JSON data, text, HTML, atom, RSS, etc. Any browser can be used because the REST approach uses the standard GET, PUT, POST, and DELETE web operations. The focus is on accessing the named resources and exposing the data as a service. Traditionally, the big drawback of REST was the lack of contract for the web service. This has changed with WSDL 2.0 defining non SOAP bindings and the emergence of WADL. Simpler to implement. REST has Ajax support. It can use the XMLHttpRequest object. Good for stateless CRUD (Create, Read, Update, and Delete) operations.
Performance Consideration (PC)	SOAP based reads cannot be cached. The application that uses SOAP needs to provide caching.	REST based reads can be cached. Performs and scales better.
Security (SE)	Supports both SSL security and WS-security, which adds some enterprise security features. Supports identity through intermediaries, not just point to point SSL. WS-Security maintains its encryption right up to the point where the request is being processed. WS-Security allows you to secure parts (e.g. only credit card details) of the message that needs to be secured. Given that encryption/decryption is not a cheap operation, this can be a performance boost for larger messages. It is also possible with WS-Security to secure different parts of the message using different keys or encryption algorithms. This allows separate parts of the message to be read by different people without exposing other, unneeded information. SSL security can only be used with HTTP. WS-Security can be used with other protocols like UDP, SMTP, etc.	Supports only point-to-point SSL security. The basic mechanism behind SSL is that the client encrypts all of the requests based on a key retrieved from a third party. When the request is received at the destination, it is decrypted and presented to the service. This means the request is only encrypted while it is travelling between the client and the server. Once it hits the server (or a proxy which has a valid certificate), it is decrypted from that moment on. The SSL encrypts the whole message, whether all of it is sensitive or not.
Transaction Management (TM)	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.	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.
Quality of Service (QoS)	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.
Best Practice (BP)	In general, a REST based web service is preferred due to its simplicity, performance, scalability, and support for multiple data formats. SOAP is favored where service requires comprehensive support for security, transactional reliability and stricter contract.