Top Most Web Services FAQS

1: What is a web service?

Basically, a web service is a type of software that is made available over the internet. It uses a standardized XML messaging system. It can have a public interface and can run a wide range from news syndication, stock market-data, and weather reports, to even tracking systems.

2: What is new about the web services?

Over some time, people have been using Remote Procedural Call (RPC), wherein they can send calls over in HTTP. However, the newest about web services would have to be XML. It stands at the very center of web services because it is able to provide a common language for describing RPCs, web services, and their directories.

3: How does a web service operate? Can you provide an example?

The IBM Web Services Browser provides a more intuitive feel for web services because of their series of demonstrations. This browser combines SOAP, WSDL, and UDDI in order to create a simple plug-and-play interface for the purpose of finding web services. You can find different services such as traffic reports service and weather report services. These are independent from one another and you can stack them one on top of the other. Thus, you can have a single page with multiple services which may look like a simplified version of my.yahoo.

4: What is the web service protocol stack?

A protocol stack comprises of evolving sets of protocols that are used to define, discover, as well as implement web services.

5: Can you define what SOAP is?

SOAP is an XML-based protocol that is used for the exchange of information between computers. It can be used thru a number of messaging systems and be delivered thru an array of transport protocols. However, its main purpose is focused on RPCs that are transported thru HTTP.

These are only some of the web services interview questions you are bound to face during an interview. There can be more web services interview questions depending on the company you are applying in. so, in order to you to get the job and correctly answer these web services interview questions, be sure to get ahead of your interviewer

6.What are the different styles of Web Services used for application integration? 
A. SOAP WS and RESTful Web Service

7. What are the differences between both SOAP WS and RESTful WS?  

The SOAP WS supports both remote procedure call (i.e. RPC) and message oriented middle-ware (MOM) integration styles. The Restful Web Service supports only RPC integration style.

The SOAP WS is transport protocol neutral. Supports multiple protocols like HTTP(S),  Messaging, TCP, UDP SMTP, etc. The REST is transport protocol specific. Supports only HTTP or HTTPS protocols.

The SOAP WS permits only XML data format.You define operations, which tunnels through the POST. The focus is on accessing the named operations and exposing the application logic as a service. The REST permits multiple data formats like XML, JSON data, text, HTML, 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. REST has AJAX support. It can use the XMLHttpRequest object. Good for stateless CRUD (Create, Read, Update, and Delete) operations.

         GET - represent()
         POST - acceptRepresention()
         PUT - storeRepresention()
         DELETE - removeRepresention()

SOAP based reads cannot be cached. REST based reads can be cached. Performs and scales better.

SOAP WS 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.

8. 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 favored 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?

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

Is the call synchronous or  asynchronous?

Is the call stateful or stateless? (REST is suited for statless 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)

9. What tools do you use to test your Web Services?
A. SoapUI tool for SOAP WS and the Firefox "poster" plugin for RESTFul services.

10.  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.

11. Web services when you can use traditional style middle-ware such as RPC, CORBA, RMI and DCOM?
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. 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. The loosely coupled applications reduce the cost of maintenance and increases re-usability. 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.


12. What are the different approaches to developing a SOAP based Web service?
A. 2 approaches.

The contract-first approach, where you define the contract first with XSD and WSDL and the generate theJava classes from the contract.

The contract-last approach where you  define the Java classes first and then generate the contract, which is the  WSDL file from the Java classes.

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