|
Back to Dot-Com Builder How-Tos Archive
A Nine-Step Process for Deriving Infrastructure Architecture from a J2EE Technology Application Architecture
by Rakesh Radhakrishnan Introduction IT architects are often tasked with providing infrastructure design and layout for e-commerce applications based on J2EE technology. They rely in part on application architects to define the application's functional architecture, as well as its J2EE technology architecture. The methodology proposed in this article facilitates the process of building an infrastructure that supports a J2EE application. This nine-step methodology will help IT architects do their jobs more effectively. Designing infrastructure in today's dot-com world has a totally different meaning from designing a traditional application infrastructure. The latter refers to network/compute and storage. The term "infrastructure" includes the following:
Figure 1: Application versus infrastructure Before the advent of the Java application environment and XML, infrastructure typically meant network, computers, and storage -- it did not involve software. Now, application infrastructure solutions (such as the following) offer techniques that meet non-functional requirements such as scalability, compatibility, and so on. Non-functional requirements are specific capabilities -- number of concurrent users to support, expected transaction throughput, maximum allowable response time, supported data growth rate, and acceptable end-to-end latency.
These solutions have evolved to a point wherein non-functional requirements are typically addressed by built-in feature sets from these application infrastructure services. Therefore, application developers simply focus their efforts on building functionality or business services. These applications use basic services that are already built into off-the-shelf solutions sold by multiple vendors. For example, multithreading, concurrency handling, connection pooling, state/session synchronization, container-managed transactions, and persistence are feature sets of the application servers that address the non-functional requirements. In many cases, an integrated development environment (IDE) offers templates for JavaBeans and EJB architecture that application developers can use whether they build, buy, and/or combine business services. As long as the application infrastructure services are built on standards such as the J2EE platform, XML, WAP, and LDAP, the application can be hosted by multiple vendors. Overview of the Architecture Formulation Process This simple and straightforward methodology for architecting infrastructure for J2EE applications uses a top-down approach. Only the business logic, presentation logic, and integration logic are developed in the virtual application layer (VAL). The VAL includes all Java components that run on a virtual machine for the Java platform (such as a JVM built into a Web server, application server, database server, or LDAP server).
The business, presentation, and integration logic primarily meet the functional requirements, and to a certain extent, the non-functional requirements. Everything else -- the application infrastructure, the management infrastructure, the network infrastructure, the compute and storage infrastructure -- is built based on the non-functional requirements or the required architectural capabilities. Functional requirements are specific business functionalities the application is expected to perform -- bill presentment, AP/AR, general ledger, time tracking, expense reporting, and so on. Building the infrastructure starts with the following approach:
The IT architect derives the required application infrastructure solutions based on the J2EE technologies in use for the application. Each application infrastructure solution, along with the selected management infrastructure solution, helps derive the network, compute, and storage infrastructure. The Detailed Step-by-Step Approach
Step 1: Defining Business Requirements
The challenges of supporting a solution's non-functional requirement -- for example, availability -- are impacted by the remaining requirements.
Step 2: Building the Application's Functional Architecture The fundamental point in this step is to determine what business services are to be offered to the user population and how they are to be provided.
Step 3: Building the Application's Technical Architecture This process involves using Java technology patterns such as the model-view-controller pattern; defining external interface communication via JMS, JTS, JIDL, and so on; identifying the usage of stateful beans and stateless beans and container-managed persistence; defining deployment descriptors; and determining protection domains, connectors, and adaptors. A sample J2EE technical architecture describing the flow of functions and its associated J2EE technologies for a financial system is shown Figures 4 and 5.
Step 4: Selecting and Architecting Appropriate Application Infrastructure Services The IT architect decides the locality of these infrastructure services and the appropriate techniques to use. For the directory server implementation, the architect needs to determine: if there is a single master or multiple masters; how LDAP data replication will be achieved; if there will be a directory router in a DMZ; if there are requirements to merge multiple LDAP schemas, and so on. For the integration server, the architect needs to establish if: there will be a proxy agent deployed to masquerade as the integration server; there is sensitive data sent via the XML document that needs digital signatures; there are built-in clustering capabilities for the integration server with a cluster store and multiple data repositories, and so on. Answers to these issues will dictate the design and the layout of the application infrastructure services. Another core activity is establishing communication flow between the application infrastructure services. For example, the communication between the proxy and the Web server is SHTTP, communication between app servers is RMI, and between app server and integration server it is XML over HTTP. A sample communication flow diagram is described in Figure 6.
Step 5: Choosing and Architecting Suitable Management Infrastructure Services
The management infrastructure plays a key role as it directs the J2EE technology-based application via Java Management Extensions (JMX); the application infrastructure; and the network, servers, and storage resources. The management infrastructure's impact on the non-functional requirements is heavy, as it not only addresses the technology factors associated with a J2EE environment but also facilitates the people and processes within the big picture. The management infrastructure also helps derive the network, compute, and storage design in an architecture. If there is a separate network interface from all nodes to a management server -- to isolate the management and monitoring traffic -- the network design is more complex. Storage selection and sizing are affected if the management systems maintain extensive logging. Dedicated network/compute resources need to be selected and sized to host the management infrastructure services to ensure non-intrusive management (see sample management VLAN in the next section).
Step 6: Selecting and Architecting Proper Network Infrastructure Services For example, application infrastructure services such as mail, Web, LDAP, messaging, portal, and transaction typically require application infrastructure components to be placed in the DMZ. These components could include a mail relay, a Web proxy, an LDAP access router, a messaging gateway, a portal gateway, and a transaction bulletin. Additionally, VLANs may be created to offer network scalability and security. A separate network interface from each node may be dedicated to isolate management and back up traffic. A firewall VPN or an application VPN may be established in the EDMZ. The networking gear selected in the form of core routers, distribution switches, and extended switches may offer redundancy by leveraging protocols such as hot-standby routing protocol (HSRP) and virtual router redundancy protocol (VRRP) at the network layer. Figure 8 gives a view of such a sample network design.
Step 7: Choosing and Architecting Appropriate Compute Server Infrastructure Steps 6, 7, and 8 are accomplished concurrently. When the network is being designed, the appropriate compute platform and management infrastructures are also selected and sized. Certain kinds of application infrastructure require vertical scaling within a box; others demand horizontal scaling between boxes; and many are sized with both scaling techniques. An application server may require eight dedicated network interfaces and be sized with two quad-fast Ethernet cards (QFE) -- two for network access, two for isolating session and state synchronization, two for management/backup interface, and two to isolate traffic generated between the application server and the integration server (for example, XML documents). Typically, compute resources that encrypt and decrypt data may be sized with crypto cards to accelerate the speed of encryption and decryption. Compute resources that cache a lot of data -- such as LDAP replicas -- may be configured with more memory than CPUs. Therefore, each compute resource in the architecture is usually selected and sized based on the application infrastructure it runs and the techniques the specific application infrastructure is using to scale. A sample choice of compute infrastructure and its respective location in the network are illustrated in Figure 9.
Step 8: Selecting and Architecting Proper Storage Infrastructure Services For example, LDAP replicas that typically cache several gigabytes of data in memory do not require network attached storage (NAS) or storage area networks (SAN) due to the proximity, size, and location of frequently accessed data. A simple internal 18-GB or 36-GB disk will work efficiently. NAS in the form of network filers are a good fit when a Web server farm is in use where not only static HTML content is served, but dynamically generated content is also cached. If the J2EE technology application is leveraging Java Media extensions and is serving media (audio, video, images) with several terabytes of storage requirements, a SAN is appropriate primarily to address non-intrusive (LAN/server-free) backups and hierarchical storage management. If the database server is complex -- (64-way) 8-node cluster with a PDB configuration and managing several hundred terabytes of data -- a SAN is worthwhile for connectivity issues addressed by SAN switches and the speed at which failover can be handled. Management infrastructure services -- such as backup management services -- require additional sizing and selection of storage media, and the locations of the storage/backup servers. If a SAN is being implemented, details about the backup within it must be figured out; requirements for storage replication need to be met; and extensions to it in the form of core switches and extended switches, and so on, must be possible. Figure 10 depicts a simple storage architecture implementation. Step 9: Ensuring Correct Infrastructure Techniques are Used to Address Non-Functional Requirements Once the design for all the infrastructure layers is firmed up, suitable techniques that offer scalability, security, manageability, compatibility, availability, and adaptability must be turned on at the application infrastructure layer. These techniques make it possible for developers to leverage the network, compute, and storage resources to their fullest extent. A partial list of such techniques is in the following table.
|
 | |||||||||||||||||||||||||||||||
 | |
