Hi,
Under what circumstances should we provide physical separation of different layers such as presentation, business logic?
Does it make sense to keep the presentation layer in a web server (tomcat) and the business logic layer in an application server (glassfish, jboss)?
Or should everything reside in one application server?
Kindly help me with your suggestions.
Good question. This decision would depend upon the environment and resources. Most application servers have web servers inside them. I can't think one one that doesn't.
If your environment has multiple nodes and is a clustered environment, it wouldn't make sense to have a separate machine just for the Presentation tier. However, it really depends upon the application, and particularly, the demands on the Business tier in relation to how many nodes are hosting the application.
More commonly, you would separate the Integration tier and Business Tier physically. Here you might have heavy data issues and required a separate machine to host one or more relational databases.
The design of each system architeture is based upon the business and non-technical requirements of the application. Each Java EE application is a bit different than the next. There are general "rules of thumb", but ultimately it depends on the applications requirements.
For one application, it may make sense to physically separate the Presentation tier from the Business tier. For another application, it may make sense to keep everything in a single application server.
One case comes to mind, if you are writing a GUI for a thirdy-party application, or an application hosted by another side of the business. You may not be able to integrate the GUI with the business logic machine/application server. Here having the GUI on a different machine (node) would be the only and best option.
> However, it really depends upon the application, and
> particularly, the demands on the Business tier in
> relation to how many nodes are hosting the
> application.
In my case, the business tier has to serve both web clients and application clients.
Both these clients may number in thousands.
I'm thinking of the following:
Web Clients => Web Server => Application Server => Database
Application Clients ========> Application Server => Database
But heavy load will be from the Application Clients.
> Hi,
> Under what circumstances should we provide physical
> separation of different layers such as presentation,
> business logic?
As expressed before, there are no hard and fast rules, however I see three aspects involved in the decision: scalability, administration, maintenance
scalability: (note that I didn't say "performance") is probably the least impacting this decision:
Depending on the application, on its functional usage as well as its technical flows, you may want to fine-tune the repartition of resources devoted to the web tier independently from the resources devoted to the business tier. If the application undergoes a lot of servlet requests, but most of them do not invoke business services, you may want to have more web container nodes (say Nw) than you have EJB containers (say, Nb).
However, it's not necessarily a waste of resources to have them all in (NW=Nb) application servers: the business part of each of them will be less loaded than the web part, that's all.
> Does it make sense to keep the presentation layer in
> a web server (tomcat) and the business logic layer in
> an application server (glassfish, jboss)?>
> Or should everything reside in one application server?
"A", "One"?
OK, so if the load is not that big, and you are confident enough in your application, and deem that you won't need clustering nor failover today, then the physical separation makes only sense if you plan to enable to have them tomorrow (say, cluster the web tier with 2-3 nodes while keeping only one business-tier node, or the other way round).
Note that I didn't mention that the database tier is most likely physically separated in all cases, if not for failover, be it only because the hardware requirements (disk, memory,...) are quite different from the web or AS hardware.
Administration:
Putting both web and business parts in the same AS enables you to monitor and manage all parts from a single management console, often an AS-specific one, cluster-aware, or an external tool using AS-specific agents.
By separating the layers you complexify the administration of the whole system; you may still have a single management console, but then it's necessarily an external tool, and you have to configure it to collect and correlate info from all nodes.
Maintenance:
Your application will have bugs, failures, outages. Even if very bug-free, it will undergo upgrades.
Separating the layers enables you to sometimes upgrade them independently (say, upgrade the web part for cosmetic enhancements with no impact on business logic).
This possibility should not be overestimated because as soon as the upgrade involves a coupling (e.g. modification of an API between the web and business tier), you will on the contrary be much safer to upgrade both in one atomic upgrade.
One last thing, if you deploy your apps as separate war and jars, instead of as one big ear, the AS will likely enable you to undeploy/upgrade/redeploy each part separately. In one EAR, the undeploy/redeploy is normally atomic, unless there are AS-specific enhancements.
> In my case, the business tier has to serve both web
> clients and application clients.
> Both these clients may number in thousands.
>
> I'm thinking of the following:
>
> Web Clients => Web Server => Application Server =>
> Database
> Application Clients ========> Application Server =>
> Database
>
> But heavy load will be from the Application Clients.
The fact that you have two different categories of clients that target different entry points of the application does not imply that you have to physically separate the entry points.
