The main reason I would isolate the web parts and the business tier is for deployment flexibility. By web, I do not include static content. This would of source sit on a Http server in the DMZ. There are no security risks in collocating the dynamic web content(servlet container hosted components) and the business tier if you have infrastructure like firewalls and a DMZ set up. With the move towards POJO based business tiers and frameworks that support it, I personally wouldnt want to add more tiers to my application unless there are significant benefits.

There is a strong case however for module based deployment (see OSGi) and we might still break up our ear to multiple parts. But I dont see it being done to separate web and ejb parts. I dont see value there.

The number of end users does not affect deployment approach. The size of the application might influence deployment if it is a standalone application deployed via the network. For server side J2EE components, you might still break it up for benefits like what you get in OSGi i.e. control over dependencies, dynamic deployment without server restart, ability to break up monolithic applications into discreet modules e.t.c.

However, the ease of deployment apart – would it be better to go for collacted approach as the application – the business services – grows ? Is there a compromise on security for the collacted approach? Is the decision based on number of end users/size of application – or what other factors need to be considered ?

happy techhing.

Regu: “… in a IP level load-balanced setup, once a request is assigned to a server, the burden is solely on the machine servicing the request and thereby processing the entire thread of execution for a period of time when other servers could have unused processing capability.”

While this is theoretically true, applications will scale and perform best if you can design them to be load-balance-able AND if they are CPU constrained. In other words, you should _design_ them to max out those CPUs, so that all you have to do to scale linearly or near-linearly is to add more and more commodity servers.

Furthermore, attempting to distribute CPU-efficient work will negatively impact both latency (how long it takes to process a request) and aggregate CPU (since distribution itself will require CPU work on both ends).

The key to achieving the goal of bottlenecking on a CPU is to eliminate “IO wait” cycles, i.e. to make sure that the application never waits for data. In our case, we have witnessed this first-hand at quite a few of the worlds largest web sites, for example. (Our Coherence software is used by most of the largest Java- and .NET-based ecommerce, travel, gambling, banking and other web sites.)

Regu: “There are ways to address this issue and ensure high CPU utilization before deciding that scalability is a factor of number of machines/CPU”

As I mentioned, the goal should be to achieve scalability by finding a way to turn “load on the application” into “high CPU utilization in the scalable app tier”.

Regu: “Co-locating applications : different applications have varied peak loads. Co-locating applications on a shared setup(software i.e framework, hardware) ensures overall better scalability and availability. [I have worked on an engagement where we have 6 applications co-deployed in production on just 2 blade servers]”

This is a much different type of scalability than the one that I am referring to. In the case that I am describing, a large ecommerce site (like some un-named auction site) may have 6,000 application servers running the same application to handle the web traffic, as opposed to one server hosting 6 applications.

Regu: “Leveraging multi-threading capabilities of the JVM. Now but isnt that against the specifications? Actually no, if you use the features of the JVM to multi-thread say Message Driven Bean(MDB) for e.g”

Yes, the container will handle messaging, HTTP requests, etc. in a multi-threaded manner. This does help significantly to achieve high CPU utilization, by allowing one thread in an “IO wait” state to go to sleep, letting another one do its work.

Of course, the key to making it scale across machines is to make sure that those machines are not all sharing a single data source, or they will all be “IO waiting” on the same shared server (e.g. a database), and the result will be that the waits will get longer and longer.

I hope this helps!

Peace,

Cameron Purdy
http://www.tangosol.com/

The key for data correctness is data replication. In GigaSpaces we have a very sophisticated cluster replication paradigm that makes sure data is consistent across the grid.

For more information, please have a look at: http://www.gigaspaces.com/wiki/display/GS/Data+Grid

The scalability paradigm you describe here known also as SBA – Space Based Architecture.
SBA is a share-nothing architecture. Self sufficient processing units are deployed on a grid.
Every processing unit contains business logic and data and is activated based on CBR scheme.

When application tiers are logical, no network overhead is involved and no data format transformation is required. The data is co-located with the business logic and it is in object format there is no need for the fetch (from a central data source) -> lock -> convert to object -> process -> convert to sql -> store paradigm anymore.

By collapsing the tier and bringing data and logic into the same address space you can achieve true linear scalability, low-latency which results in much better utilization of processing power.