In reference to EJB, what is the meaning of scalable?, how does EJB support scalability?

Dan Christopherson

First, remember that scalability is only one of the goals of the EJB sped: some of the others are portability, automated transaction management, standardization of life-cycle management, ease of development, and compatability/interoperability. A lot of the scalability goal can really be considered as supporting scalability while not forcing the code writers to jump too many hoops. In other words, ensuring that scalability is purely a design or application architecture issue and doesn't become a coding issue.

Another point to remember is that scalability is really a hardware matter: all software can do is make the problem more or less difficult.

My take at 'scalable' in enterprise level systems is that the duration of any transaction will degrade more slowly than the transaction rate increases. In other words, the goal would be linear degradation, with a small coefficient. Of course in reality it isn't linear to infinite loads, but we do want it to remain linear to as high a transaction rate as possible. Another attribute related to scalability is stability: even if our load is such that we are getting a lot slower, we shouldn't crash.

Note that this does not mean 'fast.' I expect EJB implementations to be slower than equivalent CORBA distributed systems that ignore transactions and security. I also expect EJB based implementations of Web applications to be slower than the equivalant Servlet/JSP -> JDBC/Data Access Object implementation. The performance 'knee' of the EJB application will be higher in both cases - if it's a well designed EJB application that accounts for and makes use of EJB features.

One of the scalability support features is the EBJObject itself: because the client doesn't call the bean directly, but only through a redirection layer, the container can interpose in the call and make a decision as to how to handle the call. This might involve a pool of bean instances, in which multiple beans can assume the same entity, or it can involve blocking while the last transaction executes (note, though, that a stateful session bean can balk by throwing an exception if access is attempted from two different transactions at once). The container's implementation and configuration is the limiting factor here.

Other scalability gains come in places where the spec doesn't neccessarily define behavior: container vendors are free to implement their client-side stubs in any way they see fit - in some cases, the vendor can implement client stubs in such a way as to take advantage of their clustering capabilities.

Of course, clusters of application servers would be a bear to write code for if there weren't a simple way of writing transactional code to run on them. Here, EJB enables scalability by defining a declaritive transaction model. The alternative would be to write directly to one of the distributed transaction APIs (Xopen or the CORBA Transaction Service, for example). Using these APIs directly tends to make code fairly hairy.

Another scalability feature for designers and architects to take advantage of is the Stateless Session Bean. The EJB specification allows containers to pool instances of these and rotate through them on a request by request (invocation by invocation) basis. Your client can hold a single reference to a stateless session but in making 10 method calls to it, it may actually be serviced by 10 different instances of the bean. This enables scalability in a couple of ways:

  1. methods on stateless session beans can be designed to be transactions, thus keeping critical sections short and increasing throughput by avoiding waits on locks.
  2. Total memory utilization by the server will be less than if the container had to have one instance of the bean per client reference

The passivation/activation mechanism is another scalability feature. With this feature, the container can keep a certain number of bean instances in memory, but swap state in and out of them so that that pool appears to the outside world as if it is far larger. This can keep a server running with a decent throughput even if its load is far higher than it might otherwise be able to handle