Lecture 15:Distributed Architectures

(Architecture III)

Software System Design and ImplementationITCS/ITIS 6112/8112 091

Fall 2008

Dr. Jamie PaytonDepartment of Computer Science

University of North Carolina at Charlotte

Oct. 23, 2008

Announcements

Homework 2 postedDue on Tuesday, Oct. 28 at 5:00 pmPlease name files appropriately• <Your last name>_HW2.<file extension>

Please put “ITCS 6112 HW2” in the subject line of your email

Homework drop policyDrop your lowest homework grade, replace with highest

D3Deadline: Nov. 11Updated template will be provided later this week

Team/instructor meetingsDefine emphasis on prototype vs. documentation for final deliverable

Software Architecture Definition

Architecture defines major componentscomponent relationships (structures) component interactions

Architecture encompasses the significant decisions about the organization of a systemArchitecture defines the rationale behind the components and the structure

3

Architectural Styles

A previous architectural solution for a class of design problemsPattern of system organizationTerm coined by D. Garlan and M. Shaw [GAR95]

Conveys idea that architectural model of a system may conform to a generic architectural model or styleAwareness of architectural styles can simplify the problem of defining system architecturesMost large systems are heterogeneous

do not follow a single architectural style

Taxonomy of Architectural Styles

StructureRepositoryLayeredClient-server

DecompositionObject-oriented Pipe-and-filter

ControlCentralized controller Event-driven

More Architectural Design Decisions

How will the system be distributed?How should the architecture be documented?How will the architectural design be evaluated?

Distributed systems

Virtually all large computer-based systems are now distributed systemsInformation processing is distributed over several computers Distributed software engineering is therefore very important for enterprise computing systems

Software System Types

Personal systems not distributed and are designed to run on a personal computer

Embedded systemsrun on a single processor (or on an integrated group of processors)

Distributed systems system software runs on a loosely integrated group of cooperating processors linked by a network

Distributed System Characteristics

Resource sharingSharing of hardware and software resources

OpennessUse of equipment and software from different vendors

ConcurrencyConcurrent processing to enhance performance

ScalabilityIncreased throughput by adding new resources

Fault toleranceThe ability to continue in operation after a fault has occurred

Distributed System Disadvantages

ComplexityTypically, distributed systems are more complex than centralized systems

SecurityMore susceptible to external attack

ManageabilityMore effort required for system management

UnpredictabilityUnpredictable responses depending on the system organization and network load

Distributed Systems Architectures

Client-server architecturesDistributed services which are called on by clientsServers that provide services are treated differently from clients that use services

Distributed object architecturesNo distinction between clients and serversAny object on the system may provide and use services from other objects

Client-server Architectures

Application is modelled as a set of services and a set of clientsClients know of servers but servers need not know of clientsClients and servers are logical processes The mapping of processors to processes is not necessarily 1 : 1

Several server processes on a single host

A Client-Server System (Logical View)

A Client-Server System (Physical View)

Can also run client and server on same machine

Layered Application Architecture

Presentation layerConcerned with presenting results to users and collecting user inputs

Application processing layerConcerned with logic of the application

Data management layerConcerned with performing operations on databases

Thin and Fat Clients

Thin-client model Server does:• application logic

• data management

Client does:• presentation

Fat-client model Server does:• data management

Client does:• application logic • presentation

When to Use Thin Client Model

Migration of legacy systems to client-server architectures

Legacy system = serverLocal GUI = client

Use of very simple devices to support client operationDisadvantage:

Places heavy processing load on both server and network

When to Use Fat Client Model

Most suitable for new client/server systemsCapabilities of the client system are known in advance

Disadvantages:More complex than a thin client model New versions of the application have to be installed on all clients

Fat Client Example:A Client-Server ATM System

Three-tier Architectures

Previously, saw two-tier architecturesLayer was either on the client or the server

In a three-tier architecture, each of the architecture layers may execute on a separate processorAdvantages:

Allows for better performance than thin-client approachSimpler to manage than fat-client approachMore scalable • as demands increase, extra servers can be added

Three-tier Client/Server Architecture

Client

Server

Datamanagement

Presentation

Server

Applicationprocessing

Three-tier Architecture Example:An Internet Banking System

Multi-tier Client/Server Architecture

Server

DatamanagementServer

DatamanagementServer

Datamanagement

Client

PresentationServer

Applicationprocessing

Server

Integration

Use of Client/Server Architectures

Two-tierThin client• Extending the use of legacy systems• Either application processing or data processing dominates

Fat client• Application processing performed by client-side COTS• Lots of data is processed in a computationally intensive way• Application processing is relatively stable

Multi-tierSystems with many clients (thousands)Data management and application processing likely to changeData to be processed originates from multiple sources

Distributed Object Architectures

No distinction between clients and serversEach distributable entity is an object

provides services to other objects receives services from other objects

Object communication is through a middlewaresystem called an object request broker (ORB)

Distributed Object Architecture

Evaluating Distributed Object Architectures

Advantages: Flexible and Scalable• Provides flexibility in location of services• Can reconfigure the system dynamically• Allows new resources to be added to architecture as required

Disadvantage:More complex to design than client/server systems

How to Use Distributed Object Architectures

As a logical model that allows you to structure and organize the system

Think about how to provide application functionality solely in terms of services and combinations of services

As a flexible approach to the implementation of client-server systems

The logical model of the system is a client-server modelBoth clients and servers are realized as distributed objects communicating through middleware• May be composed of several smaller distributed objects

Example of Distributed Object Architecture:

A Data Mining System

Why Use DOA for Data Mining System?

No real “services” provided by systemDoes not fit with client-server model

Allows addition of databases without disruptionIt easily allows new types of relationships to be mined

Simply add new integrator objects

Middleware

Infrastructure software that manages and supports the different components of a distributed system

Enables component communicationHides physical distribution of components

Provides standard for constructing and connecting componentsMiddleware is usually off-the-shelf, general purpose rather than specially written software

A Middleware to Support DOA:CORBA

Common Object Request Broker Architecture (CORBA) International standard for an Object Request BrokerManages communications between distributed objects

Middleware for distributed computing is required at 2 levels:

At the logical communication level• Middleware allows objects on different computers to exchange

data and control information;At the component level• the middleware provides a basis for developing compatible

components• CORBA component standards have been defined

CORBA Application Structure

CORBA Standards

An object model for application objectsA CORBA object is an encapsulation of state with a well-defined, language-neutral interface defined in an IDL (interface definition language).

An object request broker that manages requests for object servicesA set of general object services of use to many distributed applicationsA set of common components built on top of these services

CORBA Objects

CORBA objects are comparable, in principle, to objects in C++ and JavaMUST have a separate interface definition that is expressed using a common language (IDL) similar to C++There is a mapping from this IDL to programming languages (C++, Java, etc.)Therefore, objects written in different languages can communicate with each other

Object Request Broker (ORB)

ORB handles object communicationsIt knows of all objects in the system and their interfaces

Using an ORB, the calling object binds an IDL stubthat defines the interface of the called objectCalling this stub results in calls to the ORB

ORB then calls the required object through a published IDL skeleton• Links the interface to the service implementation

ORB-based Object Communications

Inter-ORB Communications

ORBs are not usually separate programs but are a set of objects in a library that are linked with an application when it is developedORBs handle communications between objects executing on the same machineSeveral ORBS may be available and each computer in a distributed system will have its own ORBInter-ORB communications are used for distributed object calls

Inter-ORB communications

Inter-organization Distributed Systems

Computation, services come from many different organizations (or even individuals)Examples

Peer-to-Peer architecturesService-oriented architectures

Peer-to-peer Architectures

P2P systems are decentralizedFlat structure• Nodes are typically considered as “equals”• Computations may be carried out by any node

Typically take advantage of distributed resourcesComputational power• Grid computing

SETI project (telescope data)Cancer cure search

Storage• File sharing

NapsterGnutella

P2P Architectural Models

Characterized by network organizationPurely decentralized architecturesSemi-centralized architectures• Have some kind of “super peer” node • Helps facilitate peer-to-peer interactions

Decentralized P2P Architecture

Semi-centralized P2P Architecture

Service-oriented Architectures

Applications constructed by using externally offered services

Service: action or performance offered by one party to anotherAny node can provide a service to any other node• Regardless of “organizational membership”

Web Services

Web service is a special kind of servicea way of making component available across the webExample• H&R Block has a tax filing component used by their accountants• Can make this component accessible to users

Package (using standards) as a web service

Characteristics of SOA

Service providers offer servicesDefines and publishes its interfaceDefines implementation

Service registry manages registered servicesApplications request services from known service registry

Request is matched against registered interfacesApplication gets handle to service from service registryApplication binds to provided service at run time

Service Oriented Architecture

SOA Standards

Many organizations provide different types of servicesCan be provided on any platformCan be written in any programming languageNeed standards to ensure interoperation

SOA standards (based on XML)SOAP• Defines standard for structured data exchange

WSDL• Defines how to represent interfaces for web services

UDDI• Defines how service description information can be organized

Differences Between SOA and DOA

With SOA:Services can be offered by any service providerServices are publicly advertised for use by others • Clients perform lookup

Potentially, run-time service binding• Can change service used at run-time

Reactive and adaptive applications• Can bind to new services as environment changes

Pay only for use of serviceOpportunistic construction of new services • through composition of services

More Architectural Design Decisions

How will the system be distributed?How should the architecture be documented?How will the architectural design be evaluated?

Architectural models

Architecture is documented from many perspectives (views)

Static structural model• Shows the major system components

Dynamic process model • Shows the process structure of the system

Interface model • Defines component interfaces

Relationships model • Shows component relationships

Distribution model • Shows how components are physically distributed across

computers

Architecture and Quality Attributes

PerformanceLocalize critical operations and minimize communicationsUse large rather than fine-grain components

SecurityUse a layered architecture with critical assets in the inner layers

SafetyLocalize safety-critical features in a small number of sub-systems

AvailabilityInclude redundant components and mechanisms for fault tolerance

MaintainabilityUse fine-grain, replaceable components

Architectural conflicts

Large-grain components improves performance reduces maintainability

Redundant data improves availability makes security more difficult.

Localizing safety-related featuressimplifies securitymore communication so degraded performance.

Evaluating Architectural Design

Architecture Tradeoff Analysis Method (ATAM)Iterative process:

1. Collect scenarios and use cases• Quality scenarios and change scenarios

2. Elicit requirements, constraints, environment description3. Describe selected architectural styles and patterns4. Evaluate quality attributes

• Consider each in isolation• Identify sensitivity to various architectural attributes

5. Critique candidate architectures using sensitivity analysis• Determine acceptable trade-offs

Evaluating Architectural Design

Evaluating Architectural Design

Software Architecture Analysis Method (SAAM)

Terminology

Software componentCohesive piece of software functionality…that can be deployed independently…and can be composed with other components

Different levels of abstraction for componentsProgram module or object-oriented class (simple)Subsystems (more complex)Databases and middleware systems (more complex)

58

Terminology

Sub-system A system component whose operation is independent of services provided by other sub-systems

Module A system component that provides services to other components Not normally be considered as separate system

Terminology

Hierarchy of software components1. Program2. Sub-programs or sub-systems3. Modules

1. Packages, compilation units2. Classes

60