3

Paolo Ciancarini

Architectural styles

2

Agenda   Types of architectural styles   Basic decomposition techniques

  layering, tiering

  Architectural styles   Pipes and filters   Repository   Client/Server

  two-tiers; three-tiers; n-tiers   Model/View/Controller   Service-Oriented   Peer-To-Peer

3

Layers and tiers   The architectural definition of a system is generally

achieved by decomposing the architecture into subsystems, following a layered and/or a partition based approach (tiers)

  These are orthogonal approaches:   A layer is a level in an architectural stack in charge of

providing services (e.g., a kernel)   A tier is the organization of several peer modules within

the same layer (e.g., a user interface)

4

Layers   An architecture which has a hierarchical structure,

consisting of an ordered set of layers, is layered   A layer is a set of subsystems which are able to provide

related services, that can be realized by exploiting services from other layers

  A layer depends only from its lower layers (i.e., layers which are located at a lower level into the architecture)   A layer is only aware of lower layers

Layers of virtual machines

5

Layers: component diagram   Connectors for layered systems

are often procedure calls   Each level implements a

different VM with a specific input language

6

Closed vs open layers   Closed architecture: the i-th layer can only have

access to the layer (i-1)-th   Open architecture: the i-th layer can have access

to all the underlying layers (i.e., the layers lower than i)

7

8

Layers – Closed architecture   The i-th layer can only invoke the services and the

operations which are provided by the layer (i-1)-th   The main goals are the system maintainability and

high portability (eg. Virtualization: each layer i defines a Virtual Machine - VMi)

VM4

VM3

VM2

VM1 C1

attr op

C1 attr op

C1 attr op

C1 attr op

C1 attr op

C1 attr op

C1 attr op

C1 attr op

C1 attr op

9

Closed layers: ISO/OSI stack

The ISO/OSI reference model defines 7 network layers, characterized by an increasing level of abstraction Eg. The Internet Protocol (IP) defines a VM at the network level able to identify net hosts and transmit single packets from host to host

Application

Presentation

Session

Transport

Network

DataLink

Physical

Leve

l of a

bstra

ctio

n

10

Layers – Open architecture   The i-th layer can invoke the services and the

operations which are provided by all the lower layers (the layers lower than i)

  The main goals are the execution time and efficiency

C1 attr op

C1 attr op

C1 attr op

C1 attr op

C1 attr op

C1 attr op

C1 attr op

C1 attr op

C1 attr op

Xlib

Xt

Motif

Application Open layers: OSF/Motif

Xlib provides low-level drawing facilities; Xt provides basic user interface widget management; Motif provides a large number of sophisticated widgets; The Application can access each layer independently

Creating layers: façade

12

Creating layers: façade

13

14

Tiers   Another approach to managing complexity consists

of partitioning a system into sub-systems (peers), which are responsible for a class of services

Typical tiered architecture

16

4 tiers architecture

17

Layers and tiers   Typically, a complete decomposition of a given

system comes from both layering and partitioning   First, the system in divided into top level subsystems

which are responsible for certain functionalities (partitioning)

  Second, each subsystem is organized into several layers, if necessary, up to the definition of simple enough layers

18

19

Architectural styles   Several architectural styles have been defined in

the literature of software engineering.   They can be used as the basis for configuring

software architectures.   The basic styles include:

  Pipes and filters   Repository   Client/Server: two-tiers; three-tiers; n-tiers   Model/View/Controller   Service-Oriented   Peer-To-Peer

Architectural variants

Pipes and Filters style

Pipe and Filter Architecture

  Main components:   Filter: process the a stream of input data to some out

put data   Pipe: a channel that allows the flow of data

read input file process file

filter

pipe

This architecture style focuses on the dynamic (interaction) rather than the structural

Batch sequential data flow

23

Pipe and Filter : UNIX shell   UNIX shell command line processing of the pipe symbol: “l”

the output from the command to the left of the symbol, l, is to be sent as input to the command to the right of the pipe;

this mechanism got rid of specifying a file as std output of a command and then specifying that same file as the std input to another command, including possibly removing this intermediate file afterwards

Example : counting occurrences in a file

I have a mailinglist file called “swarch.txt”

cat swarch.txt | grep studio | wc Note the pipe symbol, l

More Modern Version of Pipe-filter

  Consider the MS Office Product

  Specifically --- think about how the component called “copy” works in conjunction with the component called “paste” across office product (e.g. spread sheet to word document )

  The clipboard as a “pipe”

How may this be extended to the way e-mail with file attachment work?

Pipe-Filter example

  The high level design solution is decomposed into 2 parts (filters and pipes):   Filter is a service that transforms a stream of input data into a stream of

output data

  Pipe is a mechanism or conduit through which the data flows from one filter to another

Input time cards

Prepare for Check processing Process Checks

Problems that require batch file processing seem to fit this: payroll and compilers

Pipe – Filter with error processing

  Even if interactive error processing is difficult, batch error processing can be done with a pipe and filter architecture

Input time cards

Validate for payroll processing

Automatically Process Checks

Manually Reprocess Card and Cut Check

Payroll report Do the data streams need to be synchronized here for report?

Splitting the good time cards from the bad ones

Pipes and filters   Pipe: communication channel   Filter: computing component

  Filter 1 may only send data to Filter 2   Filter 2 may only receive data from Filter 1   Filter 1 may not receive data   Filter 2 may not send data   Pipe is the data transport mechanism

Filter 1 (Source)

Filter 2 (Sink)

Pipe

Pipe input output

output input * 1

* 1

Filter

+Read() +Write()

Pipe and Filter Class Diagram

Pipe and Filter Sequence Diagram

Data flow types There are three ways to make the data flow:

  Push only (Write only)   A data source may pushes data in a downstream   A filter may push data in a downstream

  Pull only (Read only)   A data sink may pull data from an upstream   A filter may pull data from an upstream

  Pull/Push (Read/Write)   A filter may pull data from an upstream and push

transformed data in a downstream

Active or passive filters   An active filter pulls in data and push out the transformed

data (pull/push); it works with a passive pipe which provides read/write mechanisms for pulling and pushing.   The pipe & filter mechanism in Unix adopts this mode.   The PipedWriter and PipedReader classes in Java are also passive

pipes that active filters must use to drive the data stream forward

  A passive filter lets connected pipes to push data in and pull data out. It works with active pipes that pull data out from a filter and push data into the next filter. The filter must provide the read/write mechanisms in this case.   This is very similar to the data flow hardware architecture

Pipe and Filter Sequence Diagram

“Architectural” package diagram

34

<<metaclass>> Component

<<metaclass>> Connector

<<stereotype>> Filter

<<stereotype>> Pipe

UML

Pipes&filters

Component diagram

35

<<filter>> <<component>>

pic


eqn

<<pipe>> <<pipe>>


tbl


troff

<<pipe>> <<pipe>> <<pipe>> <<pipe>> <<pipe>> <<pipe>>

Pipes and Filters: pro and cons

  Advantages:   Filters are self containing processing services that perform a

specific function thus the style is cohesive   Filters communicate (pass data most of the time) through pipes

only, thus the style results in low coupling

  Disadvantages:   The architecture is static (no dynamic reconfiguration)   Filter processes which send streams of data over pipes is a

solution that fits well with heavy batch processing, but may not do well with any kind of user-interaction.

  Anything that requires quick and short error processing is still restricted to sending data through the pipes, possibly making it difficult to interactively react to error-events.

Repository-based style

Shared Data   Very common in information systems where data is shared

among different functions   A repository is a shared data-store with two variants:

  Repository style: the participating parties check the data-store for changes

  Blackboard (or tuple space) style: the data-store alerts the participating parties whenever there is a data-store change (trigger)

Patient database

Physician diagnosis

Pharmacy & drug processing

Lab testing

Accounting & administration

Problems that fit this style have the following properties:

1. All the functionalities work off a shared data-store 2. Any change to the data-store may affect all or some of the functions

3. All the functionalities need the information from the data-store

Repository Architecture

39

Agent 1

Agent 3

Agent 2

Agent n

Agent 4

Repository

Repository Architecture   The subsystems use and modify (i.e., they have

access to) a shared data structure named repository

  The subsystems are relatively independent, in that they interact only through the repository

Subsystem

Repository

createData() setData() getData() searchData()

41

Example: a compiler architecture based on a repository

LexicalAnalyzer

SyntacticAnalyzer SemanticAnalyzer

CodeGenerator

Compiler

SyntacticEditor

ParseTree SymbolTable

Repository

SourceLevelDebugger

Optimizer

Repository: two flavors Data-centered style supporting user interactions   The control flow into the system can be managed

both by the repository (if stored data have to be modified) and by the subsystems (independent control flow)

  Passive repository (blackboard, tuple space): agents write or read items in the repository

  Active repository: the repository calls registered agents. This can be implemented with publish/subscribe

42

publish/subscribe   Agents interact by broadcast or multicast

messages   Each agent notifies a state change via a message

(it “raises an event”)   All agents interested to the event (“observers”)

receive a copy of the message   Event generators do not know the observers

(decoupling)   Examplex: device drivers, JavaBeans

43

publish/subscribe

44

Observer pattern

45

Publish subscribe variants

46

Tuple space   A tuple space is a repository where agents

(“Workers”) read or write tuples by pattern matching   Main primitives:

  out(tuple) non blocking, creates new tuple!  rd(tuple pattern) blocking, does not delete matching tuple   in(tuple pattern) blocking, deletes matching tuple   eval(tuple) non blocking, creates new worker

47

48

Repository: pro and cons   Benefits

  It is an effective way to share huge amounts of data: write once for all to read   Each subsystem has not to take care of how data are produced/consumed by

other subsystems   It allows a centralized management of system backups, as well as of security

and recovery procedures   The data sharing model is available as the repository schema, hence it is

easy to plug new subsystems   Pitfalls

  Subsystems have to agree on a data model, thus impacting on performance   Data evolution: it is “expensive” to adopt a new data model since (a) it has to

be applied on the entire repository, and (b) all the subsystems have to be updated

  Not for all the subsystems’ requirements in terms of backup and security are always supported by the repository

  It is tricky to deploy the repository on several machines, preserving the logical vision of a centralized entity, due to redundancy and data consistency matters

Client-Server style

Client server

50

remote remote remote

51

Client-server paradigm   It has been conceived in the context of distributed

systems, aiming to solve a synchronization issue:   A protocol was needed to allow the communication

between two different programs   The driving idea is to make unbalanced the

partners’ roles within a communication process   Reactive entities (named servers):

  They cannot initiate a communication   … they can only answer to incoming requests (reactive entities)

  Active entities (named clients):   They trigger the communication process   They forward requests to the servers, then they wait for

responses

52

Client-server paradigm   The first generation of distributed systems was

based on the client server style

Mainframe Monolithic

1st Generation Client/Server

2nd Generation Distributed Objects

Complexity & adaptability

Deg

ree

of

dist

ribut

ion

53

Client-server style   From the architectural viewpoint, a client/server system

is made up of components which can be classified according to the service abstraction:   Who provides services is a server;   Who requires a service is a client;

  A client is a program used by a user to communicate with a system   …but a server can be a client for a different service

  Clients are aware of the server interface   Servers cannot foresee clients’ requests

Client Server

service1() service2() serviceN()

* * requester! provider!

54

Client-server style   Most systems can be logically divided into three parts:

  The presentation, which is in charge of managing the user interface (graphic events, input fields check, help..)

  The actual application logic   The data management tier for the management of persistent data.

  The system architecture is defined according to how these parts are organized :   2-tiered, 3-tiered, or n-tiered

Presentation Application

processing Data

management

55

Client-server style   2 tiers Client/Server architectures

Fat client Fat server

Web has a Client-Server style   HTTP (Hypertext Transfer Protocol), ASCII-based request/reply protocol

that runs over TCP   HTTPS: variant that first establishes symmetrically-encrypted channel via

public-key handshake, so suitable for sensitive info

  By convention, servers listen on TCP port 80 (HTTP) or 443 (HTTPS)   Universal Resource Identifier (URI) format: scheme, host, port,

resource, parameters, fragment http://search.com:80/img/search/file?t=banana&client=firefox#p2

Web browser Web server A series of tubes

DNS server

1. 2.

56

A Conversation With a Web Server GET /index.html HTTP/1.0 User-Agent: Mozilla/4.73 [en] (X11; U; Linux 2.0.35 i686) Host: www.yahoo.com Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,

image/png, */* Accept-Language: en Accept-Charset: iso-8859-1,*,utf-8

  Server replies: HTTP/1.0 200 OK Content-Length: 16018 Set-Cookie: B=2vsconq5p0h2n Content-Type: text/html

<html><head><title>Yahoo!</title><base href=http://www.yahoo.com/> …etc.

  Repeat for embedded content (images, stylesheets, scripts...) <img width=230 height=33 src="http://us.a1.yimg.com/us.yimg.com/a/an/anchor/icons2.gif">

HTTP method & URI

Cookie data: up to 4KiB

MIME content type

57

Cookies   On first visit to a server, a browser may receive a cookie

from the server in HTTP header   Data is arbitrary   typically opaque, interpretation is up to the server   Usually encrypted, since the client is untrusted

  The browser automatically passes appropriate cookie back to server on each request   Server may update cookie value with any response   Simulates a concept of “session”

  Many uses   track user’s ID (canonical use: authentication)   track session state or a handle to it   in Web 1.0, before cookies, “fat URL’s” were used for this

58

59

Two-tier C/S architectures – 1/2   Pitfalls:

  Two-tiers C/S architectures exhibit a heavy message traffic since the front-ends and the servers communicate intensively

  The business logic is not managed by an ad-hoc component, but is it “shared” by front-end and back-end

  client and server depend one from each other   It is difficult to reuse the same interface to access different data   It is difficult to interact with databases which have different front-

ends   The business logic is encapsulated into the user interface

  If the logic changes, the interface has to change as well

60

Two-tier C/S architectures – 2/2   Recurrent problem:

  Business and presentation logic are not clearly separate   E.g., if there is a service which can be accessed by several

devices (e.g., mobile phone, desktop PC)   The same logic but different interface

Design pattern: dispatcher   Context: a set of servers   Problem: A client should not need to know where

servers are located   Solution: a dispatcher implementing a naming

service acts as an intermediate layer between clients and servers

61

Client do_task

Server run_service

Dispatcher Location_map locate_Server

request service

establish connection

request connection

62

Three-tier architectures – 1/6   Early 90’s; they propose a clear separation among logics:

  Tier 1: data management (DBMS, XML files, …..)   Tier 2: business logic (application processing, …)   Tier 3: user interface (data presentation and services)

  Each tier has its own goals, as well as specific design constraints

  No assumptions at all about the structure and/or the implementation of the other tiers , i.e.:   Tier 2 does not make any assumptions neither on how data are

represented, nor on how user interfaces are made   Tier 3 does not make any assumptions on how business logic works

63

Three-tier architectures – 2/6   Tiers 1 and 3 do not communicate, i.e.:

  The user interface neither receives any data from data management, nor it can write data

  Information passing (in both the directions) are filterer by the business logic

  Tiers work as they were not part of a specific application:   Applications are conceived as collections of interacting

components   Each component can take part to several applications at

the same time

64

Three-tier architectures – 3/6

65

Three-tier architectures – 4/6   Benefits:

  They leverage the flexibility of and the high modifiability of modular systems

  Components can be used in several systems   A change into a given component do not have any impacts on

the system (apart from changes into the API)   It is easier to localize a bug since the system functionalities are

isolated   New functionalities can be added to the system by only

modifying the components which are in charge of realizing them, or by plugging new components

66

Three-tier architectures – 5/6   Pitfalls:

  Application dimensions and efficiency:   Heavy network traffic

  High latency for service delivering   Ad hoc software libraries have to be used to allow the

communication among components   Many LoCs!

  Legacy software   Many companies make use of preexisting software, monolithic,

systems to manage data   Adapters have to be implemented to interoperate with the legacy

SW

67

Three-tier architectures – 6/6   Tiers are logical abstractions, not physical entities

  Three-tier architectures can be realized by using only one or two levels of machines

68

N-tier architectures   They provide high flexibility   Fundamental items:

  User Interface (UI): e.g., a browser, a WAP minibrowser, a graphical user interface (GUI)

  Presentation logic, which defines what the UI has to show and how to manage users’ requests

  Business logic, which manages the application business rules

  Infrastructure services   The provides further functionalities to the application

components ( messaging, transactions support);   Data tier:

  Application Data level

Example N-tiers

69

Model/View/Controller style

MVC

71

72

The MVC style   Three kinds of subsystems:

  Model, which has the knowledge about the application domain - also called business logic

  View, which takes care of making application objects visible to system users

  Controller, which manages the interactions between the system and it users

Controller

Model

subscriber notifier

initiator

*

repository 1

1

*

View

MVC goal   The goal of MVC is, by decoupling models and

views, to reduce the complexity in architectural design and to increase flexibility and maintainability

73

Basic interaction for MVC

74

Initialization for MVC

75

MVC interactions

76

MVC: component diagram example

77

78

MVC Architectures   The Model does not depend on any View and/or

Controller   Changes to the Model state are communicated to

the View subsystems by means of a “subscribe/notify” protocol (eg. Observer pattern)

  MVC is a combination of the repository and three-tiers architectures:   The Model implements a centralized data structure;   The Controller manages the control flow: it receives

inputs from users and forwards messages to the Model   The Viewer pictures the model

79

MVC: An example   Two different views of a

file system:   The bottom window

visualizes a folder named Comp-Based Software Engineering

  The up window visualizes file info related to file named 90DesignPatterns2.ppt

  The file name is visualized into three different places

80

MVC: communication diagram   1. Both InfoView and FolderView subscribe the changes to the model File

when created   2. The user enters the new filename   3. The Controller forwards the request to the model   4. The model actually changes the filename and notifies the operation to

subscribers   5. InfoView and FolderView are updated so that the user perceives the

changes in a consistent way

:Controller

:InfoView

:Model

2.User types new filename

1. Views subscribe to event

3. Request name change in model

4. Notify subscribers 5. Updated views

:FolderView

ClientServer 3-tiers vs MVC   The CS 3-tiers may seem similar to the model-

view-controller (MVC) concept; however, they are different

  A fundamental rule in a 3-tiers architecture is: the client tier never communicates directly with the data tier; all communication must go through the middleware tier: the 3-tiers architecture is linear

  Instead, the MVC architecture is triangular: the View sends updates to the Controller, the Controller updates the Model, and the Views get updated directly from the Model

81

82

The benefits of the MVC style   The main reason behind the separation (Model,

View and Controller) is that the user interfaces (Views) are changed much more frequently than the knowledge about the application domain (Model)

  This style is easy to reuse, to maintain, and to extend

  The MVC style is especially effective in the case of interactive systems, when multiple synchronous views of the same model have to be provided

Service-Oriented style

(SOA)

A world of services

84

The service-oriented architecture model

85

SOA, web service style (use cases)

86

87

Service-oriented architectures   SOAs represent an evolution of client-server

architectures   3rd generation of distributed software systems D

istri

butio

n de

gree

and

mob

ility

2 levels

3 levels

client-server

Complexity

Distributed objects

Distributed components

1st generation 2nd generation 3rd generation

C4 C5

C3 C2 C1

SOAs

88

Service-oriented architectures   Service-oriented architecture (SOA) is an

approach to loosely coupled, protocol independent, standards-based distributed computing where a software resource available on the network is considered as a service

  SOA is a technology solution that provides an enterprise with the agility and flexibility its users have been looking for

  The integration process is based on a composition of services spanning multiple enterprises

89

Service-oriented architectures   The following principles define the rules for

development, maintenance, and usage of a SOA:   Reuse, granularity, modularity, composability,

componentization, and interoperability   Compliance to standards (either cross-industry or

industry-specific)   Services identification and categorization, provisioning

and delivery, and monitoring and tracking

Service computing: layered style

90

SOA layers, IBM style

91

92

SOA principles – 1/2   Service encapsulation - Many web-services are

consolidated to be used under the SOA Architecture. Often such services have not been planned to be under SOA

  Service loose coupling - Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other

  Service contract - Services adhere to a communications agreement, as defined collectively by one or more service description documents

  Service abstraction - Beyond what is described in the service contract, services hide logic from the outside world

93

SOA principles – 2/2   Service reusability - Logic is divided into services

with the intention of promoting reuse   Service composability - Services can be

coordinated/assembled to form composite services   Service autonomy – Services have control over the

logic they encapsulate   Service optimization – All else equal, high-quality

services are generally considered preferable to low-quality ones

  Service discoverability – Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms

94

SOA building blocks – 1/2   Service Consumer (also known as Service

Requestor): it locates entries in the Registry using various find operations and then binds to the service provider in order to invoke one of its services

  Service Provider: it creates a service and publishes its interface and access information to the Service registry

  Service Registry (also known as Service Broker): it is responsible for making the Service interface and implementation access information available to any potential service requestor

Interaction: State diagram

95

96

SOA building blocks – 2/2   Service registration (provider) and lookup (requestor) in the

registry   Service access

Desktop Computer PDA

SERVICE REQUESTOR

SERVICE REGISTRY

SERVICE PROVIDER

Service lookup

Service access

Service registration

Laptop

97

SOA model   1 Service Consumer   2 Service Provider   3 Service Registry   4 Service Contract

  5 Service Proxy   6 Service Lease

SOA in UML

98

SOA elements

99

100

SOA characteristics   The software components in a SOA are services

based on standard protocols   Services in SOA have minimum amount of

interdependencies   Communication infrastructure used within an SOA

should be designed to be independent of the underlying protocol layer

  Offers coarse-grained business services, as opposed to fine-grained software-oriented function calls

  Uses service granularity to provide effective composition, encapsulation and management of services

101

Service granularity   Service granularity refers to the scope of

functionality a service exposes   Fine-grained services provide a small amount of

business-process usefulness, such as basic data access

  Coarse-grained services are constructed from fine-grained services that are intelligently structured to meet specific business needs.

102

Service composition

Jeff Hanson, Coarse-grained Interfaces Enable Service Composition in SOA, JavaOne, August 29, 2003

103

Web Services   A W3C standard defining an API accessed via

HTTP and executed on a remote host   Definition:

  ‘A Web service is a software application identified by a URI, whose interfaces and bindings are capable of being defined, described, and discovered as XML artifacts. A Web service supports direct interactions with other software agents using XML based messages exchanged via internet-based protocols.’

  Two flavors: big services, RESTful services

104

WS underlying technologies   The basic standards for

web services are:   XML (Extensible Markup

Language)   SOAP (Simple Object

Access Protocol)   WSDL (Web Services

Description Language)   UDDI (Universal

Description, Discovery and Integration)

105

SOA-related standards   XML 1.0 fairly stable, although Schema are in the

process of replacing DTDs (currently Schema 1.1 being worked on).

  SOAP 1.2   WSDL 2.0 (coming out, 1.2 current)   UDDI version 3 (Aug 2003)   BPEL 1.1 (Business Process Execution Language)   choreography description language (web services

work flows)   started January 2003

106

Web Services Architecture   Web Services involve three major roles

  Service Provider   Service Registry   Service Consumer

  Three major operations surround web services   Publishing – making a service available   Finding – locating web services   Binding – using web services

107

Service publication   In order for someone to use your service they have

to know about it   To allow users to discover a service it is published

to a registry (UDDI)   To allow users to interact with a service you must

publish a description of it’s interface (methods & arguments)

  This is done using WSDL

WSDL

108

109

Making a service available   Once you have published a description of your

service you must have a host set up to serve it.   A web server is often used to deliver services

(although custom application – application communication is also possible).

  This functionality has to be added to the web server. In the case of the Apache web server a ‘container’ application (Tomcat) can be used to make the application (servlet) available to Apache (deploying).

110

WS and existing protocols   Web services are layered on top of existing, mature

transfer protocols   HTTP, SMTP are still used over TCP/IP to pass the

messages   Web services (like grids) can be seen as a

functionality enhancement to the existing technologies

111

WS and XML   All Web Services documents are written in XML   XML Schema are used to define the elements used

in Web Services communication

112

WS and SOAP   SOAP is the protocol actually used to communicate

with the Web Service   Both the request and the response are SOAP

messages   The body of the message (whose grammar is

defined by the WSDL) is contained within a SOAP “envelope”

  “Binds” the client to the web service

113

WSDL   Describes the Web Service and defines the

functions that are exposed in the Web Service   Defines the XML grammar to be used in the

messages   Uses the W3C Schema language

114

WS and UDDI   UDDI is used to register and look up services with

a central registry   Service Providers can publish information about

their business and the services that they offer   Service consumers can look up services that are

available by   Business   Service category   Specific service

115

Web Services and SOAs   Web Services are an open standards-based way of

creating and offering SOAs   Web Services are able to exchange structured

documents that contain different amounts of information, as well as information about that information, known as metadata

  In other words, Web Services can be coarse grained. Such coarse granularity is one of the most important features of SOAs

116

Re-architecture to SOA: benefits   Provides location independence: Services need not be associated with

a particular system on a particular network   Protocol-independent communication framework renders code

reusability   Offers better adaptability and faster response rate to changing business

requirements   Allows easier application development, run-time deployment and better

service management   Loosely coupled system architecture allows easy integration by

composition of applications, processes, or more complex services from other less complex services

  Provides authentication and authorization of Service consumers, and all security functionality via Services interfaces rather than tightly-coupled mechanisms

  Allows service consumers (ex. Web Services) to find and connect to available Services dynamically

117

Why not SOA   For a stable or homogeneous enterprise IT

environment, SOA may not be important or cost effective to implement

  If an organization is not offering software functionality as services to external parties or not using external services, which require flexibility and standard-based accessibility, SOA may not be useful

  SOA is not desirable in case of real time requirements because SOA relies on loosely coupled asynchronous communication

Cloud computing   Software as a service, like Web services   Platform as a service, like mashups   Infrastructure as a service (or hardware as a

service)

118

Peer-to-peer style

P2P

120

Peer-to-peer architectures   They can be considered a generalization of the

client/server architecture   Each subsystem is able to provide services, as

well as to make requests   Each subsystem acts both as a server and as a client

Peer

service1() service2()

serviceN() …

requester

provider

*

*

121

Peer-to-peer architectures   In such an architecture, all nodes have the same

abilities, as well as the same responsibilities. All communications are (potentially) bidirectional

  The goal:   To share resources and services (data, CPU cycles,

disk space, …)   P2P systems are characterized by:

  Decentralized control   Adaptability   Self-organization and self-management capabilities

122

Peer-to-peer architectures   Functional characteristics of typical P2P systems

  File sharing system   File storage system   Distributed file system   Redundant storage   Distributed computation

  Nonfunctional requirements   Availability   Reliability   Performance   Scalability   Anonymity

123

P2P architectures: brief history   Although they were proposed 30 years ago, they

mainly evolved in the last decade   File sharing systems contributed to increase the

interest (Napster, 1999; Gnutella, 2000)   In 2000, the Napster client was downloaded by 50

millions users   Traffic peak of 7 TB in a day

  Gnutella followed Napster’s footprint   The first release was delivered in 2003   In June 2005, Gnutella's population was 1.81 million

computers; in 2007, it was the most popular file sharing network with an estimated market share > 40%

  Host servers are listed at gnutellahost.com

124

The phases of a P2P application A P2P application is organized in three phases:

  Boot, during which a peer connects to the networks and actually performs the connections (P2P boot is rare)

  Lookup, during which a peer looks for a provider for a given service or information (generally providers are SuperPeers)

  Resource sharing, during which requested resources are delivered, usually in several segments

125

P2P classification – 1/2   P2P applications can be categorized as follows:

  Pure P2P applications   All the phases are based on P2P

  P2P applications   lookup and resource sharing are performed according to the P2P

paradigm;   Some servers are used to make the boot

  Hybrid P2P applications :   The resource sharing is performed according to the P2P

paradigm   Some servers are used to make the boot;   Specific peers are used to perform lookup.

126

P2P classification – 2/2   With respect to lookup phase:

  Centralized Lookup   Centralized index of providers

  Decentralized Lookup   Distributed index

  Hybrid Lookup   Several centralized systems which are linked

into a decentralized system

Napster

Gnutella (original)

Gnutella

129

Gnutella: search

130

Gnutella: reply

131

Skype   A mixed client-server and peer-to-peer architecture addresses

the discovery problem   Replication and distribution of the directories, in the form of

supernodes, addresses the scalability problem and robustness problem encountered in Napster

  Promotion of ordinary peers to supernodes based upon network and processing capabilities addresses another aspect of system performance: “not just any peer” is relied upon for important services

  A proprietary protocol employing encryption provides privacy for calls that are relayed through supernode intermediaries

  Restriction of participants to clients issued by Skype, and making those clients highly resistant to inspection or modification, prevents malicious clients from entering the network

134

P2P: scalability – 1/2   The performances of a P2P system (e.g., the time

to find a file) become worse as the number of nodes increases (linearly)   The “work” for a node increases linearly with respect to

the number of nodes   The protocols used by Napster and Gnutella are

not scalable   A second generation of P2P protocols has been

realized which support DHT (Distributed Hash Table) in order to improve their scalability   Examples are Tapestry, Chord, Can, Viceroy, Koorde,

Kademlia, Kelips …

135

P2P: scalability – 2/2   The degree of scalability of a given protocol

depends on the efficiency of the adopted routing algorithm (lookup)

  Two main objectives:   To minimize the number of message to complete the

lookup   To minimize, for each node, information about other

nodes in the network

  DHT P2P differ into the routing strategy they adopt

Summary   The basic architectural styles are few and their

properties should be studied and become known   Their descriptions and properties are better

understood using a modeling notation   The architectural models and descriptions can be

exploited by a technology like UML via automatic transformations: see the Model Driven Architecture

136

Self test questions

137

  Describe an example application architecture for each of the following styles: pipe-and-filter, repository, client-server, peer-to-peer

  Discuss the difference between the active and passive repository styles

  What are the advantages of P2P over client-server style?

References

  Taylor et al., Software Architecture, Wiley 2009   Qian et al., Software Architecture and Design Illuminated, Jones

and Bartlett, 2009   Garland, Large-Scale Software Architecture: A Practical Guide

using UML, Addison-Wesley, 2005   Fielding & Taylor, Principled Design of the Modern Web

Architecture, ACM Trans. on Internet Technology, 2:2, 2002   Rao, Using UML service components to represent the SOA

architecture pattern, 2007 www.ibm.com/developerworks/architecture/library/ar-logsoa/

Useful sites   www.softwarearchitectureportal.org!  www.dossier-andreas.net/software_architecture/!

  www.bredemeyer.com/links.htm!  www.opengroup.org/architecture/!  www.iasahome.org!  alistair.cockburn.us!

Questions?

3

Technology

Transcript of 3