6.4. System Architecture: Layers Upon Layers

To ensure that its applications are channel-neutral, Codexa has layered its application architecture and centered business logic in the application server. This allows the applications to interface with new devices and standards without affecting the core business logic. Of course, the J2EE platform provides a natural fit for this kind of architecture because it is inherently layered.

Figure 6.1 illustrates the layering and partitioning within the Codexa system.

In the Codexa Service, incoming requests from users or outgoing notifications are handled through a Web or WAP server. The system uses XSL and XSLT to transform its XML document representation of data models to WML, HTML, or an XML stream for the system to process.

For the wireless channel, the international standard Wireless Application Protocol provides more-efficient Internet access than HTML because the communications stream is sent as encoded binary rather than bulky text. Wireless Markup Language (WML) provides simplified page descriptions and scripting for wireless applications, and lightweight Java Messaging Service (JMS) helps guarantee delivery of wireless communications. HTML on the Web side is ideal because it allows Codexa to provide information to client organizations without dealing with firewall issues. Codexa's JMS vendor, Softwired, has an implementation that uses HTTP for firewall tunneling, yet still supports guaranteed message delivery.

Requests from the Web or WAP server or outgoing messages to the client are handled through the servlet engine running on the GemStone/J application server. The servlet engine calls Enterprise JavaBeans (EJBs) running in Java virtual machines, which call other processes to assemble content from the GemStone/J persistent cache.

The beauty of this layered approach is that the presentation engine and the business engine don't need to know where the data is coming from or where it's going. Applications are channel-neutral because the WAP or Web server on the front end takes care of front-end communication issues and user interface issues. And because the layers isolate business information and rules from transport issues, Codexa can incorporate new front-end technologies simply by changing the front-end server.

6.4.1. GemStone/J Provides the Power

For more than 15 years, GemStone (Brokat's Java Server Unit) has helped companies build large-scale, distributed application architectures for the enterprise. As the industry moved to Java applications for e-business, the company applied its intellectual property and expertise to create practical solutions for the J2EE platform. This initiative provides a blueprint of proven, time-tested architectures and best practices for developing high-end Business-To-Business (B2B) sites and sophisticated distributed applications, such as the Codexa Service, based on J2EE technologies.

GemStone/J's chief contribution to Codexa is its Extreme Clustering architecture—multilevel resource clustering designed for high-volume, distributed environments and, able to support tens of thousands of concurrent users and many millions of transactions per day.

Extreme Clustering includes

• Multi-VM architecture. A distributed clustering architecture that transparently manages hundreds of virtual machines and other resources per server and across multiple servers

• Smart Load Balancing. Intelligent, multilevel load balancing that matches processing needs for specific operations to Java virtual machines configured to meet those needs

• Total Availability Technology. Multilevel failover to ensure continuous service and performance, plus tools and features that allow administrators to expand and adapt the e-commerce system without interrupting service

Extreme Clustering is supported and enhanced by GemStone/J's Persistent Cache Architecture (PCA), which enables users and processes to efficiently share access to business objects, and its Object Transaction Service, which provides flexible, multilevel transaction mechanisms to efficiently maintain transactional integrity across distributed business systems.

GemStone/J's Extreme Clustering architecture is designed with clustered resources at multiple levels to avoid resource bottlenecks. Figure 6.2 gives a detailed look at the server architecture behind the Codexa system.

• At the front end, requests from clients to Web servers are handled via routers and DNS scheduling. Codexa utilizes F5's HA+ for intelligent load balancing algorithms, such as lightest load or best response.

• GemStone/J uses HotSpot VMs, which provide a threefold to fivefold performance improvement over classic Java virtual machiness through improved thread handling and garbage collection.

• Each application server host supports multiple servlet engines, each in its own Java virtual machine. Servlet adapters in the Web servers independently balance requests across these servlet engines.

• Each GemStone/J application server manages pools of EJB/CORBA VMs across one or more hosts. The Global Name Service and the Object Transaction Monitor allow objects to be distributed and shared across multiple virtual machines and multiple hosts, while the Activator, using Smart Load Balancing, matches processing needs for specific operations to Java virtual machines configured to meet those needs.

• Pooled JDBC sessions optimize access to back-end relational databases.

• The GemStone/J Persistent Cache Architecture underlies and supports other resources. It provides fast, transactional access to objects through its distributed, shared-page cache; transparent object persistence to minimize object-to-relational translation for in-process data; and support for distributed, heterogeneous transaction control. It does not rely on Java serialization nor mapping to external databases.

6.4.2. J2EE Provides the Tools

To accommodate changing client needs, Codexa needs to be able to adapt or extend its applications continuously. To create a rapid application development (RAD) environment for prototyping and engineering iterations, all the technologies within the Codexa Service are based on Java technologies. Within its layered architecture, the Service relies on the J2EE platform and other technologies to provide security, scalability, reliable communication, and lifecycle management of business objects and processes. Figure 6.3 illustrates the technology stack.

In the top layer of the figure, Java Server Pages (JSPs) and Swing are used to build Web user interfaces (UIs), while InfoBus and JMS are used for system-to-system interface. (In this layer, the JMS is a producer for the InfoBus, with InfoBus as a static data bus for a presentation virtual machine.)

Enterprise JavaBeans manage session state and “short-lived” behaviors, such as component-to-component data processing and client requests via servlets and JSPs.

The next layer provides lifecycle management for longer-lived objects in the system. XML Document Type Definitions (DTDs) represent the directory hierarchies and are used to depict domain objects and their relationships to other domain objects. EJBs can use these to create CORBA objects that are run on behalf of a namespace within the Java Naming and Directory Interface (JNDI), allowing for natural system and component partitioning, and register them with the JNDI. The JNDI is the main interface for locating objects in the directory structure and creating contexts for state and relationship management among logical components. Java Transaction Service (JTS) provides XA-compliant ACID transaction management, and Java Messaging Service handles message queuing for guaranteed data delivery.

The persistence layer is handled through GemStone/J's Persistent Cache Architecture. When a given object's useful life within the system has expired, JDBC is used to store it as historical information in the relational database.

Java Security Architecture (JSA), Java Authentication and Authorization Service (JAAS), and Java Cryptography Architecture (JCA) provide multilevel security for Codexa applications.

The whole system leverages the Java 2, Standard Edition architecture, using multiple VMs, distributed processing, and other features to create a scalable, highly available system.