Middleware Layers - PowerPoint PPT Presentation

1 / 73
About This Presentation
Title:

Middleware Layers

Description:

Send: A process copies a message (a sequence of bytes) into ... An idempotent operation can be executed again. A history buffer can be used to resend the reply. ... – PowerPoint PPT presentation

Number of Views:79
Avg rating:3.0/5.0
Slides: 74
Provided by: Pri49
Category:

less

Transcript and Presenter's Notes

Title: Middleware Layers


1
Middleware Layers
2
Interprocess 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

3
Communication 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.

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

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

6
Sockets 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
7
UDP 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.

8
TCP 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.

9
Failure 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.

10
External 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

11
External 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!

12
CORBA 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.

13
CORBA CDR for Constructed Types
14
CORBA CDR message
index in sequence of bytes
notes on representation
4 Bytes
The flattened form represents a Person struct
with value Smith,London,1934
15
Java 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.

16
Java 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.

17
Example 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

18
Java Serialized Form
The true serialized form contains additional type
markers h0 and h1 are handles.
19
Extensible 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

20
XML Definition of the Person Structure
ltperson id"123456789"gt ltnamegtSmithlt/namegt ltpl
acegtLondonlt/placegt ltyeargt1934lt/yeargt lt!-- a
comment --gt lt/person gt
21
Extensible 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.

22
Namespace 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
23
XML 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
24
Remote 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.

25
Example Remote Object Reference
26
Request-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.

27
Request-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.

28
Request-Reply Communication
Client
Server
Requestmessage
Replymessage
29
Request-Reply Message Structure
30
Failure 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.

31
Invocation Semantics
32
Alternative 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.

33
RPC Exchange Protocols

Name
Messages sent by
Client
Server
Client
R
Request
R
R
Reply
Request
R
R
A
Acknowledge reply
Request
Reply
34
HTTP 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.

35
HTTP Request Message
36
HTTP Reply Message
37
Group 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.

38
IP 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

39
Sockets Used for Datagrams
40
Sockets 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
41
Middleware Layers
42
Programming 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.

43
Remote and Local Method Invocations
local invocation
C
E
F
remote invocation
local invocation
A
B
remote invocation
local invocation
D
44
Module 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.

45
Module 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.

46
CORBA 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()
47
A Remote Object and its Remote Interface
remote object
Data
remote interface
m1 m2 m3
implementation of methods
m4 m5 m6
48
The 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.

49
The 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,

50
Instantiation of Remote Objects
51
Access 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.

52
Invocation Semantics
53
Implementation 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.

54
Implementation 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.

55
Implementation 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.

56
Proxy 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
57
Implementation 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.

58
Implementation 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.

59
The 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.

60
Part 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.

61
Naming Graph in CORBA Naming Service
Initial naming context
Initial naming context
XX
P
V
S
U
T
R
Q
Naming context
CORBA object
62
Implementation 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.

63
Implementation 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

64
Garbage 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.

65
Garbage 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.

66
Remote 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.

67
Client 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
68
Events 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.

69
Events 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
70
Events 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).

71
Distributed 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
72
Role 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.

73
Jini 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.
Write a Comment
User Comments (0)
About PowerShow.com