Scaling J2EE Technology Applications Based on Application Infrastructure Techniques - Part 4
March 23, 2001

by Rakesh Radhakrishnan

This article is the fourth in a four-part series that identifies multiple techniques for scaling applications based on J2EE technology to support many concurrent users.

Scaling Techniques

Certificate Server - Functional Partitioning and Workload Distribution (e.g., iPlanet Certificate Server)
Certificate servers are critical for applications based on J2EE and XML technologies, especially in the financial space. Component-level security is achieved through digital signatures of Java and XML components. Application-level security and intrusion detection can be achieved via certified components. These techniques ensure that transaction integrity is maintained.

Typically the certificate authority for J2EE technology-based applications is outsourced to well-known certificate authorities (CAs) such as Verisign, Entrust, Identrus, and so on. In those unique cases where the CA is hosted locally, the certificate management server (CMS) can be scaled through a simple and successful approach of functional partitioning and workload distribution.

The CMS can be functionally partitioned into a RM (registration manager), a CM (certificate manager) and a DM (data store/data recovery manager) - as shown in Figure 18.

Figure 18: Functional partitioning (Click image to enlarge.)

The data manager can further be extended into DM-master and DM-replica. Through this approach, if the master data store fails, the replica takes over as the master, and vice versa. You can also configure the RM to take over the role of the CM when the CM fails, and vice versa. Figure 19 shows the addition of a second DM.

Figure 19: Redundant data stores (Click image to enlarge.)

CORBA Server - Load Balancing and Gatekeeper (e.g., VisiBroker or Iona Orbix)
CORBA (Common Object Request Broker Architecture) servers, such as Inprise's VisiBroker or Iona's Orbix, are required in dot-com environments where applications based on J2EE technology must communicate and interact with non-Java applications (like those built on C++). Enabling this communication in the J2EE technology-based framework requires Java IDL. You can also use RMI over IIOP (Internet Inter-ORB Protocol). (For more information on this topic, see the Java IDL FAQ on Sun's Java technology Web site.)

Java IDL adds CORBA capability to the Java platform, ensuring standards-based interoperability and connectivity with applications not based on Java technology. Utilizing the industry standard OMG IDL (Object Management Group Interface Definition Language) and IIOP defined by the Object Management Group, Java IDL makes it possible for distributed Web-enabled Java applications to transparently invoke operations on remote network services built with other programming languages.

There are two primary techniques associated with scaling CORBA servers: load balancing across multiple CORBA servers and using a gatekeeper.

Load-balancing CORBA Servers
You may find yourself faced with building a dot-com environment based on J2EE technology where there are frequent inter-application interface calls via a CORBA server. In such scenarios the load on the CORBA server may be heavy, and thus the CORBA server could be a potential bottleneck in the environment.

Distributed directory services can dynamically keep track of objects installed and/or active in the ORB (Object Request Broker). Server objects register with intelligent agents at startup.

Client applications seeking to communicate with a server object of a particular type obtain an object reference from these intelligent agents, and then they re-use the object reference to communicate directly with an instance of the server object.

Typically there is an object activation/deactivation daemon, which runs on each machine that hosts server objects. It cooperates with the intelligent agents to ensure that server objects are activated on demand and are shut down when they are no longer needed. Through this technique you can achieve load balancing within and across multiple CORBA servers.

Figure 20: Load balancing multiple CORBA servers (Click image to enlarge.)

Gatekeeper

The gatekeeper is the second technique associated with scaling CORBA servers. For this technique to be effective, client applications must be able to access server objects independent of their physical locations. Also known as location transparency, this is a fundamental principle of component-based distributed computing.

With an ORB gatekeeper, applications meet the requirement of location transparency. The ORB gatekeeper's role is to establish itself as a proxy object for all incoming requests from client applications. Should the server object not be available on the application host, the gatekeeper automatically creates a proxy object, thus coordinating access to all server objects that would otherwise be unreachable.

Additionally, the gatekeeper can route IDL traffic between multiple ORB servers dedicated to individual applications built on specific programming languages (such as, Java, C and C++). This technique is shown in Figure 21.

Figure 21: Gatekeeper for dedicated, multiple ORBs (Click image to enlarge.)

An alternative approach to boost performance is to build Java Native Interfaces (JNI) to speed up access and inter-application calls.

Conclusion: Scaling Techniques, Nine Design Principles

The techniques discussed in this series address nine fundamental design principles, namely:

1. Locality - Data-dependent routing - JTS. Location of data is taken into account when addressing distributed transactions.
2. Efficiency - Directory access router and replication - JNDI. Updates to master do not affect performance of LDAP data replica propagation.
3. Modularity - Building modular and de-coupled applications with presentation logic in Web components and business logic in EJB components, and therefore, paving the way for both vertical and horizontal scaling in multiple tiers.
4. Distribution - IPLB for distributed Web components - Applet/Servlet/JSP. Distributed Web components are load-balanced and redundantly available.
5. Redundancy - Redundant processes with distributed queues - JMS. Redundant messaging processes address guaranteed message delivery along with distributed queues.
6. Parallelism - Parallel DB - SQLJ. Parallel execution of transactions and embedded SQL in Java by multiple database nodes against the same database.
7. Workload - CARP and proxy chaining - Applet/Servlet/JSP. Workload is evenly distributed between chained proxies content.
8. Sharing - CM, RM and DRM - Certificates. Central certificate and registration authorities are shared for certification of a site, client, application components, and so on.
9. Isolation - Isolation of interfacing logic to non-Java application via Java IDL components and CORBA servers.

It is the architect's role to identify bottlenecks - or potential bottlenecks - in the environment and apply the appropriate scaling technique to the application infrastructure to give a boost to the performance of the application.

The architect should also incorporate high availability, especially when introducing redundancy for scalability purposes. This recommended approach achieves two objectives, scalability and availability, with a single effort. All the techniques discussed in this series address both availability and scalability of the application infrastructure, in that they introduce redundancy in one form or another.

Based on your requirements, choose an appropriate technique when incorporating scaling into an application infrastructure service that supports a J2EE application.