Difference btwn Servlet and Web Service

[Shinya Koizumi]

What's the real difference between Servlet and Web Service.
Currently we provide Document Management Platform works
with RMI and want to add web interface so that customers can
create a web application to access our system using PHP, JSP.
However, we are not sure whether to provide API as Servlet or
Web Service.

SK

 

[Jade Yuan]

The most obvious difference between Servlet and Web Service is:
You access servlet via HTTP while access Web Service via SOAP (Simple Object
Access Protocol).

But, in fact, you can not directly invoke a servlet, you can only open URL
connection and put some parameter to the servlet if the caller is out of
your application. And you can not restrict what parameters the caller can
put. The caller does not know what parameters your servlet can receive
either.

So, You'd better use web service to provide API to other applications, the
WSDL file of your web service can give the caller enough information to
invoke your web service.

I suggest you can learn more about web service.

Good luck!

 

[Monique Y. Mudama]

What's the real difference between Servlet and Web Service.
Currently we provide Document Management Platform works with RMI and
want to add web interface so that customers can create a web
application to access our system using PHP, JSP. However, we are
not sure whether to provide API as Servlet or Web Service.

I'm not sure that idea makes sense (deciding between a Servlet and a
Web Service). It seems a bit to me like asking whether one should use
PHP or HTTP.

Then again, maybe I'm the one who's confused. I guess I need to read
up on Servlets ...

 

[alexandre_paterson]

Monique Y. Mudama a écrit :

I'm not sure that idea makes sense (deciding between a Servlet and a
Web Service).

From the client point of view this is indeed strangely formulated but

from the server side to me it more or less makes sense.

I think the question is wether the OP should use "plain old Servlet"
technology to provide an answer to his clients (who would have to
use a plain old http request) or web services.

Web services are usually done using SOAP or using XML RPC (O'Reilly
has a nice "Programming Web Services with XML-RPC" book).

Apache's XML RPC implementation is using, for example, the
following naming scheme :

org.apache.xmlrpc.webserver.XmlRpcServlet

And the web service "entry point" can be defined like this
in web.xml:

<servlet-mapping>
<servlet-name>XmlRpcServlet</servlet-name>
<url-pattern>/ws</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>GoodOldServlet</servlet-name>
<url-pattern>/fakews</url-pattern>
</servlet-mapping>

Here Apache's XML RPC web services is done using
the servlet dispatcher but it doesn't have to be like
that: the web server could be dispatching normal
requests to, say, Tomcat, and web services XML RPC
request to something else...

I can see why the OP is hesitating which way to go...
Should he ask his clients to do (schematized and
considering clients are calling the API from Java
for the example):

xmlRpcClient.setServerURL("sample.com/ws")
xmlRpcClient.execute("someMethod", new Object[]{"value"})

or

httpClient.executeMethod(new
GetMethod("sample.com/fakews?param=value"))

and then parse the result.

I see this as a more or less legitimate question... It may be
bad style to parse the result (plain text?) of an http request
but then there are cases where web services are overkill.

To answer the OP: given the description I'd go with web
services / SOAP. XML RPC is simpler but not as
standardized, so it may prove more difficult to implement
correctly if the environment of the clients isn't controlled.

Alex