Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.



Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this


  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 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
  30. 30. Pipe and Filter Sequence Diagram
  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
  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, fragment 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: 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=> …etc.  Repeat for embedded content (images, stylesheets, scripts...) <img width=230 height=33 src=""> 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 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. 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 82
  83. 83. Service-Oriented style (SOA)
  84. 84. A world of services 84
  85. 85. The service-oriented architecture model 85
  86. 86. SOA, web service style (use cases) 86
  87. 87. 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 87
  88. 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 88
  89. 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 89
  90. 90. Service computing: layered style 90
  91. 91. SOA layers, IBM style 91
  92. 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 92
  93. 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 93
  94. 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 94
  95. 95. Interaction: State diagram 95
  96. 96. 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 96
  97. 97. SOA model  1 Service Consumer  2 Service Provider  3 Service Registry  4 Service Contract  5 Service Proxy  6 Service Lease 97
  98. 98. SOA in UML 98
  99. 99. SOA elements 99
  100. 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 100
  101. 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. 101
  102. 102. Service compositionJeff Hanson, Coarse-grained Interfaces Enable Service Composition in SOA, JavaOne, August 29, 2003 102
  103. 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 103
  104. 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) 104
  105. 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 105
  106. 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 106
  107. 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 107
  108. 108. WSDL 108
  109. 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). 109
  110. 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 110
  111. 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 111
  112. 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 112
  113. 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 113
  114. 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 114
  115. 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 115
  116. 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 116
  117. 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 117
  118. 118. 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
  119. 119. Peer-to-peer style P2P
  120. 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 requester * service1() service2() * … serviceN() provider 120
  121. 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 121
  122. 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 122
  123. 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, 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 123
  124. 124. The phases of a P2P applicationA 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 124
  125. 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. 125
  126. 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 126
  127. 127. Napster
  128. 128. Gnutella (original)
  129. 129. Gnutella 129
  130. 130. Gnutella: search 130
  131. 131. Gnutella: reply 131
  132. 132. Skype
  133. 133. 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. 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 … 134
  135. 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 135
  136. 136. 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
  137. 137. 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? 137
  138. 138. 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
  139. 139. Useful sites!!!!!!
  140. 140. Questions?