sampa : colin’s blog

I was reading Diego Parilla’s Spring is not designed for scalability, and simply had to respond. I actually first wrote a comment directly on his blog, but I guess he’s not going to allow the comment to be posted, as some other stuff has appeared but not mine, after a number of hours…

(Edited 20 minutes later: my comment has appeared on Diego’s blog. This entry below is however much more fleshed out. What is funny is Diego’s reply to my comment, where he says, “Spring is good for simple web apps. If you are going to face a complex project, don’t bet your ass only in Spring: do it on Spring + J2EE.”. I say funny because we’ve of course always said that J2EE is a great base specification, and J2EE and Spring are very complementary, with only some of the higher-level APIs (such as EJB) being flawed. A much more detailed treatis on this whole subject area (agile, effective, and performant J2EE-based architectures) is Rod Johnson and Juergen Hoeller’s Expert One-on-One J2EE Development without EJB. )

This is a very confused post. The main issue is that Diego apparently does not realize that J2EE doesn’t necessarilly equal EJB, and that the EJB 3 spec consists of a container spec (Session beans as POJOs, along with pretty weak IOC and AOP capabilities), as well as the separate spec for JPA (Java Persistence Architecture), which is the replacement for the old Entity beans of EJB 2.1. Of course, the various JPA implementations from people like BEA, Oracle, and JBoss, will run inside or outside of an EJB container.

The following statement alone from the blog entry is proof enough that Diego doesn’t realize JPA is usable from Spring: “”"Strictly speaking, Spring is not bad scaling, simply it was not designed to scale. EJB3 is really good simplifying the complexity of developing enterprise class applications, but the new POJO entities are really good not only simplifying the development, but hiding the complexity of clustering data to the developers. This is why I see EJB3 as a winner.”"”

Of course, in terms of scaling data across a cluster, both an EJB 3 solution and a Spring solution would be working with JPA (or another persistence API) to persist “POJO entities” (as Diego calls them; most people would talk about “transparent persistence for the domain layer) and have the same data scaling mechanisms available, including something like Tangosol’s Coherence product working as a second level cache behind JPA. Both the EJB and Spring solution would have access to a ‘transparent’ data clustering library such as TerraCotta’s, although I would make the case that usage of AOP-based libraries in the Spring case would normally be easier since the Spring app can run in any environment, while an EJB 3 app needs to run in an EJB 3 environment, with some classloading and other constraints enforced by that environment.

On the question of scaling access to POJO services, the general concensus is that a stateless service layer, duplicated horizontally, (and sitting behind a load balancer) is the most scalable approach. (State then lives in the database, or a clustered cache as per the above paragraph). Both Spring and EJB 3 facilitate this scenario, although Spring will give you more choice as to a deployment environment, including simple J2EE servlet engines if that’s all you need. Now if there is an actual need to cluster stateless services at the level of invocations between those individual services (and there’s not much of a case for this), this can be easily done outside of an EJB container by using something like WebLogic’s T3 protocol. Of course, you can also depoy the Spring app to a full EJB container and take advantage of EJB remoting. The point is, there is no disadvantage to using Spring here, anywhere EJB-only apps can get clustering for services, so can Spring-based apps, along with some environments that the EJB ones can’t.

Part of Diego’s ammunition seems to be Bob Griswold’s statement here that with regards to “some of these freameworks”, “In some respects, they actually make the task of scaling out harder than it would have been if the application were written with full J2EE specifications and run within an expensive, mission critical application server like WebLogic Server.”. Now Bob needs a good spanking (he should really know better) for mixing two completely separate things: was the app written to the full J2EE specs (as he puts it, and it’s undefined what this is, but presumably a full EJB 2.1 or EJB 3 based architecture, as opposed to a POJO/J2EE Spring architecture)? and what environment is it deployed in? I will make the claim that (as per the points above), in the same enviroment that an EJB 2.1 or 3.0 based app can run, a Spring app can scale out at least as easily as the EJB 2.1 or 3.0 app. It will also scale out very nicely, thank you, in some environments where EJB apps fear to tread…

The problem with Diego’s post and others like it is that it has a fairly inflamatory title, but there is no real substance there, and ultimately misunderstanding of the products he’s talking about. J2EE and Spring are not competitive in nature. The base J2EE spec is a great spec, and Spring allows you to build great architectures upon it. Spring will also leverage fully the persistence portion of EJB 3, i.e. JPA. Now the value proposition for the container portion of the EJB 3 spec is much more mixed. It’s generally conceeded that EJB 2.1 is a failed container model (hence the complete redesign for 3.0), and 3.0 is bringing in an IOC container and AOP functionality that in terms of functionality is for the most part not even at the level offered by Spring 1.0, but ultimately, if people choose to use the EJB 3 container they’ll be able to get value from Spring even there… And they’ll be able to get scalable apps

Some more comments on this in Call Me Pedantic - What Exactly IS Scalability? and What Is Clustering About – An answer to Spring is not d
esigned for scalability.