Read this article if you want to learn how you can deploy a web-centric application on multiple nodes in a complex network infrastructure (with Internet zone, DMZ and Intranet zone). I outlined a number of alternative configurations across the different zones, including advantages and disadvantages.
This is also a commonly found and essential pattern in today’s IT world. It is an enhancement of the pattern “Single Node Deployment Configuration for Multi-Tier Network-Centric Software Applications” covered in a previous entry.
A suitable deployment architecture is developed based on balancing non-functional requirements and constraints. This entry outlines the design rationale behind a multi-node deployment configuration, its advantages, disadvantages and underlying design decisions.
The pattern provides improved high-availability capabilities over the single-node deployment patter, in particular where high HTTP loads are concerned, and is a standard deployment pattern for large applications.
This pattern describes an Architecture that consists of a HTTP Server, Application Server and Database Server. The Application Server contains a HTTP-Container and EJB Container. The particularity about this Architecture is that the HTTP Server and Application Server are deployed on different physical nodes (i.e. physical servers).
While this pattern can be extended to provide scalable and/or services with medium or high availability it is not addressed by this pattern.
I specifically named it a pattern for network-centric applications as this pattern is frequently found in Web applications, but is as applicable for any network-centric application that offers services to a network. Be it now for end-users or as a business-to-business platform.
The conceptual ideas of this pattern may be applied to other technological environments but the pattern itself is geared towards J2EE based Architectures.
3. Design Rationale
Figure 1 shows a typical multi-node configuration for a J2EE application. It is named multi-node configuration because the server application is distributed onto three nodes:
- HTTP Server – For serving static HTTP content and routing incoming HTTP requests to the application server.
- Application Server – Hosts the enterprise application consisting of a HTTP Container (e.g. for dynamic web applications or web services) and a EJB Container (e.g. the application’s business logic)
- Database Server – Hosts the database for the application.
The fourth tier – User tier – has been put there for clients, in case the application has a rich-client or is a system using the application’s services.
Aspects of particular importance with this configuration are:
- The HTTP Server is located in the less secure demilitarized zone (DMZ).
- The Application Server is seperated from the HTTP Server and located in a more secure internal network behind the DMZ
- The Database Server is also located on the internal network behind the DMZ.
With this configuration users are located on the Internet, and requests are routed to HTTP tier. Note that users can also be systems; not just human users.
The HTTP tier decides whether or not the request is for static HTTP content or for the application server. If it is for static content it is fetched and returned to the user. If it is for the application server it is forwarded to the application server.
It is common that HTTP servers are tightly integrated with the application servers in that they proxy and forward incoming HTTP requests. This feature is offered by most major application servers.
The following table addresses the advantages and disadvantages of the discussed deployment configuration based on advantages and disadvantages based on the important non-functional criteria:
|Performance and Scalability||
||No experienced difficulties.|
||The connection between the HTTP Server and Application Server poses a security risk, which can be addressed with encryption or other measures.|
|Maintainability and Operations||
|Cost of Ownership||Offers potential for sharing hardware resources between applications||
4. Known Variations
This chapter outlines some variations of this pattern I have observed.
Variation 1 – DMZ separated into two zones
This configuration is very similar to the configuration above, but provides an additional option to secure network-centric applications. The difference is that the DMZ is divided into two zones: DMZ 1 and DMZ 2. The HTTP Server is placed into the outer DMZ (DMZ 1) and the Application Server is placed into the inner DMZ (DMZ 2). The data tier remains on the internal network, behind the third firewall.
This also has an impact on the non-functional characteristics of the application. The table below describes the differences only:
|Performance and Scalability||See above||See above|
|Availability||See above||See above|
|Maintainability and Operations||See above||More complex to administer due to more infrastructure|
|Cost of Ownership||See above||More administration- and infrastructure intensive than above|
Variation 2 – Splitting the HTTP Container and EJB Container
A fourth variation would be to split the dynamic web application (HTTP Container) and business logic (EJB Container) onto two separate physical nodes. I did not cover this scenario in detail as I do not recommend it. The communication overhead between the two tiers will typically be more costly than the performance gain.
Variation 3 – Intranet Applications
Applications of this kind can – for Intranet use – be placed entirely onto the Intranet.
5. Related Pattern
[IBMa] IBM developerWorks. 2010, “Patterns for e-business”, IBM [online] available at https://www.ibm.com/developerworks/patterns/
[IBMb] IBM Redbooks, 2009, “WebSphere Application Server V7: Concepts, Planning and Design”, IBM [online] available at http://www.redbooks.ibm.com/abstracts/sg247708.html
[IBMc] IBM Redbooks, 2006, “WebSphere Application Server V6.1: Planning and Design”, IBM [online] available at http://www.redbooks.ibm.com/abstracts/SG247305.html?Open
[IBMd] IBM Redbooks. 2005, “WebSphere Application Server V6 Scalability and Performance Handbook”, IBM [online] available at http://www.redbooks.ibm.com/abstracts/SG246392.html
[IBMe] IBM Redbooks. 2006, “IBM WebSphere Application Server V6.1 Security Handbook”, IBM [online] available at http://www.redbooks.ibm.com/abstracts/sg246316.html?Open
[IBMf] IBM Redbooks. 2009, “WebSphere Application Server V7.0 Security Guide”, IBM [online] available at http://www.redbooks.ibm.com/abstracts/sg247660.html
[Oraclea] Oracle Documentation – Oracle® WebLogic Server 10g Release 3 (10.3) Documentation Site Map. 2008, “Using Clusters – Chapter Cluster Architectures”, IBM [online] available at http://download.oracle.com/docs/cd/E12840_01/wls/docs103/cluster/planning.html
[Oracleb] Oracle Documentation – Oracle® WebLogic Server 10g Release 3 (10.3) Documentation Site Map. 2008, “Securing a Production Environment”, IBM [online] available at http://download.oracle.com/docs/cd/E12840_01/wls/docs103/lockdown/index.html
[Pic2010] Pichler, M. 2010, “Architectural Pattern: Single Node Deployment Configuration for Multi-Tier Network-Centric Software Applications”, A Practical Guide to Software Architecture [online] available at https://applicationarchitecture.wordpress.com/2010/03/02/architectural-pattern-single-node-deployment-configuration-for-multi-tier-network-centric-software-applications/
[pra2006] pranshujain. 2006, “Layers and Tiers”, Software Architecture and Content Management [online] available at http://pranshujain.wordpress.com/2006/09/15/layers-and-tiers/
Copyright © 2010 Michael Pichler