1. BINA RAMAMURTHY 9/30/2016 Copyright 2010 B. Ramamurthy 1 Distributed Systems

2. Introduction 9/30/2016 Copyright 2010 B. Ramamurthy 2 A distributed system is a network of autonomous computers cooperating to accomplish a task. Hardware and software components of a distributed system coordinate their activity by sharing resources such as data, computation, compute cycles, bandwidth and storage. Examples: Internet, intranet, grid and mobile computing systems.

3. Topics 9/30/2016 Copyright 2010 B. Ramamurthy 3 Some fundamental terms Advances in  Client-side technologies  Communication network  Middleware concept  Server-side technology  Application models (web, web2.0, web3.0)

4. Copyright 2010 B. Ramamurthy 9/30/2016 4 Terminologies

5. Protocol 9/30/2016 Copyright 2010 B. Ramamurthy 5 Protocol is a set of rules that end points in a telecommunication system use when exchanging information.  IP: Internet protocol defines an unreliable packet transfer protocol.  TCP: Transmission Control Protocol builds on IP to define a reliable data delivery protocol.  LDAP: Lightweight Directory Access Protocol builds on TCP to define a query-response protocol for querying the state of a remote database.  HTTP: Hyper Text Transfer Protocol builds on TCP to facilitate hyper-text document exchange.

6. Service 9/30/2016 Copyright 2010 B. Ramamurthy 6 Service is a network-enabled entity that provides a specific capability. Service = Protocol + Behavior A service definition permits many implementations. Examples: ability to move files, create processes, verify access rights An FTP server speaks File Transfer Protocol and supports remote read and write access to a collection of files.

7. API 9/30/2016 Copyright 2010 B. Ramamurthy 7 Application Program Interface (API) defines a standard interface for invoking a specified set of functionality. Examples: The Generic Security Service (GSS) API defines standard functions for verifying identity of communicating parties, encrypting messages and so forth.

8. SDK 9/30/2016 Copyright 2010 B. Ramamurthy 8 Software Development Kit (SDK) denotes a set of code designed to be linked with, and invoked from within, an application program to provide specified functionality. An SDK typically implements an API. Example: Different SDKs implement GSS-API using the Kerberos or PKI protocols, respectively.

9. Internet 9/30/2016 Copyright 2010 B. Ramamurthy 9 Internet is a very large distributed system. Interconnection of a collection of heterogeneous networks of computers. Protocols: IP, TCP, HTTP Services: world wide web (www), file transfers (ftp), email, etc.

10. Copyright 2010 B. Ramamurthy 9/30/2016 10 Advances in Client-side programming

11. Client programming 9/30/2016 Copyright 2010 B. Ramamurthy 11 Simple programs written as a single module Single entry point typically in a “main” function Procedural, functional and object-oriented Applications, applets (web-based) More recently the focus is on rich content: Rich Internet Application (RIA)  Adobe Flash, Adobe Flex, Microsoft Silverlight, Ajax Model-View-Controller (MVC) model for design and deployment flexibility. Ex: java swing, struts..

12. Client/Server 9/30/2016 Copyright 2010 B. Ramamurthy 12 Server: refers to a process on a networked computer that accepts requests from other (local or remote) processes to perform a service and responds appropriately. Client: requesting process in the above is referred to as the client. Request and response are in the form of messages. Request/response model Client is said to invoke an operation on the server. Many distributed systems today are constructed out of interacting clients/servers. Issues: connectivity (speed and accessibility), addressing, naming

13. Copyright 2010 B. Ramamurthy 9/30/2016 13 Advances in Networking

14. Internetworking 9/30/2016 Copyright 2010 B. Ramamurthy 14 Internet stack Standardization IPV4, IPV6: Internet protocol version 4, 6 Tremendous increase in network bandwidth: measured in bits per second From few kilobits per second (56kb/s dial up lines to 1.5Mb/s T1 to 100Gb/s ethernet) What can you do with such fast delivery speed? Connect them up.. Networked application models

15. Communication Network 9/30/2016 Pag e 15 A communication middleware framework isolates the application developers from the details of the network protocol. Application Network Protocol Stack Copyright 2010 B. Ramamurthy

16. Client/server Issues 9/30/2016 Copyright 2010 B. Ramamurthy 16 Basic object-technology could not fulfill the promises such as reusability and interoperability fully in the context internet and enterprise level applications. Deployment was still a major problem and as a result portability and mobility were impaired.

17. Issues in networked systems 9/30/2016 Pag e 17 Heterogeneity in various aspects of a distributed systems Communication modes different  Synchronous: RPC  Asynchronous: P2P, Publish and subscribe Variations in products  Many vendors: IBM, IONA, TIBCO, Apache, Adobe Additional runtime features:  fault tolerance, load balancing, transaction handling, usage metering, auditing,.. Copyright 2010 B. Ramamurthy

18. 9/30/2016 18 Advances in Middleware

19. Communication Middleware 9/30/2016 Pag e 19 Application Network Protocol Stack Middleware Copyright 2010 B. Ramamurthy

20. Remote procedure call (RPC) 9/30/2016 Pag e 20 Client Application Server Application Network Protocol Stack RPC Stub codeRPC stub code RPC library/runtime Procedure call Execute call RPC stubs and runtime enable location transparency, encapsulate RPC communication infrastructure and provide a procedure call interface. Copyright 2010 B. Ramamurthy

21. Distributed Objects 9/30/2016 Pag e 21 Client Application Server Application Network Protocol Stack Client proxiesServer skeletons ORB invoke method Execute method ORB (Object Request broker) enables client applications to remotely instantiate, locate, invoke methods and Delete server objects; Java RMI, Microsoft’s DCOM; CORBA is meant to be platform independent. Copyright 2010 B. Ramamurthy

22. 22 Middleware (Eg. CORBA, Grid) “network” client server middleware client server “desktop” 9/30/2016 Copyright 2010 B. Ramamurthy

23. Technical Layers 9/30/2016 Pag e 23 Participant AParticipant CParticipant B Technology Independent Interface Description Technology Independent Interface Description Technology Independent Interface Description Core Assets XMLORB Technology Adapters Middleware Mapping CORBA XML Web services Middleware Buses Communication facilities Business Logic GRID Copyright 2010 B. Ramamurthy

24. What is CORBA? 9/30/2016 Pag e 24 Common Object Request Broker Architecture (CORBA) specification (/standard) defines a framework for object-oriented distributed applications. It is defined by a consortium of vendors under the direction of Object Management Group (OMG). Copyright 2010 B. Ramamurthy

25. What is CORBA? (contd.) 9/30/2016 Pag e 25 Allows distributed programs in different languages and different platforms to interact as though they were in a single programming language on one computer. Brings advantages of OO to distributed systems. Allows you design a distributed application as a set of cooperating objects and to reuse existing objects. Copyright 2010 B. Ramamurthy

26. Object Request Broker (ORB) 9/30/2016 Pag e 26 A software component that mediates transfer of messages from a program to an object located on a remote host. Hides underlying network communications from a programmer. ORB allows you to create software objects whose member functions can be invoked by client programs located anywhere. A server program contains instances of CORBA objects. Copyright 2010 B. Ramamurthy

27. Clients, severs and objects 9/30/2016 Pag e 27 Client Server0 Server1 CORBA Object invocation Copyright 2010 B. Ramamurthy

28. CORBA Objects and IDL 9/30/2016 Pag e 28 These are standard software objects implemented in any supported language including Java, C++ and Smalltalk. Each CORBA object has a clearly defined interface specified in CORBA interface definition language (IDL). The interface definition specifies the member functions available to the client without any assumption about the implementation of the object. Copyright 2010 B. Ramamurthy

29. Client and IDL 9/30/2016 Pag e 29 To call a member function on a CORBA object the client needs only the object’s IDL. Client need not know the object’s implementation, location or operating system on which the object runs. Copyright 2010 B. Ramamurthy

30. IDL facilitates internetworking 9/30/2016 Pag e 30 C++ Java smalltalk OLE (VB, PB,Delphi) Ada, Cobol etc. target object Specify in IDL Use IDL-language compiler Client sees only IDL interface Copyright 2010 B. Ramamurthy

31. Separation of Interface and Implementation 9/30/2016 Pag e 31 Interface and implementation can be in two different languages. Interface abstracts and protects details (trade secrets) from client Design by contract Interface offers a means of expressing design without worrying about implementation. Copyright 2010 B. Ramamurthy

32. ORB : Conceptual View 9/30/2016 Pag e 32 When a client invokes a member function on a CORBA object, the ORB intercepts the function call. ORB directs the function call across the network to the target object. The ORB then collects the results from the function call returns these to the function call. Copyright 2010 B. Ramamurthy

33. Implementation Details 9/30/2016 Pag e 33 Access to the services provided by an Object ORB : (Object-oriented middleware) Object Request Broker ORB mediates transfer between client program and server object. Client ORB Object Stub Client Stub Copyright 2010 B. Ramamurthy

34. 9/30/2016 Copyright 2010 B. Ramamurthy 34 What is a grid? Grid is a sophisticated framework that enables sharing of a variety of resources among distributed applications. Open standard Large scale operations Automatic Intelligent Spontaneous Interoperable Service-oriented

35. 9/30/2016 Copyright 2010 B. Ramamurthy 35 What is a grid? (A formal definition) Grid specifies a standard architecture, infrastructure, protocols and application program interface (API) for building an open enterprise system. It can provide  Middleware supporting network of systems to facilitate sharing, standardization and openness.  Infrastructure and application model dealing with sharing of compute cycles, data, storage and other resources.  A framework for high reliability, availability and security.  Interoperation of batch-oriented and service-based architectures.  Standard service level feature definitions and higher level concepts for inter and intra-business collaboration.

36. 9/30/2016 Copyright 2010 B. Ramamurthy 36 Beginnings of The Grid Beginnings of the grid in Search for Extra Terrestrial Intelligence (seti@home project) http://planetary.org/html/UPDATES/seti/index.html  The Wow signal http://planetary.org/html/UPDATES/seti/SETI@h ome/wowsignal.html http://planetary.org/html/UPDATES/seti/SETI@h ome/wowsignal.html

37. Message-oriented Middleware (MOM) 9/30/2016 Pag e 37 Made famous by IBM’s MQseries and TIBCO’s Rendezvous products. Based on messages and queues.  A message contains a header and a payload.  A queue can store and distribute messages. Publish/subscribe model of communication:  A topic offers another model of communication between subscribers and publishers. MOM allows for loose coupling between message consumers and message producers enabling dynamic, reliable, flexible, high-performance systems to be built. Copyright 2010 B. Ramamurthy

38. 9/30/2016 38 Server-side Advances

39. Server-side advances: Two-tier applications 9/30/2016 Copyright 2010 B. Ramamurthy 39 Presentation Logic Business Logic Database Server

40. Server-side: Three-tier Applications 9/30/2016 Copyright 2010 B. Ramamurthy 40 Presentation Logic Business Logic Database Server Tremendous advances in DBMS: relational, query languages, Object-relational…ACID property transactional systems

41. Programming Model for Web-based applications 9/30/2016 Copyright 2010 B. Ramamurthy 41 Web client Web Application Database Server Enterprise components Logic container Web Container Business Logic Web Service

42. Components and Application Servers 9/30/2016 42 An application server mediates between a web server and backend systems. Request from a web client is passed onto an application server by the web server. Programmer productivity, cost-effective deployment, rapid time to market, seamless integration, application portability, scalability, security are some of the challenges that component technology tries to address head on. Enterprise Java Beans is Sun’s server component model that provides portability across application servers, and supports complex systems features such as transactions, security, etc. on behalf of the application components. EJB is a specification provided by Sun and many third party vendors have products compliant with this specification: BEA systems (bought out by oracle), IONA, IBM, Oracle, Sybase (bought out by IBM). Copyright 2010 B. Ramamurthy

43. Application Programming Model for Three- tier Applications 9/30/2016 Copyright 2010 B. Ramamurthy 43 Presentation Components Database Server Enterprise Components Container Application Container Business Logic

44. Expectations of a Distributed System 9/30/2016 Copyright 2010 B. Ramamurthy 44 Access transparency: enables local and remote resources to be accessed using identical operations. Location transparency: enables resources to be accessed without knowledge of their location. Concurrency transparency: enables several processes to operate concurrently using shared resources without interference between them. Replication transparency: enables multiple instances of resources to be used to increase reliability and performance without knowledge of the replicas by users or application programmers. Failure transparency: enables the concealment of faults, allowing users and application programs to complete their tasks despite the failure of hardware or software components. Mobility transparency: allows the movement of resources and clients within a system without affecting the operation of users or programs. Performance transparency: allows the system to be reconfigured to improve performance as loads vary. “Scalability” Expansion transparency: allows the system and applications to expand in scale without change to the system structure or the application algorithms.

45. Issues contd. 9/30/2016 Copyright 2010 B. Ramamurthy 45 Heterogeneity of components Scalability : ability to perform well under increased loads and data sizes  Failure handling  Concurrency  Transparency Reliability Interoperability Performance Openness Security and protection

46. Copyright 2010 B. Ramamurthy 9/30/2016 46 Emerging Application Models

47. Large scale systems 9/30/2016 Copyright 2010 B. Ramamurthy 47 Most emerging distributed applications are very large demanding large amounts of storage and data resources E-commerce systems and online businesses Applications connecting communities: from search to social networking See world’s 10 largest data basesworld’s 10 largest data bases Amount of data collected by various sources from terrorism monitoring to environmental monitoring Data deluge: most of the data is write once read many (WORM)  Analytics resulting in data-intensive computing models and big-data computing (CSE487 material) We will look just one success story of distributed system: amazon.com

48. Amazon.com 9/30/2016 Copyright 2010 B. Ramamurthy 48 Werner Vogels’ talk “Order in the Chaos: Building the Amazon.com Platform."talk 1995: Started out with a single web service on a single server. Today amazon has about 150 web services on its homepage alone. 1 million merchant partners; 60 million customers One server of customers and inventory grew into two servers; more database servers were added as the business expanded 1999: A mistep during this exponential growth period was moving to mainframe from distributed server. Failed to meet scalability, reliability and performance; it was scratched in 2000.

49. Amazon (contd.) 9/30/2016 Copyright 2010 B. Ramamurthy 49 Robustness: Shopping cart is tested for 20000 items by a single customer, for example! Amazon’s secret sauce is “operating reliably at scale”. After “the denial of service” debacle in 1999, they decided to use Web services to insulate the databases from being overwhelmed by direct interaction with online applications. Each web service is the responsibility of a team of developers:  “And they are not just responsible for writing the service and then tossing it over the wall for testing and eventual entry into production where some poor maintenance geek has to look after it.  The Amazon CTO tells his Web services team members: "You build it. You own it."  That means the team is responsible for its Web service's on-going operation. If a Web service stops working in the middle of the night, team members are called to fix it.” Web services are kept simple: complexity is the notorious enemy of reliability No attachment to one technology or standard: what ever customer wants, give it.

50. Copyright 2010 B. Ramamurthy 9/30/2016 50 On to more fundamental concepts

51. Synchrony 9/30/2016 51 Synchronous and asynchronous communications Synchronous:  immediate response of communicating partners  Server process/thread blocks until response is completed  Follows request/response pattern  Used when servers are available all the time  Typically communicating partners are tightly coupled  Examples:  request from web client to a web browser for “search” or for “information”  CORBA procedure invocation  Java RMI (remote method invocation)  Traditional remote procedure call (RPC) Copyright 2010 B. Ramamurthy

52. Asynchronous communication 9/30/2016 52 Communicating partners are decoupled Message driven:  sender creates a message and delivers it to a mediator who then sends it to “a” recipient  Server need not be available all the time  Sender and receiver loosely coupled  Can facilitate high-performance message-based system  Example:  Any event-driven system  Any messaging system (instant messenger)  Publish-subscribe mode communications Copyright 2010 B. Ramamurthy

53. Interface vs Payload Semantics 9/30/2016 53 Typically interaction between a client and a server results in the execution of an activity (ot transaction) Request needs to be specified by the request.  Interface semantics: Requested activity can be encoded in the operation signature in the server’s “interface” or  Payload semantics: It can be embedded in the message itself Copyright 2010 B. Ramamurthy

54. Interface Semantics 9/30/2016 54 Process1Process2 getCustomer() retrieveCustomerData() returnResult() Semantics of the activity is explicitly stated in the message/method call Copyright 2010 B. Ramamurthy

55. Payload Semantics 9/30/2016 55 Process 1Process 2 Envelop With message Requested transaction/activity is embedded in the message Details of the activity not explicit; the semantics are embedded in the message Copyright 2010 B. Ramamurthy

56. Payload Semantics 9/30/2016 Pag e 56 onMessage() Copyright 2010 B. Ramamurthy

57. Payload semantics is generic 9/30/2016 Pag e 57 String transferMoney (amt: decimal, accTo: String) { …} String executeService (message: String) { …} Copyright 2010 B. Ramamurthy

58. Document-centric Messages 9/30/2016 Pag e 58 With emergence of self-descriptive data structures such as XML, document-centric has become popular Semantically rich messages where operation name, its parameters, return type are self descriptive. SOAP (Simple Object Access Protocol) over XML is an example Lets look at XML, SOAP, WS evolution. WS  SOA Copyright 2010 B. Ramamurthy

59. Tight vs. Loose Coupling 9/30/2016 59 An important characteristics of an SOA that is a loosely coupled system. On the technology front this is driven by dynamic discovery and binding enabled by Universal Description, Discovery and Integration (UDDI) On the business front loose coupling addresses the growing need for companies to be flexible and agile with respect changes in their own processes and those of their partners How does loose coupling help in improving agility, flexibility and performance? Copyright 2010 B. Ramamurthy

60. Tight vs. Loose coupling LevelTight couplingLoose coupling Physical couplingDirect physical link requiredPhysical intermediary Communication style synchronousasynchronous Type systemStrongly typed (interface semantics) Weak type system (payload semantics) Interaction patternOO-style navigation of complex object trees Data-centric, self-contained messages Control of process logic Central control of process logicDistributed logic components Service discovery and binding Statically bound servicesDynamically bound services Platform dependencies Strong OS and programming language dependencies OS- and programming language dependent 9/30/2016 Page 60 Copyright 2010 B. Ramamurthy

61. Summary 9/30/2016 61 We discussed the fundamental choices available to a designer in assembling a distributed system A designer must choose appropriate communication infrastructure, synchrony, call semantics, use of intermediary, object-oriented versus data-centric interfaces. All these factors impact the coupling of the distributed systems. In this course, we will study different types of distributed systems and learn to design, develop and implement distributed systems. Copyright 2010 B. Ramamurthy

62. Tools to explore 9/30/2016 62 Design tool: Rational rose demo model Windows http://www.cse.buffalo.edu/bina/rosecppdemo.exe Language for your distributed system development: Java IDE for development needs of your projects: Netbeans? Eclipse? Copyright 2010 B. Ramamurthy