Spring's WS vs. SLSB WS

[joegaber]

I am interested to see if there's an opinion concerning the statements I found in the following exerpt from IBM's developerworks webservices site in regards to how their claim that stateless session beans have the stated advantages over Spring's core and WS capabilities.

Any thoughts?

[dejanp]

Well, I'm not Rod, but here it goes anyway.

* Leveraging existing business logic and processes: In many organizations, existing business logic has already been coded using EJB components; exposing it through Web services is the best possible option for making those services available to the outside world. An EJB endpoint is a good choice because it keeps business logic located in the same tier with the endpoint.

Yes. If you have EJBs and you like them - keep them.

* Concurrency support: An EJB service endpoint implemented as a stateless session bean need not worry about multi-threaded access, since the EJB container must serialize requests to any particular instance of a stateless session bean.

Frankly, I'm yet to see a stateless session bean that's not threadsafe. I mean you really have to be totally drunk to create a stateless session bean that has a state that itself is not threadsafe. In other words - it's a feature if your programmers are totally drunk all the time.

* Secure access to services: Enterprise beans permit various method-level security features to be declared in the deployment descriptor. The method-level roles are mapped to an actual principal domain. Using EJB components as Web service endpoints brings this method-level security to Web service clients.

Spring Acegi.

* Transaction considerations: An EJB service endpoint runs in a transaction context specified in the deployment descriptor. The container handles the transactions, so the bean developer doesn't need to write transaction-handling code.

Spring supports declarative transactions in 3 zillion ways.

* Scalability: Almost all EJB containers provide support for the clustering of stateless session beans. So, as load increases, additional machines can be added to a cluster, and Web service requests can be directed to those various servers. By modeling Web services as EJB endpoints, you can make the services scalable and increase their reliability.

Load balancing of web services is best done on the http level, not on the underlying implementation level. Actually, for pure WS you don't need any kind of clustering as there is no state to be replicated across the cluster. You need a failover and every load-balancer supports that.

* Pooling and resource utilization: An EJB container provides pooling of stateless session beans. This improves resource utilization and memory management. By modeling Web services as EJB endpoints, such features can easily be extended to make Web services respond effectively multiple client requests.

Hmm... A misfeature workaround is somehow a feature? (As I said above, one stateless instance per thread is simply not needed, pooling is a poor workaround for it.)

[joegaber]

Thanks for the input. All that you've said is familiar now that you've outlined it so well. It coinsides with Rod's books and the main counter points to EJBs from the Spring perspective. I very much appreciate the assistance in evaluating the IBM statement.

I was hoping I could get a little more clarification on a couple of your comments in order to improve my understanding:

Frankly, I'm yet to see a stateless session bean that's not threadsafe.

Hmm... A misfeature workaround is somehow a feature? (As I said above, one stateless instance per thread is simply not needed, pooling is a poor workaround for it.)

Thx

[dejanp]

Well - EJB spec makes sure you get one instance of the SLSB per thread. I'd say that for 99% of the cases (and 100% of the cases I've actually seen) it's simply not needed because SLSB instances have no state (instance variables) or have the state that's threadsafe so you simply do not need multiple instances, simple singleton will do the job. In my book that's an overengineered solution to a problem that doesn't exist and not a feature.

Having a pool of SLSB instances is a feature if you need multiple instances. If you don't need multiple instances (and you don't) it's a workaround around a problem that shouldn't be there in the first place.

[joegaber]

I apologize, but what book is that?

[wuj98]

Well - EJB spec makes sure you get one instance of the SLSB per thread. I'd say that for 99% of the cases (and 100% of the cases I've actually seen) it's simply not needed because SLSB instances have no state (instance variables) or have the state that's threadsafe so you simply do not need multiple instances, simple singleton will do the job. In my book that's an overengineered solution to a problem that doesn't exist and not a feature.

Having a pool of SLSB instances is a feature if you need multiple instances. If you don't need multiple instances (and you don't) it's a workaround around a problem that shouldn't be there in the first place.

Could explain why "it's simply not needed because SLSB instances have no state (instance variables) or have the state that's threadsafe so you simply do not need multiple instances, simple singleton will do the job"? Thanks

[wpoitras]

Could explain why "it's simply not needed because SLSB instances have no state (instance variables) or have the state that's threadsafe so you simply do not need multiple instances, simple singleton will do the job"? Thanks

If an object is thread safe basically any number of threads can invoke methods on it and get correct results.

What EJB protects against is if you have an object which modifies member variables during the operation of a single service method. If not deployed as an EJB, but a singleton, then if a thread changed the object's member variables while another one was using the same variable, you may not correct results.

So as long as you don't code your services this way, singletons work fine. If you are using singletons, then you don't need EJB.

[dejanp]

Could explain why "it's simply not needed because SLSB instances have no state (instance variables) or have the state that's threadsafe so you simply do not need multiple instances, simple singleton will do the job"? Thanks

Consider a class:

public class FooStatelessService {

  public doIt(int i) {
    return i*i;
  }

}

You can have any number of threads running the method doIt with no problems. The class has no state (instance variables) so it's threadsafe. (local variables and parameters are on the stack and each thread uses it's own stack so they are always threadsafe)

Case 2:

public class FooStatefulService {
  private int i;
  public setI(int i) {
    this.i = i;
  }
  public doIt() {
    return i*i;
  }
}

This class is stateful. You need to call the method setI to set the state and calls to doIt are not threadsafe anymore as different threads can change the state between the calls.

Does it mean that only classes with no instance variables are threadsafe? Well, no. The class is threadsafe if it has no state or the state is constant and threadsafe itself.

Case 3:

public class FooThreadsafeService {
  private Datasource ds;
  public setDs(Datasource ds) {
    this.ds = ds;
  }
  public void doIt() {
    /* do some db magic here*/
  }
}

In this case datasource is set once, when the instance is created, he datasource class itself is threadsafe so - this class is threadsafe too.

Case 4:

public class FooNonThreadsafeService {
  private SimpleDateFormat sdf;
  public setSdf(SimpleDateFormat sdf) {
    this.sdf = sdf;
  }
  public void doIt() {
    /* do some date formatting here*/
  }
}

SimpleDateFormat is set once, at the creation time, but it's not threadsafe (see it's javadocs) so this class is also not threadsafe. So, how do we make it threadsafe? Easiest solution is to make the offending instance local:

public class FooThreadsafeAgainService {
  private String sf;
  public setSf(String sf) {
    this.sf = sf;
  }
  public void doIt() {
    SimpleDateFormat sdf = new SimpleDateFormat(sf);
    /* do some date formatting here*/
  }
}

So we made the SimpleDateFormat local and instead of it we have a constant string as a state. Strings are threadsafe so it's all in green again.

Now, how does all this relate to SLSB and WS? SLSB are Stateless Session Beans. WS calls are stateless. They per definition do not have the state that needs to be saved in instance variables between the calls (case 2). They most likely look something like case 3 or 4.

[wpoitras]

One issue when trying to make code similar to the SimpleDateFormat threadsafe is the cost of creating those classes. A good example is builder or parser objects that need additional resources (like external schema files or databases)

In EJB this is solved by allocating one object per EJB at EJB construction time.

In Spring you need to use a pool of some sort. The reference manual has a few solutions: Pooling target sources and ThreadLocal target sources

So you gain the threadsafety that EJB provides without having to resort to a pool of your service. Just a pool of resources that really need to be pooled. And you change the implementation of your pool (or even configure your object to use a prototype target source to create a new one for each request) without changing your class. Basically you are taking the solution for thread-safety out of your class.

[wuj98]

Thanks for the reply!

I think "Stateless" may only mean thread-safe instance variables. But code a thread-safe "singleton" is more challenge, because you need to make sure all local variables threadsafe or use "synchronized " method.

Correct me if I'm wrong.