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, 3rd ed. Coulouris, Dollimore and Kindberg, Addison-Wesley, 2001

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

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

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

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

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

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

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

Communication Infrastructure

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

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)

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

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

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

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)

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

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

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…

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

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

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

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

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.

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>

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.

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

Distributed Objects

ATM • ATM “Teller” object works with Account object • Teller object is local to the ATM • Account object is in some process back at the bank • How do they talk to each other?

Talking to Remote Objects • Finding the object you want • Getting a reference to the object • Invoking methods on the object • Receiving results • Differences from talking to local objects

Finding The Object You Want • Requires a naming or directory service • Finding hosts on the Internet – Domain Name System (DNS) • You give it a URL • DNS gives you an IP address

Getting The Object You Want • Ask the server that has the object to send it to you • Identify it by some sort of key • The server sends you a proxy or stub • The stub supports the same interface as the actual remote object

Invoking Methods on the Object • Client talks to the stub • Stub’s job • Specifies the method to execute • Marshalls the parameters • Sends method ID and parameters to the skeleton • Skeleton’s job • Unmarshalls parameters • Calls the actual object

Receiving Results • Skeleton’s job • Receives results from the actual object • Marshalls the results • Sends results to the stub • Stub’s job • Unmarshalls the results • Passes them back to the client

Web-Based Travel Site • The site must maintain a shopping cart for the client, remember his preferences, etc. • One remote service, the site, must collaborate with several other remote services, the airline and hotel reservation systems • How does the site avoid treating each as a special case? • How does the site perform adequately?

Maintaining a Shopping Session • Http is a stateless protocol • Session state must be implemented somehow • Cookies • Hunks of information the server leaves on the client machine • URL rewriting • Session information is encoded in the URL string sent between the client and server

Talking to Distributed Databases • N-tier architecture • Client • Web Server • Application server • Database server • Use standard database abstractions • Connections • ODBC and JDBC

Stock Transaction Processing System • Client processes must be able to subscribe to trades and changes in price of specific securities • Subscriptions are maintained when client or server system is restarted • If client is not running, notices to which it subscribes are saved for it • System sends asynchronous notices to subscribers • How does the client know what happens without poling?

Messaging • Asynchronous interaction between clients and servers • Messages are passed between them on queues • Queues are provided by message-oriented middleware • Producers put message on queues • Consumers get messages off queues • Can poll for messages (not common) • Can be notified when messages arrive • Assign listeners to the queue

Messaging (cont.) • Durable subscriptions • If the receiver is not running, the queue will deliver the messages when the receiver comes back • Persistent queues • All messages that are put on the queue are also saved to a database • Listeners • Methods that wait to receive messages from queues • Separate thread owned by the receiver process • When a message arrives, the listener is “woken up”

Messaging – Point to Point • One consumer • Usually owns the queue • Many producers • Process that wants to send a message to the receiver puts a message on the receivers input queue

Multithreaded and Distributed Programming – How Distributed Programs Communicate