Software Architecture Shared data University of Oviedo Constraints Components interact with the global state Components don't communicate between each other Only through shared state Shared repository handles data stability and consistency School of Computer Science
Software Architecture Shared data University of Oviedo Challenges Advantages Unique point of failure Independent A failure in the central components repository can affect the whole system They don't need to be Distributing the central data aware of the can be difficult existence of other Possible bottleneck components Inefficient communication Data consistency Problems for scalability Centralized global state School of Computer Science Synchronization to access shared memory Unique Backup of all the system state
Software Architecture Shared data University of Oviedo Applications Lots of systems use this approach Some variants This style is also known as: Shared Memory, Repository, Shared data, etc. Blackboard Rule based systems School of Computer Science
Software Architecture Blackboard University of Oviedo Complex problems which are difficult to solve Knowledge sources solve parts of the problem Each knowledge source aggregates partial solutions to the blackboard Blackboard School of Computer Science Knowledge Knowledge Knowledge Control Source Source Source ...
Software Architecture Blackboard University of Oviedo Elements Blackboard : Central data repository Knowledge source: solves part of the problem and aggregates partial results Control: Manages tasks and checks the work state Blackboard School of Computer Science Knowledge Knowledge Knowledge Control source source source ...
Software Architecture Blackboard University of Oviedo Constraints Problem can be divided in parts Each knowledge source solves a part of the problem Blackboard contains partial solutions that are improving Blackboard School of Computer Science Knowledge Knowledge Knowledge Control source source source ...
Software Architecture Blackboard University of Oviedo Challenges Advantages Debugging Experimentability No warranty that the right Can be used for open solution will be found problems Difficult to establish control strategy Facilitates strategy Performance changes It may need to review Reusability incorrect hypothesis Knowledge sources High development cost can be reused Parallelism implementation School of Computer Science It is necessary to synchronize Fault tolerance blackboard access
Software Architecture Blackboard University of Oviedo Applications Some speech recognition systems HEARSAY-II Pattern recognition Weather forecasts Games Analysis of molecular structure Crystalis School of Computer Science
Software Architecture Rule based systems University of Oviedo Variant of shared memory Shared memory = Knowledge base Contains rules and facts Knowledge base Rules + facts User Interface School of Computer Science Inference Engine
Software Architecture Rule based systems University of Oviedo Elements: Knowledge base: Rules and facts about some domain User interface: Queries/modifies knowledge base Inference engine: Answers queries from data and knowledge base Knowledge base School of Computer Science Rules + facts User Interface Inference Engine
Software Architecture Rule based systems University of Oviedo Constraints: Domain knowledge captured in knowledge base Limit imperative access to knowledge base It is based on rules like: IF antecedents THEN consequent Limits expressiveness with regards to imperative languages Knowledge base School of Computer Science Rules + facts User Interface Inference Engine
Software Architecture Rule based systems University of Oviedo Challenges Advantages Maintainability Debugging It may be easy to modify Performance the knowledge base Rules creation and Specially tailored to be maintenance modified by domain Introspection experts Separation of concerns Automatic rule learning Algorithm Runtime update of School of Computer Science Domain knowledge rules Reusability
Software Architecture Rule based systems University of Oviedo Applications Expert system Production systems Rules libraries in Java JRules, Drools, JESS Declarative, rule based languages Prolog (logic programming) BRMS (Business Rules Management Systems) School of Computer Science
Software Architecture University of Oviedo Call-return Client-Server Event based architectures Publish-Subscribe Actor models School of Computer Science
Software Architecture Call-return University of Oviedo A component calls another component and waits for the answer School of Computer Science call Component A Component B return
Software Architecture Call-return University of Oviedo Elements Component that does the call Component that sends the answer Constraints Synchronous communication: The caller waits for the answer School of Computer Science call Componente A Componente B return
Software Architecture Call-return University of Oviedo Advantages Easy to implement Challenges Problems for concurrent computation If component is blocked waiting for the answer It can be using unneeded resources Distributed environments Little utilization of computational capabilities School of Computer Science
Software Architecture Client-Server University of Oviedo Variant of layers 2 layers physically separated (2-tier) Functionality is divided in several servers Clients connect to services Interface request/response Network request School of Computer Science response server client
Software Architecture Client-Server University of Oviedo Elements Server: offers services through a query/answer protocol Client: does queries and process answers Network protocol: communication management between clients and servers Network request School of Computer Science response server client
Software Architecture Client-Server University of Oviedo Constraints Clients communicate with servers Not the other way Clients are independent from other clients Servers don't have knowledge about clients Network protocol establishes some communication warranties Network request School of Computer Science response server client
Software Architecture Client-Server University of Oviedo Challenges Advantages Each server can be a single Distribution point of failure Servers can be distributed Server attacks Low coupling Unpredictable performance Separation of functionality Dependency on the system between clients/servers and the network Independent development Problems when servers belong to other Scalability organizations School of Computer Science Availability How can quality of service Functionality available to all be warranted? clients But not all the servers need to offer all functionality
Software Architecture Client-Server University of Oviedo Variants Stateless Replicated server With cache School of Computer Science
Software Architecture Client-Server stateless University of Oviedo Constraint Server does not store information about clients Same query implies same answer Network query School of Computer Science answer server client
Software Architecture Client-Server stateless University of Oviedo Advantages Scalability Challenges Application state management Client must remember requests Handle information between requests School of Computer Science
Software Architecture Replicated server University of Oviedo Constraint Several servers offer the same service Offer the client the appearance that there is only one server Network query server School of Computer Science Abstract Server server answer client server
Software Architecture Replicated server University of Oviedo Advantages Better answer times Less latency Fault tolerance Challenges Consistency management between replicated servers Synchronization School of Computer Science
Software Architecture Client-server with cache University of Oviedo Cache = mediator between client/server Stores copies of previous answers to the server When a query is received it return the cached answer without asking the original server Network query School of Computer Science Cache answer server client
Software Architecture Client-server with cache University of Oviedo Elements: Intermediate cache nodes Constraints Some queries are directly answered by the cache node Cache node has a policy for answer management Expiration time School of Computer Science
Software Architecture Client-server with cache University of Oviedo Challenges Advantages: Complexity of Less network configuration overload Expiration policy Lots of repeated requests can be Not appropriate for certain stored in the cache domains Less answer time When high fidelity of Cached answers answers is needed School of Computer Science arrive earlier Example: real time systems
Software Architecture Event based University of Oviedo EDA (Event-Driven-Architecture) Event Event Event Consumer Producer Processor School of Computer Science event event
Software Architecture Event based University of Oviedo Elements: Event: Something that has happened (≠ request) Event producer Event generator (sensors, systems, ...) Event consumer DB, applications, scorecards, ... Event processor School of Computer Science Transmission channel Filters and transforms events Event Event Event Consumer Producer Processor event event
Software Architecture Event based University of Oviedo Constraints: Asynchronous communication Producers generate events at any moment Consumers can be notified of events at any moment Relationship one-to-many An event can be sent to several consumers School of Computer Science
Software Architecture Event based University of Oviedo Challenges Advantages Decoupling Non sequential execution Producer does not Possible lack of control depend on consumer, Difficult to debug nor vice versa. Timelessness Events are published without any need to wait for the termination of any cycle School of Computer Science Asynchronous In order to publish an event there is no need to finish any process
Software Architecture Event based University of Oviedo Applications Event processing networks Event-Stream-Processing (ESP) Complex-event-processing Variants Publish-subscribe Actor models School of Computer Science
Software Architecture Publish-subscribe University of Oviedo Components subscribe to a channel to receive messages from other components Component Component Component School of Computer Science Event Bus Subscribe Port Component Component Publish Port
Software Architecture Publish-subscribe University of Oviedo Elements: Component: Component that subscribes to a channel Publication port It is registered to publish messages Subscription port It is registered to receive some kind of messages Event bus (message channel): Transmits messages to subscribers School of Computer Science Component Component Component Event Bus Subscribe Port Component Component Publish Port
Software Architecture Publish-subscribe University of Oviedo Constraints: Separation between subscription/publication port A component may have both ports Non-direct communication Asynchronous communication in general Components delegate communication responsibility to the channel School of Computer Science Component Component Component Event Bus Subscribe Port Component Component Publish Port
Software Architecture Publish-subscribe University of Oviedo Challenges Advantages It adds a new indirection Communication quality level Improves performance Direct communication Debugging may be more efficient in Low coupling between some domains components Complex implementation Consumers do not It may require COTS depend on publishers School of Computer Science ...nor vice versa...
Software Architecture Actor models University of Oviedo Used for concurrent computation Actors instead of objects There is no shared state between actors Asynchronous message passing Theoretical developments since 1973 (Carl Hewitt) School of Computer Science
Software Architecture Actor models University of Oviedo Elements Actor: computational entity with state It communicates with other actors sending messages It process messages one by one Messages Addresses: Identify actors ( mailing address ) School of Computer Science
Software Architecture Actor models University of Oviedo Constraints An actor can only: Send messages to other actors Messages are immutable Create new actors Modify how it will process next message Actors are decoupled Receiver does not depend on sender School of Computer Science
Software Architecture Actor models University of Oviedo Constraints (2) Local addresses An actor can only send messages to known addresses Because they were given to it or because he created them Parallelism: All actions are in parallel No shared global state Messages can arrive in any order School of Computer Science
Software Architecture Actor models University of Oviedo Advantages Challenges Highly parallel Message sending Transparency and How to handle arriving scalability messages Internal vs external Actor Coordination addresses Non-consistent systems Non-local actor models by definition Web Services School of Computer Science Multi-agent systems
Software Architecture Actor models University of Oviedo Implementations Erlang (programming language) Akka (library) Applications Reactive systems Examples: Ericsson, Facebook, twitter School of Computer Science
Software Architecture University of Oviedo Broker Peer-to-peer MapReduce Lambda arquictecture Kappa architecture School of Computer Science Network
Software Architecture Broker University of Oviedo Intermediate node that manages communication between a client and a server Client Broker Server stub skeleton School of Computer Science bridge Client Broker Server stub skeleton
Software Architecture Broker University of Oviedo Elements Broker Manages communication Client: Sends requests Client Proxy: stub Server: Returns answers Server Proxy: skeleton Bridge: Can connect brokers School of Computer Science Client Broker Server stub skeleton bridge
Software Architecture Broker University of Oviedo Advantages Challenges Separation of concerns Performance Delegates low level Adds an indirection layer communication aspects Can increase coupling to the broker Separate maintenance between components Reusability Broker = single point of Servers are independent failure from clients Portability Broker = low level aspects School of Computer Science Interoperability Using bridges
Software Architecture Broker University of Oviedo Applications CORBA and distributed systems Android uses a variation of Broker pattern School of Computer Science
Software Architecture University of Oviedo Peer-to-Peer Equal and autonomous nodes ( peers ) that communicate between them. Peer Peer Peer Network School of Computer Science Peer Peer Peer
Software Architecture Peer-to-Peer University of Oviedo Elements Computational nodes: peers They contain their own state and control thread Network protocol Constraints There is no main node All peers are equal School of Computer Science
Software Architecture Peer-to-Peer University of Oviedo Challenges Advantages Keeping the state of Decentralized information the system and control Complexity of the Fault tolerance protocol There is no single point of Bandwidth Limitations failure Network and protocol A failure in one peer does latency not compromise the School of Computer Science Security whole system Detect malicious peers
Software Architecture Peer-to-Peer University of Oviedo Popular applications Napster, BitTorrent, Gnutella, ... This architecture style is not only to share files e-Commerce (B2B) Collaborative systems Sensor networks Blockchain ... School of Computer Science Variants Super-peers
Software Architecture MapReduce University of Oviedo Proposed by Google Published in 2004 Internal implementation by Google Goal: big amounts of data Lots of computational nodes Fault tolerance Map Reduce Write-once, read-many Style composed of: Master-slave School of Computer Science Batch Result Big Data
Software Architecture MapReduce University of Oviedo Elements Master node: Controls execution Node table It manages replicated file system S lave nodes Execute mappers, reducers Map Reduce Contain replicated data blocks School of Computer Science Result Big Data
Software Architecture MapReduce - Scheme University of Oviedo Inspired by functional programming 2 components: mapper and reducer Data are divided for their processing Each data is associated with a key Transforms [(key1,value1)] to [(key2,value2)] c2 v2 School of Computer Science v1 c1 Input: c2 v2 Output: MapReduce v1 c1 [(key1,value1)] [(key2,value2)] c2 v2 v1 c1 c2 v2
Software Architecture Step 1: mapper University of Oviedo mapper: (Key1, Value1) [(Key2,Value2)] v1 k1 mapper vi1 c1 v2 k2 v3 k1 mapper vi2 v4 c2 k3 School of Computer Science v5 k1 v6 k1 mapper vi3 c3 v7 k3
Software Architecture Step 2: Merge and sort University of Oviedo System merges and sorts intermediate results according to the keys k1 v1 v1 v6 k1 v3 v5 k2 v2 k1 v3 Merge and k3 v4 v2 k2 sort School of Computer Science k1 v5 k1 v6 k3 v4 v7 k3 v7
Software Architecture University of Oviedo Step 3: Reducers reducer: (Key2, [Value2]) (Key2,Value2) k1 v1 v3 v5 v6 reducer k1 vf1 reducer k2 v2 k2 vf2 School of Computer Science k3 vf3 k3 v4 v7 reducer
Software Architecture MapReduce - general scheme University of Oviedo v1 k1 reducer k1 v1 v3 v5 v6 k1 vf1 mapper c1 vi1 v2 k2 v3 k1 Merge and reducer mapper v4 c1 vi1 k3 k2 v2 k2 vf2 sort v5 k1 v6 k1 k3 vf3 reducer k3 v4 v7 mapper c1 vi1 School of Computer Science v7 k3 MapReduce
Software Architecture MapReduce - count words University of Oviedo a 1 reducer 1 1 a 4 a 1 1 mapper d1 a b b 1 a 1 Mezcla reducer mapper y d2 a c a c 1 1 b 1 b ordena a 1 c a 1 2 reducer c 1 1 mapper d3 a c c 1 MapReduce School of Computer Science // return each work with 1 // sum the list of numbers of each word mapper(d,ps) { reducer(p,ns) { for each p in ps: sum = 0 emit (p, 1) for each n in ns { sum += n; } } emit (p, sum) }
Software Architecture University of Oviedo MapReduce - execution environment Execution environment is in charge of: Planning: Each job is divided in tasks Placement of data/code Each node contains its data locally Synchronization: reduce tasks must wait map phase Error and failure handling High tolerance to computational nodes failures School of Computer Science
Software Architecture MapReduce - File system University of Oviedo Google developed a distributed file system - GFS Hadoop created HDFS Files are divided in chunks 2 node types: Namenode (master), datanodes (data servers) Datanodes store different chunks Block replication Namenode contains metadata Where is each chunk School of Computer Science Direct communication between clients and datanodes
Software Architecture MapReduce - File system University of Oviedo Master Namenode file1: (B1 – N1 N2, B2 – N1 N2 N3) Client1 file2: (B3 – N2 N3, B4 – N1 N2) file3: (B5 – N1 N3) Client2 B1 B2 B1 B4 B5 Datanodes Slaves School of Computer Science B5 B4 B2 B3 B3 B2 N1 N2 N3
Software Architecture MapReduce University of Oviedo Challenges Advantages Dependency on master Distributed node computations Non interactivity Split input data Data conversion to Replicated repository Fault tolerant MapReduce Hardware/software Adapt input data heterogeneous Convert output data Large amount of data School of Computer Science Write-once. Read-many
Software Architecture MapReduce: Applications University of Oviedo Lots of applications: Google, 2007, 20petabytes/day, around 100,000 mapreduce jobs/day PageRank algorithm can be implemented as MapReduce Success stories: Automatic translation, similarity, sorting, ... Other companies: last.fm, facebook, Yahoo!, twitter, etc. School of Computer Science
Recommend
More recommend
