Comments on: Spring is Most Certainly Designed for Scalability http://blog.exis.com/colin/archives/2006/01/16/spring-is-most-certainly-designed-for-scalability/ Whatever hits the spot Fri, 12 Mar 2010 18:06:22 +0000 http://wordpress.org/?v=2.0.2 by: kishore reddy katta http://blog.exis.com/colin/archives/2006/01/16/spring-is-most-certainly-designed-for-scalability/#comment-1727 Sun, 22 Jan 2006 15:38:19 +0000 http://blog.exis.com/colin/archives/2006/01/16/spring-is-most-certainly-designed-for-scalability/#comment-1727 Hello Folks iam new to java..and particulary speaking i dont know much of this Spring framework..iam working on Weblogic Tool(BEA).And people do say that weblogic is purely dependant and makes use of this Spring FrameWork.So can someone plz explain in lay terms ..like how does this both are dependant and how it works out..Basic info is needed..bye thanks Kishore reddy katta Hello Folks
iam new to java..and particulary speaking i dont know much of this Spring framework..iam working on Weblogic Tool(BEA).And people do say that weblogic is purely dependant and makes use of this Spring FrameWork.So can someone plz explain in lay terms ..like how does this both are dependant and how it works out..Basic info is needed..bye

thanks
Kishore reddy katta

]]> by: Vinny Carpenter’s blog » Daily Del.icio.us for Jan 18, 2006 http://blog.exis.com/colin/archives/2006/01/16/spring-is-most-certainly-designed-for-scalability/#comment-1714 Thu, 19 Jan 2006 02:48:48 +0000 http://blog.exis.com/colin/archives/2006/01/16/spring-is-most-certainly-designed-for-scalability/#comment-1714 [...] sampa : colin’s blog » Spring is Most Certainly Designed for Scalability 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 (tags: java spring programming scalability) [...] […] sampa : colin’s blog » Spring is Most Certainly Designed for Scalability 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 (tags: java spring programming scalability) […]

]]> by: POJO Mojo http://blog.exis.com/colin/archives/2006/01/16/spring-is-most-certainly-designed-for-scalability/#comment-1711 Tue, 17 Jan 2006 17:56:58 +0000 http://blog.exis.com/colin/archives/2006/01/16/spring-is-most-certainly-designed-for-scalability/#comment-1711 <strong>Comments on Spring Scalability</strong> Several people have commented to me, and have posted links to my latest blog posting effectively twisting my words around to make the point that Spring was not designed for scalability. Nothing could be further from the truth. Colin's blog... Comments on Spring Scalability

Several people have commented to me, and have posted links to my latest blog posting effectively twisting my words around to make the point that Spring was not designed for scalability. Nothing could be further from the truth. Colin’s blog…

]]> by: Bob Griswold http://blog.exis.com/colin/archives/2006/01/16/spring-is-most-certainly-designed-for-scalability/#comment-1710 Tue, 17 Jan 2006 17:39:07 +0000 http://blog.exis.com/colin/archives/2006/01/16/spring-is-most-certainly-designed-for-scalability/#comment-1710 Spring is indeed scalable Colin is right - I deserve a spanking (no jokes, please!) and should know better. I was not very clear in my original post, and my words and intentions were taken out of context by a lot of people. Please see my clarification <a href="http://blog.terracottatech.com/archive/2006/01/comments_on_spr.html" rel="nofollow">on the Terracotta blog here</a>. Thanks for clarifying this, Colin! Spring is indeed scalable

Colin is right - I deserve a spanking (no jokes, please!) and should know better. I was not very clear in my original post, and my words and intentions were taken out of context by a lot of people. Please see my clarification on the Terracotta blog here.

Thanks for clarifying this, Colin!

]]> by: Diego http://blog.exis.com/colin/archives/2006/01/16/spring-is-most-certainly-designed-for-scalability/#comment-1709 Tue, 17 Jan 2006 08:47:47 +0000 http://blog.exis.com/colin/archives/2006/01/16/spring-is-most-certainly-designed-for-scalability/#comment-1709 You should not feel attacked by my blog, because I was just expressing what a lot of people in the community feel about Spring: probably the best framework, a good swiss knife, but sometimes you need a hammer and not swiss knife to put a nail. Sorry for the delay publishing comments, some of us have to work. Congratulations anyway for building the best framework. You should not feel attacked by my blog, because I was just expressing what a lot of people in the community feel about Spring: probably the best framework, a good swiss knife, but sometimes you need a hammer and not swiss knife to put a nail.
Sorry for the delay publishing comments, some of us have to work.
Congratulations anyway for building the best framework.

]]> by: Colin Sampaleanu http://blog.exis.com/colin/archives/2006/01/16/spring-is-most-certainly-designed-for-scalability/#comment-1708 Tue, 17 Jan 2006 02:53:40 +0000 http://blog.exis.com/colin/archives/2006/01/16/spring-is-most-certainly-designed-for-scalability/#comment-1708 Hi Eugene, I would define scalability as how well does the app behave under increasing load, and the number is really probably only relevant when comparing it to the number you'd get from alternative implementation/deployment strategies, i.e. you can say, "this approach is more scalable than that approach". So when I said, "And they’ll be able to get scalable apps" I basically meant as scalable as they would using an alternative to Spring for what Spring does. My basic point (and perhaps it didn't come across that clearly) is that you can make apps with a Spring+J2EE based architecture that scale as well or better than the alternatives; EJB 3.0 (or 2.1), doesn't have any real advantage here w/regards to scalability. Spring is just as "designed" for scalability as EJB is (as a container). But of course, as you mention, scalability mostly doesn't come from the container framework itself, but rather from the basic architecture, ability to distribute data structures, and deployment topology. And as you say, Spring is just an enabler here, same as the EJB 3 container would be. That's a nice article btw! Regards, Colin Hi Eugene,

I would define scalability as how well does the app behave under increasing load, and the number is really probably only relevant when comparing it to the number you’d get from alternative implementation/deployment strategies, i.e. you can say, “this approach is more scalable than that approach”. So when I said, “And they’ll be able to get scalable apps” I basically meant as scalable as they would using an alternative to Spring for what Spring does.

My basic point (and perhaps it didn’t come across that clearly) is that you can make apps with a Spring+J2EE based architecture that scale as well or better than the alternatives; EJB 3.0 (or 2.1), doesn’t have any real advantage here w/regards to scalability. Spring is just as “designed” for scalability as EJB is (as a container).

But of course, as you mention, scalability mostly doesn’t come from the container framework itself, but rather from the basic architecture, ability to distribute data structures, and deployment topology. And as you say, Spring is just an enabler here, same as the EJB 3 container would be.

That’s a nice article btw!

Regards,
Colin

]]> by: eu http://blog.exis.com/colin/archives/2006/01/16/spring-is-most-certainly-designed-for-scalability/#comment-1707 Tue, 17 Jan 2006 02:24:23 +0000 http://blog.exis.com/colin/archives/2006/01/16/spring-is-most-certainly-designed-for-scalability/#comment-1707 I actually wonder what do you mean by "scale"? There is no magic in any framework that would make application perform good under increasing number of requests. I guess Bob Griswold’s post was assuming scalability as described in earlier Terracotta's blogs and one who read those may agree that there is not much in frameworks that make it easier to the developer to deploy application on multiple physical servers and make the same data available on each node without hitting bottleneck on the database or other syncpoints. I am not talking about various API-based caches because those assume that developers will know where and when caching should be applied. This issue maybe not as critical for the web frontend applications, for which requests can be always routed to the same node by load-balancer. But in case of asynchronous message-based processing units of work (even related) can be spread randomly across the cluster (especially when communicating with an external messaging server or different cluster) and to synchronize application will have to use some shared infrastructure such as database, L2 cache or something else. Spring don't really help to resolve this, but it prepare a base ground and makes application more structured, so others can take these structures and make them distributed. BTW, please don't consider this as a self promotion, but rather as an example of Spring + J2EE approach. http://dev2dev.bea.com/pub/a/2005/12/spring-aop-with-ejb.html I actually wonder what do you mean by “scale”? There is no magic in any framework that would make application perform good under increasing number of requests. I guess Bob Griswold’s post was assuming scalability as described in earlier Terracotta’s blogs and one who read those may agree that there is not much in frameworks that make it easier to the developer to deploy application on multiple physical servers and make the same data available on each node without hitting bottleneck on the database or other syncpoints. I am not talking about various API-based caches because those assume that developers will know where and when caching should be applied.

This issue maybe not as critical for the web frontend applications, for which requests can be always routed to the same node by load-balancer. But in case of asynchronous message-based processing units of work (even related) can be spread randomly across the cluster (especially when communicating with an external messaging server or different cluster) and to synchronize application will have to use some shared infrastructure such as database, L2 cache or something else. Spring don’t really help to resolve this, but it prepare a base ground and makes application more structured, so others can take these structures and make them distributed.

BTW, please don’t consider this as a self promotion, but rather as an example of Spring + J2EE approach. http://dev2dev.bea.com/pub/a/2005/12/spring-aop-with-ejb.html

]]>