Interprocess Communication and Middleware

1
Interprocess Communication and Middleware

• Yih-Kuen Tsay
• Dept. of Information Management
• National Taiwan University

2
Middleware

• Note middleware provides a bridge across
  different platforms.

Source Coulouris et al., Distributed Systems
Concepts and Design
3
Purposes of Middleware

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

4
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.

5
The Middleware layer
Note The operating system provides common
network protocols (UDP, TCP, ).
Source Coulouris et al., Distributed Systems
Concepts and Design
6
Sockets and Ports
Node 2
Node 1

• Note Sockets provide an operating system
  abstraction for UDP/TCP.

Source Coulouris et al., Distributed Systems
Concepts and Design
7
Marshalling (Serialization) in CORBA CDR
Source Coulouris et al., Distributed Systems
Concepts and Design
8
Remote Object References

• System-wide unique (non-reusable) identifiers for
  remote objects
• Passed in an invocation message, to identify the
  object whose method is to be invoked
• Can also be passed as inputs or results of a
  remote invocation

Source Coulouris et al., Distributed Systems
Concepts and Design
9
Request-Reply Communication
Source Coulouris et al., Distributed Systems
Concepts and Design
10
Dealing with Communication Failures

• 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.

11
Request-Reply Communication Using HTTP
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.
Source of figures Coulouris et al., Distributed
Systems Concepts and Design
12
Distributed Objects

• System architectures mainly client/server
  (two-tier, three-tier, etc.)
• Remote Interfaces and Interface Definition
  Languages (IDLs)
• Remote Object References (or Identifiers)
• Remote Method Invocation (RMI)
• Garbage Collection
• Exceptions (in particular, timeouts)

13
A CORBA IDL Example
Source Coulouris et al., Distributed Systems
Concepts and Design
14
Interactions among Distributed Objects
Source Coulouris et al., Distributed Systems
Concepts and Design
15
Interactions among Distributed Objects (cont.)
Source Coulouris et al., Distributed Systems
Concepts and Design
16
Two Design Issues in RMI

• Invocation Semantics
• Transparency

17
Invocation Semantics of RMI

• Maybe
• The method may be executed or not at all
• When occasional failed operations are acceptable
• At-least-once
• The invoker receives either (1) a result (the
  method was executed at least once) or (2) an
  exception
• When operations have been made idempotent
• At-most-once
• The invoker receives either (1) a result (the
  method was executed exactly once) or (2) an
  exception (the method might have been executed
  once)
• Java and CORBA

18
Invocation Semantics of RMI (cont.)
Note 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.
Source of the table Coulouris et al.,
Distributed Systems Concepts and Design
19
Transparency in RMI

• Should local and remote method invocations be
  distinguished?
• Programming convenience
• marshalling/unmarshalling, object location, etc.
  should be hidden
• Fault handling
• Concurrency control

20
Implementation of RMI
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 Coulouris et al., Distributed Systems
Concepts and Design
21
Implementation of RMI (cont.)

• Communication Module requests and replies
• Remote Reference Module
• Object table entries creation
• Table lookup
• The RMI Software generated automatically by an
  interface compiler
• 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

22
Implementation of RMI (cont.)

• Dynamic Invocation
• Object Activation active vs. passive objects
• Persistent Objects passivation, permanent
  deletion,
• The Binder and Object Location
• Garbage Collection
• Cooperation between a local proxy and its server
• Leases
• Synchronization (because of threads),
  Replication, Migration,

23
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.

24
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

25
A Dealing Room System
Source Coulouris et al., Distributed Systems
Concepts and Design
26
An Architecture for Event Notification
NNote Java-based event system (specification)
Jini has a similar architecture.
Source Coulouris et al., Distributed Systems
Concepts and Design
27
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.

28
Java RMI

• Invoking a remote method is just like invoking a
  local one
• The caller must handle RemoteExceptions
• The callee must implement the Remote interface
• The semantics of parameter passing differ (from
  those for local invocations)

29
Java Remote Interfaces





NNote GraphicalObject must implement the
Serializable interface.
Source Coulouris et al., Distributed Systems
Concepts and Design
30
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.

31
Serialization in Java RMI
Source Coulouris et al., Distributed Systems
Concepts and Design
32
The RMIRegistry in Java

• The binder for Java RMI
• An instance of RMIRegistry on every server
  hosting remote objects
• Maintaining a table mapping textual, URL-style
  names (//computerNameport/objectName) to remote
  object references

33
The Naming Class of RMIRegistry
Source Coulouris et al., Distributed Systems
Concepts and Design
34
A Java Server
Source Coulouris et al., Distributed Systems
Concepts and Design
35
A Java Server (cont.)
Source Coulouris et al., Distributed Systems
Concepts and Design
36
A Java Client
Source Coulouris et al., Distributed Systems
Concepts and Design
37
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.

38
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 of the figure Coulouris et al.,
Distributed Systems Concepts and Design
39
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

40
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.

41
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 servers objects.

42
Shape and Shapelist in CORBA IDL
Source Coulouris et al., Distributed Systems
Concepts and Design
43
Java Interface Generated from ShapeList
Source Coulouris et al., Distributed Systems
Concepts and Design
44
Java Implementation of Shapelist
Source Coulouris et al., Distributed Systems
Concepts and Design
45
Java Implementation of ShapeList (cont.)
Source Coulouris et al., Distributed Systems
Concepts and Design
46
Java Implementation of ShapeList (cont.)
Source Coulouris et al., Distributed Systems
Concepts and Design
47
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

48
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.

49
CORBA Naming Graph
initial naming context
initial naming context
initial naming context
XX
ShapeList
B
V
P
C
T
D
E
S
R
Q
U
Source Coulouris et al., Distributed Systems
Concepts and Design
50
The NamingContext Interface (partial)

• struct NameComponent string id string kind
• typedef sequence ltNameComponentgt 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 Coulouris et al., Distributed Systems
Concepts and Design
51
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.

52
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.

53
How a COM Interface Works
Source Microsoft, The COM Specification.
54
Creation of a COM Object
Source Microsoft, The COM Specification.
55
Location Transparency in COM
Source Microsoft, The COM Specification.
56
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.

57
The IUnknown Interface
object, uuid(00000000-0000-0000-C000-0000000
00046), pointer_default(unique) interface
IUnknown HRESULT QueryInterface(in REFIID
iid, out void ppv) ULONG AddRef(void)
ULONG Release(void)