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.
22.214.171.124.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.
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.
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...