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


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.

1.      Objective

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.

2.      Pattern

Multi-Node Deployment Configuration
Figure 1 - Multi-Node Deployment Configuration

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:

  1. The HTTP Server is located in the less secure demilitarized zone (DMZ).
  2. The Application Server is seperated from the HTTP Server and located in a more secure internal network behind the DMZ
  3. 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:

Non-Functional Requirement Advantages Disadvantages
Performance and Scalability
  • Can – with additional infrastructure – be scaled horizontally as well as vertically
  • Suitable for heavy static HTTP load configurations
  • With additional design considerations – such as caching – suitable for high performance configurations
  • Reduced competition for hardware and software resources
  • Many layers may create network and communication overhead which needs to considered
  • Security measures between HTTP Server and Application Server may create additional communication overhead
Availability
  • Can – with additional infrastructure – be clustered if the application is designed for clustering
  • Suitable for medium to high availability solutions
No experienced difficulties.
Non-Functional Requirement Advantages Disadvantages
Security
  • Isolation between the HTTP Server and Application Server
  • Added security for the Application Server, located on the internal network
  • The data is located on the internal network
The connection between the HTTP Server and Application Server poses a security risk, which can be addressed with encryption or other measures.
Non-Functional Requirement Advantages Disadvantages
Maintainability and Operations
  • Clear separation of responsibilities between tiers
  • Offers potential for synergies in administration due separation of tiers
  • Offers potential for sharing hardware resources between applications
  • More complex to administer
  • Requires more infrastructure (hardware, software, middleware, etc.)
Cost of Ownership Offers potential for sharing hardware resources between applications
  • More cost due to more complex administration
  • More cost due to more infrastructure (hardware, software, middleware, etc.)

4.      Known Variations

This chapter outlines some variations of this pattern I have observed.

Variation 1 – DMZ separated into two zones
Variation I of Multi Node Configuration
Figure 2 - Variation I of Multi 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 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:

Non-Functional Requirement Advantages Disadvantages
Performance and Scalability See above See above
Availability See above See above
Security
  • See above
  • Added security for the database server
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

Single 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

[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

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