1 / 41

Multithreaded and Distributed Programming – How Distributed Programs Communicate

Multithreaded and Distributed Programming – How Distributed Programs Communicate. ECEN5053 Software Engineering of Distributed Systems University of Colorado. Distributed Systems – Concepts and Design, 4th ed. Coulouris, Dollimore and Kindberg, Addison-Wesley, 2001.

max
Download Presentation

Multithreaded and Distributed Programming – How Distributed Programs Communicate

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Multithreaded and Distributed Programming – How Distributed Programs Communicate ECEN5053 Software Engineering of Distributed Systems University of Colorado Distributed Systems – Concepts and Design, 4th ed. Coulouris, Dollimore and Kindberg, Addison-Wesley, 2001

  2. In certain applications, need to balance these forces: • Services provided by others through remote, location-transparent invocations. • Components exchanged, added, or removed at run time. • The architecture should hide from the users of components and services: • system-specific and • implementation-specific details • The Broker Pattern addresses these issues.

  3. In some applications, need to balance these forces: • Sequence of operations on a stream of data • Future: exchange, recombine, or insert steps • Small processing steps more likely to be reusable in other contexts • Non-adjacent steps do not share information • There are different sources of input data • Need to present or store final results in various ways • Avoid explicit storage of intermediate results (clutters directories, error-prone) • May want to run some steps in parallel • Pipes and Filters Pattern addresses these

  4. In certain dist’d apps, need to balance these forces: • Application domain includes broad spectrum of similar standards and technologies. • The application platform must cope with continuous hardware and software evolution. • For easy integration of emerging technologies, application platform should be portable, extensible, adaptable • The apps in the domain need to support different but similar application platforms. • The apps may use the same functional core in different ways; underlying app platform emulates existing stds • Functional core of the app platform should be separated into a component with min memory size and services that consume as little processing power as possible. • Micro-kernel Pattern provides a design solution.

  5. Event-handling forces - Reactor • Handle multiple service requests simultaneously even if ultimately processed serially. • Before executing serially, the app must demultiplex and dispatch the events to the corresponding service implementations. • To improve scalability and latency, an app should not block on any single source of events and exclude other event sources • To maximize throughput, unnecessary context switching, synchronization, and data movement among CPU’s should be avoided. • Integrating new services with existing event demultiplexing and dispatching mechanisms should require minimal effort • Application code should largely be shielded from the complexity of multi-threading and synch mechanisms.

  6. Event-handling forces – Asynchronous completion pattern • A client invokes an operation request on one or more servicesasynchronously • Each service returns its response via a completion event • The app must direct this to the appropriate handler that will process the response contained in the completion event. • A service does not know the originating context. Therefore the client must determine what to do with the completion events and which gets which. • Minimize communication overhead between client & server to determine how to process completion events • Minimize time spent by client app in assigning the completion event to the handler that will process the response

  7. Service access & Configuration • Service components’ interfaces evolve. • Existing operating system APIs are likely non-object-oriented. • The Wrapper Facade pattern wraps lower-level APIs to improve application portability • Component Configurator allows an application to link and unlink its component implementations at run-time without having to modify, recompile, or relink the application statically. • Interceptor pattern allows services to be added to a framework transparently and be triggered automatically when certain events occur.

  8. Extension Interface Patternaddresses these • Developers extend/modify service functionality of existing components; over time, leads to • Bloated interfaces • Broken client code • Multiple extension interfaces can be attached to the same component. • Need to provide clients with an authorized access to a component • Need to provide clients with a role-specific access to a component’s functionality

  9. Examples of Distributed Systems • ATM • Web-based travel site • Stock transaction processing system • Search service • Games

  10. Fill in the blanks

  11. ATM • Client-server • Simple reply-response • Transactions required • Tightly controlled distributed system

  12. Web-Based Travel Site • Multi-tiered • Client • Travel site • Vendor reservation systems • Referred to as n-tiered • Organization responsible for site has little control over other tiers • Session-oriented

  13. Stock Transaction Processing • Peer-to-peer communication • Publish/subscribe model for many interactions

  14. Google Search Service • Language-neutral service • Easy to write program against • Freely available • Low support overhead

  15. What They All Need • Communication infrastructure • Remote references to objects and methods • Remote method invocation or remote procedure call

  16. Special Needs • Transactions • ATM • Stock transaction processing • Asynchronous Messaging • Stock transaction processing • Session support • Travel site • Language neutrality – standard interfaces • Travel site • Stock transaction processing • Google search service

  17. Special Needs • Transactions • ATM • Stock transaction processing • Asynchronous Messaging • Stock transaction processing • Session support • Travel site • Language neutrality – standard interfaces • Travel site • Stock transaction processing • Google search service

  18. Communication Infrastructure

  19. Synchronous communication • Remote procedure call (RPC) • Remote method invocation (RMI) • Client waits until server responds, or request times out • Most distributed processing falls into this model • Is much like normal, non-distributed programming, but… • Pass by reference is not practical • Not all data types may be available • Platform neutrality may be hard to achieve

  20. Synchronous communication • Remote procedure call (RPC) • Remote method invocation (RMI) • Client waits until server responds, or request times out • Most distributed processing falls into this model • Is much like normal, non-distributed programming, but… • Pass by reference is not practical • Not all data types may be available • Platform neutrality may be hard to achieve

  21. Asynchronous communication • Messaging • Client sends a message and moves on • If a response is needed, the client has a mechanism that listens for it • Point-to-point • Used in publish/subscribe applications, e.g. • Uses message-oriented middleware (MOM)

  22. Asynchronous communication • Messaging • Client sends a message and moves on • If a response is needed, the client has a mechanism that listens for it • Point-to-point • Used in publish/subscribe applications, e.g. • Uses message-oriented middleware (MOM)

  23. Message-Oriented Middleware • IBM MQ Series • Oracle AQS • JMS – Java Messaging Service • Part of the J2EE standard • A set of standard interfaces, not a defined implementation • Many vendors provide JMS wrappers or adapters for their MOM

  24. Messaging-Oriented Middleware • IBM MQ Series • Oracle AQS • JMS – Java Messaging Service • Part of the J2EE standard • A set of standard interfaces, not a defined implementation • Many vendors provide JMS wrappers or adapters for their MOM

  25. External Data Representation • Behavior vs State • An object’s behavior is defined independently of its identity • An object’s state is intimately associated with its identity • To send an object between remote processes, only its state needs to be transmitted • Marshalling and Unmarshalling • The mechanisms by which state is packaged for transmission, and unpackaged on the other end

  26. External Data Representation • Behavior vs State • An object’s behavior is defined independently of its identity • An object’s state is intimately associated with its identity • To send an object between remote processes, only its state needs to be transmitted • Marshalling and Unmarshalling • The mechanisms by which state is packaged for transmission, and unpackaged on the other end

  27. External Data Representation • Behavior vs State • An object’s behavior is defined independently of its identity • An object’s state is intimately associated with its identity • To send an object between remote processes, only its state needs to be transmitted • Marshalling and Unmarshalling • The mechanisms by which state is packaged for transmission, and unpackaged on the other end

  28. Data Representation Issues • Hardware specifics • Endian issues – how numbers are stored • OS specifics • Character sets • Integer sizes • Language specifics • String representations • Floating point number representations • Date/time representations • Object definitions

  29. Data Representation Approaches • External representation is defined by the language (e.g., Java) • Sender marshalls to receiver’s representation • All processes subscribe to common, pre-compiled external representation (e.g., CORBA) • External representation is self-descriptive (e.g., XML, Web Services)

  30. Data Representation Approaches • External representation is defined by the language (e.g., Java) • Sender marshalls to receiver’s representation • All processes subscribe to common, pre-compiled external representation (e.g., CORBA) • External representation is self-descriptive (e.g., XML, Web Services)

  31. Java • Marshalling and unmarshalling are built into the language • Called serialization and deserialization • Huge advantage: it’s part of the language • Only works for Java-to-Java • Encompasses a very wide range of Java types • Widely used in Java • Simple persistence • Distributed computing

  32. Java (cont.) • Referenced objects are also serialized • Redundant references and circularities are handled • Static attributes are not automatically serialized

  33. CORBA • Object interfaces are defined in CORBA Interface Description Language (IDL) • CORBA interface compiler for a specific language/OS/platform creates code to marshall and unmarshall objects • Not all vendor’s CORBA tools are interoperable • Language neutrality has its costs…

  34. Web Services • Uses Simple Object Access Protocol (SOAP) as common representation • SOAP is expressed in an XML dialect • All information is transmitted as strings • Uses HTTP as the request-reply protocol

  35. XML eXtensible Markup Language • Structured data in a text file • XML looks a bit like HTML but isn't HTML • XML is text, but isn't meant to be read • XML is new, but not that new • XML is not really a markup language itself, but a meta-language for defining markup languages • HTML can be defined using XML • Groups are attempting to define standard domain-specific XML dialects • Home-grown XML dialects are common for single applications, too

  36. Why is XML a Big Deal? • Self-descriptive • Open standard • Platform and language neutral • License-free • Widely supported with free tools • A great way for applications to communicate with each other • The basis for a wide array of emerging technologies

  37. Self-Descriptive Data • Consider data used in a pizza business to describe a pizza: • Style • Toppings • Size • Price • What do you think the following data record should mean? “fishy”, 12, “cheese”, “anchovies”, 12.5

  38. Self-Descriptive Data (cont.) • Is “12” an integer or a float? • Is “12.5” the size or the price? • If “12.5” were sent as a binary number, marshalling / unmarshalling would require knowledge of endpoint platforms • If the data came from a database, we need the database schema, and probably the database engine itself, to interpret the data. • If the data came from a file, we need to write code to interpret the data. • Adding or removing fields causes major problems.

  39. XML is Self-Descriptive • Each datum is enclosed and tagged with a descriptor that tells us about its semantics • Possible XML representation for a pizza: <pizza style=“fishy”> <toppings> <topping>cheese</topping> <topping>anchovies</topping> </toppings> <size>12</size> <price>12.5</price> </pizza>

  40. XML is Platform & Language Neutral • Usually sent in a character format: • Usually ASCII Strings • Could be Unicode, although this is still less common • Documents are human-readable • Drawbacks • Uses more bytes than other representations • Documents can get hard to read • Writing documents can be error-prone • This format can be awkward when dealing with binary (non-character) data. • Binary data can be sent in encoded form, but the programs at either end of the conversation must understand the encoding.

  41. XML Schema • Schema documents define the structure and semantics of an XML dialect • A group of people who want to define an XML dialect (say for standard medical records), would define a schema

More Related