Read this article if you want to earn how you can deploy a web-centric application on a single node in a complex network infrastructure (with Internet zone, DMZ and Intranet zone). I outlined a number of alternative configurations, including advantages and disadvantages.
This is a commonly found pattern in today’s IT world. I nevertheless wanted to cover it in a short entry as it is an essential pattern to know.
A suitable deployment architecture is developed based on balancing non-functional requirements and constraints. This entry outlines the design rationale behind a single-node deployment configuration, its advantages, disadvantages and underlying design decisions.
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 one physical node (i.e. physical server).
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 single-node configuration for a network-centric J2EE application. It is called single-node configuration because the entire application – i.e. the Application Server and HTTP Server – is located on a single physical node (physical or virtualized server).
The application represents a typical three-tier application consisting of:
- client tier,
- application tier (the HTTP Server and Application Server), and
- data tier.
Aspects of particular importance with this configuration are that:
- the entire application is located in one physical server in the demilitarized zone (DMZ), and that
- the database server is located in a more secure Intranet zone, behind the DMZ.
The users are located on the Internet, and user requests are routed to the application tier through the first firewall and network infrastructure. Note that users can also be systems; not just human users.
A single-node configuration of this kind has some advantages as well as disadvantages which are outlined in the table below based on the important non-functional criteria:
|Performance and Scalability||Can – with additional infrastructure – be scaled horizontally as well as vertically||Heavy static HTTP traffic may consume resources needed by application server and vice versa|
|Availability||Can – with additional infrastructure – be clustered if the application is designed for clustering||HTTP Server is co-located with Application Server – Application Server will be unavailable if HTTP Server fails|
|Maintainability and Operations||Simpler to administer as there is only one physical server for the application.||No experienced disadvantages|
|Cost of Ownership||Less hardware, software and administrative resources required than for other configurations||N/A|
4. Known Variations
This chapter outlines some variations of this pattern I have observed.
Variation 1 – Application placed in Intranet
The primary intent of this change is to increase security for the application tier. It is now located on the internal network, instead of the DMZ. The users’ requests are passed on to the application via network infrastructure and reverse proxy server.
Naturally, this 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||
|Cost of Ownership||See above||
Variation 2 – 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 application tier remains in the DMZ, but that the DMZ has two zones separated by a firewall which provides more security than conventional environments.
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
[Pic2010a] Pichler, M. 2010, “Architectural Pattern: Multi 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/16/architectural-pattern-multi-node-deployment-configuration-for-multi-tier-network-centric-software-applications/
[Pic2010b] Pichler, M. 2010, “Knowledge Nugget: Reverse Proxy”, A Practical Guide to Software Architecture [online] available at https://applicationarchitecture.wordpress.com/2010/03/30/knowledge-nugget-reverse-proxy/
[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