Difference between web-service and text based servlet

Question

okay this might be a pretty lame and basic question but its stuck in my head since i never had chance to work on web-services.

We can get the same "text bases" response(xml, json etc) from our server by very basic/simple implementations (lets say servlet) then why do someone has to develop a web-service.

What is the exception thing a web-service gives over simple http response?

Answer 1

At a basic level, you are quite correct, from a low level point of view, it's just text (XML) on a socket.

For simple web services, a servlet is adequate (I'm writing one of these as we speak).

When talking about something like SOAP and WSS-* web services, however, there is a lot of boiler plate processing and features available from the standards that web service toolkits expose as higher level transactions.

A simple example is data marshaling. If you treat it purely as XML, then your service basically gets to process the XML by hand -- parse it, evaluate it, populate your internal models, etc.

Contrast this to something like this from Java EE:

@WebService
public Person getPerson(String personId) {
    Person p;
    ...
    return p;
}

The web service stack will convert your Person object in to a SOAP compliant XML blob. It will also produce a WSDL that you can use to create client code (on many platforms: .NET, PHP, etc.) to make the web service code.

In the end, your client and server have only a few lines of code, while the frameworks do all of the grunt work parsing, marshaling, and publishing for you.

So, the value of the WS stack is that it handles much of the bureaucracy of writing WSS compliant web services.

It's no panacea, but for many modern implementations, SOAP <-> SOAP remote processing can be a, mostly, cross platform, drag and drop affair.