Architectural Pattern: Single Node Deployment Configuration for Multi-Tier Network-Centric Software Applications


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.

1.      Objective

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.

2.      Pattern

Single Node Deployment Configuration
Figure 1 - Single Node Deployment Configuration

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:

  1. client tier,
  2. application tier (the HTTP Server and Application Server), and
  3. data tier.

Aspects of particular importance with this configuration are that:

  1. the entire application is located in one physical server in the demilitarized zone (DMZ), and that
  2. 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:

Non-Functional Requirement Advantages Disadvantages
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
Security
  • No security benefits for the application server
  • The data is located on the internal network
  • Not recommended from a security point of view
  • Application code is located in DMZ
  • No isolation between HTTP server and Application Server
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
Variation I of Single-Node Configuration
Figure 2 - Variation I of Single-Node Configuration

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:

Non-Functional Requirement Advantages Disadvantages
Performance and Scalability See above See above
Availability See above See above
Security
  • See above
  • Added security for the application server
See above
Maintainability and Operations
  • Other than to disadvantages see above
  • More complex to administer due to reverse proxy server.
Cost of Ownership See above
  • Requires more hardware, software and administrative resources than similar configurations
Variation 2 – DMZ separated into two zones
Variation II of Single-Node Configuration
Figure 3 - Variation II of Single-Node Configuration

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

Architectural Pattern: Multi Node Deployment Configuration for Multi-Tier Network-Centric Software Applications

References

[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

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s