DistributedSoftware Engineering
Lecture 3Middleware Solutions Cont.
Sam MalekSWE 622, Fall 2012
George Mason University
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 2
outlineRMI Review &TutorialMiddleware Solutions Cont.
message passingdata sharing & streamingpublish-subscribe
The network is the computerConsider the following program organization:
If the network is the computer, we ought to be able to put the two classes on different computersRMI is one technology that makes this possible
SomeClass AnotherClass
method call
returned object
computer 1 computer 2
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 3
What is needed for RMIJava makes RMI (Remote Method Invocation) fairly easy, but there are some extra stepsTo send a message to a remote “server object,”
The “client object” has to find the object• Do this by looking it up in a registry
The client object then has to marshal the parameters (prepare them for transmission)Java requires Serializable parametersThe server object has to unmarshal its parameters, do its computation, and marshal its responseThe client object has to unmarshal the response
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 4
TerminologyA remote object is an object on another computerThe client object is the object making the request (sending a message to the other object)The server object is the object receiving the request“client” and “server” can easily trade roles (each can make requests of the other)The rmiregistry is a special server that looks up objects by name
Hopefully, the name is unique!rmic is a special compiler for creating stub (client) and skeleton (server) classes
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 5
ProcessesFor RMI, you need to be running three processes
The ClientThe ServerThe Object Registry, rmiregistry, which is like a DNS service for objects
You also need TCP/IP
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 6
InterfacesInterfaces define behaviorClasses define implementation
Therefore,In order to use a remote object, the client must know its behavior (interface), but does not need to know its implementation (class)In order to provide an object, the server must know both its interface (behavior) and its class (implementation)
In short,The interface must be available to both client and serverThe class should only be on the server
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 7
Remote and SerializableA Remote class is one whose instances can be accessed remotely
On the computer where it is defined, instances of this class can be accessed just like any other objectOn other computers, the remote object can be accessed via object handles
A Serializable class is one whose instances can be marshaled (turned into a linear sequence of bits)
Serializable objects can be transmitted from one computer to another
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 8
Conditions for serializabilityIf an object is to be serialized:
The class must be declared as publicThe class must implement SerializableAll fields of the class must be serializable: either primitive types or serializable objects
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 9
Remote interfaces and classA Remote class has two parts:
The interface (used by both client and server):• Must be public • Must extend the interface java.rmi.Remote• Every method in the interface must declare that it
throws java.rmi.RemoteException (other exceptions may also be thrown)
The class itself (used only by the server):Must implement a Remote interface Should extend java.rmi.server.UnicastRemoteObjectMay have locally accessible methods that are not in its Remote interface
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 10
Remote vs. SerializableA Remote object lives on another computer (such as the Server)
You can send messages to a Remote object and get responses back from the objectAll you need to know about the Remote object is its interfaceRemote objects don’t pose much of a security issue
You can transmit a copy of a Serializable object between computers
The receiving object needs to know how the object is implemented; it needs the class as well as the interfaceThere is a way to transmit the class definitionAccepting classes does pose a security issue
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 11
SecurityIt isn’t safe for the client to use somebody else’s code on some random server
Your client program should use a more conservative security manager than the defaultSystem.setSecurityManager(new RMISecurityManager());
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 12
The server classThe class that defines the server object should extend UnicastRemoteObject
This makes a connection with exactly one other computerIf you must extend some other class, you can use exportObject() insteadSun does not provide a MulticastRemoteObject class
The server class needs to register its server object:String url = "rmi://" + host + ":" + port + "/" + objectName;
The default port is 1099Naming.rebind(url, object);
Every remotely available method must throw a RemoteException. Why?
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 13
Hello world server: interfaceimport java.rmi.*;
public interface HelloInterface extends Remote { public String say() throws RemoteException;}
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 14
Hello world server: classimport java.rmi.*;import java.rmi.server.*;
public class Hello extends UnicastRemoteObject implements HelloInterface { private String message; // Strings are serializable
public Hello (String msg) throws RemoteException { message = msg; }
public String say() throws RemoteException { return message; }}
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 15
Registering the hello world server
class HelloServer { public static void main (String[] argv) { try { Naming.rebind("rmi://localhost/HelloServer", new Hello("Hello, world!")); System.out.println("Hello Server is ready."); } catch (Exception e) { System.out.println("Hello Server failed: " + e); } }}
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 16
The hello world client program
class HelloClient { public static void main (String[] args) { HelloInterface hello; String name = "rmi://localhost/HelloServer"; try { hello = (HelloInterface)Naming.lookup(name); System.out.println(hello.say()); } catch (Exception e) { System.out.println("HelloClient exception: " + e); } }}
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 17
rmicThe class that implements the remote object should be compiled as usualThen, it should be compiled with rmic:
rmic HelloThis will generate files Hello_Stub.class and Hello_Skel.classThese classes do the actual communication
The “Stub” class must be copied to the client areaThe “Skel” was needed in SDK 1.1 but is no longer necessary
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 18
Trying RMIIn three different terminal windows:
1. Run the registry program:• rmiregistry
2. Run the server program:• java HelloServer
3. Run the client program:• java HelloClient
If all goes well, you should get the “Hello, World!” message
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 19
ReferencesTrail: RMI by Ann Wollrath and Jim Waldo
http://java.sun.com/docs/books/tutorial/rmi/index.html
Fundamentals of RMI Short Courseby jGuru
http://developer.java.sun.com/developer/onlineTraining/rmi/RMI.html
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 20
Take 10Find your teammates!
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 21
RMI exercise
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 22
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 23
outlineRMI TutorialMiddleware Solutions Cont.
message passingdata sharing & streamingpublish-subscribe
SWE 622 – Distributed Software Engineering
© Malek Lecture 2 – Middleware Solutions Cont. – 24
message passingcomes in many flavors
persistenceonce sent, messages endure in the system, regardless of the sender remaining activeand the recipient being availablesynchronicitythe sender continues after sending,or blocks, waiting for the message
to be delivered (buffered)to be received (read)to be processed
SWE 622 – Distributed Software Engineering
© Malek Lecture 2 – Middleware Solutions Cont. – 25
some flavors (1)
persistentasynchronous
persistentsynchronous delivery
SWE 622 – Distributed Software Engineering
© Malek Lecture 2 – Middleware Solutions Cont. – 26
network transport
some flavors (2)
transientasynchronous
persistentsynchronous receipt
SWE 622 – Distributed Software Engineering
© Malek Lecture 2 – Middleware Solutions Cont. – 27
some flavors (3)
persistentsynchronous start
server-persistent synchronous processing
SWE 622 – Distributed Software Engineering
© Malek Lecture 2 – Middleware Solutions Cont. – 28
call-return
some flavors (4)
transientsynchronous processing
transientsynchronous receipt
(g) (h)
SWE 622 – Distributed Software Engineering
© Malek Lecture 2 – Middleware Solutions Cont. – 29
some middlewaresupport persistent messaging
example middleware: IBM MQSeries, Java Messaging Servicesupports guarantied delivery, logging, priorities, load balancing…
example application: emailimplements lightweight solution on top of network transport
SWE 622 – Distributed Software Engineering
© Malek Lecture 2 – Middleware Solutions Cont. – 30
network transport (TCP/IP)supports transient asynchronous
Release the connectionCloseReceive some data over the connectionReceiveSend some data over the connectionSendActively attempt to establish a connectionConnectBlock caller until a connection request arrivesAcceptAnnounce willingness to accept connectionsListenAttach a local address to a socketBind
Create a new communication endpointSocketMeaningPrimitive
Release the connectionCloseReceive some data over the connectionReceiveSend some data over the connectionSendActively attempt to establish a connectionConnectBlock caller until a connection request arrivesAcceptAnnounce willingness to accept connectionsListenAttach a local address to a socketBind
Create a new communication endpointSocketMeaningPrimitive
call-return example
SWE 622 – Distributed Software Engineering
© Malek Lecture 2 – Middleware Solutions Cont. – 31
when to usethe messaging style
messages
c1 c2m1
m3m2
component interactions don’tfollow a strict call-return patternmake components more responsiveto other events/user (no blocking)allow any component to initiate communicationcomponents may not be available to receive/process messages (persistency)
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 32
outlineRMI TutorialMiddleware Solutions Cont.
message passingdata sharing & streamingpublish-subscribe
SWE 622 – Distributed Software Engineering
© Malek Lecture 2 – Middleware Solutions Cont. – 33
when to usethe data sharing style
(persistent) data plays a central role in the systemcomponents don’t need to synchronize control flow other than on data availability or valuesE.g., modern database management systems, distributed file systems
data store
c1 c2
files / objectspersistent store
data store
C Sr/w
r/w...
SWE 622 – Distributed Software Engineering
© Malek Lecture 2 – Middleware Solutions Cont. – 34
the data streaming styleis a variant where:
data is stored/generated at one place and consumed by one or more clientstimeliness of data delivery is crucial
asynchronous (unbound, e.g., caching)synchronous (upper bound, e.g., sensors)isochronous (bounded jitter, e.g., media)
complex data may be transmitted as separate streams which need to be synchronized: e.g. video + stereo soundstreaming is supported by middleware (e.g. RSVP) on top of the data link network layer
data stream
C Sreq
data
data streamC
req
datastore/source
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 35
outlineRMI TutorialMiddleware Solutions Cont.
message passingdata sharing & streamingpublish-subscribe
Publish-Subscribe orEvent notification style
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 36
Space decouplinginteraction partners do not need to know each other
• Time decoupling– the interaction partners do
not need to be actively participating in the interaction at the same time
• Synchronization decoupling
– Publishers are not blocked while producing events, and subscribers can get asynchronously notified of the occurrence of an event
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 37
Example of an event notification service (MW)
• SIENA: a wide-area event notification service– Nodes and servers (access points)– Notify– Subscribe– Filter– Advertise– Match
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 38
Event Notifications• Event notification is a set of typed
attributes– Each attribute has a name, a type, and a value
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 39
Event filters and patterns• An event filter selects event notifications by
specifying a set of attributes and constraints on the values of those attributes
• A pattern is composed of several filters• A subscription can be expressed as a filter or
a pattern
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 40
Event matching• A subscription matches an event notification
when the notification satisfies all the constraints specified in the subscription
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 41
Publish, Subscribe & Advertise• Nodes publish event notifications to
access points
• Nodes subscribe to access points in order to receive event notifications
– Specified by filters and/or patterns
• Advertisements– defines the event notifications a node may possibly
generate using the same semantics as filters
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 42
Filtering• The goal of filtering
– only deliver messages “of interest” to nodes, reducing the overall traffic across the network
• The system is aided by use of advertisements
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 43
Routing Algorithms• Server must establish appropriate routing path to
ensures that notification published by objects of interest are correctly delivered to all the interested parties that subscribed to them
• Simplest strategy is to maintain the subscriptions at their access point and broadcast the notification throughout the network
– Least efficient– Consumes lots of bandwidth
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 44
Routing strategy in SIENA• Central idea is to send the notification towards the
event servers that have clients that are interested in that notification (possibly using shortest path)
– Downstream replication• Notification should be replicated only downstream and as
close as possible to parties interested in it
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 45
Routing strategy in SIENA• Upstream evaluation
– Filters are applied and patterns are assembled upstream – as close as possible to the source of notification
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 46
Routing strategy in SIENA• Subscription forwarding
– Routing paths for notification are set by subscriptions which are propagated throughout the network so as to form a tree that connects subscribers to all the servers in network
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 47
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 48
3
2
4
8
1
7
6
5
9
SIENA Content-Based RoutingSubscription Forwarding
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 49
3
2
4
8
1
7
6
5
9
SIENA Content-Based RoutingSubscription Forwarding
as1
s1:a
s1:1
s1:2
s1:3
s1:2
s1:6
s1:3
s1:1
s1:5
s1: “price < 700”
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 50
s2: “price < 600”
3
2
4
8
7
6
5
9
SIENA Content-Based Routing Subscription Merging
s1:1
s1:2
s1:6
s1:3
s1:1
s2b
s1:3
s1:2
s1:5
s1:1s2:5
s1:2s2:8
s1:5s2:b
a
s1 covers s2
1
s1 covers s2
s1:as1:as2:2
SWE 622 – Distributed Software Engineering
© Malek Lecture 3 – Middleware Solutions Cont.– 51
3
2
4
8
1
7
6
5
9
SIENA Content-Based Routing Notification Delivery
b
s1:1s2:5
s1:2
s1:6
s1:3
s1:1s1:3
s1:2s2:8
a s1:as2:2
s1:5s2:b
n1: “price = 550”
n1
SWE 622 – Distributed Software Engineering
© Malek Lecture 2 – Middleware Solutions Cont. – 52
Summary: different styles of conceptual modeladdress different problems
data volume
interactioncomplexity
protocols
call/return
read/write
messages
RPC/RMI
streaming data store
• middleware is more generic
• app writer works harder
• middleware is more specialized
• app writer is more constrained