Exposing a servlet as a web service

[somesh sai]

Hi,

Is it possible to expose the servlet as a webservice? Can servlet perform the both the tasks or serving as webservice and processing requests through request/response at the same time?

Thanks,
Somesh

[William Brogden]

If a servlet is "exposed as a Webservice" it will be responding to requests in the normal manner. Web services use HTTP just like browsers do.

Bill

[somesh sai]

Thanks Bill.

Do you have any example where Servlet exposed as web service? I am working in Netbeans IDE on Glassfish server.


Thanks,
Somesh

[Chintan Rajyaguru]

If I understand your question correctly, you want to expose an HTTPServlet as a web service, which would mean that one or more of its doxyz() methods will be exposed as web services. The answer is, No. You can't expose those methods because they contain incompatible data types (HttpServeletRequest is not a JAX-RPC or JAX-WS compatible type for example).

You may be able to define a compatible method inside a servlet and expose just that method as a web service but that would be a poor design. Plus, I have never tried that so not sure if that works.

Help me understand why you are trying to expose a servlet as a web service. If you want a common piece of functionality available through both web service and a servlet, you should write a POJO service and expose it as a web service. From the Servlet, invoke the POJO.
[ December 16, 2008: Message edited by: Chintan Rajyaguru ]

[Paul Clapham]

Depends on what you mean by "web service". If you mean something in the WS-* stack then what Chintan says is right. At least, it looks like he knows more about it than I do so it's more likely to be right than what I say about that.

But if you take a more generic view of "web services" then REST-oriented services simply use HTTP GET and POST methods, which can certainly be implemented by servlets.

[Peer Reynders]

But if you take a more generic view of "web services" then REST-oriented services simply use HTTP GET and POST methods, which can certainly be implemented by servlets.

Given the current limitations of the servlet spec (up to 2.4) with reference to current web technologies using something like Restlet or Jersey (JSR-311; JAX-RS) would actually be more prudent as they do not have any dependencies on a servlet container.

Originally posted by somesh sai:
Can servlet perform the both the tasks or serving as webservice and processing requests through request/response at the same time?

The only way that could make any sense is with a representation format that can do "double-duty" - e.g. a response in XHTML that can be displayed in a browser while a microformat supplies the meta-data for a programmatic consumer (IANA MediaType: application/xhtml+xml).

However as you earlier inquiries were regarding SOAP web services with JAX-WS the answer to your question should be an emphatic NO.

Now, you can find code on the internet for SAAJServlets and as SOAP only uses HTTP POST you could build a servlet that serves regular HTML on the doGet while it "processes SOAP" on the doPost - however as was already previously pointed out - that would be a really bad idea. And I'm not aware that you can actually do it with JAX-WS.
[ December 16, 2008: Message edited by: Peer Reynders ]

[William Brogden]

Backing off a few thousand meters ...

My general feeling is that the actual servlet code should contain as little business logic as possible, instead a servlet should take a request and decide how to present the data to a separate class or classes which actually do the logic but have no servlet dependency. Thus one set of business logic/application classes can easily talk SOAP thru a SOAP servlet, REST through a REST servlet and HTML through a third servlet.

If you see your servlet class getting full of business logic it is time to take a deep breath and step back from the keyboard.

Bill

[somesh sai]

Thank you all for the replies.

To eloborate my current requiremts... We have a long polling servlet which sends information to clients based on the information received from external interface.

The external inteface want to interact with the servlet through a webservice and we have two options..
1. Calling the Sevlet from Webservice using java.net api which we are facing some issues.
2. Exposing servlet itself as web service so that we can expose some methods.

Could you please guide which is the better way to go in the above case..

Thanks,
Somesh

[Peer Reynders]

Originally posted by somesh sai:

1. Calling the Sevlet from Webservice using java.net api which we are facing some issues.

Sounds like this situation:

SOAP Consumer--> (WSDL)-JAX-WS Provider--> (HTTP)-Servlet

Don't know what your issues are but there are reports that Jarkarta Commons HttpClient is easier to work with than java.net.URL

2. Exposing servlet itself as web service so that we can expose some methods.

Sounds like this situation:

SOAP Consumer--> (WSDL)-|
HTTP Client----> (HTTP)-Servlet [i.e. both SOAP web service and HTTP service on the same URL]

Which still is a bad idea.


What Bill is suggesting is the way to go:

SOAP Consumer-----> (WSDL)-JAX-WS Provider-----------------|
                                                           |---> |
HTTP Client-------> (HTTP)-Servlet-----------------------------> (Java)-POJO
                                                           |---> |
RESTful Consumer--> (HTTP[REST])-Resources[Jersey/Restlet]-|

i.e. centralize the common business logic in a POJO and reuse it in the JAX-WS endpoint, Servlet, and Resources - each exposed at their own URL(s).
[ December 17, 2008: Message edited by: Peer Reynders ]

[Joby Wilson Mathews]

A tutorial to Build webserivce using  Servlets  https://www.youtube.com/watch?v=0L9yTE_zFM0