Lecture 15: Distributed Architectures (Architecture III) 2008... · Distributed Architectures...
Transcript of Lecture 15: Distributed Architectures (Architecture III) 2008... · Distributed Architectures...
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