1. 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. 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

2. 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

3. 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

4. REST Style First style constraint is: Client-Server 2 nd constraint is: Stateless, meaning every request is independent and no “interaction” information is kept to aid the processing, allowing us to free up resources 3 rd 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. 4 th 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 5 th constraint: Layered system for client server to further improve characteristics such as security, independent processing, scalability, etc. 6 th constrain is: Code-on-demand for dynamic extension of functionality REST style is driven by the distributed hypermedia application domain

5. 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

6. 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

7. Decentralized Architecture Key to Decentralized Architecture is the existence of multiple authority (control) domains, 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 Systems distributed systems “Decentralized” focuses on 1) control problems in addition to 2) latency and other problems

8. 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 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 “Foster, Kesselamn, Tuecke” layered Grid style

9. Decentralized Systems Napster: a information (music) sharing, networking “semi” peer-to-peer system Peer & Content Directory Peer 1 Peer 4 Peer 3 Peer 2 Registers with directory asks for music “gee” Peer 3 has “gee” Request for “gee” transfers “gee” Uses Napster proprietary protocols except for the fetching of content from peer when HTTP is used. acts as a “coordinator”

10. Decentralized System Gnutella: a more “pure” peer-to-peer system Peer 3 Peer 5 Peer 4 Peer 2 Peer 1 Request for “gee” Peer 5 has “gee” Please send me “gee” Transfer gee “gee” 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”

11. More Decentralized peer-to-peer Systems 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.

12. 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

13. 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 requestor Service provider internet Service request Service response 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

14. SOA Architecture (cont.) May view SOA to have three “layers” Business Services & Business Management Software Services & Management (Components &Connectors) IT Services & Management (processors, network, etc.) organizations must agree on their “ways” to conduct business The business services must be supported by software/technical functionalities The software, hardware and network must be supported by IT services and management

15. 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 )

16. Architectures for Robot systems Sense Plan: Model of the “world” of activities Act Sensor 1 Sensor 2 Skill C Skill B Skill A Actuator i Actuator ii Sense-Plan-Act (SPA) Architecture: Plan is the “central brain” Subsumption Architecture: more modular/nimble and flexible (like human)

17. 3L Architecture for Robotics Planning Layer (slower, log-term planning –similar to SPA) Reactive Layer (reacts and performs basic functions) Sequence Layer (links chains of reactive actions and/or administers complex activities from planning) sensor actuator sensor