Use of EJBs doesn't make an application magically scalable, unfortunately. In an ideally horizontally scalable system you can just throw more nodes at it, but it is certainly not just limited to infrastructure. Your application needs to accommodate this, and that can be hard to achieve. How scalable a system should be is also difficult to determine, because in the architectural phase you don't know how the system is going to perform with a single node, let alone X nodes operating concurrently. That can only be measured. Should it be able to scale dynamically depending on load? Is it allowable to use a BASE consistency model to achieve increased scalability or is ACID required? There are a lot of concerns that conflict with high scalability and a lot of ways to reach a level of scalability that fits. It's impossible to list a set of solutions or technologies that are always applicable. It's always a different puzzle.
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
As Jelle mentioned, (fortunately or unfortunately )each problem is different and there are different solutions.
During my experience so far (which is not much acutally )while scaling up the application, I needed to take decision whether to switch to EJB or stay in Core Java, whether I can afford the overhead of EJB etc. There were times where Core Java a was actually a better option (even given the overhead of manual coding for multi-threading and network communication).
Sometimes the issues used to get fixed just by increasing heap size and number of threads, sometimes I needed to fine tune the GC algorithms and relevant JVM arguments and so on.
However, typically, if a code is good enough (i.e. optimum usage of GC, proper thread-safety, no unnecessary synchronization etc.) then usually increasing heap size and number of threads does the trick, but again, it totally depends upon the way the code is written and what is exact bottleneck (e.g. application might work nicely with single JVM, but with multiple JVMs, inter-JVM communication might be one of the bottlenecks etc.)
Andres Delrotti wrote:Have you ever did a design for an application with requirements such as X number of anticipated users of the application in the next 5 years, and should still perform as expected.
Answers: yes, and (oddly) not as difficult as you might think; it just takes a bit of planning.
The fact is that no system is likely to remain static over the course of five years, and upgrades to memory, CPU, storage, and (possibly most important) your network pipe can do an awful lot to help maintain SLAs. These just need to be planned and budgeted for.
Where choosing EJB might help is in providing increased manageability and flexibility when you do start to expand; but it is quite an undertaking, so you need to be sure that it's not a "sledgehammer to crack a walnut" at this stage.
I'm also not sure that it's a simple "either/or" choice (not an EJB expert, so I really can't say). If you write your system clearly and simply, using good OO principles, it seems to me the sort of thing that could be factored into your "5-year plan", say when you hit some threshold. That way you don't incur a big initial expense before your figures actually reflect a need.
My 2 ¢ (and I could be wrong )
Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
H Paul wrote:I found your question is cool and I sell you this article for free:
Fallacies of Distributed Computing Explained
Interesting. I also like your notion of "selling". Maybe it'll catch on...
I was a "jack of all trades" (*n[iu]x, network, db, security) admin for nearly 15 years, so I'm aware of a few of the things you (?) mention, but I'm sure they'll provide good bedtime reading for anyone else who's interested.