Poor, tight coupling Difficult, data access and Integrity – Data can only be modified in allowed ways Privacy – Data is disclosed to authorized entities in authorized ways Auditability – The system maintains logs of actions taken for later analysis Scalability - the ability to support the required quality of service as the load increases Maintainability - the ability to correct flaws in the existing functionality without impacting other components/systems Reliability - the assurance of the integrity and consistency of the application and all of its transactions. Reliability spans from the OS to the Application to the service provided. Availability - the assurance that a service/resource is always accessible Extensibility - the ability to add/modify additional fuctionality without impacting existing functionality Manageability - the ability to manage the system in order to ensure the continued health of a system with respect to scalability, reliability, availability, performance, and security. Effects The following table outlines some inherent properties of common architectures. Single tier Two-tier Three- or Multi-tier Scalability Very limited Still limited, DB connections Good. Resource pooling possible, hardware can be added if and when need arises. Maintainabil business logic are mixed Good, layers can be changed independently. Reliability OK, Data consistency is simple because one storage Availability Poor, single point of failure Poor, DB server is still single point of failure Excellent with appropriate redundancy architecture. Extensibility Poor, tight coupling Difficult, data access and business logic are mixed. Code is dependent on DB schema. Good, layers can be changed independently. Performance OK Poor, DB Server can become bottleneck. Each client requires a connection, no pooling. High network bandwidth required, because all data has to travel to Good. Because the system is scalable, performance can be influenced by choosing the right system components. Bottlenecks can be removed at the relevant layer. Manageabilit y Relatively easy Poor, complex client installation and maintenance OK Security OK Problematic, because client has too much control. Good. Only certain services can be accessed, no direct database access. Firewalls and authentication and authorization systems help to further control access.
Wednesday, April 11, 2007
Some rough guidelines:
More than 25 top-level classes will lead to problems Every use case should be able to be implemented using domain model methods J2EE supports extensibility because it is component-based and allows you to separate the roles of an app. JSPs can handle presentation. Servlets can handle routing, and EJBs can handle business logic. Performance Architectural performance is concerned with creating an architecture that forces end-to-end performance. The purpose of an architecture that ensures performance is to control expensive calls and to identify bottlenecks. If you know the boundaries of the various parts of the system, the technologies, and the capabilities of the technologies you can do a good job of controlling performance. You want to minimize the number of network calls your distributed app makes – make a few “large” calls that get a lot of data vs. lots of calls that get small amounts of data. Try to minimize process-to-process calls because they are expensive. Use resource pooling to reduce the number of expensive resources that need to be created like network connections, database connections, etc. Performance involves minimizing the response time for a given transaction load. While a number of factors relating to the application design can affect this, adding additional resources in the following two ways, or a combination of both, can be used to good effect: Vertical scaling, which involves creating additional application server processes on a single physical machine in order to provide multiple thread pools, each corresponding to the JVM associated with each application server process. Horizontal scaling, which Manageability
Manageability refers to the ability to manage a system to ensure the health of the system. A single tier or monolithic app would be more manageable from a management perspective than a multitier system but this must be weighed against the possibility of a change rippling through a monolithic app. A simple architecture may not be as flexible or available as a more complex system but the amount of effort required to keep the system up & functioning will be less. A component-based architecture like J2EE offsets some of the manageability problems caused by a multitier system. Security Security ensures that info is neither modified nor disclosed except in accordance with the security policy. Tradeoffs: personal privacy, ease of use, and expense.
3 A highly secure system is: More costly Harder to define and develop Requires more watchdog activities Principles of Security: Identity – The user is correctly ID’d thru an authentication mechanism
2 Availability Availability is about assuring that services are available to the required number of users for the required proportion of time. Availability requires that the topology provide some degree of process redundancy in order to eliminate single points of failure. While vertical scalability can provide this by creating multiple processes, the physical machine then becomes a single point of failure. For this reason a high-availability topology typically involves horizontal scaling across multiple machines. Hardware-based high availability: By providing both vertical and horizontal scalability the WebSphere Application Server runtime architecture eliminates a given application server process as a single point of failure. In fact the only single point of failure in the WebSphere runtime is the database server where the WebSphere administrative repository resides. It is on the database server that any hardware-based high availability (HA) solutions such as HACMP, Sun Cluster, or MC/ServiceGuard should be configured. Extensibility Ability to modify or add functionality without impacting the existing functionality. The key to an extensible