LECTURE #16

Heterogeneous Architectures

 Definition: Combines multiple architectural styles in a single software project.

 Purpose: Leverages the strengths of different styles to meet complex project requirements.

 Example: Operating systems (e.g., Mac OS, Windows) often use layered architectures for
high stability. A failure in one layer does not affect others.

Methodology of Architecture Decision

Choosing the Right Software Architecture

 Architecture decisions depend on:

o Requirements: Functional needs of the system.

o Priorities: Stakeholder preferences (e.g., performance vs. cost).

o Constraints: Budget, timeline, or technical limitations.

 The goal is to trade off competing needs for an "optimal" architecture rather than excelling in
just one area.

Architecture Selection Process

1. Outline Project Details: Define requirements, constraints, and desired quality attributes.

2. Functional Decomposition: Break down the system's required functionalities.

3. Propose Architectural Patterns: Suggest possible styles that align with the project goals.

4. Mapping and Validation: Assign system functionalities to specific layers or components in

the architecture.

5. Evaluate Quality Attributes: Measure how well the architecture meets performance,
reliability, and other attributes.

6. Documentation: Record all proposed architectures for stakeholder review.

Refinement

 If no suitable design works, refine the process by:

1. Extending deadlines.

2. Increasing budgets.

3. Reducing functional requirements.

 Reiterate with stricter boundaries to achieve the best design.

Quality Attributes
Definition

 Non-functional characteristics of the system that must be determined before the detailed
design phase.

Examples of Quality Attributes

1. Efficiency:

o Time efficiency: Fast processing.

o Resource economy: Minimal hardware and energy use.

2. Functionality:

o Completeness: Meeting all requirements.

o Security: Protecting against threats.

o Interoperability: Compatibility with other systems.

3. Maintainability:

o Modifiability: Easy to update or expand.

o Testability: Easier error detection and debugging.

4. Portability:

o Hardware/software independence: Adaptable to different environments.

o Reusability: Components usable in other projects.

5. Reliability:

o Error tolerance: Handling unexpected failures gracefully.

o Availability: System uptime and readiness.

6. Usability:

o Understandability: Easy-to-read code.

o User interface: Intuitive for end-users.

o Learnability: Low learning curve.

Evaluation of Quality Attributes

Quantitative Evaluation

 Attributes like performance can be directly measured (e.g., latency, throughput).

 Example: Latency in milliseconds or bandwidth in Mbps.

Qualitative Evaluation

 Attributes like understandability are rated on scales:

 o Example: "Excellent" = 90, "Poor" = 20 on a 100-point scale.

Steps to Evaluate Quality

1. Assign weights to each attribute based on its importance (e.g., performance = 50%, cost =
20%).

2. Score each design on a scale (e.g., 0–100) for each attribute.

3. Calculate the weighted total score to compare designs.

Final Steps in Architecture Design

1. Choose an Architecture Style: Select a style like Pipe-Filter or Layered based on project
needs.

2. Detail the Design:

o Define components (e.g., filters in Pipe-Filter).

o Specify how components interact.

Architecture Styles and Comparisons

 Styles are evaluated based on how well they meet various quality attributes.

 Ratings:

o +: Good.

o ++: Very good.

o -: Poor.

o --: Very poor.

o Empty cell: No clear judgment in the general case.

Systematic Evaluation Approaches

1. SAAM (Software Architecture Analysis Method):

o Focuses on modifiability and scenario-based risks.

o Best for initial evaluations.

2. ATAM (Architecture Trade-off Analysis Method):

o Comprehensive analysis of multiple attributes.

o Identifies trade-offs between conflicting qualities.

3. ARID (Active Reviews for Intermediate Designs):

 o Reviews and refines designs during the development process.

SAAM Analysis Example

Case Study: IRS Online Tax System

 Objective: Improve system efficiency and scalability.

 Scenarios:

1. Adding a New Class:

 Expands the system with minimal changes.

 Design 2 excels due to compliance with the Open/Closed Principle.

2. Handling Heavy Load:

 Testing the system with one million users per day.

 Both designs perform well, but Design 2 shows better scalability.

3. Algorithm Changes:

 Modifying the tax calculation logic.

 Both designs require updates, but strategy patterns can optimize the
process.

Conclusion

 Design 2 is superior in scalability and flexibility but requires thoughtful implementation to

address algorithm updates efficiently.

 LECTURE # 20
Middleware Architectures
Definition
 Middleware acts as the "plumbing or wiring" of software applications.
 Facilitates communication between software components.
Purpose
1. Enables data exchange between components.
2. Supports various connection types: one-to-one, one-to-many, many-to-many.
Key Traits
 Invisible to end-users unless a failure occurs.
 General and configurable for diverse applications.

Technology Classification
Middleware technologies vary based on application domains:
1. Transport Layer: Simple data exchange mechanisms, like pipes.
2. Application Servers: Multi-threaded servers providing transactions, security, and
directory services.
3. Message Brokers: Focused on message transformation and routing.
4. Business Process Orchestrators: Manage workflows and long-term processes,
including human tasks.

Why Middleware is Critical

Benefits
1. Pre-built infrastructure for connecting software components.
2. Scalable and configurable for diverse domains.
3. Seamless for end-users, only noticed during failures.
Key Middleware Technologies
1. Distributed Objects (e.g., CORBA):
o Object-oriented systems that communicate over networks.
2. Message-Oriented Middleware (MOM):
o Facilitates loose coupling of distributed systems using asynchronous
messaging.

Distributed Objects
Overview
 Based on CORBA (Common Object Request Broker Architecture).
 Enables communication between object-oriented systems across networks.
Key Components
1. Object Request Broker (ORB):
o Handles communication between client and server objects.
o Abstracts network details for location transparency.
2. Interface Definition Language (IDL):
o Defines interfaces for platform and language independence.
3. Client:
o Initiates requests to server objects.
4. Server (Servant):
o Implements the actual business logic.
Interaction Process
1. Client makes a request through a local stub.
2. ORB serializes and transmits the request to the server.
3. Server-side ORB processes the request and sends a response back.

Message-Oriented Middleware (MOM)

Overview
 Provides asynchronous communication through message queues.
 Ensures independence between senders and receivers.
Architecture
1. Message Queues:
o Store and deliver messages in a First-In-First-Out (FIFO) manner.
2. MOM Server:
o Manages message persistence, delivery, and acknowledgments.
Advantages
1. Decoupled Communication: Senders and receivers operate independently.
2. Reliability: Messages persist until delivered, even during system downtimes.
3. Scalability: Handles large-scale, distributed systems efficiently.
Advanced Features
1. Message Delivery:
o Options: Best Effort, Persistent, or Transactional.
2. Transactions:
o Ensures atomic operations, integrating with databases.
3. Clustering:
o Provides high availability and load balancing.
4. Two-Way Messaging:
o Enables synchronous communication when required.

Publish-Subscribe Architecture
Definition
 Extends MOM to support one-to-many and many-to-many communication models.
Key Components
1. Publisher:
o Sends messages to a named topic.
2. Topic:
o Acts as a logical equivalent of a queue.
3. Subscriber:
o Registers to a topic and receives messages.
4. Messaging Layer:
o Manages topics and ensures message delivery.
Core Features
1. Dynamic subscription allows flexible updates.
2. Supports time-to-live for messages.
3. Offers persistence for reliable delivery.
Applications
 Event notification systems.
 Financial market data distribution.
 Collaboration platforms.

Choosing the Right Middleware

Factors to Consider
1. System Requirements:
o Distributed Objects for real-time interactions.
o MOM for asynchronous, scalable systems.
2. Failure Tolerance:
o MOM offers better reliability with message persistence.
3. Scalability:
o MOM is superior for integrating multiple applications across diverse
platforms.
Middleware technologies play a critical role in modern enterprise systems, providing
robust, scalable, and flexible solutions for communication and integration.

N j,vj.vk.vilxci8