If not all, atleast in few of the examples I referred, I see com.sun.xml.ws.transport.http.servlet.WSServlet being declared in web.xml. I did not do this, when I deployed by application in GlassFish using eclipese (Dynamic Web Project). Apparently GlassFish must be providing a servlet implicitly, which I did not happen to see.
But what is com.sun.xml.ws.transport.http.servlet.WSServlet and I could not get any good information or API around this component. So, can some body point me to a link where I can read more about this.
Joined: Oct 04, 2006
I think this is the servlet that is responsible for directing incoming web service requests to the appropriate endpoint implementation class and to make any conversions/preparations needed before the endpoint appropriate implementation class is invoked.
With JAX-WS, this is taken care of "behind the scenes", as you correctly suspect. That is, when GlassFish encounters an endpoint implementation class, it knows it must use a WSServlet to handle incoming requests and thus it adds the servlet to the generated deployment descriptor etc. etc.
The only resource I was able to find being in a hurry was this:
Reading that you will at least get a feel for how incoming web service requests over HTTP are handled.
If someone has a better source for information, I would also be very interested!
From your explanation and my understanding, can we consider this servlet as a part of Service Interaction layer, you described in "Endpoint Design and Architecture" in your notes. Also, this being a servlet I guess, it is possible to have the filters and listeners to be configured as any other web app. Though the functionality of filters can be achieved using Handlers in Jax-WS. What are your thoughts on this?
and this servlet seems to be implementation and container dependent. Because when I deployed an app, having this servlet configured in Tomcat 6, my tomcat startup failed, as there was a failure in initializing a listener. I wish Sun provides a better documentation on this servlet.
Kumar Raja wrote:From your explanation and my understanding, can we consider this servlet as a part of Service Interaction layer, you described in "Endpoint Design and Architecture" in your notes.
No, I would not say that this servlet is part of anything related to a specific service. As far as I am concerned, the servlet is part of the web service stack (Metro in this case).
As you correctly point out, the servlet is implementation and container dependent. If it were part of the service interaction layer then the service would have to be rewritten for every container I wished to deploy the service on.
Admitted, in reality there may still be things that affect portability in a negative manner.