Java ES Architectural Framework
Java ES components support the deployment of distributed software solutions. To achieve the required functionality at the levels of performance, availability, security, scalability, and serviceability mandated by business requirements, these software solutions must be properly designed.
A number of architectural dimensions are involved in designing enterprise-strength solutions. These dimensions represent different perspectives from which to view the interactions of the many software components used to build such systems. In particular, the design of distributed systems involves the following three architectural dimensions:
-
Infrastructure service dependencies. This dimension emphasizes the role of system service components in supporting distributed solutions (see System Service Components).
-
Logical tiers. This dimension emphasizes the logical and physical independence of solution components for the purpose of deploying them across a network or Internet environment.
-
Quality of service. This dimension emphasizes how quality of service requirements such as availability, security, scalability, and serviceability are achieved, including the role of service quality components (see Service Quality Components).
These three dimensions of solution architecture are shown in the following figure.
Figure 2–1 Dimensions of a Java ES Solution Architecture
Together these three dimensions represent a single framework that incorporates the relationships between the software components, both application components and infrastructure components, that are needed to achieve the service functions and service quality required of a software solution.
The following sections describe the three dimensions individually, followed by a synthesis of the three dimensions into a unified framework.
Dimension 1: Infrastructure Service Dependencies
The interacting software components of distributed enterprise applications require underlying infrastructure services that allow the distributed components to communicate with each other, coordinate their work, implement secure access, and so forth. This section explains the key role played by a number of Java ES components in providing these infrastructure services.
Infrastructure Service Levels
In designing a distributed software system, whether it consists mostly of custom-developed components or out-of-the-box Java ES components, you need to incorporate a number of infrastructure services. These services operate at many levels.
The infrastructure service dependencies of solution architecture are illustrated in Figure 2–2. The levels shown in this figure are an expanded view of the infrastructure service layer of Figure 1–1. The hierarchy of services in Figure 2–2 and the dependencies between them constitute an important dimension of a solution’s logical architecture. These infrastructure services provide the main rationale for Java ES system service components (see System Service Components).
In general, the services shown in the following figure divide into three broad groupings: low-level platform services, high-level application services, and a group of middleware services named for their location between the other two groupings.
Figure 2–2 Dimension 1: Infrastructure Service Levels
The following descriptions of the different infrastructure service levels refer to Java programming language artifacts, where relevant, and are listed from lowest to highest, as shown in Figure 2–2:
-
Operating system platforms. Provides the basic support for any process running on a computer. The operating system manages physical devices as well as memory, threads, and other resources necessary to support the Java Virtual Machine (JVMTM machine).
-
Network transport. Provides basic networking support for communication between distributed application components running on different computers. These services include support for protocols such as TCP and HTTP. Other higher-level communication protocols (see the messaging level) depend on these basic transport services.
-
Persistence. Provides support for accessing and storing both static data (such as user, directory, or configuration information) and dynamic application data (information that is frequently updated).
-
Messaging. Provides support for both synchronous and asynchronous communication between application components. Synchronous messaging is the real-time sending and receipt of messages and includes remote method invocation (RMI) between J2EE components and SOAP interactions with web services. Asynchronous messaging is communication in which the sending of a message does not depend on the readiness of the consumer to immediately receive it. Asynchronous messaging specifications, for example, Java Message Service (JMS) and ebXML, support guaranteed reliability and other messaging semantics.
-
Runtime. Provides support required by any distributed component model, such as the J2EE or CORBA models. In addition to the remote method invocation needed for tightly coupled distributed components, runtime services include component state (life cycle) management, thread pool management, synchronization (mutex locking), persistence services, distributed transaction monitoring, and distributed exception handling. In a J2EE environment, these runtime services are provided by EJB, web, and message-driven bean containers in an application server or web server.
-
Security and policy. Provides support for secure access to application resources. These services include support for policies that govern group or role-based access to distributed resources as well as single sign-on capabilities. Single sign-on allows a user’s authentication to one service in a distributed system to be automatically applied to other services (J2EE components, business services, and web services) in the system.
-
User collaboration. Provides services that play a key role in supporting direct communication between users and collaboration among users in enterprise and Internet environments. These services are application-level business services, normally provided by stand-alone servers such as an email server or a calendar server.
-
Integration. Provides the services that aggregate existing business services. Provides a common interface for accessing the services, as in a portal, or by integrating the services through a process engine that coordinates them within a production work flow. Integration can also take place as business-to-business interactions between different enterprises.
The service levels shown in Figure 2–2 reflect a dependence of the infrastructure services on one another, from the lowest-level operating system services to the highest-level application and integration services. Each service generally depends on services below it and supports services above it. Figure 2–2, however, does not represent a strict layering of infrastructure services. Higher-level services can directly interact with lower-level services without depending on intermediate levels. For example, some runtime services might depend directly on platform services without requiring any of the service levels in between. In addition, other service levels, such as a monitoring or management service, might also be included in this conceptual illustration.
Java ES Infrastructure Service Components
Java ES components implement the distributed infrastructure service levels shown in Figure 2–2. The positioning of system service components within the different levels is shown in the following figure.
Figure 2–3 Java ES System Service Components
Note –
The shaded boxes in the figure indicate components that are not included in Java ES. User collaboration components are not part of Java ES but are often deployed with Java ES components and used within Java ES architectures. These components are part of the Sun Java Communications Suite and are referenced in this document for illustrative purposes only. Also, operating system platforms are not formally part of Java ES, but are included to show the operating system platforms on which Java ES components are supported.
Java ES Infrastructure Service Dependencies
In general, each Java ES system service component shown in Figure 2–3 depends on components below it in the infrastructure and supports components above it. These dependency and support relationships are a key factor in designing logical architectures.
The following table shows the specific relationships between the Java ES system service components, listed from top to bottom, as shown in Figure 2–3.
Table 2–1 Relationships Between Java ES System Service Components
Dimension 2: Logical Tiers
The interacting software components of distributed enterprise applications can be viewed as residing in a number of logical tiers. These tiers represent the logical and physical independence of software components based on the nature of the services they provide.
The logical tier dimension of solution architecture is illustrated in the following figure.
Figure 2–4 Dimension 2: Logical Tiers for Distributed Enterprise Applications
For the most part, logical tier architectures represent the distributed enterprise application layer of Figure 1–1 . The Java ES system service components discussed in Infrastructure Service Levels provide support to application components in all of the logical tiers shown in Figure 2–4. While logical tier concepts apply mostly to custom enterprise applications, they also apply to collaboration services provided by Sun Java Communications Suite components and some portal services.
Description of Logical Tiers
This section provides brief descriptions of the four logical tiers shown in Figure 2–4. The descriptions refer to application components implemented using the J2EE platform component model. However, other distributed component models, such as CORBA, also support this architecture.
-
Client tier. The client tier consists of application logic accessed directly by an end user through a user interface. The logic in the client tier could include browser-based clients, Java components running on a desktop computer, or JavaTM 2 Platform, Micro Edition (J2METM platform) mobile clients running on a handheld device.
-
Presentation tier. The presentation tier consists of application logic that prepares data for delivery to the client tier and processes requests from the client tier for delivery to back-end business logic. The logic in the presentation tier typically consists of J2EE components such as Java servlet or JSP components that prepare data for delivery in HTML or XML format or receive requests for processing. This tier might also include a portal service that can provide personalized, secure, and customized access to business services in the business service tier.
-
Business service tier. The business service tier consists of logic that performs the main functions of the application: processing data, implementing business rules, coordinating multiple users, and managing external resources such as databases or legacy systems. Typically, this tier consists of tightly coupled components that conform to the J2EE distributed component model, such as Java objects, EJB components, or message-driven beans. Individual J2EE components can be assembled to deliver complex business services, such as an inventory service or a tax calculation service. Individual components and service assemblies can be encapsulated as loosely coupled web services within a service oriented architecture model that conform to Simple Object Access Protocol (SOAP) interface standards. Business services can also be built as stand-alone servers, such as an enterprise calendar server or messaging server.
-
Data tier. The data tier consists of services that provide persistent data used by business logic. The data can be application data stored in a database management system or it can be resource and directory information stored in a Lightweight Directory Access Protocol (LDAP) data store. The data services can also include data feeds from external sources or data accessible from legacy computing systems.
Logical and Physical Independence
The architectural dimension illustrated in Figure 2–4 emphasizes the logical and physical independence of components, represented by four separate tiers. These tiers signify the partitioning of application logic across various computers in a networked environment:
-
Logical independence. The four tiers in the architectural model represent logical independence: You can modify application logic in one tier (for example, in the business service tier) independently of the logic in other tiers. You can change your implementation of business logic without having to change or upgrade logic in the presentation or client tier. This independence means, for example, that you can introduce new types of client components without having to modify business service components.
-
Physical independence. The four tiers also represent physical independence: You can deploy the logic in different tiers on different hardware platforms (that is, different processor configurations, chip sets, and operating systems). This independence allows you to run distributed application components on the computers best suited to their individual computing requirements and best suited to maximizing network bandwidth.
How you map application components or infrastructure components to a hardware environment (that is, your deployment architecture) depends on many factors, depending on the scale and complexity of your software solution. For very small deployments, a deployment architecture might involve only a few computers. For large-scale deployments, the mapping of components to a hardware environment might take into account factors such as the speed and power of different computers, the speed and bandwidth of network links, security and firewall considerations, and component replication strategies for high availability and scalability.
Tiered Architecture Applied to System Components
As shown in Figure 2–3, Java ES infrastructure service components provide the underlying infrastructure support for distributed software solutions. Some of these solutions include application-level services provided by Sun Java Communications Suite components and some Java ES components. These solutions use logical tier design approaches.
For example, the email communication services provided by Messaging Server are implemented using a number of logically distinct configurations of Messaging Server. These distinct configurations each provide a distinct set of services. When designing messaging solutions, these distinct configurations are represented as separate components that are situated in different logical tiers, as shown in the following figure where lines connecting components represent interactions.
Note –
The following figure is not meant to be a complete logical architecture. A number of Java ES components are omitted to simplify the illustration.
Figure 2–5 Messaging Server: Example of Tiered Architecture
Note –
Communications components are not part of Java ES but are often deployed with Java ES components and used within Java ES architectures. These communications components are part of the Sun Java Communications Suite and are referenced in this document for illustrative purposes only.
The logical separation of Messaging Server functions into different tiers allows the logically distinct configurations of Messaging Server to be deployed on different computers in a physical environment. The physical separation allows for flexibility in meeting quality of service requirements (see Dimension 3: Quality of Service). For example, it provides for different availability solutions for the different instances, and different security implementations for different Messaging Server functions.
Dimension 3: Quality of Service
The previous two architectural dimensions (infrastructure service dependencies and logical tiers) mostly concern logical aspects of architecture, namely which components are needed to interact in what way to deliver services to end users. Another equally important dimension of any deployed solution is the ability of the solution to meet quality of service requirements.
The quality of service dimension of solution architecture highlights the roles played by Java ES service quality components.
Service Qualities
As Internet and e-commerce services have become more critical to business operations, the performance, availability, security, scalability, and serviceability of these services have become key quality of service requirements of large-scale, high-performance deployment architectures.
To design a successful software solution, you must establish relevant quality of service requirements and design an architecture that meets those requirements. A number of important service qualities are used to specify quality of service requirements. These service qualities are summarized in the following table.
Table 2–2 Service Qualities Impacting Solution Architecture|
System Service Qualities |
Description |
|---|---|
|
The measurement of response time and latency with respect to user load conditions. |
|
|
A measure of how often a system’s resources and services are accessible to end users (the uptime of a system). |
|
|
A complex combination of factors that describes the integrity of a system and its users. Security includes physical security of systems, network security, application and data security (authentication and authorization of users), as well as the secure transport of information. |
|
|
The ability to add capacity to a deployed system over time. Scalability typically involves adding resources to the system but should not require changes to the deployment architecture. |
|
|
The ability of a system to handle unusual peak load usage without additional resources. |
|
|
The ease by which a deployed system can be maintained, including monitoring the system, repairing problems that arise, and upgrading hardware and software components. |
The quality of service dimension strongly impacts a solution’s deployment architecture: how application components and infrastructure components are deployed in a physical environment.
The service qualities that affect deployment architecture are closely interrelated. Requirements for one system quality often affect the design for other service qualities. For example, higher levels of security might affect performance, which in turn might affect availability. Adding additional computers to address availability issues through redundancy often affects maintenance costs (serviceability).
Understanding how service qualities are interrelated and which trade-offs to make is key to designing deployment architectures that satisfy both business requirements and business constraints.
Java ES Service Quality Components
Several Java ES components are used principally to enhance the quality of services provided by system service components or distributed application components. These software components are often used in conjunction with hardware components such as load balancers and firewalls.
The Java ES service quality components, introduced in Service Quality Components, are summarized as follows:
-
Availability components. Provide near-continuous uptime of a deployed solution.
-
Access components. Provide secure Internet access to system services, and often provide a routing function as well.
-
Monitoring components. Provide real-time information about Java ES components.
The following table lists the most important Java ES service quality components from an architectural perspective with the system qualities they impact most.
Table 2–3 Service Quality Components and the System Qualities Impacted|
Component |
System Qualities Impacted |
|---|---|
|
High Availability Session Store |
Availability |
|
Monitoring Console |
Serviceability |
|
Security Scalability |
|
|
Sun Cluster |
Availability Scalability |
|
Sun Cluster Geographic Edition |
Availability Scalability |
|
Web Proxy Server |
Security Performance Scalability |
Sun Cluster Software
Sun Cluster software provides high availability and scalability services for Java ES components and for applications supported by Java ES infrastructure. A cluster is a set of loosely coupled computers that collectively provides a single client view of services, system resources, and data. Internally, the cluster uses redundant computers, interconnects, data storage, and network interfaces to provide high availability to cluster-based services and data.
Sun Cluster software continuously monitors the health of member nodes and other cluster resources. In case of failure, Sun Cluster software intervenes to initiate failover of the resources it monitors and uses the internal redundancy to provide near-continuous access to these resources.
Sun Cluster data service packages (sometimes referred to as Sun Cluster agents) are available for all Java ES system service components. You can also write agents for custom-developed application components.
Because of the control afforded by Sun Cluster software, it can also provide for scalable services. By leveraging a cluster’s global file system and the ability of multiple nodes in a cluster to run infrastructure or application services, increased demand on these services can be balanced among multiple concurrent instances of the services. When properly configured, Sun Cluster software can therefore provide for both high availability and scalability in a distributed enterprise application.
Because of the redundancy necessary to support Sun Cluster environments, inclusion of Sun Cluster in a solution substantially increases the number of computers and network links required in your physical environment.
Unlike the services provided by other Java ES components, Sun Cluster availability services are distributed peer-to-peer services. Sun Cluster software therefore needs to be installed on every computer in a cluster.
An extension to Sun Cluster software is provided by Sun Cluster Geographic Edition, which protects applications from unexpected disruptions using multiple clusters that are geographically separated and an infrastructure that replicates data between clusters.
Note –
Sun Cluster and Sun Cluster Geographic Edition are supported on SolarisTM Operating System (Solaris OS) only.
Synthesis of the Three Architectural Dimensions
When viewed together, the three architectural dimensions shown in Figure 2–1 and discussed in the previous sections provide a framework for designing distributed software solutions. The three dimensions (infrastructure service dependencies, logical tiers, and quality of service) highlight the role played by Java ES components in solution architectures.
Each dimension represents a distinct architectural perspective. Every solution architecture must take them all into account. For example, distributed components in each logical tier of a solution architecture (dimension 2) need to be supported by appropriate infrastructure components (dimension 1) and appropriate service quality components (dimension 3).
Similarly, any component within a solution architecture plays different roles with respect to the different architectural dimensions. For example, Directory Server can be seen both as a back-end component in the data tier (dimension 2) and as a provider of persistence services (dimension 1). Because of the centrality of Directory Server with respect to these two dimensions, quality of service issues (dimension 3) are paramount for this Java ES component. A Directory Server failure would have a tremendous impact on a business system, so high availability design for this component is very important. Because Directory Server is used to store sensitive user or configuration information, security design for this component is also very important.
The interplay of the three dimensions with respect to Java ES components impacts the design of solution logical architectures and solution deployment architectures.
Detailed design methodologies based on the architectural framework represented by Java ES Architectural Framework are not described in this book. However, the three-dimensional architecture framework highlights aspects of design that are important to understand when deploying software solutions based on Java Enterprise System.
- © 2010, Oracle Corporation and/or its affiliates