Jax-WS 2.2 web service instances management on Glassfish 3

Question

I'm studying Jax-WS specification in general and its implementation on Glassfish 3.1.2. I built a simple standard example where a jax-ws soap based web service is called from a jsp page by using the artifacts generated through wsimport (the webservice and the jsp page are both deployed on Glassfish in the same EAR but in 2 different wars).

Everything works as expected but I have a question: looking at the application log, it seems that Glassfish creates a new instance of the webservice each time it is called. I would like to know where Java offically defines how a web container should manage webservice instances and if developers can customize this behaviour.

I read jax-ws 2.1 specification here

http://download.oracle.com/otndocs/jcp/jaxws-2.1-mrel2-eval-oth-JSpec/

but I found only a clue when speaking about how to publish a webservice using the Endpoint class by hand (section 5.2.2 "Publishing", page 69):

"An endpoint consists of an object that acts as the Web service implementation (called here implementor) plus some configuration information...

An Endpoint will be typically invoked to serve concurrent requests, so its implementor should be written so as to support multiple threads. The synchronized keyword may be used as usual to control access to critical sections of code. For finer control over the threads used to dispatch incoming requests, an application can directly set the executor to be used..."

This note is present even in Jax-WS 2.2 specification (used by Glassfish 3).

Actually, if I build a webservice using only JavaSE 7 (which includes Jax-WS 2.2), this description is true because there is only one instance of the webservice. Is there any reason why JavaEE doesn't follow this policy?

Thanks a lot for your help,

Nico

Answer 1

I found the answers on this specification (JSR-109):

http://jcp.org/aboutJava/communityprocess/mrel/jsr109/index3.html

It describes how Jax-WS works on JavaEE:

"4.1 Client Programming model (page 18)

a client must assume that the methods of a Web service have no state that is persistent across multiple Web service method invocations. A client can treat the Web service implementation as stateless.

The client has no control over the life cycle of the Web service implementation on the server. A client does not create or destroy instances of a Web service, which is referred to as a Port. The client only accesses the Port. The life cycle of the Ports, or instances of a Web service implementation, are managed by the run-time that hosts the Web service. A Port has no identity. This means that a client cannot compare a Port to other Ports to see if they are the same or identical, nor can a client access a specific Port instance.

5.3.2.4.2 Web container programming model for JAX-WS (page 42)

A Service Implementation must be a stateless object. A Service Implementation Bean must not save client specific state across method calls either within the bean instance’s data members or external to the instance. A container may use any bean instance to service a request.

5.3.4 Service Implementation Bean Life Cycle (page 43)

Before a request can be serviced, the container must instantiate a Service Implementation Bean and ready it for method requests. A container may pool method ready instances of a Service Implementation Bean and dispatch a method request on any instance in a method ready state."

Moreover, the specification states that JavaEE must not use the Endpoint class to publish a webservice:

"5.3.3 Publishing Endpoints – javax.xml.ws.Endpoint (page 43)

JAX-WS provides functionality for creating and publishing Web Service endpoints dynamically using javax.xml.ws.Endpoint API. The use of this functionality is considered non-portable in a managed environment. It is required that both the Servlet and the EJB container disallow the publishing of the Endpoint dynamically, by not granting the publishEndpoint security permission."