Interprocess Communication And Middleware

IM

NTU

Interprocess Communication and Middleware Yih-Kuen Tsay Dept. of Information Management National Taiwan University Distributed Information Systems 2004

Interprocess Communication and Middleware -- 1

IM

NTU

Sockets and Ports

Node 2

Node 1

Source: G. Coulouris et al., Distributed Systems: Concepts and Design

Distributed Information Systems 2004

Interprocess Communication and Middleware -- 2

IM

NTU

Sockets and Ports

Source: G. Coulouris et al., Distributed Systems: Concepts and Design

Distributed Information Systems 2004

Interprocess Communication and Middleware -- 3

IM

NTU

Purposes of Middleware • • • • •

Higher-level abstractions (RPC, RMI, …) Location transparency Independent of communication protocols Independent of hardware/operating systems Use of several programming languages

Distributed Information Systems 2004

Interprocess Communication and Middleware -- 4

IM

NTU

Local vs. Remote Modules • Variables – Variables of a remote module cannot be directly accessed.

• Parameter-passing Mechanisms – Call by reference, for input parameters, is not feasible for a remote procedure/method.

• Pointers – Pointers of a remote module are not very useful for the local module. * For a module in some process, any other module in a different process, not necessarily a different computer, is a remote module.

Distributed Information Systems 2004

Interprocess Communication and Middleware -- 5

IM

NTU

The Middleware layer

* The operating system includes common network protocols (TCP/IP, …).

Source: G. Coulouris et al., Distributed Systems: Concepts and Design Distributed Information Systems 2004

Interprocess Communication and Middleware -- 6

Marshalling (Serialization) in CORBA CDR

IM

NTU

Source: G. Coulouris et al., Distributed Systems: Concepts and Design

Distributed Information Systems 2004

Interprocess Communication and Middleware -- 7

IM

NTU

Request-Reply Communication

Source: G. Coulouris et al., Distributed Systems: Concepts and Design

Distributed Information Systems 2004

Interprocess Communication and Middleware -- 8

Dealing with Communication Failures

IM

NTU

• What causes a timeout for doOperation? • What should doOperation do after a timeout? • How should duplicate request messages be handled? • What should the server do if a reply message has been lost? – Idempotent operation – History

• Some of the above problems still exist even if one uses TCP. Distributed Information Systems 2004

Interprocess Communication and Middleware -- 9

IM

Request-Reply Communication Using HTTP

NTU

An HTTP request message:

An HTTP reply message:

HTTP is not only a request-reply protocol but also has been used as the transport of other request-reply protocols. SourceInformation of figures: G. Coulouris et al., Distributed Systems: Concepts and Design Distributed Systems 2004 Interprocess Communication and Middleware -- 10

IM

NTU

The Distributed Object Model • Client/Server: two-tier, three-tier, etc. • Interfaces and Interface Definition Languages (IDLs) • Object References (or Identifiers) • Remote Method Invocation (RMI) • Garbage Collection • Exceptions (in particular, timeouts) Distributed Information Systems 2004

Interprocess Communication and Middleware -- 11

IM

NTU

Interactions among Distributed Objects

Source: G. Coulouris et al., Distributed Systems: Concepts and Design

Distributed Information Systems 2004

Interprocess Communication and Middleware -- 12

Interactions among Distributed Objects (cont.)

IM

NTU

Source: G. Coulouris et al., Distributed Systems: Concepts and Design

Distributed Information Systems 2004

Interprocess Communication and Middleware -- 13

A Remote Object and Its Interface

IM

NTU

A client proxy is also known as a client stub and server skeleton as server stub. The remote reference module is mainly for translating between local and remote object references. Source: G. Coulouris et al., Distributed Systems: Concepts and Design Distributed Information Systems 2004 Interprocess Communication and Middleware -- 14

IM

NTU

The RMI Software • Proxy: the local representative of the remote object. • Dispatcher: relays a request to the appropriate skeleton method. • Skeleton: unmarshals the request and invokes the corresponding method in the remote object. • These RMI components are generated automatically by an interface compiler. Distributed Information Systems 2004

Interprocess Communication and Middleware -- 15

RMI/RPC Semantics and Transparency

IM

NTU

Remote invocations may be made syntactically identical to local invocations, but they have far more implications that both the client and the server designers have to deal with. Distributed Source ofInformation the table: G.Systems Coulouris et al., Distributed Systems: Concepts and Design 2004 Interprocess Communication and Middleware -- 16

IM

NTU

A CORBA IDL Example

Source: G. Coulouris et al., Distributed Systems: Concepts and Design Distributed Information Systems 2004 Interprocess Communication and Middleware -- 17

IM

NTU

Issues for RMI • Object Activations – Active vs. passive objects

• Persistent Objects – Passivation, permanent deletion, …

• Object Location • Garbage Collection – Cooperation between a local proxy and its server – Leases

• Synchronization, Replication, Migration, … Distributed Information Systems 2004

Interprocess Communication and Middleware -- 18

IM

NTU

Events • An event is an action performed that may cause changes to the state of an object. • For instance, pushing a button or entering a piece of text is an event. • The state change of an object may trigger state changes of other objects. • Objects responsible for state changes are notified of the event. Distributed Information Systems 2004

Interprocess Communication and Middleware -- 19

IM

NTU

Event-Based Systems • The publish-subscribe paradigm – An object that generates events publishes the type of events. – Other objects subscribe to the type of events of interest. – A publisher sends subscribers a notification ---- an object representing a subscribed event, when the represented event occurs.

• Two main characteristics: – Heterogeneous: with suitable RMI interfaces for receiving notifications – Asynchronous: decoupling publishers and subscribers Distributed Information Systems 2004

Interprocess Communication and Middleware -- 20

IM

NTU

A Dealing Room System External source

Dealer’s computer Dealer

Dealer’s computer

Notification

Notification

Notification

Information provider Notification

Notification

Dealer

Notification

Notification Dealer’s computer

Dealer’s computer Notification

Notification

Information provider Notification

Dealer

Dealer External source

Source: G. Coulouris et al., Distributed Systems: Concepts and Design

Distributed Information Systems 2004

Interprocess Communication and Middleware -- 21

IM

NTU

An Architecture for Event Notification Event service subscriber

object of interest 1.

notification

object of interest 2. object of interest 3.

notification

observer

subscriber notification

observer

subscriber notification

Note: Java-based event system (specification) Jini has a similar Source: G. Coulouris et al., Distributed Systems: Concepts and Design architecture. Distributed Information Systems 2004

Interprocess Communication and Middleware -- 22

IM

NTU

The Roles for Observers/Agents

• • • •

An observer decouples an object of interest from its subscribers. The roles it plays include: Forwarding Filtering Allowing patterns of events to be subscribed Notification mailboxes: a subscriber may check notifications intended for it later.

Distributed Information Systems 2004

Interprocess Communication and Middleware -- 23

IM

NTU

Java Remote Interfaces

Source: G. Coulouris et al., Distributed Systems: Concepts and Design

Distributed Information Systems 2004

Interprocess Communication and Middleware -- 24

IM

NTU

Parameter Passing in Java • By reference (passed as remote object references) – For parameters whose type is defined as a remote interface, one that extends Remote

• By value (new objects created at local site) – For parameters of serializable types, including primitive types and classes that implement the serializable interface

• Classes for arguments and results are downloaded automatically to the recipient. Distributed Information Systems 2004

Interprocess Communication and Middleware -- 25

IM

NTU

The Naming Class of RMIRegistry

Source: G. Coulouris et al., Distributed Systems: Concepts and Design

Distributed Information Systems 2004

Interprocess Communication and Middleware -- 26

IM

NTU

A Java Server

Note:

The server acts like a shared

Source: G. Coulouris et al., Distributed Systems: Concepts and Design

Distributed Information Systems 2004

Interprocess Communication and Middleware -- 27

IM

NTU

A Java Server (cont.)

Distributed Source:Information G. CoulourisSystems et al., Distributed Systems: Concepts and Design 2004 Interprocess Communication and Middleware -- 28

IM

NTU

A Java Client

Distributed Source:Information G. CoulourisSystems et al., Distributed Systems: Concepts and Design 2004 Interprocess Communication and Middleware -- 29

IM

NTU

CORBA • Defined by OMG to facilitate the development of distributed object-oriented systems. • Language-independency is achieved through the use of a standard interface definition language--the CORBA IDL. • An ORB (Object Request Broker) receives invocations from a client and deliver them to a target object. • The main communication protocol is GIOP (General Inter-ORB Protocol), known as IIOP when implemented over the Internet. Distributed Information Systems 2004

Interprocess Communication and Middleware -- 30

IM

NTU

The CORBA Architecture *

**

•*

The implementation repository allows server objects to be activated on •demand. ** The interface repository gives run-time type information, mainly for dynamic invocations. Source Information of the figure:Systems G. Coulouris et al., Distributed Systems: Concepts and Design Distributed 2004 Interprocess Communication and Middleware -- 31

IM

NTU

The Object Adapter • Creates remote object references for CORBA objects • Maps the names of CORBA objects to their servants • Dispatches each remote invocation via a skeleton to the appropriate server object • Activate objects

Distributed Information Systems 2004

Interprocess Communication and Middleware -- 32

IM

NTU

CORBA Object Interfaces • Each object has an interface defined in IDL. • An interface defines the operations that can be called by the clients. • An interface can be implemented in one language and called from by another. • The CORBA IDL includes features such as inheritance of interfaces, exceptions, and compound data types. Distributed Information Systems 2004

Interprocess Communication and Middleware -- 33

IM

NTU

CORBA Programming with Java • Define the interfaces using IDL and compile them into Java interfaces. • Implement the interfaces with Java classes. • Write a server main function that creates instances of these classes and then inform the underlying CORBA implementation. • Register the server. • Write a client main function to connect to the server and to use server’s objects.

Distributed Information Systems 2004

Interprocess Communication and Middleware -- 34

IM

NTU

Shape and Shapelist in CORBA IDL

Distributed Information Systems Source: G. Coulouris et al., Distributed Systems: Concepts and Design 2004 Interprocess Communication and Middleware -- 35

Java Interface Generated from ShapeList

IM

NTU

Source: G. Coulouris et al., Distributed Systems: Concepts and Design

Distributed Information Systems 2004

Interprocess Communication and Middleware -- 36

Java Implementation of Shapelist

IM

NTU

Distributed Information Systems Source: G. Coulouris et al., Distributed Systems: Concepts and Design 2004 Interprocess Communication and Middleware -- 37

IM

NTU

Java Implementation of ShapeList (cont.)

Distributed Source:Information G. CoulourisSystems et al., Distributed Systems: Concepts and Design 2004 Interprocess Communication and Middleware -- 38

IM

NTU

Java Implementation of ShapeList (cont.)

Distributed Information Systems Source: G. Coulouris et al., Distributed Systems: Concepts and Design 2004 Interprocess Communication and Middleware -- 39

IM

NTU

CORBA Services • Naming Service – locate objects by their names

• Trading Service – locate objects by their attributes

• Event Service and Notification Service • Security Service • Transaction Service and Concurrency Control Service • Persistent Object Service Distributed Information Systems 2004

Interprocess Communication and Middleware -- 40

IM

NTU

The CORBA Naming Service • Allows (1) a name to be bound to an object and (2) that object to be found subsequently by resolving that name. • A name is a sequence of name components and is resolved within a given naming context. • The IDL interface NamingContext defines the core of the naming service. • A NamingContext object acts much like a directory in a filing system. Distributed Information Systems 2004

Interprocess Communication and Middleware -- 41

IM

NTU

CORBA Naming Graph initial naming context

ShapeList

initial naming context

B

initial naming context

XX

P

V

C D

E

R

S

Q

U

T

Source: G. Coulouris et al., Distributed Systems: Concepts and Design

Distributed Information Systems 2004

Interprocess Communication and Middleware -- 42

The NamingContext Interface (partial)

IM

NTU

struct NameComponent { string id; string kind; }; typedef sequence  Name; interface NamingContext  { void bind (in Name n,  in Object  obj); binds the given name and remote object reference in my context. void unbind (in Name n); removes an existing binding with the given name. void bind_new_context(in Name n); creates a new naming context and binds it to a given name in my context. Object  resolve (in Name n);  looks up the name in my context and returns its remote object reference.  void list  (in unsigned long how_many, out BindingList bl, out BindingIterator bi); returns the names in the bindings in my context. }; Source: G. Coulouris et al., Distributed Systems: Concepts and Design

Distributed Information Systems 2004

Interprocess Communication and Middleware -- 43

IM

NTU

COM/DCOM • COM stands for Component Object Model. Its distributed version is referred to as DCOM. • It is a programming model for binary components reuse and a foundation of OLE (Object Linking and Embedding) and ActiveX controls. • COM interfaces are defined in the interface definition language IDL and compiled by MIDL.EXE.

Distributed Information Systems 2004

Interprocess Communication and Middleware -- 44

IM

NTU

COM Objects • All COM objects implement the IUnknown interface (defined in unknwn.idl) or one of its extended interfaces. • Methods of IUnknown: – QueryInterface: checks if the named interface is supported and, if so, returns the corresponding interface reference – AddRef – Release

• A COM object may implement multiple interfaces. Distributed Information Systems 2004

Interprocess Communication and Middleware -- 45

IM

NTU

How a COM Interface Works Interface Pointer Interface Function Table pointer

Pointer to Function1 Pointer to Function2 Pointer to Function3 ...

Function1(...) { ... } Function2(...) { ... } Function3(...) { ... }

...

Source: Microsoft, The COM Specification.

Distributed Information Systems 2004

Interprocess Communication and Middleware -- 46

IM

NTU

Creation of a COM Object Server Client

(1) “Create an Object”

Class Factory (3) Return new interface pointer to client

(2) Manufacture Object

Object

Source: Microsoft, The COM Specification.

Distributed Information Systems 2004

Interprocess Communication and Middleware -- 47

IM

NTU

Location Transparency in COM Client Process

Local Server Process

In-Process Object

Client Application

Local Object

Stub

In-Process Server RPC

COM

Local Server

Local Object Proxy

Remote Machine

COM

Remote Server Process

Remote Object Proxy

RPC

Stub

COM

Remote Object

Remote Server

Source: Microsoft, The COM Specification.

Distributed Information Systems 2004

Interprocess Communication and Middleware -- 48

IM

NTU

GUIDS • To eliminate name collisions, all COM interfaces are assigned a unique binary name at design time that is the physical name of the interface. • These physical names are called Globally Unique Identifiers (GUIDs). • GUIDs are 128-bit extremely large numbers that are guaranteed to be unique in both time and space. Distributed Information Systems 2004

Interprocess Communication and Middleware -- 49

IM

NTU

The IUnknown Interface [ object, uuid(00000000-0000-0000-C000-000000000046), pointer_default(unique) ] interface IUnknown { HRESULT ULONG ULONG } Distributed Information Systems 2004

QueryInterface([in] REFIID iid, [out] void **ppv) ; AddRef(void) ; Release(void);

Interprocess Communication and Middleware -- 50