Architectural styles     Paolo Ciancarini
Agenda    Types of architectural styles    Basic decomposition techniques         layering, tiering    Architectural s...
Layers and tiers    The architectural definition of a system is generally     achieved by decomposing the architecture in...
Layers    An architecture which has a hierarchical structure,     consisting of an ordered set of layers, is layered    ...
Layers of virtual machines                             5
Layers: component diagram    Connectors for layered systems     are often procedure calls    Each level implements a    ...
Closed vs open layers    Closed architecture: the i-th layer can only have     access to the layer (i-1)-th    Open arch...
Layers – Closed architecture    The i-th layer can only invoke the services and the     operations which are provided by ...
Closed layers: ISO/OSI stackThe ISO/OSI reference                                   Applicationmodel defines 7 networklaye...
Layers – Open architecture    The i-th layer can invoke the services and the     operations which are provided by all the...
Open layers: OSF/Motif                                             Application                                  Motif     ...
Creating layers: façade                          12
Creating layers: façade           13
Tiers    Another approach to managing complexity consists     of partitioning a system into sub-systems (peers),     whic...
15
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  ...
Architectural styles    Several architectural styles have been defined in     the literature of software engineering.   ...
Architectural variants
Pipes and Filters style
Pipe and Filter Architecture    Main components:       Filter: process the a stream of input data to some out        put...
Batch sequential data flow                          Rejected                        transaction                          -...
Pipe and Filter : UNIX shell      UNIX shell command line processing of the pipe symbol: “l”            the output from t...
More Modern Version of Pipe-filter    Consider the MS Office Product    Specifically --- think about how the component c...
Pipe-Filter example    The high level design solution is decomposed into 2 parts (filters     and pipes):          Filte...
Pipe – Filter with error processing    Even if interactive error processing is difficult, batch error     processing can ...
Pipes and filters    Pipe: communication channel    Filter: computing component          Filter 1 may only send data to...
Pipe and Filter Class Diagram                             Pipe     Filter                        +Read()                  ...
Pipe and Filter Sequence Diagramdata source:           filter1:               pipe:             filter2:                  ...
Data flow typesThere are three ways to make the data flow:    Push only (Write only)          A data source may pushes d...
Active or passive filters    An active filter pulls in data and push out the transformed     data (pull/push); it works w...
Pipe and Filter Sequence Diagram                        active                passive                active   Pull only   ...
“Architectural” package diagram   UML      <<metaclass>>     <<metaclass>>       Component          Connector   Pipes&filt...
Component diagram<<pipe>> <<pipe>>   <<pipe>> <<pipe>>   <<pipe>> <<pipe>>   <<pipe>> <<pipe>>  <<filter>>            <<fi...
Pipes and Filters: pro and cons    Advantages:         Filters are self containing processing services that perform a   ...
Repository-based style
Shared Data    Very common in information systems where data is shared     among different functions    A repository is ...
Repository Architecture                            Agent 2     Agent 1               Repository                           ...
Repository Architecture    The subsystems use and modify (i.e., they have     access to) a shared data structure named   ...
Example: a compiler architecture based on a repository     Compiler                          SemanticAnalyzer     Syntacti...
Repository: two flavorsData-centered style supporting user interactions  The control flow into the system can be managed ...
publish/subscribe    Agents interact by broadcast or multicast     messages    Each agent notifies a state change via a ...
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    Ma...
Repository: pro and cons    Benefits          It is an effective way to share huge amounts of data: write once for all t...
Client-Server style
Client server remote    remote   remote                             50
Client-server paradigm    It has been conceived in the context of distributed     systems, aiming to solve a synchronizat...
Client-server paradigm       The first generation of distributed systems was        based on the client server style     ...
Client-server style    From the architectural viewpoint, a client/server system     is made up of components which can be...
Client-server style    Most systems can be logically divided into three parts:         The presentation, which is in cha...
Client-server style    2 tiers Client/Server architectures            Fat server                     Fat client 55
Web has a Client-Server style    HTTP (Hypertext Transfer Protocol), ASCII-based request/reply protocol     that runs ove...
A Conversation With a Web ServerGET /index.html HTTP/1.0User-Agent: Mozilla/4.73 [en] (X11;HTTP method & URIi686)         ...
Cookies    On first visit to a server, a browser may receive a cookie     from the server in HTTP header         Data is...
Two-tier C/S architectures – 1/2    Pitfalls:         Two-tiers C/S architectures exhibit a heavy message          traff...
Two-tier C/S architectures – 2/2    Recurrent problem:         Business and presentation logic are not clearly separate ...
Design pattern: dispatcher    Context: a set of servers    Problem: A client should not need to know where     servers a...
Three-tier architectures – 1/6    Early 90’s; they propose a clear separation among logics:         Tier 1: data managem...
Three-tier architectures – 2/6    Tiers 1 and 3 do not communicate, i.e.:         The user interface neither receives an...
Three-tier architectures – 3/6                                 64
Three-tier architectures – 4/6    Benefits:         They leverage the flexibility of and the high modifiability         ...
Three-tier architectures – 5/6    Pitfalls:         Application dimensions and efficiency:               Heavy network ...
Three-tier architectures – 6/6    Tiers are logical abstractions, not physical entities         Three-tier architectures...
N-tier architectures    They provide high flexibility    Fundamental items:         User Interface (UI): e.g., a browse...
Example N-tiers                  69
Model/View/Controller style
MVC      71
The MVC style    Three kinds of subsystems:         Model, which has the knowledge about the application          domain...
MVC goal    The goal of MVC is, by decoupling models and     views, to reduce the complexity in architectural     design ...
Basic interaction for MVC                            74
Initialization for MVC                         75
MVC interactions                   76
MVC: component diagram example                                 77
MVC Architectures    The Model does not depend on any View and/or     Controller    Changes to the Model state are commu...
MVC: An example                      Two different views of a                       file system:                      Th...
MVC: communication diagram    1. Both InfoView and FolderView subscribe the changes to the model File     when created  ...
ClientServer 3-tiers vs MVC    The CS 3-tiers style may seem similar to the     model-view-controller (MVC) style; howeve...
MVC vs tiers               82
The benefits of the MVC style    The main reason behind the separation (Model,     View and Controller) is that the user ...
Alternatives to MVC                      84
Service-Oriented style        (SOA)
A world of services                      86
The service-oriented architecture model                                      87
SOA, web service style (use cases)                                     88
Service-oriented architectures    SOAs represent an evolution of client-server     architectures    3rd generation of di...
Service-oriented architectures    Service-oriented architecture (SOA) is an     approach to loosely coupled, protocol    ...
Service-oriented architectures    The following principles define the rules for     development, maintenance, and usage o...
Service computing: layered style                                   92
SOA layers, IBM style                        93
SOA principles – 1/2    Service encapsulation - Many web-services are     consolidated to be used under the SOA Architect...
SOA principles – 2/2    Service reusability - Logic is divided into services     with the intention of promoting reuse  ...
SOA building blocks – 1/2    Service Consumer (also known as Service     Requestor): it locates entries in the Registry u...
Interaction: State diagram                             97
SOA building blocks – 2/2        Service registration (provider) and lookup (requestor) in the         registry        S...
SOA model    1   Service Consumer    2   Service Provider    3   Service Registry    4   Service Contract    5   Serv...
SOA in UML             100
SOA elements               101
SOA characteristics    The software components in a SOA are services     based on standard protocols    Services in SOA ...
Service granularity    Service granularity refers to the scope of     functionality a service exposes    Fine-grained se...
Service compositionJeff Hanson, Coarse-grained Interfaces Enable Service Composition in SOA, JavaOne, August 29, 2003     ...
Web Services    A W3C standard defining an API accessed via     HTTP and executed on a remote host    Definition:      ...
WS underlying technologies    The basic standards for     web services are:         XML (Extensible Markup          Lang...
SOA-related standards    XML 1.0 fairly stable, although Schema are in the     process of replacing DTDs (currently Schem...
Web Services Architecture    Web Services involve three major roles         Service Provider         Service Registry  ...
Use cases for Web services                             109
Service publication    In order for someone to use your service they have     to know about it    To allow users to disc...
WSDL       111
Making a service available    Once you have published a description of your     service you must have a host set up to se...
WS and existing protocols    Web services are layered on top of existing, mature     transfer protocols    HTTP, SMTP ar...
WS and XML    All Web Services documents are written in XML    XML Schema are used to define the elements used     in We...
WS and SOAP    SOAP is the protocol actually used to communicate     with the Web Service    Both the request and the re...
WSDL    Describes the Web Service and defines the     functions that are exposed in the Web Service    Defines the XML g...
WS and UDDI    UDDI is used to register and look up services with     a central registry    Service Providers can publis...
Web Services and SOAs    Web Services are an open standards-based way of     creating and offering SOAs    Web Services ...
Re-architecture to SOA: benefits    Provides location independence: Services need not be associated with     a particular...
Why not SOA    For a stable or homogeneous enterprise IT     environment, SOA may not be important or cost     effective ...
Cloud computing    Software as a service, like Web services    Platform as a service, like mashups    Infrastructure as...
Peer-to-peer style       P2P
Peer-to-peer architectures    They can be considered a generalization of the     client/server architecture    Each subs...
Peer-to-peer architectures    In such an architecture, all nodes have the same     abilities, as well as the same respons...
Peer-to-peer architectures    Typical functional characteristics of P2P systems         File sharing system         Fil...
P2P architectures: brief history    Although they were proposed 30 years ago, they     mainly evolved in the last decade...
The phases of a P2P applicationA P2P application is organized in three phases:      Boot, during which a peer connects to...
P2P classification – 1/2    P2P applications can be categorized as follows:         Pure P2P applications              ...
P2P classification – 2/2    With respect to lookup phase:         Centralized Lookup               Centralized index of...
Napster
Gnutella (original)
Gnutella           132
Gnutella: search                   133
Gnutella: reply                  134
Skype
Skype    A mixed client-server and peer-to-peer architecture addresses     the discovery problem    Replication and dist...
P2P: scalability – 1/2    The performances of a P2P system (e.g., the time     to find a file) become worse as the number...
P2P: scalability – 2/2    The degree of scalability of a given protocol     depends on the efficiency of the adopted rout...
Summary    The basic architectural styles are few and their     properties should be studied and exploited    Their desc...
Self test questions    Describe an example application architecture for     each of the following styles: pipe-and-filter...
References    Taylor et al., Software Architecture, Wiley 2009    Qian et al., Software Architecture and Design Illumina...
Useful sites    www.softwarearchitectureportal.org!    www.dossier-andreas.net/software_architecture/!    www.bredemeye...
Questions?"We are searching for some kind ofharmony between two intangibles: a formwhich we have not yet designed and acon...
Upcoming SlideShare
Loading in...5
×

3 - Architetture Software - Architectural styles

6,773

Published on

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
6,773
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
199
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

3 - Architetture Software - Architectural styles

  1. 1. Architectural styles Paolo Ciancarini
  2. 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 2
  3. 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) 3
  4. 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 4
  5. 5. Layers of virtual machines 5
  6. 6. Layers: component diagram  Connectors for layered systems are often procedure calls  Each level implements a different VM with a specific input language 6
  7. 7. 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. 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) C1 C1 C1 attr attr attr VM1 op op op C1 C1 attr attr VM2 op op C1 C1 attr attr VM3 op op C1 C1 attr attr VM4 op op 8
  9. 9. Closed layers: ISO/OSI stackThe ISO/OSI reference Applicationmodel defines 7 networklayers, characterized by an Presentationincreasing level of Level of abstraction SessionabstractionEg. The Internet Protocol Transport(IP) defines a VM at thenetwork level able to identify Networknet hosts and transmitsingle packets from host to DataLinkhost Physical 9
  10. 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 C1 C1 attr attr attr op op op C1 C1 attr attr op op C1 C1 attr attr op op C1 C1 attr attr op op 10
  11. 11. Open layers: OSF/Motif Application Motif Xt XlibXlib 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
  12. 12. Creating layers: façade 12
  13. 13. Creating layers: façade 13
  14. 14. Tiers  Another approach to managing complexity consists of partitioning a system into sub-systems (peers), which are responsible for a class of services 14
  15. 15. 15
  16. 16. Typical tiered architecture 16
  17. 17. 4 tiers architecture 17
  18. 18. 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. 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 19
  20. 20. Architectural variants
  21. 21. Pipes and Filters style
  22. 22. 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 This architecture style focuses on the dynamic (interaction) rather than the structural pipe
  23. 23. Batch sequential data flow Rejected transaction -123 U Validated SortedTransaction File transaction transaction 222 U 222 U 111 I 111 I Validate 111 I sort 222 U 333 D 333 D 333 D -123 U 100 ---- Update 111 ---- 200 ---- 222 ---- Generate Report 444 ---- Reports 100 --- Updated 200 --- Master file 222 --- 333 --- 444 --- Master file 23
  24. 24. 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 afterwardsExample : counting occurrences in a fileI have a mailinglist file called “swarch.txt” Note the pipecat swarch.txt | grep studio | wc symbol, l
  25. 25. 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?
  26. 26. 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 Prepare for Process Checks time cards Check processing Problems that require batch file processing seem to fit this: payroll and compilers
  27. 27. 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 Splitting the good time cards from the bad ones Validate for payroll processing Manually Reprocess Automatically Card and Cut Check Process Checks Do the data streams Payroll report need to be synchronized here for report?
  28. 28. Pipes and filters  Pipe: communication channel  Filter: computing component   Filter 1 may only send data to Filter 2 Filter 1 Pipe Filter 2   Filter 2 may only receive data from Filter 1 (Source) (Sink)   Filter 1 may not receive data   Filter 2 may not send data   Pipe is the data transport mechanism * input output 1 Filter Pipe * output input 1 +Read() +Write()
  29. 29. Pipe and Filter Class Diagram Pipe Filter +Read() +Write() Data Source Data Sink +read() +write()
  30. 30. Pipe and Filter Sequence Diagramdata source: filter1: pipe: filter2: data sink:Data Source Filter pipe Filter Data Sink read Filter1 W Filter2 R write Data Source Filter1 Filter2 Data Sink pipe
  31. 31. Data flow typesThere 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
  32. 32. 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
  33. 33. Pipe and Filter Sequence Diagram active passive active Pull only Pull /push Pull / push Pull /push Push only data source Filter 1 Pipe Filter 2 data sink R ead R ead ( blocking ) Wr ite R ead R ead Wr ite Wr ite R ead
  34. 34. “Architectural” package diagram UML <<metaclass>> <<metaclass>> Component Connector Pipes&filters <<stereotype>> <<stereotype>> Filter Pipe 34
  35. 35. Component diagram<<pipe>> <<pipe>> <<pipe>> <<pipe>> <<pipe>> <<pipe>> <<pipe>> <<pipe>> <<filter>> <<filter>> <<filter>> <<filter>><<component>> <<component>> <<component>> <<component>> pic eqn tbl troff 35
  36. 36. 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.
  37. 37. Repository-based style
  38. 38. 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) Physician Lab testing diagnosis Patient database Accounting Pharmacy & & administration drug processing 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
  39. 39. Repository Architecture Agent 2 Agent 1 Repository Agent 3Agent 4 Agent n 39
  40. 40. 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 Repository Subsystem createData() setData() getData() searchData()
  41. 41. Example: a compiler architecture based on a repository Compiler SemanticAnalyzer SyntacticAnalyzer Optimizer LexicalAnalyzer CodeGenerator Repository ParseTree SymbolTable SourceLevelDebugger SyntacticEditor 41
  42. 42. Repository: two flavorsData-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
  43. 43. 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
  44. 44. publish/subscribe 44
  45. 45. Observer pattern 45
  46. 46. Publish subscribe variants 46
  47. 47. 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. 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 48
  49. 49. Client-Server style
  50. 50. Client server remote remote remote 50
  51. 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 51
  52. 52. Client-server paradigm  The first generation of distributed systems was based on the client server style 2nd Generation Distributed Objects 1st Generation Client/Serverdistribution MainframeDegree of Monolithic Complexity & adaptability 52
  53. 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 Server Client * * requester! provider! service1() service2() serviceN() 53
  54. 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 Application Data Presentation processing management 54
  55. 55. Client-server style  2 tiers Client/Server architectures Fat server Fat client 55
  56. 56. 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 Web browser 2. A series of Web server 1.tubes DNS server   By convention, servers listen on TCP port 80 (HTTP) or 443 (HTTPS)  Universal Resource Identifier (URI) format: scheme, host, port, resource, parameters, fragmenthttp://search.com:80/img/search/file?t=banana&client=firefox#p2 56
  57. 57. A Conversation With a Web ServerGET /index.html HTTP/1.0User-Agent: Mozilla/4.73 [en] (X11;HTTP method & URIi686) U; Linux 2.0.35Host: www.yahoo.comAccept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*Accept-Language: enAccept-Charset: iso-8859-1,*,utf-8  Server replies:HTTP/1.0 200 OK Cookie data: up toContent-Length: 16018 4KiBSet-Cookie: B=2vsconq5p0h2nContent-Type: text/html MIME content type<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"> 57
  58. 58. 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. 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 59
  60. 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 60
  61. 61. 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 Client request service Server do_task run_service Dispatcher Location_map request establish locate_Server connection connection 61
  62. 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 62
  63. 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 63
  64. 64. Three-tier architectures – 3/6 64
  65. 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 65
  66. 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 66
  67. 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 67
  68. 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 68
  69. 69. Example N-tiers 69
  70. 70. Model/View/Controller style
  71. 71. MVC 71
  72. 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 initiator Controller * 1 repository Model 1 notifier subscriber View * 72
  73. 73. 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
  74. 74. Basic interaction for MVC 74
  75. 75. Initialization for MVC 75
  76. 76. MVC interactions 76
  77. 77. MVC: component diagram example 77
  78. 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 78
  79. 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 79
  80. 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 way2.User types new filename :Controller 3. Request name change in model 1. Views subscribe to event :Model5. Updated views :InfoView 4. Notify subscribers :FolderView 80
  81. 81. ClientServer 3-tiers vs MVC  The CS 3-tiers style may seem similar to the model-view-controller (MVC) style; 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. 82. MVC vs tiers 82
  83. 83. 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 83
  84. 84. Alternatives to MVC 84
  85. 85. Service-Oriented style (SOA)
  86. 86. A world of services 86
  87. 87. The service-oriented architecture model 87
  88. 88. SOA, web service style (use cases) 88
  89. 89. Service-oriented architectures  SOAs represent an evolution of client-server architectures  3rd generation of distributed software systems Distribution degree and mobility 1st generation 2nd generation 3rd generation SOAs Distributed objects C3 C1 C2 C4 C5 client-server 3 levels Distributed components 2 levels Complexity 89
  90. 90. 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 90
  91. 91. 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 91
  92. 92. Service computing: layered style 92
  93. 93. SOA layers, IBM style 93
  94. 94. 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 94
  95. 95. 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 95
  96. 96. 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 96
  97. 97. Interaction: State diagram 97
  98. 98. SOA building blocks – 2/2   Service registration (provider) and lookup (requestor) in the registry   Service access SERVICE Service lookup REGISTRY Service registration SERVICE SERVICE REQUESTOR PROVIDER Service access PDA Laptop Desktop Computer 98
  99. 99. SOA model  1 Service Consumer  2 Service Provider  3 Service Registry  4 Service Contract  5 Service Proxy  6 Service Lease 99
  100. 100. SOA in UML 100
  101. 101. SOA elements 101
  102. 102. 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 102
  103. 103. 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. 103
  104. 104. Service compositionJeff Hanson, Coarse-grained Interfaces Enable Service Composition in SOA, JavaOne, August 29, 2003 104
  105. 105. 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 105
  106. 106. 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) 106
  107. 107. 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 107
  108. 108. 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 108
  109. 109. Use cases for Web services 109
  110. 110. 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 110
  111. 111. WSDL 111
  112. 112. 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). 112
  113. 113. 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 113
  114. 114. WS and XML  All Web Services documents are written in XML  XML Schema are used to define the elements used in Web Services communication 114
  115. 115. 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 115
  116. 116. 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 116
  117. 117. 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 117
  118. 118. 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 118
  119. 119. 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 119
  120. 120. 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 120
  121. 121. Cloud computing  Software as a service, like Web services  Platform as a service, like mashups  Infrastructure as a service (or hardware as a service) 121
  122. 122. Peer-to-peer style P2P
  123. 123. 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 requester * service1() service2() * … serviceN() provider 123
  124. 124. 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 124
  125. 125. Peer-to-peer architectures  Typical functional characteristics of P2P systems   File sharing system   File storage system   Distributed file system   Redundant storage   Distributed computation  Typical non-functional requirements   Availability   Reliability   Performance   Scalability   Anonymity 125
  126. 126. 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, Gnutellas 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 126
  127. 127. The phases of a P2P applicationA P2P application is organized in three phases:   Boot, during which a peer connects to the network and actually performs the connections (P2P boot is rare)   Lookup, during which a peer looks for a provider of a given service or information (generally providers are SuperPeers)   Resource sharing, during which requested resources are delivered, usually in several segments 127
  128. 128. 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. 128
  129. 129. 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 129
  130. 130. Napster
  131. 131. Gnutella (original)
  132. 132. Gnutella 132
  133. 133. Gnutella: search 133
  134. 134. Gnutella: reply 134
  135. 135. Skype
  136. 136. 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
  137. 137. 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 … 137
  138. 138. 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 138
  139. 139. Summary  The basic architectural styles are few and their properties should be studied and exploited  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 139
  140. 140. Self test questions  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? 140
  141. 141. 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/
  142. 142. 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!
  143. 143. Questions?"We are searching for some kind ofharmony between two intangibles: a formwhich we have not yet designed and acontext which we cannot properlydescribe.” Christopher Alexander
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×