Applied Architecture & Styles
• Not all problems can be solved by following a simple, uniform design
solution.
• Most will require some invention or innovation on top of the various
lessons learned from the past.
• Here, we will look specifically at problems dealing with Network-Based
Distributed Software where we would like to “soften” the network
problems for the software developers:
– “location” transparency (physical network transparency)
– “implementation transparency (programming language, platform, etc.
transparency)
• Masking the network is very difficult and we still do need to consider:
–
–
–
–
–
–
–
–
Network reliability – the network does go down
Network latency - the network does cause delay and timing problems
Bandwidth limitation - bandwidth variation and limitations exist
Network topological change – parts of network connections come and go
Network security – network can be exploited and is vulnerable to attacks
Network administration (multiple)- established procedure may change
Network transportation cost – there is always a network cost
Homogeneity of network – network is not uniformly the same
Network-Based Applications
• a) Distributed applications run on multiple CPU’s
and the underlying network may be “covered” while
b) network-based applications are distributed but
expose the network.
• We will look at the following:
– REpresentational State Transfer (REST) style
– Leading Commercially available application
• Akamai
• Google
Representational State Transfer (REST) style
• REST is a style of architecture for distributed
hypermedia applications --- a vast amount of related
information (e.g. www):
– Term introduced by Roy Fielding (one of the authors of HTTP
protocol) in his PhD thesis in 2000
– REST is Based on several design principles (constraints):
•
•
•
•
Application state and functionality are abstracted into resources
Every resource is uniquely identifiable via uniform resource identifier (URI)
All resources share a uniform interface (e.g. HTTP protocol)
All protocols are :
–
–
–
–
Client-Server based
Stateless
Cashable
Layered
REST Style
• 1st style constraint is: Client-Server
• 2nd constraint is: Stateless, meaning every request is independent and no
“interaction” information is kept to aid the processing, allowing us to
free up resources
• 3rd constraint is: Cacheable, meaning information may be replicated in
anticipation of future request of the same information, allowing us to
scale up in performance
– Note that not all information are cashable --- e.g. current stock price or
current time or anything that is “time” related.
• 4th constraint is: Uniform Interface, meaning the interface is general
between components (not a fixed code used by all components) and
focusing on i) naming/identification of resource, ii) representation or
visualization of information, iii) communication via descriptive
“message” and iv) standard form of transmission for large-grain
hypermedia
• 5th constraint: Layered system for client server to further improve
characteristics such as security, independent processing, scalability, etc.
• 6th constrain is: Code-on-demand for dynamic extension of functionality
REST style is driven by the distributed hypermedia application domain
Example of Commercial Internet Applications
• Subscribing to the REST style and improving on it:
– Akamai:
• extended REST to replication (caching concept) of servers
because caching certain time related information does not work
(e.g. web sports casting). Then redirecting the clients to the
“closest” replicated servers. Note that the replicated servers still
need to get to the “origin” server for the information, but the
traffic is dramatically reduced.
• The algorithms for placing the replicated servers through out the
“edges” of the Internet is a key
• Separating the representation of information from the actual
data is another of the REST style element that was adopted; this
allowed (a) the sending of actual data from origin server to
replicated edge servers and (b) the processing of representation
of data to be done at the multiple replicated edge servers --- a
performance gain with separation of concern and allowing some
parallelism (pipe-filter style)
Akamai is driven by its speed of moving large amount of “current” data,
attacking network latency and bandwidth problems
Another Commercial Internet Application
• Not all applications subscribe to REST
– Google chose their own approach focused on i)
scalability and ii) availability (fault-tolerance)
• Use lots of duplicative & cheap hardware to store and
process
• Use a simpler storage system than the full-relational db
– Designed and implemented their own Google file system (GFS)
– GFS is focused on handling “large” files and failures of systems
• Run the various “search engine” applications via a
“generalized” data extraction/reduction problem
approach called MapReduce.
Google is driven by its search and reliability of moving of large amounts of data,
attacking the network reliability, latency, and bandwidth problems
Decentralized Architecture
• Key to Decentralized Architecture is the existence of
multiple authority (control) domains, or agencies,
participating in the application.
– Multiple artifacts are controlled by multiple “owners”
– The parts may communicate over a network
• Distributed system has parts of the system
physically located in different places, but may still
have one control point.
“Decentralized” focuses
on 1) control problems
in addition to 2) latency
and other problems
Decentralized
Systems
distributed
systems
Decentralized Systems
• Grid computing: this is a “coordinated” resource sharing and
computation in a decentralized environment.
– The resources are under different ownership and control and may be
physically distributed
– However, during execution of an application the resources are
allocated and the logical system is executing under one single control.
application layer
“Foster,
Kesselamn,
Tuecke”
layered Grid
style
Collective layer
Resource layer
Connectivity layer
Fabric layer
Components for application
Coordinates multiple resources
Managing a single resource
Manages communications
Manages the components of Grid
Decentralized Systems
• Napster: a information (music) sharing, networking
“semi” peer-to-peer system
Peer
2
Registers with directory
Peer &
Content
Directory
Peer
1
acts as a
“coordinator”
Registers with directory
Peer
4
Peer
3
Uses Napster proprietary protocols except for the fetching of content from peer
when HTTP is used.
Decentralized System
• Gnutella: a more “pure” peer-to-peer system
Peer 5 has “gee”
Peer
1
Peer
3
Peer
2
Peer
4
Peer
5
Gnutella also uses proprietary protocol except for HTTP for actual
transfer of content. It is highly robust with addition and removal of peers.
But may be insecure or inefficient or “unknown” ; added “special peer”
More Decentralized peer-to-peer Systems examples
• Skype: internet communications application:
– Users download skype application from a skype server (solves the
discovery of peers problem and some security problems)
– Uses proprietary, secret protocol (solves some security problems)
– Has “super-nodes” that will aid in directory service and call routing
(solves the scalability problem)
– Locations of super-nodes are chosen based on network and call
capacity; peer node may become super-node. (solves some
performance/latency problem)
• BitTorrent: an open source file sharing application for
distributing large software and media files
– It reduces the “congestion” of requests to a single peer for a popular
item problem by distributing parts of a file to multiple peers.
Latency & Agency
• Decentralized System must address:
– Solving Latency problems
• Replication and caching
• Centralized and decentralized servers
– Solving Agency (control) problems
•
•
•
•
•
Heterogeneous peers
Locating peers
Reliability
Trust
Security
Service Oriented Architecture (SOA)
• SOA is not quite an architecture, but more a concept or style
of conducting business using the internet, using a messaging
scheme.
Service request
Service
provider
Service
requestor
internet
1) will use xml to describe the
business and the protocols
2) will use HTTP and SOAP as
basic means of messaging
3) use standards such WSDL to
describe services; WS-BPEL to
describe business process & execution
4) Other business related properties
such as trust, security, performance are in the works
1. Business process
2. Service components
3. Communicating network
SOA Architecture (cont.)
• May view SOA to have three “layers”
Business Services &
Business Management
organizations must agree on
their “ways” to conduct business
Software Services &
Management
(Components &Connectors)
The business services must
be supported by software/technical
functionalities
IT Services &
Management
(processors, network, etc.)
The software, hardware and network
must be supported by IT services
and management
Architecture for A Special Domain (Robotics)
• Robotics come in multiple levels of autonomy:
– Mobile tele-operated system: the robot’s motions are
controlled by a remote human (e.g. hazardous material)
disposal
– Industrial automation system: the robot performs a
predefined activity repetitiously without human
intervention (e.g. automotive assembly arms)
– Mobile autonomous robot system: robot performs its
activity totally independent of human control (e.g. robot
driven vehicle )
Architectures for Robot systems
Plan:
Sense
Act
Model of the
“world” of activities
Sense-Plan-Act (SPA) Architecture: Plan is the “central brain”
Reminds one of the real-time sensor architecture style?
Skill C
Actuator
i
Sensor 1
Sensor 2
Skill A
Skill B
Actuator
ii
Subsumption Architecture: more modular/nimble and flexible (like human)
3L Architecture for Robotics
Planning Layer
(slower, log-term planning –similar to SPA)
Sequence Layer
(links chains of reactive actions and/or
administers complex activities from planning)
Reactive Layer
(reacts and performs basic functions)
sensor
sensor
sensor
actuator
actuator