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 distd 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 CPUs 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 services asynchronously
• 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 components 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 objects behavior is defined independently of
  its identity
• An objects 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 objects behavior is defined independently of
  its identity
• An objects 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 objects behavior is defined independently of
  its identity
• An objects 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 receivers 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 receivers 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 its 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 vendors 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

chees
e anchovies ings 12 12.5 a
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