Sun Java logo     Previous      Contents      Index      Next     

Sun logo
Sun Java Enterprise System 2005Q1 Deployment Planning Guide 

Chapter 4
Logical Design

During the logical design phase of the solution life cycle, you design a logical architecture showing the interrelationships of the logical components of the solution. The logical architecture and the usage analysis from the technical requirements phase form a deployment scenario, which is the input to the deployment design phase.

This chapter contains the following sections:


About Logical Architectures

A logical architecture identifies the software components needed to implement a solution, showing the interrelationships among the components. The logical architecture and the quality of service requirements determined during the technical requirements phase form a deployment scenario. The deployment scenario is the basis for designing the deployment architecture, which occurs in the next phase, deployment design.

When developing a logical architecture you need to identify not only the components that provide services to users, but also other components that provide necessary middleware and platform services. Infrastructure service dependencies and logical tiers provide two complementary ways of performing this analysis.

Infrastructure service dependencies and logical tiers are two of the three dimensions of the solution architecture upon which Sun Java™ Enterprise System is based. The three dimensions are listed below and are also represented in Figure 4-1.

A logical architecture depicts infrastructure service levels by showing the necessary components and their dependencies. A logical architecture also distributes the components among logical tiers that represent presentation, business, and data services that can be ultimately accessed by a client tier. Quality of service requirements are not modeled in the logical architecture but are paired with the logical architecture in a deployment scenario.


Designing a Logical Architecture

When you design a logical architecture, use the use cases identified during the technical requirements phase to determine the Java Enterprise System components that provide the services necessary for the solution. You must also identify any components providing services to the components you initially identify.

You place the Java Enterprise System components within the context of a multitiered architecture according to the type of services that they provide. Understanding the components as part of a multitiered architecture helps you later determine how to distribute the services provided by the components and also helps determine a strategy for implementing quality of service (such as scalability, availability, and others.)

Additionally, you can provide another view of the logical components that places them within secure access zones. The section Access Zones provides an example of secure access zones.

Java Enterprise System Components

Java Enterprise System consists of interacting software components providing enterprise services that you can use to build your enterprise solution. The following figure shows the key software components provided with Java Enterprise System. The Java Enterprise System Technical Overview, http://docs.sun.com/doc/819-0061, provides additional information on Java Enterprise System components and the services they provide.

Figure 4-2  Java Enterprise System Components

Diagram showing the relationship among the components of Java Enterprise System.[D]

Component Dependencies

When identifying Java Enterprise System components for a logical architecture, you need to also identify supporting components. For example, if you identify Messaging Server as a necessary component to a logical architecture, then your logical architecture must also include Directory Server and possibly Access Manager. Messaging Server depends on Directory Server for directory services and Access Manager for solutions requiring single sign-on.

The following table lists dependencies of Java Enterprise System components. Refer to Figure 4-3 for a visual representation of dependencies among key components. When designing a logical architecture, use this table and accompanying figure to determine dependent components in your design.

Table 4-1  Java Enterprise System Component Dependencies 

Java Enterprise System Component

Depends On

Application Server

Message Queue
Directory Server (optional)

Calendar Server

Messaging Server (for email notification service)
Access Manager (for single sign-on)
Web Server (for web interface)
Directory Server

Communications Express

Access Manager (for single sign-on)
Calendar Server
Messaging Server
Instant Messaging
Web Server (for web interface)
Directory Server

Directory Proxy Server

Directory Server

Directory Server

None

Access Manager

Application Server or Web Server
Directory Server

Instant Messaging

Access Manager (for single sign-on)
Directory Server

Message Queue

Directory Server (optional)

Messaging Server

Access Manager (for single sign-on)
Web Server (for web interface)
Directory Server

Portal Server

If configured to use Portal Server Channels:

Calendar Server
Messaging Server
Instant Messaging

Access Manager (for single sign-on)
Application Server or Web Server
Directory Server

Portal Server Secure Remote Access

Portal Server

Web Server

Access Manager (optional, for access control


Note

The dependencies among Java Enterprise System components listed in Table 4-1 does not list all component dependencies. Table 4-1 does not list dependencies that you must consider when planning for installation. For a complete list of Java Enterprise System dependencies, refer to the Java Enterprise System Installation Guide., http://docs.sun.com/doc/819-0056.


Figure 4-3  Java Enterprise System Component Dependencies

This figure provides a visual representation of the dependencies described in Table 4-1.

Web Container Support

The previous section, Component Dependencies, does not account for the web container in which Portal Server and Access Manager run. This web container can be provided by Application Server, Web Server, or a third-party product. When designing a logical architecture that includes Portal Server or Access Manager be sure to account for the web container required for these components.

Logically Distinct Services Provided by Messaging Server

The Java Enterprise System Messaging Server can be configured to provide separate instances that provide the following logically distinct services:

These various configurations of Messaging Server provide functionality that can be deployed on separate physical servers and can be represented in different tiers of a logical architecture. Because these configurations for Messaging Server represent logically distinct services in separate tiers, consider them as logically distinct components when designing a logical architecture. The section Example Logical Architectures provides an example of logically distinct components.

The following table describes the logically distinct configurations of Messaging Server.

Table 4-2  Messaging Server Configurations 

Subcomponent

Description

Message Transfer Agent (MTA)

Supports the sending of email by handling SMTP connections, routing emails, and delivering messages to the proper message stores. The MTA components can be configured to support email sent from outside the enterprise (inbound) or sent from within the enterprise (outbound).

Message Store (STR)

Provides for the retrieval and storage of email messages.

Message Multiplexor (MMP)

Supports the retrieval of email by accessing the message store for email clients, using either IMAP or POP protocols.

Messenger Express Multiplexor (MEM)

Supports the retrieval of email by accessing the message store on behalf of web- based (HTTP) clients.

Access Components

Java Enterprise System also contains components that provide access to system services, often from outside an enterprise firewall. Some configurations of Messaging Server can also provide network access, such as Messaging Server configured for message multiplexor. The following table describes Java Enterprise System components that provide remote access to system services.

Table 4-3  Java Enterprise System Components Providing Remote Access 

Component

Description

Directory Proxy Server

Provides enhanced directory access, schema compatibility, routing, and load balancing for multiple Directory Server instances.

Portal Server, Portal Server Secure Remote Access

Provides secure Internet access from outside a corporate firewall to Portal Server content and services, including internal portals and Internet applications.

Portal Server, Portal Server Mobile Access

Provides wireless access from mobile devices and voice access to Portal Server.

Messaging Server Message Multiplexor (MMP)

Supports the retrieval of email by accessing the message store on behalf of web-based (HTTP) clients.

Components providing remote access are generally deployed in secures access zones, as illustrated by the example in the section Access Zones.

Multitiered Architecture Design

Java Enterprise System is well-suited for multitiered architecture design, where services are placed in tiers according to the functionality they provide. Each service is logically independent and can be accessed by services in either the same tier or a different tier. The following figure depicts a multitiered architecture model for enterprise applications, illustrating the client, presentation, business service, and data tiers.

Figure 4-4  Multitiered Architecture Model

This figure shows the relationship of services in a multitiered architecture.[D]

The following table describes the logical tiers depicted in Figure 4-4.

Table 4-4  Logical Tiers in a Multitiered Architecture 

Tier

Description

Client tier

Contains client applications that present information to end users. For Java Enterprise System, these applications are typically mail clients, web browsers, or mobile access clients.

Presentation tier

Provides services that display data to end users, allowing users to process and manipulate the presentation. For example, a web mail client or Portal Server component allows users to modify the presentation of information they receive.

Business service tier

Provides back-end services that typically retrieve data from the data tier to provide to other services within the presentation or business service tiers or directly to clients in the client tier. For example, Access Manager provides identity services to other Java Enterprise System components.

Data tier

Provides database services accessed by services within the presentation tier or business service tier. For example, Directory Server provides LDAP directory access to other services.

Multitiered architecture design provides several advantages. During the deployment design phase, the placement of services according to functionality in a multitiered architecture helps you determine how to distribute services in your network. You also can see how components within the architecture access services of other components. This visualization helps you plan for availability, scalability, security, and other quality of service solutions.


Example Logical Architectures

This section provides some examples of logical architectures for Java Enterprise System solutions. These examples show how you place logical components within the appropriate tiers of a multitiered architecture and then analyze the relationships between the components by studying the use cases. Use the logical architectures examples in this section as a basis for understanding logical architecture design in Java Enterprise System solutions.

The first example is a basic Messaging Server solution that illustrates how the logically distinct components of Messaging Server interact with other components. The second example shows a logical architecture for an identity-based deployment solution that might be appropriate for a medium-sized enterprise of about 1,000 to 5,000 employees.

Messaging Server Example

The following figure shows a basic logical architecture for a deployment of Messaging Server. This logical architecture shows only the logically distinct components required for Messaging Server. Later figures illustrate the relationships among these components.


Note

Typically, a deployment of Messaging Server is part of an enterprise solution that includes other Java Enterprise System components, as illustrated in Identity-Based Communications Example.


Figure 4-5  Logical Architecture for Messaging Server Deployment

Diagram showing logical components for a Messaging Server scenario deployed in a multitiered architecture.[D]

The following table describes the components depicted in Figure 4-5.

Table 4-5  Components in Messaging Server Logical Architecture 

Component

Description

Email clients

Client applications for reading and sending email.

Messaging Server MTA

Messaging Server configured as a message transfer agent (MTA) to receive, route, transport, and deliver email messages.

Messaging Server MMP

Messaging Server configured as a message multiplexor (MMP) to route connections to appropriate message stores for retrieval and storage. MMP accesses Directory Server to look up directory information to determine the proper message store.

Messaging Server STR

Messaging Server configured as a message store for retrieval and storage of email messages.

Directory Server

Provides access to LDAP directory data.

The logical architecture does not specify replication of services for the Messaging Server components. For example, enterprise deployments typically create separate inbound and outbound MTA instances but Figure 4-5 shows only one MTA component. The replication of logical components into multiple instances is a design decision that you make during the deployment design phase.

Messaging Server Use Cases

Use cases help identify the relationships among the logical components in an architecture. By mapping the interactions between the components according to the use cases, you get a visual picture of component interaction that is helpful in deployment design.

Typically, you analyze each use case to determine the interaction of components prior to deployment design. The following three use cases are typical for Messaging Server and show interactions among the logical components.

Use Case 1: User Logs in Successfully to Messaging Server
  1. Email client sends login information to Messaging Server Multiplexor (MMP)
  2. MMP requests verification of user ID and password from Directory Server.
  3. Directory Server returns verification to MMP.
  4. MMP requests message list from Messaging Server Message Store (STR).
  5. STR requests user’s LDAP record from Directory Server.
  6. Directory Server returns user’s LDAP record to STR.
  7. STR returns message list to MMP.
  8. MMP forwards message list to email client.
  9. Figure 4-6  Messaging Server Logical Architecture Showing Use Case 1
    Diagram illustrating data flow among Messaging Server components for Use Case 1.

Use Case 2: Logged-In User Reads and Deletes Mail
  1. Email client requests message to read from Messaging Server Multiplexor (MMP).
  2. MMP requests message from Messaging Server Message Store (STR).
  3. STR returns message to MMP.
  4. MMP forward message to email client.
  5. Email client sends deletes message action to MMP.
  6. MMP forwards delete message action to STR.
  7. STR deletes message from database and sends confirmation to MMP.
  8. MMP forwards delete confirmation to email client.
  9. Figure 4-7  Messaging Server Logical Architecture Showing Use Case 2
    Diagram illustrating data flow among Messaging Server components for Use Case 2.

Use Case 3: Logged-In User Sends Email Message
  1. Email client sends message composed in client to Messaging Server Message Transfer Agent (MTA).
  2. MTA requests verification of user ID and password from Directory Server.
  3. Directory Server returns verification to MTA.
  4. MTA checks Directory Server for the destination domain for each recipient.
  5. Directory Server returns to MTA the destination domain for each recipient.
  6. MTA forwards message to each recipient.
  7. MTA forwards message to Messaging Server Message Store (STR) to store message in outbox.
  8. MTA sends confirmation to email client.
  9. Figure 4-8  Messaging Server Logical Architecture Showing Use Case 3
    Diagram illustrating data flow among Messaging Server components for Use Case 3.

Identity-Based Communications Example

This example illustrates an identity-based communications solution for a medium-sized enterprise of about 1,000 to 5,000 employees. Typically, an exhaustive business analysis followed by detailed technical requirements analysis is needed to design the logical architecture. However, because this is a theoretical example, assume that the following business requirements have been determined:

Use cases for this example would detail login procedures, reading email, sending email, personalizing the portal, synchronizing calendars, and other similar user activities.

The following figure shows a logical architecture for this type of identity-based communications solution.

Figure 4-9  Logical Architecture for Identity-Based Communications Scenario

Diagram showing logical components for an Identity-based Communications scenario deployed in a multitiered architecture.[D]

Use Cases for Identity-Based Communications Example

For a deployment solution of this nature, there typically are numerous detailed use cases outlining the user interaction with the services provided by the solution. This example focuses on the interaction among components when a user logs into a portal from a web browser client. The example splits this login scenario into two use cases:

The two use cases can be considered one extended use case. However, for this example, the use cases are separated for simplicity.

Use Case 1: User Logs in Successfully and Portal Retrieves User’s Configuration
  1. Web browser client sends user ID and password to Portal Server.
  2. Portal Server requests authentication from Access Manager.
  3. Access Manager requests verification of user ID and password from Directory Server.
  4. Directory Server verifies user ID and password.
  5. Access Manager requests user profile from Directory Server.
  6. Directory Server returns user profile.
  7. Portal Server requests user display profile from Access Manager.
  8. Access Manager returns portal configuration.
  9. Portal configuration is displayed in web browser client.
  10. Figure 4-10  Communications Scenario Logical Architecture Showing Use Case 1
    Diagram illustrating the data flow among Identity-based Communications scenario components for Use Case 1.

Use Case 2: Portal Server Displays Email and Calendar Information
  1. After successful log in, authentication, and retrieval of portal configuration, Portal Server requests email messages from Messaging Server MMP.
  2. MMP requests message list from Messaging Server STR.
  3. STR returns message list to MMP.
  4. MMP forwards message headers to Portal Server.
  5. Portal Server requests calender information from Communications Express.
  6. Communications Express requests calendar information from Calendar Server backend.
  7. Calendar Server backend returns calendar information to Communications Express.
  8. Communications Express forwards calendar information to Portal Server.
  9. Portal Server sends all channel information to web browser client.
  10. Figure 4-11  Communications Scenario Logical Architecture Showing Use Case 2
    Diagram illustrating the data flow among Identity-based Communications scenario components for Use Case 2.


Access Zones

Another way to represent the components of a logical architecture is to place them in access zones that show how the architecture provides secure access. The following figure illustrates access zones for deploying Java Enterprise System components. Each access zone shows how components provide secure remote access to and from the Internet and intranet.

Figure 4-12  Logical Components Placed in Access Zones

Diagram showing the placement of Java ES components within secure access zones.[D]

The following table describes the access zones depicted in Figure 4-12.

Table 4-6  Secure Access Zones and Components Placed Within Them 

Access Zone

Description

Internal access zone
(Intranet)

Access to the Internet through policies enforced by a firewall between the intranet and the Internet. The Internal access zone is typically used by end users for web browsing and for sending email.

In some cases, direct access to the Internet for web-browsing is allowed. However, typically secure access to and from the Internet is provided through the external access zone.

External access zone
(DMZ)

Provides secure access to and from the Internet, acting as a security buffer to critical back-end services.

Secure access zone
(Back-end)

Provides restricted access to critical back-end services, which can only be accessed from the external access zone.

Figure 4-12 does not illustrate the logical tiers depicted in the previous examples, but instead focuses on which components provide remote and internal access, the relationship of these components to security measures such as firewalls, and a visual depiction of access rules that must be enforced. Use the multi-tier architecture design in combination with the design showing access zones to provide a logical model of your planned deployment.


Deployment Scenario

The completed logical architecture design by itself is not sufficient to move forward to the deployment design phase of the solution life cycle. You need to pair the logical architecture with the quality of service (QoS) requirements determined during the technical requirements phase. The pairing of the logical architecture with the QoS requirements constitutes a deployment scenario. The deployment scenario is the starting point for designing the deployment architecture, as explained in Chapter 5, "Deployment Design."



Previous      Contents      Index      Next     


Part No: 819-0058-10.   Copyright 2005 Sun Microsystems, Inc. All rights reserved.