The concurrency guarentees are equivalent to the encompasing container. For statless ejb endpoints the concurrency is taken care of by virtual the pooling. For the servlet backed endpoints, there is no concurrency contract so you are subject to concurrent invocations on the same endpoint instance as far as I remember. I would have to drill into the servlet based handler to make sure, but this is what I would expect to find.
Scott is right on the EJB endpoint, it is a stateless session bean.
A java service endpoint (JSE) is not a servlet, although it is declared in the <servlet-class> element in web.xml it is a plain java bean not subject to the servlet life cycle.
Our current implementation instanciates a new JSE for every request, there is no pooling yet which would be desirable.
Umm.. OK. So Tom's response soulds like each client that connects would actually be concurrent?
We have several products that need to be server based and accessible to Java, C# and C++ clients. I am attempting to talk the powers that be into using a J2EE server approach instead of custom sockets for each product. Some of the calls can take a while though, so I can't have one client waiting for another client.
Am I understanding this correctly?
Thanks for your responses (and patience),
You essentially get the same stateless bean behaviour with java service endpoints as you get with EJB service endpoints. There is no point of contention, every client is assigned its own service endpoint instance.
The difference is the pooling behaviour. With EJB you hav precreated SLSB instances in the pool. With JSE you get a new (unpooled) instance for every request. Of course, you can have multiple concurrent requests.
The number of concurrent WS requests would be limmited by the capabilities of the transport layer. e.g . if you use SOAP over HTTP you can have maxThreads="250" concurrent requests configures in tomcat
Excellent! Even without the pooling this is what I was hoping to hear.
Thanks so much for your help!