Title: Middleware Layers
1Middleware Layers
2Interprocess Communication
- Point-to-point message passing is typically based
on two message communication operations
(subroutines). - Send A process copies a message (a sequence of
bytes) into the (incoming) buffer of a remote
system. - Receive A process copies a message from the
(incoming) buffer of its system into its local
memory. - Typically, Receive must be called before the
corresponding Send. - Unbuffered communication If a receive has not
been called before the message arrives it is
lost! - Alternatively, some incoming messages are kept
temporarily in a buffer (mailbox) assuming that a
suitable receive will be called soon. - Otherwise there is a time-out or a buffer
overflow. - Failure model
3Communication Types
- Synchronous Communication The sending and
receiving processes synchronize each other at
every message. - The Send and the Receive operations are blocking.
- The Send process is blocked until the
corresponding Receive is issued. - The Receive process is blocked until a message
arrives. - Asynchronous Communication
- The sending process is allowed to proceed as soon
as the message has been sent to the outgoing
(local) buffer. - The Send operation is non-blocking.
- The Receive operation may be either blocking or
non-blocking.
4Message Destinations
- Internet protocol Messages are sent to (Internet
address, local port) pairs. - Local port Message destination within a computer
- specified as integer
- A port has exactly one receiver (exception
multicast ports, UDP) but possibly many senders - A process may use multiple ports to receive
messages. - A process must know the destination port number
to send a message to this port. - Alternative solution Messages are addressed to
processes - Ports provide alternative points of entry to a
receiving process..
5Sockets
- Sockets are endpoints for communication between
processes. - They originate from BSD UNIX but are also found
in other OS. - They are used by UDP and TCP.
- Each socket is associated with a particular
protocol. - Interprocess communication consists of
transmitting a message between a socket in one
process and a socket in another process. - A socket must be bound to a local port and an
Internet address of the computer on which it
runs. - Processes may use the same socket for sending and
receiving messages.
6Sockets and Ports
agreed port
any port
socket
socket
message
client
server
other ports
Internet address 138.37.88.249
Internet address 138.37.94.248
7UDP Datagram Communication
- UDP is unreliable and does not support
acknowledgements and retries. - If a message does not arrive, a failure occurs.
- Most environments support a message size of 8kB.
- Larger messages must be fragmented.
- The receiving process needs to specify an array
for the message. - The message is truncated it is too long.
- UDP uses non-blocking sends and blocking
receives. - A message is placed in a queue for the socket and
can be collected by a future receive. - Time-outs can be set on sockets.
- The message is discarded if the no socket is
bound to the receiving port. - A receive gets any message addressed to this
socket.
8TCP Stream Communication
- TCP is reliable and uses and acknowledgement
scheme. - Sliding window
- The TCP stream is transmitted as one or more IP
packets (implementation dependent). - TCP tries to match the speed of the processes
writing to or reading from a stream Flow
control. - A sender may be blocked.
- Due to message identifiers the recipient can
detect and reject duplicates and reorder message
if necessary. - A pair of communicating process must establish a
connection before using a stream. - Once the connection exists no Internet addresses
and ports are necessary to write to or read from
the stream. - The processes must agree on the content of the
message.
9Failure Models for UDP and TCP
- UDP uses a checksum to ensure that a message is
not corrupted. - Some messages may get lost (omission failures).
- Messages may arrive out of sender order.
- TCP uses checksums to detect and reject corrupt
packets. - TCP uses sequence numbers to detect and reject
duplicate packets. - TCP uses timeouts and retransmissions to deal
with lost packets. - After a long time without acknowledgement TCP
will declare the connection to be broken. - The processes cannot distinguish between network
failure and failure of the process at the other
end of the connection. - In this case, a process cannot tell whether its
most recent messages have been received.
10External Data Representation (1)
- The information used by running programs is
stored in data structures whereas the information
in messages consists of sequences of bytes. - A data structure must be flattened before
transmission and must be rebuilt on arrival. - The representation of primitive data items
(integer, floating point) may differ between
different computers or operating systems. - Example little-endian and big-endian
- Marshalling
- The process of taking a collection of data items
and assembling them into a form suitable for
transmission - Unmarshalling
- Reverse process on arrival of a message
11External Data Representation (2)
- Alternatives
- The values are converted to an agreed external
format before the transmission and converted to
the local form afterwards - External data representation
- The values are transmitted in the format of the
sender together with an indication of the format
used. The recipient converts the data if
necessary. - Examples
- CORBAs Common Data Representation (CDR)
- It can be used for a variety of programming
languages. - Javas Object Serialization
- It can be used for Java only.
- XML textual format for representing structured
data (web services) - The conversion is done by the middleware!
12CORBA CDR
- CDR can represent all data types that can be used
as arguments or return values of remote
invocations in CORBA. - 15 primitive types
- short (16-bit), long (32-bit), unsigned short,
unsigned long, float (32-bit), double (64-bit),
char, boolean, octet (8-bit), - constructed types
- Primitive types
- CORBA defines a representation for big-endian and
little-endian. - Transmission in the ordering of the sender
- Floating point values use the IEEE standard.
- CORBA assumes that both the server and the client
have common knowledge of the order and types of
the data items. - The type of a data item is not transmitted.
13CORBA CDR for Constructed Types
14CORBA CDR message
index in sequence of bytes
notes on representation
4 Bytes
The flattened form represents a Person struct
with value Smith,London,1934
15Java Object Serialization (1)
- In Java, a class can state that it implements the
Serializable interface. - The instances of this class can be serialized.
- Serialization Flattening an object or a
connected set of objects. - Deserialization Restoring the state of an object
from it serialized form. - The process performing the deserialization has no
prior knowledge of the types of the objects in
the serialized form. - Information about the class of each object is
included in the serialized form. - The recipient can load the appropriate class when
an object is deserialized.
16Java Object Serialization (2)
- Java objects can contain references to other
objects. - References are serialized together with the
object handles. - There must be a 1-1 correspondence between object
references and handles. - Each object is written only once on an
subsequent occurrence of an object the handle is
written instead of the object. - During serialization, classes and instances are
written in a recursive way. - Primitive types are written in a portable format.
- Transient variables and references to local
resources are not serialized. - Reflection The ability of enquiring about the
properties of a class.
17Example Java Object Serialization
- public class Person implements Serializable
- private String name
- private String place
- private int year
- public Person String aName, String aPlace, int
a Year) - name aName
- place aPlace
- year aYear
-
- // followed by methods for accessing the
instance variables
18Java Serialized Form
The true serialized form contains additional type
markers h0 and h1 are handles.
19Extensible Markup Language (XML) (1)
- XML was defined by the World Wide Web Consortium
(W3C). - XML data items are tagged with markup strings.
- Tags describe the logical structure of the data
- Tags associate attribute-value pairs to logical
structures - XML is textual
- It is readable by any computer and by humans
- It requires more resources. ( processing,
transmission) - User can define their own tags XML is
extensible. - An XML document is well formed
- It conforms to the rules about its structure
- It is easy to implement parsers
20XML Definition of the Person Structure
ltperson id"123456789"gt ltnamegtSmithlt/namegt ltpl
acegtLondonlt/placegt ltyeargt1934lt/yeargt lt!-- a
comment --gt lt/person gt
21Extensible Markup Language (XML) (2)
- XML namespace A set of names for a collection of
element types and attributes - An element can specify an XML namespace as an
attribute. - An XML document may be defined in the form of
several different namespaces (each referenced by
a unique prefix) - An XML schema defines the elements and attributes
that can appear in a document. - Nesting of elements
- Order and number of elements
- Type and default value of elements
- A single schema may be shared by many documents.
22Namespace in the Person Structure
ltperson persid"123456789" xmlnspers
"http//www.cdk4.net/person"gt ltpersnamegt
Smith lt/persnamegt ltpersplacegt London
lt/persplace gt ltpersyeargt 1934
lt/persyeargt lt/persongt
23XML Schema for the Person Structure
ltxsdschema xmlnsxsd URL of XML schema
definitions gt ltxsdelement name "person" type
"personType" /gt ltxsdcomplexType
name"personType"gt ltxsdsequencegt
ltxsdelement name "name" type"xsstring"/gt
ltxsdelement name "place"
type"xsstring"/gt ltxsdelement name
"year" type"xspositiveInteger"/gt
lt/xsdsequencegt ltxsdattribute name "id"
type "xspositiveInteger"/gt lt/xsdcomplexTypegt
lt/xsdschemagt
24Remote Object Reference
- Remote Object Reference Identifier of a remote
object that is valid throughout the system. - Remote object references is passed in an
invocation message. - Remote object references must be unique in space
and time. - A remote object reference cannot be reused even
if the corresponding object is deleted. - The reference contains the internet address, port
number, time of creation and local object number. - The local object number is incremented each time
an object is created. - It may be necessary to relocate a remote object.
- A remote object reference should not be used as
the address of the remote object.
25Example Remote Object Reference
26Request-Reply Protocol (1)
- Typically, request-reply communication is
synchronous. - The client blocks until the reply arrives from
the server. - If the client can afford to retrieve replies
later - It may use an asynchronous alternative.
- TCP is frequently used for request-reply
protocols although there are unnecessary
overheads associated with TCP - Some acknowledgements are redundant, as request
are followed by replies. - Establishing a connection involves 2 extra pair
of messages. - Flow control is not necessary as most messages
are small.
27Request-Reply Protocol (2)
- A simple request-reply protocol is based on 3
communication primitives - doOperation
- It is used by clients to invoke remote
operations. - It contains several arguments (remote object,
method). - After sending the request message, doOperation
invokes receive to get a reply message (blocking
communication). - getRequest
- It is used by the server to acquire service
requests from other processes via the server
port. - sendReply
- It is used by the server to send the result to
the client - Upon receive it unblocks doOperation at the
client.
28Request-Reply Communication
Client
Server
Requestmessage
Replymessage
29Request-Reply Message Structure
30Failure Model of the Protocol
- If the request-reply protocol is implemented over
UDP it is subject to the UDP failure model. - Timeout of doOperation
- doOperation may fail immediately.
- doOperation may resend the message until
- sendReply is received or
- there is no reply for a given number of tries
(failure). - Discarding duplicate request messages
- The server identifies messages (use of a request
identifier). - Lost reply messages
- An idempotent operation can be executed again.
- A history buffer can be used to resend the reply.
31Invocation Semantics
32Alternative Protocols
- Request protocol
- It may be used when no value need to be returned
from the server. - The client is not blocked until a reply arrives.
- Request-Reply-Acknowledge Reply protocol
- This protocol allows the server to delete entries
from the history buffer. - The acknowledgement message is interpreted as
acknowledging all message with a lower requestID. - Loss of an acknowledgement message is harmless
- The acknowledgement message does not block the
client. - It consumes network and processing resources.
33RPC Exchange Protocols
Name
Messages sent by
Client
Server
Client
R
Request
R
R
Reply
Request
R
R
A
Acknowledge reply
Request
Reply
34HTTP A Request-Reply Protocol
- HTTP is implemented over TCP
- The client requests and the server accepts a
connection at a server port. - default port or port specified in the URL
- The client sends a request message to the server.
- The server sends a reply message to the client.
- content of a page and/or applet
- result of a program (cgi script or servlet)
- The connection is closed.
- HTTP 1.1 uses persistent connections.
- They remain open over a series of request-reply
exchanges. - They are close by either communication partner.
35HTTP Request Message
36HTTP Reply Message
37Group Communication
- Sometimes a process need to communicate with a
group of other processes. - Multicast operation An operation that sends a
message from one process to each member of a
group of processes. - Fault tolerance based on replicated services
- Several processes obtain the request and try to
satisfy it. - Finding the discovery servers in spontaneous
networking - It is unknown which discovery server is actually
reachable. - Better performance through replicated data
- Changed data are sent to all processes managing
the data. - Propagation of event notifications
- Several processes must be informed of an event.
38IP Multicast
- For application programs IP multicast is
available only via UDP. - It has the same failure characteristics as UDP.
- Some but not all members of the target group may
receive a message unreliable multicast. - A multicast group is specified by a specific IP
address. - Class D Internet address, 1110x.x.x.x in IPv4
- The sender does not know the identities of the
members of the group. - The membership of a multicast group is dynamic.
- Multicast addresses can be permanent or
temporary. - Permanent addresses 224.0.0.1 to 224.0.0.255
39Sockets Used for Datagrams
40Sockets Used for Streams
Requesting a connection
Listening and accepting a connection
s socket(AF_INET, SOCK_STREAM,0)
s socket(AF_INET, SOCK_STREAM,0)
bind(s, ServerAddress)
listen(s,5)
connect(s, ServerAddress)
sNew accept(s, ClientAddress)
write(s, "message", length)
n read(sNew, buffer, amount)
ServerAddress and ClientAddress are socket
addresses
41Middleware Layers
42Programming Models
- In distributed applications programs need to
invoke operations in other processes, often
running in different computers. - Conventional programming models have been
extended to address those situations. - Access transparency should be observed.
- Remote Procedure Call
- Client programs call procedures running in
separate processes. - Remote Method Invocation
- An object living in one process can invoke a
method of an object living in another process. - Event-based Programming
- Objects receive notifications of events at
objects living in another process if they have
registered their interest.
43Remote and Local Method Invocations
local invocation
C
E
F
remote invocation
local invocation
A
B
remote invocation
local invocation
D
44Module Interfaces (1)
- In distributed systems an explicit interface must
be defined for each module. - Procedures, that can be accessed from other
modules, are specified. All additional
information about the module is hidden. - It is not possible to directly access a variable
in a module in another process. - Use of a procedure instead.
- Parameters of the procedure are declared as input
or output parameters or both. - Input parameters are sent as values in the
request message. - Output parameters are sent as values in the reply
message. - Pointers in one process are not valid in a remote
process. - Call by reference is impossible.
45Module Interfaces (2)
- A Service Interface is used to specify the
procedures offered by a server in the RPC
programming model. - The types of input and output arguments of each
procedure are defined. - A Remote Interface is used to specify the methods
of an object that are available for invocation by
objects in other processes. - The types of input and output arguments of each
method are defined. - Objects and references to remote objects can be
passed as arguments and results. - An Interface Definition Language (IDL) is defined
to allow objects implemented in different
languages to invoke one another.
46CORBA IDL Example
// In file Person.idl struct Person string
name string place long year interface
PersonList readonly attribute string
listname void addPerson(in Person p) void
getPerson(in string name, out Person p) long
number()
47A Remote Object and its Remote Interface
remote object
Data
remote interface
m1 m2 m3
implementation of methods
m4 m5 m6
48The Object Model (1)
- In a distributed object system, an objects data
are accessible only via its methods. - Encapsulation of the data
- This is not completely enforced by some object
oriented languages like Java and C. - Objects are accessed via object references.
- Object references can be assigned to variables
and passed as arguments. - A remote object reference is an identifier that
can be used throughout the distributed system to
refer to a particular unique remote object. - The representation of a remote object reference
is different from that of local object
references. - The object whose method is invoked is called
receiver or target of an invocation.
49The Object Model (2)
- An action is a chain of related method
invocations, each of which eventually returns. It
is initiated by an object invoking another
object.An invocation of a method may result in - a change of the state of the receiver
- further invocations of methods in other objects.
-
- Exceptions provide a clean way to handle error
conditions without complicating the code. - Upon an error or an unexpected condition a block
of code throws an exception. - Control passes to another block of code that
catches the exception. - Control does not return to the first code block.
- In a distributed system, additional exceptions
are necessary. - Timeout of a network connection, remote process
crash,
50Instantiation of Remote Objects
51Access Transparency
- There are several necessary conditions to achieve
access transparency for RPC and RMI. - All calls to marshalling and message passing must
be hidden from the programmer of a procedure. - In RMI, the task of locating and contacting a
remote object must be hidden as well. - The semantics of a remote procedure call and of a
local procedure call must be identical. - However, there are some differences that cannot
be hidden. - Differences in the invocation latency
- Differences in failure types
- Those differences between remote and local
invocations are expressed in the interface.
52Invocation Semantics
53Implementation of RMI (1)
- Several separate objects and modules are involved
in achieving a remote method invocation. - Communication moduleThe two cooperating
communication modules execute the request-reply
protocol. - They provide a specified invocation semantic.
- The communication module in the server obtains
the local object reference from the remote
reference module in return for the remote object
reference in the request message. - It selects the dispatcher for the class of the
object to be invoked. - It passes the local object reference to the
dispatcher.
54Implementation of RMI (2)
- Remote reference moduleIt translates between
local and remote object references. The local
object reference may either refer to a local
object or to a local proxy. - The remote reference table of the module contains
- an entry for all remote objects held by the
process and - an entry for each local proxy.
-
- The module creates a remote object reference
when a remote object is passed as argument or
result for the first time. - The remote object reference is added to the
table. -
- If a remote object reference arrives but is not
in the table, the RMI software generates a new
proxy. - An entry for the proxy is added to the table.
55Implementation of RMI (3)
- The RMI softwareIt contains several types of
objects. - Proxy It generates access transparency for the
local invoker. It hides the details of remote
object references, (un)marshalling, sending and
receiving messages.There is one proxy for each
remote object for which a process holds a remote
object reference.A server has one dispatcher
and one skeleton for each class representing a
remote object located at the server. - Dispatcher It receives the request message from
the communication module and selects the
appropriate method in the skeleton. - Skeleton It implements the methods of the remote
interface including (un)marshalling, invoking the
appropriate method, and generating the reply
message.
56Proxy and Skeleton in Remote Method Invocation
Client
Server
proxyfor B
remote object B
skeleton dispatcher for Bs class
object A
Request
Reply
servant
remotereference module
communicationmodule
remote reference module
communicationmodule
57Implementation of RMI (4)
- Server and client programsThe classes for the
proxy, dispatcher and skeleton used in the RMI
software are generated automatically by an
interface compiler. - The Java RMI compiler derives those classes from
the class of the remote object. -
- The server program contains an initialization
section.It creates and initializes at least one
of the remote objects hosted by the server. It
will register some of the remote objects with a
binder. Usually a separate server thread will be
allocated for the execution of each remote
invocation. - The client program uses the binder to look up
remote object references.
58Implementation of RMI (5)
- The binderA client program needs a remote object
reference for at least one remote object held by
a server.The server program registers their
remote objects by name.The binder is a separate
service with a table containing a mapping from
textual names to remote object references. - RMIregistryThe binder for JavaRMI. However, it
is not a system-wide binding service. - CORBA Naming ServiceThe binder for CORBA. The
binder is rather sophisticated with the names
being structured in a hierarchic fashion. Names
are bound to remote object references within
naming contexts.
59The Naming class of Java RMIregistry
- void rebind (String name, Remote obj)
- registers the identifier of a remote object by
name. - void bind (String name, Remote obj)
- registers the identifier of a remote object by
name. If the name is already bound to a remote
object reference an exception is thrown. - void unbind (String name, Remote obj)
- removes a binding.
- Remote lookup (String name)
- looks up a remote object by name. A remote
object reference is returned. - String list ()
- returns an array of Strings containing the
names bound in the registry.
60Part of the CORBA Naming ServiceNamingContext
interface in IDL
- 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 a 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. -
61Naming Graph in CORBA Naming Service
Initial naming context
Initial naming context
XX
P
V
S
U
T
R
Q
Naming context
CORBA object
62Implementation of RMI (6)
- Activation of remote objectsSome data must
survive for a long period of time. However, it is
not practical to keep objects representing this
data in running processes for unlimited periods. - An active remote object is available for
invocation within a running process. - A passive remote object is not currently active
but can be made active with a remote object
called activator. It consists of - the implementation of its methods and
- its state in the marshalled form.
- Activation consists of creating an active object
from the corresponding passive object by creating
a new instance of its class and initializing the
instance variables with the stored state.
63Implementation of RMI (7)
- An activator is responsible for
- Registering passive objects that are available
for activation. - Starting named server processes and activating
remote objects in them. - Keeping track of the locations of the servers for
remote objects that it has already activated. - Persistent object An object that is guaranteed
to live between activations of processes. - Persistent objects are managed by persistent
object stores. - CORBA persistent object service
- Persistent Java
64Garbage Collection (1)
- It is advantageous to free the space occupied by
objects that are no longer needed. - Garbage collection Automatic detection of
objects that are no longer accessible and
recovery of the space, e.g. in Java. - Distributed garbage collectionFreeing the space
of any object to which no other object holds a
reference. - Each server maintains a set of processes that
hold remote object references for each of its
remote objects. - When a client first receives a remote reference
to a particular remote object it creates a proxy
and informs the server. - When a clients local garbage collector removes
the proxy of a remote object it informs the
server. - When the set of the server is empty and there are
no local references the garbage collector of the
server deletes the object.
65Garbage Collection (2)
- Distributed garbage collection can be carried out
by means of pair wise request-reply
communication with at-most-once invocation
semantics. - No global synchronization is required.
- Timing problems between a remove and an add
request can be solved by use of a temporary entry
in the set. - In the Java distributed garbage collector the
remove and the add request are idempotent. - Failed add requests are followed by a remove
request. - Servers lease their objects to clients for a
limited period of time. Clients may renew the
lease.
66Remote Procedure Call
- The client has one client stub procedure for each
procedure of the service interface. - The role of the client stub procedure is similar
to that of a proxy in RMI. - The server has a dispatcher and one server stub
procedure and one service procedure for each
procedure in its service interface. - The server stub procedure is like the skeleton in
RMI. - The service procedures implement the procedures
in the service interface. - The client and server stub procedures and the
dispatcher can be generated by an interface
compiler from the interface definition of the
service.
67Client and Server Stub Procedures in RPC
client process
server process
Request
Reply
server stub procedure
client stub procedure
client program
communicationmodule
service procedure
dispatcher
communicationmodule
68Events and Notifications (1)
- In some applications, clients want a reply from a
server as soon as a certain condition becomes
valid, that is, when a change in another object
has occurred. Such a change is called an event. - The client does not want to be blocked until the
event occurs. - The server sends a object representing this event
as soon the event has occurred. This object is
called a notification. - Notifications are sent asynchronously.
- Components in an event based system can be
heterogeneous. Client objects only need to
publish an interface to receive notifications. - The object that generates the event publishes the
type of events that are made available for
observation by other objects. - The object that wants to receive a notification
of an event subscribes to the event or registers
interest in the event.
69Events in a Dealing Room System
External source
Dealers computer
Dealers computer
Notification
Notification
local invocation
Notification
Information provider
Notification
F
B
Notification
Notification
Notification
Dealers computer
Dealers computer
Notification
Information provider
Notification
Notification
External source
70Events and Notifications (2)
- The object of interest experiences a change of
state. It is part of the event service if it
transmits notifications. - An event source can generate events of different
types. - The type is specified when an object subscribes
to an event. - An event has attributes that specify information
about the event. - Identifier of the object of interest, time stamp,
operation, - A notification contains the type of the event and
its attributes. - A subscriber is an object that receives
notifications about events it has subscribes to. - An observer object decouples the object of
interest from its subscribes - One or more observers can be interposed between
an object of interest and its subscribers. - A publisher is an object that declares that it
will generate notifications of a particular type
of event (object of interest or observer).
71Distributed Event Notification
object of interest
subscriber
1.
notification
object of interest
observer
subscriber
2.
notification
notification
object of interest
observer
subscriber
3.
notification
Event service
72Role of Observers
- ForwardingAn object of interest only passes
information of an event to the observer. The
observer manages the sending of notifications to
the subscribers. - Filtering of notificationsA filter can reduce
the number of notifications sent to an individual
subscriber by evaluating the content of the
notification. - Patterns of eventsA subscriber can specify
relationships of events that it has subscribed
to. These relationships are called patterns. The
observer only sends a notification once such a
pattern has occurred. - Notification mailboxAn observer may store a
notification until the subscriber is ready to
receive it.
73Jini Distributed Event Specification
- Jini is a distributed event system based on a
Java Virtual Machine. - A remote event is an object that is passed by
value to remote event listeners. An instance
contains the following variables - A reference to the event generator, an event
identifier, a sequence number, a marshalled
object. - An event generator is an object that allows other
objects to subscribes to its events and generates
remote events. - The event generator interface provides a method
called register. This specifies a requested
leasing period. - A remote event listener is an object that can
receive remote events. - The interface of the remote event listener
provides a method called notify. - Third-party agents are the equivalent of
observers.