In addition to the JNDI ENC there is another API that a JSE can use to interact with its environment, the javax.xml.rpc.server.ServletEndpointContext. This is an interface to the servlet container system itself. It provides the JSE with access to the underlying ServletContext, SOAP messages, and other information.
I am aware of the additional ServletEndpointContext object that is passed in during the init() call. I used this object to get the ServletContext in order to store some state. (I considered this approach a kludge). However, this doesn't seem to answer my basic question about preserving implementation objects in simple object-level variables between business method callbacks.
I was under the impression that I could design the JSE much like a Servlet, where in the init() I could do all my JNDI lookups and get a DataSource, etc. I wanted to use that same DataSource in each of my business method calls.
Are you saying that this is not possible and that I must use objects made available to me through the ServletEndpointContext to store that implementation state? or is there a way to store it in a simple object-level variable and keep my endpoint implementation from being destroyed and re-created between each business method call?
J2EE-1.4 service endpoints are by definition stateless. There is a notion of session in JAXRPC-2.0, which will probably be part of J2EE-1.5
To say that a J2EE 1.4 JSE is stateless with respect to client-specific state gets no argument from me. However, what I am observing with respect to internal implementation/resource state seems to be inconsisten with intent of section 10.1.1 "JAX-RPC Service Endpoint Lifecycle" of the JAX-RPC 1.1 Spec (http://java.sun.com/xml/downloads/jaxrpc.html#jaxrpcspec10).
This section states that...
...The JAX-RPC runtime system is required to invoke the ServiceLifecycle.init method (if this interface is implemented by the endpoint class) for the initialization of the service endpoint instance. The service endpoint instance uses the init method to initialize its configuration and setup access to any external resources....
Good so far; that is what is happening and what I am doing. I am doing a few JNDI.lookups and placing the results in object-level variables of my JSE implementation class. However, in the next set of statements:
...Once a service endpoint instance has been initialized (and in a method ready state), the JAX-RPC runtime system may dispatch multiple remote method invocations to the service endpoint instance. ....
I will grant you that they used the word "may". But wouldn't one expect to be able to re-use resources obtained during the init() and placed in the JSE object over multiple remote method invocations after reading that section and being familiar with the way HttpServlet lifecycles also work?
Axis supports [request|session|application] scope services. What we implement for ws4ee and what you observe is request scope. If I understand correctly you would expect application scope, right?
That however has a number of implications WRT concurrency and locking. Either there is just a single instance that allows concurrent threads (servlets do that AFAIK), or there is a locking mechanism which may cause congestion, or there is a pool of instances (like for SLSB endpoints).
I am not at all convinced that the JAXRPC spec implies application scope service endpoints. Show me the section in the spec where it talks about concurrency in the endpoint.
Out of interest why are you not using a SLSB endpoint if management of resources is a concern? What does JSE offer that EJBSE does not have?
Thanks. In answer to your question, I have nothing against using a Stateless Session EJB for the WEB service (which will hopfully do the trick in my case). With J2EE 1.4 web services and JBoss 4.0.0 being relatively new, I was trying to get an accurate read on the boundaries present in each type before advancing any designs in either direction.
I didn't want to walk away saying incorrect things about the JSE approach without verifying my results with some experts. I _do_ remember Axis' request/session/application scope and that was primarily what I had in the back of my head when asking the question. I just didn't know whether you dissallowed the option or I just could not locate the way to specify it using J2EE 1.4/JAX-RPC versus Axis-specific mechanisms.