Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Software ArchitecturePart II. Software Architecture TaxonomiesLesson 8: Components and connectors
Jose Emilio Labra Gayo
2014
ENEnglish
University of Oviedo
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Styles based on behaviour
Runtime behaviourComponents and connectors
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Main classification
Data flowJob managementInteractionRepositoryInvocationDistributed systemsAdaptable systems
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Data flowBatchPipes & Filters
Pipes & Filters with uniform interface
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Batch
Independent programs are executed sequentially
Data is passed from one program to the next
NoteBatch style can be considered the grandfather of software architectural styles
Stage
Write port
Stage
Stage
ConnectorStage
Read port
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Batch
Elements: Independent executable programs
ConstraintsOutput of one program is linked to input of
the nextA program usually waits for the previous one
to finish its execution
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Batch
AdvantagesLow coupling between componentsRe-configurabilityDebugging
It is possible to debug each input independently
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Batch
ChallengesIt does not offer interactive interfaceRequires external interventionNo support for concurrency
Low throughputHigh latency
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Pipes & Filters
Data flows through pipes and is processed by filters
Filter
Filter
Filter
Pipe
Filter
Filter Filter
Write port
Read port
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Pipes & Filters
ElementsFilter: component that transforms data
Filters can be executed concurrently
Pipe: Takes output data from one filter to the input of another filterProperties: buffer size, data format, interaction
protocol
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Pipes & Filters
ConstraintsPipes connect outputs from one filter to inputs
of other filtersFilters must agree on the exchange format they
admit
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Pipes & FiltersAdvantages
Better understanding of global systemTotal behavior = sum of each filter behavior
Reusability: Filters can be recombined
Evolution and extensibility: It is possible to create/add new filtersIt is possible to substitute old filters by new ones
IndependenceIndependent verification of each filter
PerformanceIt enables concurrent execution of filters
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Pipes & Filters
ChallengesPossible delays in case of long pipesIt may be difficult to pass complex data
structuresNon interactivity
A filter can not interact with its environment
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Pipes & Filters
ApplicationsUnix
who | wc -lJava
Clases java.io (PipedReader, PipedWriter)
Yahoo Pipes
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo Pipes & Filters - uniform
interfaceVariant of Pipes & Filters where filters have
the same interfaceElements
The same as in Pipes & FiltersConstraints
Filters must have a uniform interface
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo Pipes & Filters - uniform
interfaceAdvantages:
Independent development of filtersRe-configurabilityFacilitates system understanding
Challenges:Performance can be affected if data have to
be converted to the uniform interfaceMarshalling
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo Pipes & Filters - uniform
interfaceExamples:
Unix operating systemPrograms with a text input (stdin) and 2 text
outputs (stdout y stderr)Web architecture: REST
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Work organizationMaster-Slave
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Master-Slave
Master divides work in sub-tasksAssigns each sub-task to different nodesThe computational result is obtained as the
combination of the slaves results results
Slave 1 Slave 2
Master
Slave N. . .
Problem
task 1 task 2 task N
Solution
result Nresult 2result 1
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Master-Slave
ElementsMaster: Coordinates executionSlave: does a task and returns the result
ConstraintsSlave nodes are only in charge of the
computationControl is done by the Master node
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Master-Slave
AdvantagesParallel computationFault tolerance
ChallengesDifficult to coordinate work between slavesDependency on Master nodeDependency on physical configuration
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Master-Slave
Applications: Process control systemsEmbedded systemsFault tolerant systemsSearch systems
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Interactive systemsMVC: Model - view - controllerMVC variants
PAC: Presentation - Abstraction - Control
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
MVC
MVC: Model - View - ControllerProposed by Trygve Reenskaug (end of 70's)Solution for GUIController separates model from the view"Mental model" offered through views
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
MVCElements
Model: represents business logic and stateView: Offers state representation to the userController: Coordinates interaction, views and
model
MentalModel
Controller
Model
View 1
View 2
User
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
MVC
ConstraintsController processes user events
Creates/removes viewsHandles interaction
Views only show valuesModels are independent of controllers/views
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
MVC
AdvantagesIt supports multiple views of the same modelViews synchronizationSeparation of concerns
Interaction (controller), state (model)It is easy to create new views and controllersEasy to modify look & feelCreation of generic frameworks
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
MVC
ChallengesIncreases complexity of GUI developmentCoupling between controllers and viewsControllers/Views should depend on a model
interface Some difficulties for GUI tools
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
MVC
ApplicationsLots of web frameworks follow MVC
Ruby on Rails, Spring MVC, Play, etc.Some variants
Push: controllers send orders to viewsRoR
Pull: controllers receive orders from viewsPlay
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
MVC variants
PACModel-View-PresenterModel View ViewModel...
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
PAC
PAC: Presentation-Abstraction-ControlHierarchy of agentsEach agent contains 3 components
PresentationAbstraction Control
PAC Agent
PresentationAbstraction Control
PAC Agent
PresentationAbstraction Control
PAC Agent
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
PAC
ElementsAgents with
Presentation: visualization aspectsAbstraction: data model of an agentControl: connects presentation and abstraction
components and enables communication between agents
Hierarchical relationship between agents
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
PAC
ConstraintsEach agent is in charge of some functionalityThere is no direct communication between
abstraction and presentation in each agentCommunication through the control
component
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
PAC
AdvantagesSeparation of concerns
Identifies functionalitiesSupport for changes and extensions
It is possible to modify an agent without affecting others
MultitaskAgents can reside in different threads,
processes or machines
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
PAC
ChallengesComplexity of the system
Too many agents can generate a complex structure which can be difficult tom maintain
Complexity of control componentsControl components handle communicationQuality of control components is important for
the whole quality of the systemPerformance
Communication overload between agents
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
PAC
ApplicationsNetwork monitoring systemsMobile robotsDrupal is based on PAC
RelationshipsThis patterns is related with MVC
MVC has no agent hierarchyThis pattern was re-discovered as
Hierarchical MVC
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
RepositoryShared dataBlackboardRule based
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Shared data
Independent components access the same stateApplications based on centralized data
repositories
Component Component
SharedData
Component...
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Shared data
ElementsShared data
Database or centralized repositoryComponents
Processors that interact with shared data
Component Component
SharedData
Component...
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Shared data
ConstraintsComponents interact with the global stateComponents don't communicate between each
otherOnly through shared state
Shared repository handles data stability and consistency
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Shared data
AdvantagesIndependent components
They don't need to be aware of the existence of other components
Data consistencyCentralized global stateUnique Backup of all the system state
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Shared data
ChallengesUnique point of failure
A failure in the central repository can affect the whole system
Distributing the central data can be difficultPossible bottleneck
Inefficient communicationProblems for scalability
Synchronization to access shared memory
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Shared data
ApplicationsLots of systems use this approach
Some variantsThis style is also known as:
Shared Memory, Repository, Shared data, etc.BlackboardRule based systems
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Blackboard
Complex problems which are difficult to solveKnowledge sources solve parts of the problemEach knowledge source aggregates partial
solutions to the blackboard
KnowledgeSource
KnowledgeSource
Blackboard
KnowledgeSource ...
Control
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Blackboard
ElementsBlackboard: Central data repositoryKnowledge source: solves part of the problem
and aggregates partial resultsControl: Manages tasks and checks the work
state
Fuente conocimien
to
Fuenteconocimiento
Blackboard
FuenteConocimient
o ...Control
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Blackboard
ConstraintsProblem can be divided in partsEach knowledge source solves a part of the
problemBlackboard contains partial solutions that
are improving
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Blackboard
AdvantagesCan be used for open problems
ExperimentingFacilitates strategy changes
Knowledge source can be reusedSupport for fault tolerance
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Blackboard
ChallengesIt may be difficult to debugNo warranty that the right solution will be
foundIt may be difficult to establish a control
strategyLow performance
Sometimes it may need to review the incorrect hypothesis
High development costImplementation of parallelism
It is necessary to synchronize blackboard access
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Blackboard
ApplicationsSome speech recognition systems
HEARSAY-IIPattern recognitionWeather forecastsGamesAnalysis of molecular structure
Crystalis
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Rule based systems
Variant of shared memoryShared memory = Knowledge base
Contains rules and facts
InferenceEngine
Knowledge base
Rules + factsUser
Interface
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Rule based systems
Elements:Knowledge base: Rules and facts about some
domainUser interface: Queries/modifies knowledge
baseInference engine: Answers queries from data
and knowledge base
InferenceEngine
Knowledge base
Rules + factsUser
Interface
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Rule based systems
Constraints:Domain knowledge captured in knowledge
baseLimit imperative access to knowledge base
It is based on rules like:IF antecedents THEN consequent
Limits expressiveness with regards to imperative languages
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Rule based systems
AdvantagesDeclarative solution
It may be easy to modify the knowledge baseSpecially tailored to be modified by domain
experts
Separation of concernsAlgorithmDomain knowledge
Reusability
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Rule based systems
ChallengesRules Debugging PerformanceRules creation and maintenance
IntrospectionAutomatic rule learningRuntime update of rules
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Rule based systems
ApplicationsExpert systemProduction systems
Rules libraries in JavaJRules, Drools, JESS
Declarative, rule based languagesProlog (logic programming)
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
InvokationCall-returnClient-ServerEvent based architectures
Publish-SubscribeActor models
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Call-return
A component calls another component and waits for the answer
Component A Component B
call
return
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Call-return
ElementsComponent that does the callComponent that sends the answer
ConstraintsSynchronous communication:
The caller waits for the answer
Componente A
Componente B
call
return
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Call-return
AdvantagesEasy to implement
ChallengesProblems for concurrent computation
If component is blocked waiting for the answerIt can be using unneeded resources
Distributed environmentsLittle utilization of computational capabilities
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Client-Server
Variant of layers2 layers physically separated (2-tier)
Functionality is divided in several serversClients connect to services
Interface query/answer
Network
query
answer
clientserver
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Client-Server
ElementsServer: offers services through a
query/answer protocolClient: does queries and process answersNetwork protocol: communication
management between clients and serversNetwork
query
answer
clientserver
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Client-Server
ConstraintsClients communicate with servers
Not the other wayClients are independent from other clientsServers don't have knowledge about clientsNetwork protocol establishes some
communication warranties Network
query
answer
clientserver
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Client-Server
AdvantagesServers can be distributedSeparation of functionality between
clients/serversIndependent developmentScalability
General functionality available for all clientsAlthough not all the servers need to offer all the
functionality
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Client-Server
ChallengesEach server can be a single point of failiure
Server attacksUnpredictable performance
Dependency on the system and the networkProblems when servers belong to other
organizationsHow can quality of service be warranted?
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Client-Server
VariantsStatelessReplicated serverWith cache
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Network
Client-Server stateless
ConstraintServer does not store information about
clientsSame query implies same answer
query
answer
clientserver
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Client-Server stateless
AdvantagesScalability
ChallengesApplication state management
Client must remember requestsSome strategies can be established to handle
information between requests
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Network
Replicated server
ConstraintSeveral servers offer the same service
Offer the client the appearance that there is only one server
query
answerclient
server
server
server
Abstract
Server
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Replicated server
AdvantagesBetter answer timesLess latencyFault tolerance
ChallengesConsistency management between
replicated serversSynchronization
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Client-server with cache
Cache = mediator between client/serverStores copies of previous answers to the
serverWhen a query is received it return the cached
answer without asking the original server
Networkquery
answerclient server
Cache
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Client-server with cache
Elements:Intermediate cache nodes
ConstraintsSome queries are directly answered by the
cache nodeCache node has a policy for answer
managementExpiration time
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Client-server with cache
Advantages:Less network overload
Lots of repeated requests can be stored in the cache
Less answer timeCached answers arrive earlier
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Client-server with cache
ChallengesComplexity of configurationExpiration policyNot appropriate for certain domains
If high fidelity of answers is neededExample: real time systems
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Event based
EDA (Event-Driven-Architecture)
EventProducer
EventProcessor
EventConsumer
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Event based
Elements:Event:
Something that has happened (≠ request)Event producer
Event generator (sensors, systems, ...)Event consumer
DB, applications, scorecards, ...Event processor
Transmission channelFilters and transforms events
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Event based
Constraints:Asynchronous communication
Producers generate events at any momentConsumers can be notified of events at any
momentRelationship one-to-many
An event can be sent to several consumers
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Event based
AdvantagesDecoupling: event producer does not depend
on the consumer, nor vice versa.Timelessness: events are published without
any need to wait for the termination of any cycle
Asynchronous: In order to publish an event there is no need to finish any process
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Event based
ChallengesNon sequential executionDifficult to debug
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Event based
ApplicationsEvent processing networksEvent-Stream-Processing (ESP)Complex-event-processing
VariantsPublish-subscribeActor models
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Publish-subscribe
Components that subscribe to a channel to receive message from other components
Component
Event BusSubscribePort
PublishPort
Component
Component Component
Component
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Publish-subscribe
Elements:Component:
Component that subscribes to a channelPublication port
It is registered to publish messagesSubscription port
It is registered to receive some kind of messages
Event bus (message channel): Transmits messages to subscribers
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Publish-subscribe
Constraints:Separation between subscription/publication
portA component may have both ports
Non-direct communicationAsynchronous communication in generalComponents delegate communication
responsibility to the channel
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Publish-subscribe
AdvantagesCommunication quality
Improves performanceDebugging
Low coupling between componentsConsumers do not depend on publishers...nor vice versa...
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Publish-subscribe
ChallengesIt adds a new indirection level
Direct communication may be more efficient in some domains
Complex implementationIt may require COTS
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Actor modelsUsed for concurrent computation
Actors instead of objectsThere is no shared state between actorsAsynchronous message passing
Theoretical developments since 1973 (Carl Hewitt)
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Actor models
ElementsActor: computational entity with state
It communicates with other actors sending messages
It process messages one by oneMessagesAddresses: Identify actors (mailing address)
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Actor models
ConstraintsAn actor can only:
Send messages to other actorsMessages are immutable
Create new actorsModify how it will process next message
Actors are decoupledReceiver does not depend on sender
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Actor models
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 parallelNo shared global stateMessages can arrive in any order
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Actor models
ChallengesMessage sending
How to handle arriving messagesActor Coordination
Non-consistent systems by definitionTransparency and scalability
Internal vs external addressesNon-local actor models
Web ServicesMulti-agent systems
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Actor models
ImplementationsErlang (programming language)Akka (library)
ApplicationsReactive systemsExamples: Ericsson, Facebook, twitter
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Distributed and network systemsBrokerPeer-to-peerMapReduce
Network
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Broker
Intermediate node that manages communication between a client and a server
Client ServerBrokerstubskeleto
n
Client ServerBrokerstubskeleto
n
bridge
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Broker
ElementsBroker
It manages communicationClient: Sends requests
Client Proxy: stubServer: Returns answers
Server Proxy: skeletonBridge: Can connect brokers
Client ServerBrokerstubskeleto
n
bridge
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Broker
AdvantagesSeparation of concerns
Delegates low level communication aspects to the broker
Separate maintenanceReusability
Servers are independent from clientsPortability
Broker = low level aspectsInteroperability
Using bridges
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Broker
ChallengesPerformance
It adds an indirection layerDirect communication can be quicker
It can generate a high coupling between components
Broker = single point of failure
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Broker
ApplicationsCORBA and distributed systemsAndroid uses a variation of Broker pattern
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Peer-to-Peer
Equal and autonomous nodes (peers) that communicate between them.
Network
Peer
Peer
Peer
Peer
Peer
Peer
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Peer-to-Peer
ElementsComputational nodes: peers
They contain their own state and control thread
Network protocolConstraints
There is no main nodeAll peers are equal
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Peer-to-Peer
AdvantagesDecentralized information and controlFault tolerance
There is no single point of failureA failure in one peer does not compromise the
whole system
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Peer-to-Peer
ChallengesKeeping the state of the system
Complexity of the protocolBandwidth Limitations
Network and protocol latencySecurity
Detect malicious peers
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Peer-to-Peer
Popular applicationsNapster, BitTorrent, Gnutella, ...This architecture style is not only to share
filese-Commerce (B2B)Collaborative systemsSensor networks...
VariantsSuper-peers
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
MapReduce
Proposed by GooglePublished in 2004Internal implementation by Google
Goal: big amounts of dataLots of computational nodesFault toleranceWrite-once, read-many
Style composed of:Master-slave Batch Big
Data
Map Reduce
Result
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
MapReduce
ElementsMaster node: Controls execution
Node tableIt manages replicated file system
Slave nodesExecute mappers, reducersContain replicated data blocks
Big Data
Map Reduce
Result
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
MapReduce - Scheme
INspired by functional programming2 components: mapper and reducer
Data are divided for their processingEach data is associated with a key
Transforms [(key1,value1)] to [(key2,value2)]
c1Input: [(key1,value1)]
v1
c1 v1
c1 v1
Output: [(key2,value2)]
c2 v2
c2 v2
c2 v2
c2 v2
MapReduce
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
MapReduce - Mapper
Type: (clave1, valor1) [(clave2,valor2)]
c1 vi1
c2 vi2
c3 vi3
k1 v1
k2 v2
k1 v3
k3 v4
k1 v5
k1 v6
k3 v7
mapper
mapper
mapper
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
MapReduce - Merge and sort
System merges and sorts intermediate results according to the keys
k1 v1
k2 v2
k1 v3
k3 v4
k1 v5
k1 v6
k3 v7
k1 v1 v3 v5 v6
k2 v2
k3 v4 v7
Mergeand sort
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
MapReduce - Reducer
Type: (clave2, [valor2]) (clave2,valor2)
k1 v1 v3 v5 v6
k2 v2
k3 v4 v7 reducer
reducer
reducer vf1
vf2
vf3
k1
k2
k3
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
MapReduce - general scheme
c1 vi1
c1 vi1
c1 vi1mappe
r
reducer
reducer
reducer vf1
vf2
vf3
k1
k2
k3
mapper
mapper
k1 v1
k2 v2
k1 v3
k3 v4
k1 v5
k1 v6
k3 v7
k1 v1 v3 v5 v6
k2 v2
k3 v4 v7
Mergeand sort
MapReduce
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
MapReduce - count words
d1 a b
d2 a c a
d3 a c
4
1
2
a
b
c
a 1
b 1
a 1
c 1
a 1
a 1
c 1mapper
mapper
mapper
reducer
reducer
reducera 1 1 1 1
b 1
c 1 1
Mezcla y
ordena
MapReduce
// return each work with 1mapper(d,ps) { for each p in ps: emit (p, 1)}
// sum the list of numbers of each wordreducer(p,ns) { sum = 0 for each n in ns { sum += n; } emit (p, sum)}
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo MapReduce - execution
environmentExecution environment is in charge of:
Planning: Each job is divided in tasksPlacement of data/code
Each node contains its data locallySynchronization:
reduce tasks must wait map phaseError and failure handling
High tolerance to computational nodes failures
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
MapReduce - File system
Google developed a distributed file system - GFS
Hadoop created HDFSFiles are divided in chunks2 node types:
Namenode (master), datanodes (data servers)Datanodes store different chunks
Block replicationNamenode contains metadata
Where is each chunkDirect communication between clients and
datanodes
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
MapReduce - File system
Namenode
file1: (B1 – N1 N2, B2 – N1 N2 N3)file2: (B3 – N2 N3, B4 – N1 N2)file3: (B5 – N1 N3)
B1 B1
B4
B4
B5
B5
B3 B3
Client1
Cliente
N1 N2 N3
DatanodesSlaves
B2
B2 B2
Data published by Google (2007)
200+ clusters
Lots of clusters 1000+ machines
Pools with thousands of clients
4+ PB
HW/SW fault tolerance
Master
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
MapReduce - Inverted index
Given a number of documents, obtain a list of words associating each word with the document where it appearsOrder documents according to number of
word appearance
Documento 1En un lugar de la Mancha , de cuyo nombre no quiero acordarme no ha mucho
tiempo que vivía un hidalgo de los de lanza en astillero,
adarga antigua, rocín flaco y galgo corredor. Una olla de
algo más…
InvertedIndex
lugar doc16, doc21, doc23, doc45Mancha doc22, doc2, doc4, doc9, doc11Quijote doc22, doc1, doc2, doc7
. . .
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
MapReduce - Inverted index
Basic scheme of a search engine
P1P1
P1Cacheddocuments
Web crawlin
g
WebIndexing
Index
word1 doc1, doc23, doc4,…word2 doc54,doc23word3 doc1,doc7,d1oc9,doc5...word4 doc7,doc9,doc10…
Query
Search
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo MapReduce - Inverted index
d1 a b
d2 a c a
d3 a c
d2
d1
d2
a
b
c
a d1
b d1
a d2
c d2
a d2
a d3
c d3mapper
mapper
mapper
reducer
reducer
reducera d1 d2 d2 d3
b d1
c d2 d3
Mezcla y
ordena
MapReduce
// return each word with its documentmapper(d,ps) { for each p in ps: emit (p, d)}
// sort list of documentsreducer(p,ds) { ds1 = sort(ds) emit (p, ds1)}
d1 d3
d3
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
MapReduce - Popular songs
Given the listening logs of a music server, obtain the number of times that each song is listenedInspired by last.fm
2/3/2010 9:41 Ana C12/3/2010 9:42 Dani C22/3/2010 9:44 Ana C22/3/2010 10:01 Luis C12/3/2010 10:10 Ana C32/3/2010 10:15 Ana C22/3/2010 10:20 Dani C22/3/2010 10:21 Luis C42/3/2010 10:24 Luis C22/3/2010 10:26 Luis C42/3/2010 10:27 Ana C4
Analyzer
C1 2 listeners, 2 timesC2 3 listeners, 5 timesC3 2 listeners, 2 timesC4 2 listeners, 3 times
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
MapReduce: popular songs9:41 A C1
MapReduce
reducer
reducer
reducer
reducer
C1 2
C2 3
C3 1
C4 2
9:42 D C2
9:44 A C2
10:01 L C1
10:10 A C3
10:15 A C2
10:20 D C2
10:21 L C4
10:24 L C2
10:26 L C4
2
5
3
10:27 A C4
mapper
mapper
mapper
mapper
C1 A
C2 D
C2 A
C1 L
C3 A
C2 A
C2 D
C4 L
C2 L
C4 L
C4 A
C1 A C
C2 D
C3 A
C4 L L
Mezcla y
ordenaA A D L
A
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo MapReduce: Friends in
commonFind the list of friends in common
Inspired by Facebook
Ana Dani Juan LuisDani Ana Juan Luis MarJuan Ana Dani Luis MarLuis Ana Dani Juan MarMar Dani Juan Luis
If Ana visits Juan's page, system should show Dani, Luis
Dani
JuanLuis
Mar
Ana
A D J L
D A J L M
J A D L M
L A D J M
M D J L
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo MapReduce: Friends in
commonA D J L
D A J L M
J A D L M
reducer
reducer
reducer
MapReduce
L A D J M
M D J L
A D D J L
A J D J L
A L D J L
A D A J L M
D J
D L
D M
mapper
mapper
mapper
mapper
D M D J L
J M D J Lmapper
A J A D L M
D J
J L
J M
L M D J L
A L A D J M
D L
J L
L M
A J L M
A J L M
A J L M
A D L M
A D L M
A D L M
A D J M
A D J M
A D J M
reducer
reducer
reducer
reducer
reducer
reducer
A D J L
A J D L
A L D J
D J A L M
D L A J M
D M J L
J L A D M
J M D L
L M D J
A D D J L A J L M
A J D J L A D L M
A L D J L A D J M
D J A J L M A D L M
D L A J L M A D J M
D M A J L M D J L
J L A D L M A D J M
J M A D L M D J L
L M A D J M D J L
Mezcla y
ordena
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
MapReduce: Similarity
From the listening logs, find the number of songs in common between 2 usersInspired by Amazon (similar books),
Facebook (possible friends), etc.It is usual to do several mapReduce jobs
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
MapReduce2
MapReduce: Similarity9:41 A C1
9:42 D C2
9:44 A C2
10:01 L C1
10:10 A C3
10:15 A C2
10:20 D C2
10:21 L C4
10:24 L C2
10:26 L C4
10:27 A C4
A C C1, 1
A D C2, 2
A L C2, 1
A L
mapper
mapperC4, 2
A C C1, 1
A D C2, 2
A L C2 1 C4 2
Mezcla y
ordena
reducer
reducer
reducer
A C 1
A D 2
A L 3
C1 A C
C2 D
C3 A
C4 L L
A A D L
A
MapReduce1
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
MapReduce: Applications
Lots of applications:Google, 2007, 20petabytes/day, around 100,000
mapreduce jobs/dayPageRank algorithm can be implemented as
MapReduceSuccess stories:
Automatic translation, similarity, sorting, ...Other companies: last.fm, facebook, Yahoo!,
twitter, etc.
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
MapReduce: Implementations
Google (internal)Hadoop (open source)CloudMapReduce (based on Amazon
services) Aster Data (SQL)Greenplum (SQL)Disco (Python/Erlang) Holumbus (Haskell)
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo MapReduce:
Libraries/languagesHive (Hadoop): query language inspired by
SQLPig (Hadoop): specific language that can
define data flowsCascading: API that can specify distributed
data flowsFlume Java (Google) Dryad (Microsoft)
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Adaptable SystemsPluginsMicrokernelReflectionInterpreters and DSLMobile codeCode on demand
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
PluginPlugin
Plugins
It allows to extend the system using plugins that add new functionality
Runtimeengine
Base system
Plugin
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Plugins
ElementsBase system:
System that allows pluginsPlugins: Components that can be
added/removed dynamicallyRuntime engine:
Starts, localizes, initializes, executes, and stops plugins
PluginPlugin
Runtimeengine
Base system
Plugin
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Plugins
ConstraintsRuntime engine manages pluginsSystem can add/remove pluginsSome plugins can depend on other plugins
The plugin must declare dependencies and the exported API
PluginPlugin
Runtimeengine
Base system
Plugin
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Plugins
AdvantagesExtensibility
Application can get new functionalities in some ways that were not foreseen by the original developers
PersonalizationApplication can have a small kernel that is
extended on demandPlugin
Plugin
Runtimeengine
Base system
Plugin
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Plugins
ChallengesConsistency
Plugins must be added to the system in a sound way
PerformanceDelay searching/configuring plugins
SecurityPlugins made by third parties can compromise
securityPlugin management and dependencies
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Plugins
ExamplesEclipse Firefox
TechnologiesComponent systems: OSGi
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Microkernel
Identify minimal functionality in a microkernel
Extra functionality is added using internal servers
External server handles communication with other systems
Microkernel
AdapterServidor internoServidor
internoInternalserver
External
serverClient
System
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Microkernel
ElementsMicrokernel: Minimal functionalityInternal server: Extra functionalityExternal server: Offers external APIClient: External application
Adapter: Component that establish communication with external server
Microkernel
AdapterServidor internoServidor
internoInternalserver
External
serverClient
System
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Microkernel
Constraints:Microkernel implements only minimal
functionalityThe rest of the functionality is implemented
using internal serversCommunication with clients by external
servers
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Microkernel
AdvantagesPortability
It is only needed to port the kernelFlexibility and extensibility
Adding new functionality with new internal servers
Security and reliabilityCritical parts of the system are encapsulatedErrors in external parts don't affect the
microkernel
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Microkernel
ChallengesPerformance
A monolithic can be more efficientDesign complexity
Identify components in the microkernelIt may be difficult to separate parts to internal
servers
Unique point of failureIf microkernel fails, the whole system may fail
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Microkernel
ApplicationsOperating systemsGamesEditors
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Reflection
It allows to change the structure and behavior of an application dynamically
Systems that can modify themselves
Base level
Metalevel
Meta-objectProtocol
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Reflection
ElementsBase level: Implements application logicMetalevel: Aspects that can be modifiedMetaobject protocol: Interface that can
modify the metalevel
Base level
Metalevel
Meta-objectProtocol
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Reflection
ConstraintsBase level uses metalevel aspects for its
behaviorAt runtime, it is possible to modify the
metalevel using the metaobject protocol
Base level
Metalevel
Meta-objectProtocol
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Reflection
AdvantagesFlexibility
The system can adapt to changing conditionsIt is not necessary to modify source code or to
stop the execution to change the running system
Base level
Metalevel
Meta-objectProtocol
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Reflection
ChallengesImplementation
Not all the languages enable meta-programming
More difficult to combine with static type systems
PerformanceIt may be necessary to do some optimizations
to limit reflectionSecurity:
Consistency maintenanceBase level
Metalevel
Meta-objectProtocol
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Reflection
ApplicationsMost dynamic languages support reflection
Scheme, CLOS, Ruby, Python, ....Intelligent systemsSelf-modifiable code
Base level
Metalevel
Meta-objectProtocol
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Interpreters and DSLs
Include a domain specific language (DSL) that is interpreted by the system
Context
InterpreterDSL
program
Application
User
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Interpreters and DSLs
ElementsInterpreter: Module that executes the programProgram: Written in the DSL
DSL can be designed so the end user can write programs
Context: Environment where the program is executed
Contexto
Intérprete
Programa
en DSL
Aplicación
Usuario
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Interpreters and DSLs
ConstraintsInterpreter runs the program interacting
with the contextIt is necessary to define a DSL
Syntax (grammar, parsing,...)Semantics (behavior)
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Interpreters and DSLs
AdvantagesFlexibility
Adapt application behavior to user needsUsability
End users can write their own programsAdaptability
Easy to adapt to unforeseen situations
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Interpreters and DSLs
ChallengesDesign of the DSLComplexity of implementation
InterpreterSeparation of context/interpreter
PerformancePossible programs may be not optimal
SecurityHandle wrong programs
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Interpreters and DSLs
Variants:Embedded DSLs
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Embedded DSLs
Embedded DSLsDomain specific languages that are
embedded in general purpose host languagesThis technique is popular in soma languages
like Haskell, Ruby, Scala, etc.Advantages:
Reuse of host language syntaxAccess to libraries and IDEs of host language
ChallengesSeparation between DSL and host language
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Mobile code
Code that is transferred from one machine to anotherSystem A sends a program to be run by system
BSystem B must contain an interpreter for the
language in which the program is written
Network
SystemA
SystemB
Interpreter
program
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Mobile code
ElementsInterpreter: Runs the codeProgram: Program that is transferredNetwork: Transfers the program
Network
SystemA
SystemB
Interpreter
program
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Mobile code
ConstraintsThe program must be run in the receiver
systemThe network protocol transfers the program
Network
SystemA
SystemB
Interpreter
program
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Mobile code
AdvantagesFlexibility and adaptability to new
environmentsParallelism
ChallengesComplexity of implementationSecurity
Network
SystemA
SystemB
Interpreter
program
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Mobile code
VariantsCode on demandRemote evaluationMobile Agents
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Network
Code on demand
Code is downloaded and run by the clientCombination between mobile code and
client-serverExample:
ECMAScript
Client
Program
ServerQuery
InterpreterAnswer
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Code on demand
ElementsClientServerCode that is transferred from server to client
ConstraintsCode resides or is generated by the serverIt is transferred to the client when it asks for
itIt is run by the client
Client must have an interpreter for the corresponding language
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Code on demand
AdvantagesImproves user experienceExtensibility: Application can add new
functionalities that were not foreseenNo need to install or download a whole
applicationAlways Beta
Adaptability to client environment
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Code on demand
ChallengesSecurityCoherence
It may be difficult to ensure an homogeneous behavior in different types of clientsClient can even decide not to run the program
Reminder: Responsive design
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Code on demand
Applications:RIA (Rich Internet Applications)
HTML5 standardizes a lot of APIsImproves coherence between clients
VariantsAJAX
Initially: Asynchronous Javascript and XMLThe program that is running at the client side
sends asynchronous requests to the server without stopping its running
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Remote evaluation
System A sends program to system B to be run and obtain its results
SystemA
SystemB
Answer(Result)
Interpreter
Program
Query
Network
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Remote evaluation
ElementsSender: Does the query including the
programReceiver: Runs the program and returns the
resultsConstraints
Receiver runs the programIt must contain some interpreter of the
program language or the program could be in machine code
Network protocol transfers program and results
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Remote evaluation
AdvantagesExploits capabilities of third parties
Computational capabilities, memory, resources, etc.
ChallengesSecurity
Untrusted codeVirus = variant of this style
Configuration
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Remote evaluation
Example: Volunteer computation
SETI@HOMEIt was the basis for the BOINC system
Berkeley Open Infrastructure for Network Computing
Other projects: Folding@HOME, Predictor@Home, AQUA@HOME, etc.
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Mobile agents
Code and data can move from one machine to another to be runThe process takes its state from machine to
machineCode can move autonomously
Systema B
Program Interpreter
System A
Program Interpreter
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Mobile agents
ElementsMobile agent: Program that travels and is
run from one machine or another autonomously
System: Execution environment where the mobile agents are run
Network protocol: transfers state between agents
Systema B
Program Interpreter
System A
Program Interpreter
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Mobile agents
ConstraintsSystems host and run mobile agentsMobile agents can decide to change its
running from one system to anotherThey can communicate with other agents
Systema B
Program Interpreter
System A
Program Interpreter
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Mobile agents
AdvantagesIt can reduce network traffic
Code blocks that are run are transmittedImplicit parallelismFault tolerance to network failuresAgents can be conceptually simple
Agent = independent unit of executionIt is possible to create mobile agent systems
Adaptability to environtment changesReactive and learning systems
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Mobile agents
ChallengesComplexity of configurationSecurity
Malicious or incorrect code
Systema B
Program Interpreter
System A
Program Interpreter
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Mobile agents
ApplicationsInformation retrieval
Web crawlersPeer-to-peer systemsTelecommunicationsRemote control and monitoring
Systems:JADE (Java Agent DEvelopment framework)IBM Aglets
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
End of presentation