Multithreaded and Distributed Programming – How Distributed Programs Communicate

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