Architectures

Common Architectures

Tiered decomposition

In Sun’s terminology, a two-tier application is a client/server architecture. Client software runs on a PC or workstation, and communicates directly to a database server.

two tier

A three-tier architecture splits presentation from business logic. In Sun’s definition, the client is typically a thick client, rather than a web browser.

three tier

A multi-tier architecture is the traditional J2EE decomposition. It supports web clients as well as thick/rich clients. Typical breakdowns might include:

  • Client tier – Browser or rich client
  • Presentation tier – servlet container
  • Business tier – EJBs or web services
  • Integration tier – communication to databases, messaging systems, ERP systems, etc.
  • Resource tier – databases, legacy systems, etc.

multi

All software development begins with requirements. Software architecture concerns itself with Service Level Requirements. Note that hardware effects software services. Hardware with poor performance, reliability, or availability may pass on those characteristics to a software architecture. Sometimes good software architecture may compensate for unreliable or insecure hardware.

Sun defines eight service level concerns:

Performance

Performance is a raw measure of work done, typically expressed in throughput or sometimes as response time. Response time is measured in seconds. Throughput might be measured in transactions per second.

Adding tiers increase the amount of communication that must be done to accomplish some task, so it decreases raw response time. However, since adding tiers adds opportunities for scaling, then multi-tier systems may ultimately have greater maximum throughput.

Scalability

Scalability is the ability to support quality of service as system load increases. Most commonly it is related to performance (e.g. “How does throughput change as load increases”), but it could relate load to any of the service level measures. Systems can be scaled horizontally or vertically. Vertical scaling means adding resources such as memory, processor speed, networking hardware, etc. Horizontal scaling means adding parallel redundant components to a system.

Adding tiers increases the components at which horizontal and vertical scaling can occur, so multi-tier systems scale better for performance, availability, etc.

Reliability

Reliability measures integrity and consistency of the application and all its transactions. A system that loses messages would be unreliable. If a system has a single point of failure, then the system is only as reliable as the hardware and software at that point. A reliable system maintains data integrity no matter what happens.

Adding tiers increases complexity, which may decrease reliability. However, multi-tier architectures support redundant processors, which may increase reliability.

Availability

An available system is always accessible. An architecture that supports redundant modules will be more reliable.

Highly available systems tend to be multi-tiered. Horizontal scaling can add redundant load-balanced components which will increase availability.

Maintainability

Maintainability is the ability to correct flaws in the system without impacting other components of the system. Architectures should be easy to understand and easy to alter safely.

Breaking a system into independent modules makes maintenance easier, so a multi-tiered architecture will be more maintainable.

Extensibility

Extensibility is the ability to add functionality or modify existing functionality without impacting existing functionality.

Decomposing a system into separate tiers may make extensibility on any layer easier.

Manageability

Manageability is the ability to ensure the quality of service as it runs. Managing a system involves monitoring activity, reconfiguring, deploying and undeploying.

Separating concerns into different tiers may make manageability of a given tier easier, or management of the whole system more difficult.

Security

Security involves protecting the system from being compromised. It includes concerns of confidentiality and data integrity, but also relates to Denial of Service attacks.

Security becomes harder as an architecture becomes more complex, so adding tiers can be bad from this perspective. Comprehensive security support from the system software and operating system can address this. Also, extra attention should be paid to physical security if the application is split between separate machines.

If tiers are protected behind separate firewalls, then multiple tiers may have better security characteristics. A typical pattern is a DMZ where application servers hide behind an additional firewall.

These eight concerns are the primary “non-functional requirements” tested on the SCEA exam. There are certainly other non-functional requirements. One good list is provided by Julian Browne.

Advantages of the EJB Architecture

Clients

Fat Clients

A fat client in a client/server architecture runs directly on a PC’s operating system. It puts a lot of functionality into the client logic, and may communicate to the server only sporadically.

Deploying a fat client can be an issue. Users must get a client that runs on their computer. They must also get updated clients as the updates are released.

Thin Clients

A thin client runs on a standardized framework, such as a browser or a terminal service (Citrix or X-windows). The client code does minimal processing, and depends heavily on server communication.

A web browser provides a standard thin client platform. It is easy to develop web software. Browsers are cheap, reliable, and are available on many operating systems. Utilizing scripting on the browser allows some functionality to be moved onto the user’s PC. Deployment of the client is trivial. Basic authentication and secure communication is built into all browsers.

A drawback to web deployment is that different browsers behave differently. Applications should stick to web standards and should test on multiple platforms. Scripting is useful, but may fail, may be non-standard, or may be subverted. For example, validation of data can be done using JavaScript, but it should also be repeated on the server.

Another drawback is that some applications don’t lend themselves to stateless page-based formats. The fact that users can bookmark pages or use a “Back” button often messes up application logic. There are frameworks (such as Wicket or JSF) that support complex interaction, but the simulation of “windows” behavior sometimes breaks down.

Rich Clients

Rich clients deploy as web applications, but have features more in common with desktop applications. They do more processing on the client side than web applications, and require less communication than thin clients. They often run on a platform that provides richer user interfaces than available on a web page.

Rich clients deploy at startup, so updated client software is delivered automatically. They tend to be highly portable, running on most operating systems and browsers. They have a smaller footprint than fat clients, and may run on inexpensive hardware. They don’t have back-button or bookmarking vulnerabilities.

Development of rich clients is more difficult than web applications. A rich client will require more memory and processing power than a web client. Download time during startup may be substantial. The plugin platform that the rich client uses may not be available, or may not be up to date; Flash is highly available, but Java is less-so, and Silverlight is still uncommon.

Common rich client platforms include:

Uses of web services

Web services are appropriate for stateless, decoupled communication. Calls should be course-grained. They are good for linking disparate business services, that may be hosted by different business organizations. Web services may scale well in a horizontal fashion.

The are inappropriate for fine-grained communication that may require optimum response time. They are inappropriate for session-based processes that need to maintain a conversational state.

%d bloggers like this: