Software Architecture

Architecture is a set of structuring principles that enables a system to be comprised of a set of simpler systems each with its own local context that is independent of but not inconsistent with the context of the larger system as a whole. [Sun Microsystems, Inc.]

Software Architecture

·         Software architecture is the structure of structures and take away the functions that implement business requirements and what remains is architecture.

·         Description of a structural framework to help the design of the application.

·         The description of a development environment and deployment configuration that supports the non-functional requirements of a software application.

·         A software architect is most active during the early stages of development but must participate during the entire development lifecycle of a product.

·         Architecture is developed and described somewhere between when a vision for the product is developed and before construction begins.

·         The software architecture must be baselined (agreed on by all stakeholders) before construction begins because a change in the architecture usually has vast consequences.

Architectural considerations: An architecture can be assessed using the following qualitative measures:

·         A non-functional requirement is one that is specified for a software system and does not pertain to a business function to be developed in the system.

·         Non-Functional requirements are usually quality attributes for the software system.

·         Also called service-level requirements or Quality of Service (QoS) requirements or Non-functional requirements

·         During the inception and elaboration phases, architect works with defining the quality of service measurement for these QoS reqs.

·         One has to make trade-offs between these requirements (For example, if the most important service-level requirement is the performance of the system, you might sacrifice the maintainability and extensibility of the system to ensure that you meet the performance quality of service)

1. Scalability
2. Maintainability
3. Reliability
4. Availability
5. Extensibility
6. Performance
7. Manageability
8. Security

1. Scalability

Scalability is the ability to economically support the required quality of service as the load increases. There are two types of scaling:

• Sign of Scalable system: as the load increases, the system still responds within the acceptable limits
• Capacity of a system:  maximum number of processes or users a system can handle and still maintain the quality of service
• If a system is running at capacity and can no longer respond within an acceptable time frame, then it has reached its maximum scalability.
•  To scale a system that has met capacity, you must add additional hardware. This additional hardware can be added vertically or horizontally

1.1. Vertical Scaling

• Achieved by adding capacity (memory, CPUs, etc.) to existing servers.
• Requires few to no changes to the architecture of a system.
• Increases: Capacity, Manageability
• Decreases: Reliability, Availability (single failure is more likely to lead to system failure)
• Vertical scalability is usually cheaper than horizontal scalability.
• J2EE supports vertical scaling because of automatic lifecycle management. Adding more capacity to a server allows it to manage more components (EJBs, etc.).

1.2. Horizontal Scaling

• Achieved by adding servers to the system.
• Increases the complexity of the system architecture.
• Increases: Reliability, Availability, Capacity, Performance (depends on load balancing), Flexibility
• Decreases: Manageability (more elements in the physical architecture)
• J2EE supports horizontal scaling because the container and server handle clustering and load-balancing.
• Availability and reliability are obtained through scaling. Scalability affects capacity. The more scalable the system is the more capacity it can support. This must be traded-off against the complexity & manageability costs.

2. Maintainability

• Maintainability is the ability to correct flaws in the existing functionality without impacting any other components
• cannot measure at the time of deployment ( like extensibility )
• Features to  enhance the maintainability of a system: low coupling, modularity, and documentation
• How related is this to Flexibility? Flexibility is the ability to change the architecture to meet new requirements in a cost-efficient manner. A flexible system should be more maintainable in the face of changes to the environment and/or to the application itself.
• Improves: Availability, Reliability, Scalability
• Decreases: Performance, Manageability

3. Reliability

• Reliability is the ability to ensure the integrity and consistency of the application and all of its transactions.
• You increase reliability through the use of horizontal scalability, i.e., by adding more servers. This only works up to a certain point, though.
• When you increase reliability you increase availability.
• Reliability can have a negative impact on scalability. If the system cannot maintain the reliability as the load increases, then the system is really not scalable. So, for a system to truly scale it must be reliable.

4. Availability

• Availability is about assuring that services are available to the required number of users for the required proportion of time.
• Reliability can contribute to availability, but availability can be achieved even if components fail. By setting up an environment of redundant components and failover, an individual component can fail and have a negative impact on reliability, but the service is still available due to the redundancy.

5. Extensibility

• The ability to modify or add functionality without impacting the existing functionality.
• Features to ensure extensibility: low coupling, interfaces, and encapsulation
• You cannot measure extensibility when the system is deployed, but it shows up the first time you must extend the functionality of the system ( like maintainability )
• The key to an extensible design is to make an effective OO design. Extensibility pays the most towards the font end of a system.
• 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.

6. Performance

• Measured as response time/transaction/user or number of transactions/unit time.
• 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.

7. 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 multi-tier 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 multi-tier system.

8. Security

• Security is the ability to ensure that the system cannot be compromised.
• Security is by far the most difficult systemic quality to address.
• In the architecture description of any system a description of security strategies and implementation methods is very important
• Creating an architecture that is separated into functional components makes it easier to secure the system because you can build security zones around the components. If a component is compromised, then it is easier to contain the security violation to that component
• Security includes not only issues of confidentiality and integrity, but also relates to Denial-of-Service (DoS) attacks that impact availability
• Tradeoffs: personal privacy, ease of use, and expense.
• JAAS is a Java API for authentication and authorization that can be implemented by application server vendors, JCE for cryptography and JSSE for SSL extensions are java technologies that support data encryption.
• A highly secure system is:
• More costly
• Harder to define and develop
• Requires more watchdog activities

Architectural terms: (Paul Allen Book)

• Abstraction is a symbol for something used repeatedly in a design  that hides details and is a clear representation.
• Boundaries are the area where two components interact.
• Brittleness is the degree to which small changes will break large portions of the system.
• Capabilities are the non-functional, observable system qualities including scalability, manageability, performance, availability, reliability, and security that are defined in terms of context.
• Friction is how much interaction occurs between two components. Friction is measured based on how a change in one affects both components.
•  Layering is a hierarchy of separation.
• Surface Area is list of methods that are exposed to the client.
• The key difference between architecture and design is in the level of detail. Architecture operates at a high level of abstraction with less detail. Design operates at a low level of abstraction, obviously with more of an eye to the details of implementation
• System architecture corresponds to the concept of architecture as a product. It is the result of a design process for a specific system and must consider the functions of components, their interfaces, their interactions, and constraints. This specification is the basis for application design and implementation steps.
• Reference architecture corresponds to architecture as a style or method. It refers to a coherent design principle used in a specific domain.

Role of an architect: (Paul Allen Book)

• Visualizes the behavior of the system.

• Create the blueprint for the system.
• define the way in which the elements of the system work together and
• Distinguish between functional and nonfunctional system requirements.
• Architects are responsible for integrating non-functional requirements into the system.

Load Balancing Web Applications:

• Cluster: group of servers running a Web application simultaneously, appearing to the world as if it were a single server. Within the J2EE framework, clusters provide an infrastructure for high availability (HA) and scalability. 
• Clustering = replication + load balancing + fail over  à achieves HA +scalability+ performance
• Load balancing: the system distributes requests to different nodes within the server cluster, with the goal of optimizing system performance. This results in higher availability and scalability
• Load balancers: Single points of entry into the cluster and traffic directors to individual Web or application servers
• High Availability: can be defined as redundancy. In a highly available system, if a single Web server fails, then another server takes over, as transparently as possible, to process the request. A cluster only provides HA at the application server tier. For a Web system to exhibit true HA, it must be like Noah's ark in containing at least two of everything, including Web servers, gateway routers, switching infrastructures, and so on.
• Scalability: application's ability to support a growing number of users. Scalability is a measure of a range of factors, including the number of simultaneous users a cluster can support and the time it takes to process a request

Of the many methods available to balance a server load, the main two are:

• DNS round robin and
• Hardware load balancers.

DNS RR Load Sharing:

• DNS is the process by which a logical name (i.e., www.javaworld.com) is converted to an IP address. In DNS round-robin load balancing, a single logical name can return any IP address of the machines in a cluster.
• Spreading incoming IP packets among a number of DNS addresses equally.
• One host name URL but different IP addresses.
• Simple Round Robin (but not using DNS),which is different from DNS RR, is load balancing technique
• Advantages:
• Widely available, easy to use, and low cost.
• A simple addition to the name-server configuration file allows a pool of servers to be clustered and appear to act as a single host to the clients, when in reality requests are being alternated between all the hosts in the pool.
• Very effective for small to medium size business or organizations. It is extremely popular among ISPs, e-commerce sites, universities, and other cost sensitive sites.
• Disadvantages:
• No support for high availability. Inability to handle server failures. Requests from clients will still go to this failed server IP address when it is its turn in the round robin pool. The result is that all of these requests will go to hosts that will not operate correctly
• When new   node is added/removed i.e. Changes to the cluster take time to propagate through the rest of the Internet.  (DNS servers cache DNS lookups from their clients )When you drop a node, a user may be trying to hit a non-existing server. When you add one, that server may just be under-utilized until its IP address propagates to all the DNS server
• Is a simple load-sharing strategy. It does not take into account the actual load on the machines. One or more of the hosts in the pool will tend to get more activity than the other servers
•  It is Load sharing technique rather than load balancing. Load balancing distributes connection loads across multiple servers, giving preference to those servers with the least amount of congestion. In round robin's case, server distribution remains on a rigid one IP address to one user rotating basis.
• No support for server affinity. Server affinity is a load-balancing system's ability to manage a user's requests, either to a specific server or any server, depending on whether session information is maintained on the server or at an underlying, database level.

Hardware Load Balancers:

·         The load balancer shows a single (virtual) IP address to the outside world, which maps to the addresses of each machine in the cluster

·         When a request comes to the load balancer, it rewrites the request's header to point to other machines in the cluster

·         Advantages of Hardware Load Balancers:

o        Server affinity. The hardware load balancer reads the cookies or URL readings on each request made by the client. Based on this information, it can rewrite the header information and send the request to the appropriate node in the cluster, where its session is maintained.

o        High Availability through Failover. Failover happens when one node in a cluster cannot process a request and redirects it to another. There are two types of failover:

• Request Level Failover. When the load balancer detects that a particular node has gone down, it redirects all subsequent requests to that dead node to another active node in the cluster. However, any session information on the dead node will be lost when requests are redirected to a new node.
• Transparent Session Failover. When an invocation fails, it's transparently routed to another node in the cluster to complete the execution. To achieve transparent session failover, the nodes in the cluster must collaborate among each other and have something like a shared memory area or a common database where all the session data is stored. Therefore, if a node in the cluster has a problem, a session can continue in another node.
• Metrics. Used to collect metrics data as all requests to a Web application must pass through the load-balancing system.

·         Disadvantages of Hardware Load Balancers:

o        Can’t provide server affinity in HTTPS communication as the messages are SSL-encrypted, and this prevents the load balancer from reading the session information. There are two options to solve this problem: Web server proxies OR Hardware SSL decoders.

o        High costs, the complexity of setting up

o        Vulnerability to a single point of failure- Since all requests pass through a single hardware load balancer, the failure of that piece of hardware sinks the entire site

Load Balancing HTTPS Requests:

·         Web Server Proxies:

o        A Web server proxy that sits in front of a cluster of Web servers takes all requests and decrypts them. Then it redirects them to the appropriate node, based on header information in the header, cookies, and URL readings

o        Advantages:

§         Are that they offer a way to get server affinity for SSL-encrypted messages, without any extra hardware.

o        Disadvantages:

§         But extensive SSL processing puts an extra load on the proxy.

§         The hardware load balancer cannot use metrics to direct requests

§         Web server proxies need to support server affinity

·         Hardware SSL Decoder / SSL Accelerator:

o        sit in front of the hardware load balancer, allowing it to decrypt information in cookies, headers and URLs.

o        Advantages:

§         Faster than Web server proxies

§         Off-loaded SSL processing to the SSL accelerator, which increases scalability

§         Centralized SSL certificate management in a single box

o         Disadvantages:

§         Cost more

§         Complicated to set up and configure

Reverse Proxy load balancing:

§         Is generally used when you have servers with different amounts of CPUs and Memory.

§         You might have some really powerful servers just to be used for SSL sessions and others to handle static html.

§         Using this will maximize the performance of your application

FAULT TOLERANCE:

§         Failure: discrepancy between the desired or specified and the actual behavior of a system. Failures are external symptoms of faults (defects).A failure is an external symptom of a fault.

§         Fault: defect with the potential to cause a failure. While it has this potential, it may never actually do so. A failure is a guarantee that a fault has occurred.3 types of faults: server process fault, server fault, network fault

§         Fault tolerance: the ability to prevent failures even when some of the system components have faults.

§         The key to achieving fault tolerance is redundancy. Redundancy requires replication

§         Hot backup / Active Replication: Extra, live copies (replicas) of an object are serving client requests and synchronize continuously with the primary object. If the primary object fails, one of the copies takes over. Every replica handles requests and replies. Interceptor has to block extra calls to third objects and extra responses

§         Warm backup / Passive Replication: Backup copies of an object run, but don’t serve clients. Synchronization happens at certain, regular intervals. One primary replica handles requests and synchronizes state with secondary replicas. Requests are also logged. For fail-over, a secondary replica becomes primary and processes all requests after the last synchronization point

§         Cold backup: The primary object synchronizes with stable storage in certain intervals. In the case of a failure, a new object is instantiated and reads the storage for set-up.

§         Hot backup or active replication is for Load balancing also. But the Warm backup/ passive replication and cold backup are not for load balancing, but only for fault tolerance.

§         Fault handling includes service replication, fault detection, fault recovery, and fault notification.

§         Fault detection is often done by using heartbeats (server sends periodical signal to monitor) or polling (monitor checks server once in a while).

§         Fault handling in CORBA involves Replica Managers and Replica Service Agents.

Comparison of J2EE architecture with Microsoft DNA Architecture:

• Component types supported. Windows DNA has no support for data components, whereas J2EE platform-based products support both types of components (data components and business components).
• State management. Windows DNA has very poor support for a stateful business process component, and does not provide state management services. J2EE platform-based products support stateful business processes today.
• Database caching. A robust data caching system enhances the scalability of a commerce system significantly. The Windows DNA architecture provides automatic result set caching for applications. Unfortunately, Windows DNA does not include support for data object caching, nor for distributed shared data object caching. This significantly impairs the scalability of a Windows DNA deployment compared to a J2EE platform-based deployment.
• Declarative (automated) persistence. A declarative persistence model enables developers to persist enterprise data without writing code, such as Java Database Connectivity (JDBC) code. This reduces coding time significantly, and allows one to author database independent code. Windows DNA does not support declarative persistence as it doesn’t support data components. By way of comparison, several vendors implementing the J2EE platform support complex automated persistence today.
• Scalability through load-balancing. For a scalable multi-tier deployment, a corporation must be able to add middle tier machines as necessary to handle high-volume transactional load. This requires logic to automatically load-balance across middle tier components. Windows DNA contains load-balancing technology to spread IP traffic among Web servers, which is called Network Load-Balancing. This technology is effective at balancing incoming requests to Web server machines. Microsoft does not currently offer load-balancing technology that directs requests from the presentation tier to the business tier

Supply Chain Collaboration: Spoke, Exchange, or Hub : B2B

• Basis for Supply-chain collaboration à CPFR: Collaborative Planning, Forecasting and Replenishment

Spoke

• Working with trading partners over the Internet by sub-scribing to a large partner’s extranet hub.
• These ex-tranets typically provide online access through a web browser to reports of supply chain activity, as well as key performance measures
• two sets of benefits:
• Speed and ease of getting access.
• Richness of the information that is available. Trading partners only need a PC and Internet access to take advantage of the extranet. Typically they do not need to purchase, install and configure any software, or translate data from some machine-readable format to review it.
• The problems with using partners’ extranets are also twofold:
• Users only get to see the data one partner at a time. Assembling the “big picture” of a company’s supply chain performance and customer demand from multiple trading partner extranet reports is next to impossible.
• Making sense of data that is represented in terms of a partner’s geographies, channels and product categories is difficult. A retailer typically shows its data by department, while a manufacturer needs data by brand. Retailer departmental data may not map well to a manufacturer’s brands. Differences in multiple partners’ views further complicate the problem.
• Being a spoke on a trading partner extranet hub is an excellent way to ex-periment, but a difficult way to move supply chain collaboration into production.
• Relationships can only be managed one-on-one, and
• Data is difficult to translate to local company needs.
• The approach is most appropriate if a company is small, or limited in IT capabilities, and does most of its business with a single large customer or supplier.

Exchange

• Demand from several trading partners can be integrated and represented in each company’s own category, geography, and channel views.
• The exchange handles IT implementation issues, so local company IT investment is minimal.
• Each partner simply supplies core supply chain data to the exchange; beyond that, all access is by users through their web browsers.
• three limitations of using a B2B exchange to implement supply chain collaboration:
•  An exchange may represent a large number of trading partners, but it is unlikely to represent all of a company’s trading partners. Strategic partners may be missing.
•  An exchange provides only a standard offering – some manufacturers and retailers may wish to collaborate with a different workflow process or data conventions.
• There are technical limits to the amount of data that a B2B exchange can host. If a large retailer wishes to provide supply chain collaboration at a store level on a daily basis, it is currently not feasible to replicate the required data to a B2B exchange.

Hub  ~~Trading Partner’s Extranet Hub

• Building and managing a trading partner extranet can be a major undertaking.
• For medium-to-large companies who need to gain the maximum competitive advantage it is probably a necessity.
• Only on its own hub can a company aggregate the demand from its entire network, includ-ing strategic partners, exchanges, and internal relationships (for vertically integrated companies).
• For retailers who wish to drive collaboration down to the detailed level – daily, store-level data, and 52-week or longer forecasts that are updated frequently – im-plementing CPFR directly on their own enterprise data warehouse is the only practical solution, at least today

What Is The Difference Between B2B and B2C?

B2B

• Concerns itself primarily with supply chain management.
• These are portals that allow businesses to deal directly with their suppliers and distributors online
• Wholesalers, distributors and manufacturers fall in this category
• B2B sites normally handle a lot more than just sales of products; they are a portal to conduct business transactions.

B2C

• B2C concerns itself with selling to the end user
• They are actually internet based. That is to say they exist primarily on the internet. Offices and warehousing are borne from necessity of their internet success.
• B2C websites are intermediary portals to link customers to suppliers
• All of these businesses exist primarily on the internet. They are what is known as e-businesses 
• All of them can be classified under one general heading, market places.
• A B2B site deals primarily with other businesses, not the general public, a B2C site sells directly to the end user

One Tier Architecture:

• Think of an application that runs on your PC: Everything you need to run the application (data storage, business logic, user interface, and so forth) is wrapped up together
• Monolithic, “all-in-one” model – e.g. clients are “dumb” terminals connected directly to the mainframe.
• is a simple design that's easy to distribute, it does not scale well
• does not adequately address the needs of a web-based application
• Scalability à  Poor.   Vertical scalability only; expansion capabilities are physically limited (e.g. free CPU slots, terminal ports)
• Security à  Good  à as the connectivity is  physically limited
• Extensibility à Poor à component reuse difficult due to tight-couplingà as any change affects the entire system
• Availability à  Poor à Single point of failure
• Maintainability à Poor à any change affects the entire system
• Performance à Mixed  à Pros: no  remote process communication;  àCons: a runaway process could affect others
• Manageability àgood as the all are at one place.
• Reliability à  Mixed  à Risk of failure

Two Tier Architecture / Client – Server Model:

• Typically composed of multiple clients and a single server; the clients connect to the server over a network
• Fat Client e.g. implements the GUI, retrieves data from the server(s), and performs business logic based on the data. E.g.: use of Java-applets
• Server is typically a database. Provides a shared data-store for the client.
• The server doesn’t typically implement business logic. Later revisions to the model implement some of the business logic on the server as stored procedures (a.k.a. fat servers).
• Fat Servers: the client is used only to perform the display portion of the presentation component, and the server performs most of the presentation logic and all of the business and data access logic. e.g. in typical web-applications where the browser has to cope with HTML
• Problems with the 2-tier model are :
• The business logic may be complex and computationally expensive. Consequently, the client may require powerful hardware
• client components are tightly coupled, not modular – e.g. a change to the GUI means shipping the whole application to every client
• Data retrieval - each client has to make a direct connection to each server it needs data from. Also, the results transferred may be large and transferred using an inefficient (and perhaps proprietary)protocol
• Fat servers use stored procedures which are not very portable.
• Security à Poor à Client: difficult to enforce the security policy (fat clients are distributed all over the place; could be used/accessed by anyone); available options are SSL/VPN/user authentication (too coarse); Server:  has to be exposed to the outside world for client access so vulnerable to attack.
• Extensibility à Poor à Client: client tightly coupled to the business logic (although code may be reused for clients that support the language the code is written in, there would be multiple deployments); Server: if using a fat server, stored procedures have to be provided for each DB used.
• Availability à Poor   àsingle point of failure (usually a single database)
• Reliability à Mixed  à availability and performance issues
• Maintainability à Poor à Client: updates have to be applied to all clients in turn; Server: ok - everything in one  place; simple to troubleshoot
• Performance à Poor  à Client: result may be large; result data transfer protocol may be inefficient; client may be underpowered (local processing may be intensive); Server: ok – e.g. DB caching
• Scalability à Poor  à Client: each client requires a separate DB connection; Server: server can be scaled vertically; some horizontal scaling is possible but potentially requires client intelligence
• Manageability à in between 1-tier and n-tier

3 - Tier Architecture:

• In the typical example of this model, the web browser acts as the client, an application handles the business logic, and a separate tier handles database functions.
• 3-tier architecture is the most common approach used for web applications today.
• Although the 3-tier approach increases scalability and introduces a separation of business logic from the display and database layers, it does not truly separate the application into specialized, functional layers. For prototype or simple web applications, 3-tier architecture may be sufficient. However, with complex demands placed on web applications, a 3-tiered approach falls short in several key areas, including flexibility and scalability. These shortcomings occur mainly because the business logic tier is still too broad- it has too many functions grouped into one tier that could be separated out into a finer grained model.

N Tier Architecture:

• The single most important benefit of an n-tiered architecture, compared to a 3-tier approach, is breaking up the business logic from the application-server level into a more fine-grained model
• The separation of concerns, packaging, and service distribution helps immensely in maintainability, scalability and flexibility of deployment configurations
• Scalability à Good à Good modular which supports vertical/horizontal scaling; multiple instances; demand-based pooling
• Security à Good  à Pros: security can be applied to each tier and targeted where required; à Cons: complex architecture so something could be missed; more to secure so could be expensive
• Extensibility à Good à Good modular in nature so components can be added/replaced as required; business logic is centralized on the app servers
• Reliability à Good  à as the  availability and performance are good
• Availability à Good à because of clustering  à Pros: multiple instances (no single point of failure); Cons: expensive
• Maintainability à good  à Pros: multiple instances (facilitates day-to-day maintenance); centralized business logic so easy to update; Cons: complex; distributed in nature; difficult to troubleshoot; requires ASAs (app server admins), DBAs
• Manageability à Mixed  à compenent architecture lessens the burden
• Performance à Good à Pros: load balanced over multiple instances; instance and DB pooling; caching; specific modules can be tuned in isolation; à Cons: process communication overhead (e.g. remote method invocation creates an overhead which affects performance)

N Tier J2EE Architecture:

• Web Client Tier:
• The Web Client Tier is visible to the end user.
• This tier consists of the HTML that is generated from either Java Server Pages (JSP) or parsed XML documents, and is viewed using a web-browser such as Internet Explorer or Netscape Navigator. The web browser will format the HTML using Cascading Style Sheets (CSS).
• Tier Constraint: Components in this tier must only display business data and capture user gestures for change requests. 
• This tier participates in the implementation of the View and Control of MVC.
• Technologies:
• Java Based Technologies: Applets, Applications.
• Related Technologies: HTML, HTML Forms, JavaScript, Style Sheets, SSL
• Non-Java Technologies: MS Active Technologies such as ActiveX and OLE, VB Script, Jscript.
• Protocol: HTTP, HTTPS.
• Presentation Tier
• Responsible for the generation of the views (i.e. the HTML pages that are delivered to the browser).
• The components in this tier use JSP technology to access the business tier to query for data and to communicate the changes to it as requested by the user.
• Tier Constraints: Components and objects in this tier must interpret business data and generate documents that can be viewed by web browsers. They must also be capable of receiving change requests from the web client tier and passing it on to the Business Tier.
• This tier participates in the implementation of the View and Control of MVC.
• Technologies:
• Java Based Technologies: JSP, Servlets.
• Related Technologies: Web Services, SOAP.
• Non-Java Technologies:  MS Active Server Pages.
• Protocol: JRMP, IIOP, RMI-IIOP.
• Business Tier
• Business logic and rules are implemented in this tier.
• The components in this tier model business objects and concepts of the application.
• The design provides a layer of abstraction giving us implementation transparency to the data store and mechanisms.
• These components are the interfaces to data and provide essential services such as transaction monitoring, data integrity availability etc.
• Tier Constraints:
• The components in this tier must contain business logic, rules and represent business data.
• The container of the components of this tier must provide transaction management, component lifecycle management, enable load handling and fault tolerance and other services as specified in the product requirements.
• This tier participates in the Control and Model of MVC.
• Technologies:
• Java Based Technologies: EJB (the mainstay of J2EE), JTA, JTS
• Related Technologies: JNDI, CORBA, RMI.
• Non-Java Technologies: COM, DCOM, COM+.
• Integration Tier
• This contains objects, components and services that provide data connectivity.
• The APIs used in this tier hides the heterogeneous nature of resources that is available and necessary for business operations. For example data from an oracle database or a bar code scanner can be treated pretty much the same way by the objects in business tier thanks to this tier.
• Tier Constraints:
• Components in this tier must enable the communication of the business tier with the resource tier.
• This communication must be location transparent and homogenous to the business tier.
• This tier participates in the Model of MVC.
• Technologies:
• Java Based Technologies: JDBC, JCA, JMS, JDO
• Related Technologies: Messaging products like MQSeries, SonicMQ
• Non-Java Technologies: ODBC, OLEDB, ADO.
• Resources Tier / Data Tier /Persistence Tier
• This tier can also be called data tier, persistence tier etc. This tier is where data for the business application is stored. Other resources such as real-time data collects like barcode scanners can also belong to this tier.
• Tier Constraints: The contents of this tier must provide persistence of business objects represented in the business tier.
• This tier participates in the Model of MVC.
• Technologies:
• Related Technologies: RDBMS, Mainframes, CICS, ERP Systems like SAP, barcode scanners