1. Distributed Software Engineering Lecture 3 Middleware Solutions Cont. Sam Malek SWE 622, Fall 2012 George Mason University

2. SWE 622 – Distributed Software Engineering © MalekLecture 3 – Middleware Solutions Cont.– 2 outline RMI Review &Tutorial Middleware Solutions Cont. message passing data sharing & streaming publish-subscribe

3. The network is the computer Consider the following program organization: If the network is the computer, we ought to be able to put the two classes on different computers RMI is one technology that makes this possible SomeClass AnotherClass method call returned object computer 1computer 2 SWE 622 – Distributed Software Engineering © MalekLecture 3 – Middleware Solutions Cont.– 3

4. What is needed for RMI Java makes RMI (Remote Method Invocation) fairly easy, but there are some extra steps To 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 parameters The server object has to unmarshal its parameters, do its computation, and marshal its response The client object has to unmarshal the response SWE 622 – Distributed Software Engineering © MalekLecture 3 – Middleware Solutions Cont.– 4

5. Terminology A remote object is an object on another computer The 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 © MalekLecture 3 – Middleware Solutions Cont.– 5

6. Processes For RMI, you need to be running three processes The Client The Server The Object Registry, rmiregistry, which is like a DNS service for objects You also need TCP/IP SWE 622 – Distributed Software Engineering © MalekLecture 3 – Middleware Solutions Cont.– 6

7. Interfaces Interfaces define behavior Classes 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 server The class should only be on the server SWE 622 – Distributed Software Engineering © MalekLecture 3 – Middleware Solutions Cont.– 7

8. Remote and Serializable A 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 object On 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 © MalekLecture 3 – Middleware Solutions Cont.– 8

9. Conditions for serializability If an object is to be serialized: The class must be declared as public The class must implement Serializable All fields of the class must be serializable: either primitive types or serializable objects SWE 622 – Distributed Software Engineering © MalekLecture 3 – Middleware Solutions Cont.– 9

10. Remote interfaces and class A 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.UnicastRemoteObject May have locally accessible methods that are not in its Remote interface SWE 622 – Distributed Software Engineering © MalekLecture 3 – Middleware Solutions Cont.– 10

11. Remote vs. Serializable A Remote object lives on another computer (such as the Server) You can send messages to a Remote object and get responses back from the object All you need to know about the Remote object is its interface Remote 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 interface There is a way to transmit the class definition Accepting classes does pose a security issue SWE 622 – Distributed Software Engineering © MalekLecture 3 – Middleware Solutions Cont.– 11

12. Security It 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 default System.setSecurityManager(new RMISecurityManager()); SWE 622 – Distributed Software Engineering © MalekLecture 3 – Middleware Solutions Cont.– 12

13. The server class The class that defines the server object should extend UnicastRemoteObject This makes a connection with exactly one other computer If you must extend some other class, you can use exportObject() instead Sun 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 1099 Naming.rebind(url, object ); Every remotely available method must throw a RemoteException. Why? SWE 622 – Distributed Software Engineering © MalekLecture 3 – Middleware Solutions Cont.– 13

14. Hello world server: interface import java.rmi.*; public interface HelloInterface extends Remote { public String say() throws RemoteException; } SWE 622 – Distributed Software Engineering © MalekLecture 3 – Middleware Solutions Cont.– 14

15. Hello world server: class import 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 © MalekLecture 3 – Middleware Solutions Cont.– 15

16. 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 © MalekLecture 3 – Middleware Solutions Cont.– 16

17. 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 © MalekLecture 3 – Middleware Solutions Cont.– 17

18. rmic The class that implements the remote object should be compiled as usual Then, it should be compiled with rmic : rmic Hello This will generate files Hello_Stub.class and Hello_Skel.class These classes do the actual communication The “Stub” class must be copied to the client area The “Skel” was needed in SDK 1.1 but is no longer necessary SWE 622 – Distributed Software Engineering © MalekLecture 3 – Middleware Solutions Cont.– 18

19. Trying RMI In 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 © MalekLecture 3 – Middleware Solutions Cont.– 19

20. References Trail: RMI by Ann Wollrath and Jim Waldo http://java.sun.com/docs/books/tutorial/rmi/index.html Fundamentals of RMI Short Course by jGuru http://developer.java.sun.com/developer/onlineTraining/rmi/ RMI.html SWE 622 – Distributed Software Engineering © MalekLecture 3 – Middleware Solutions Cont.– 20

21. Take 10 Find your teammates! SWE 622 – Distributed Software Engineering © MalekLecture 3 – Middleware Solutions Cont.– 21

22. RMI exercise SWE 622 – Distributed Software Engineering © MalekLecture 3 – Middleware Solutions Cont.– 22

23. SWE 622 – Distributed Software Engineering © MalekLecture 3 – Middleware Solutions Cont.– 23 outline RMI Tutorial Middleware Solutions Cont. message passing data sharing & streaming publish-subscribe

24. SWE 622 – Distributed Software Engineering © MalekLecture 2 – Middleware Solutions Cont. – 24 message passing comes in many flavors persistence once sent, messages endure in the system, regardless of the sender remaining active and the recipient being available synchronicity the sender continues after sending, or blocks, waiting for the message to be delivered (buffered) to be received (read) to be processed

25. SWE 622 – Distributed Software Engineering © MalekLecture 2 – Middleware Solutions Cont. – 25 some flavors (1) persistent asynchronous persistent synchronous delivery

26. SWE 622 – Distributed Software Engineering © MalekLecture 2 – Middleware Solutions Cont. – 26 network transport some flavors (2) transient asynchronous persistent synchronous receipt

27. SWE 622 – Distributed Software Engineering © MalekLecture 2 – Middleware Solutions Cont. – 27 some flavors (3) persistent synchronous start server-persistent synchronous processing

28. SWE 622 – Distributed Software Engineering © MalekLecture 2 – Middleware Solutions Cont. – 28 call-return some flavors (4) transient synchronous processing transient synchronous receipt (g) (h)

29. SWE 622 – Distributed Software Engineering © MalekLecture 2 – Middleware Solutions Cont. – 29 some middleware support persistent messaging example middleware: IBM MQSeries, Java Messaging Service supports guarantied delivery, logging, priorities, load balancing… example application: email implements lightweight solution on top of network transport

30. SWE 622 – Distributed Software Engineering © MalekLecture 2 – Middleware Solutions Cont. – 30 network transport (TCP/IP) supports transient asynchronous Release the connectionClose Receive some data over the connectionReceive Send some data over the connectionSend Actively attempt to establish a connectionConnect Block caller until a connection request arrivesAccept Announce willingness to accept connectionsListen Attach a local address to a socketBind Create a new communication endpointSocket MeaningPrimitive Release the connectionClose Receive some data over the connectionReceive Send some data over the connectionSend Actively attempt to establish a connectionConnect Block caller until a connection request arrivesAccept Announce willingness to accept connectionsListen Attach a local address to a socketBind Create a new communication endpointSocket MeaningPrimitive call-return example

31. SWE 622 – Distributed Software Engineering © MalekLecture 2 – Middleware Solutions Cont. – 31 when to use the messaging style messages c1c2 m1 m3 m2 component interactions don’t follow a strict call-return pattern make components more responsive to other events/user (no blocking) allow any component to initiate communication components may not be available to receive/process messages (persistency)

32. SWE 622 – Distributed Software Engineering © MalekLecture 3 – Middleware Solutions Cont.– 32 outline RMI Tutorial Middleware Solutions Cont. message passing data sharing & streaming publish-subscribe

33. SWE 622 – Distributed Software Engineering © MalekLecture 2 – Middleware Solutions Cont. – 33 when to use the data sharing style (persistent) data plays a central role in the system components don’t need to synchronize control flow other than on data availability or values E.g., modern database management systems, distributed file systems data store c1c2 files / objects persistent store data store CS r/w...

34. SWE 622 – Distributed Software Engineering © MalekLecture 2 – Middleware Solutions Cont. – 34 the data streaming style is a variant where: data is stored/generated at one place and consumed by one or more clients timeliness 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 sound streaming is supported by middleware (e.g. RSVP) on top of the data link network layer data stream CS req data data stream C req data store/source

35. SWE 622 – Distributed Software Engineering © MalekLecture 3 – Middleware Solutions Cont.– 35 outline RMI Tutorial Middleware Solutions Cont. message passing data sharing & streaming publish-subscribe

36. Publish-Subscribe or Event notification style SWE 622 – Distributed Software Engineering © MalekLecture 3 – Middleware Solutions Cont.– 36

37. Space decoupling interaction 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 © MalekLecture 3 – Middleware Solutions Cont.– 37

38. 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 © MalekLecture 3 – Middleware Solutions Cont.– 38

39. 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 © MalekLecture 3 – Middleware Solutions Cont.– 39

40. 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 © MalekLecture 3 – Middleware Solutions Cont.– 40

41. Event matching A subscription matches an event notification when the notification satisfies all the constraints specified in the subscription SWE 622 – Distributed Software Engineering © MalekLecture 3 – Middleware Solutions Cont.– 41

42. 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 © MalekLecture 3 – Middleware Solutions Cont.– 42

43. 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 © MalekLecture 3 – Middleware Solutions Cont.– 43

44. 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 © MalekLecture 3 – Middleware Solutions Cont.– 44

45. 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 © MalekLecture 3 – Middleware Solutions Cont.– 45

46. 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 © MalekLecture 3 – Middleware Solutions Cont.– 46

47. 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 © MalekLecture 3 – Middleware Solutions Cont.– 47

48. SWE 622 – Distributed Software Engineering © MalekLecture 3 – Middleware Solutions Cont.– 48 3 2 4 8 1 7 6 5 9 S IENA Content-Based Routing Subscription Forwarding

49. SWE 622 – Distributed Software Engineering © MalekLecture 3 – Middleware Solutions Cont.– 49 3 2 4 8 1 7 6 5 9 S IENA Content-Based Routing Subscription Forwarding a s1s1 s1:a s1:1 s1:2 s1:3 s1:2 s1:6 s1:3 s1:1 s1:5 s 1 : “price < 700”

50. SWE 622 – Distributed Software Engineering © MalekLecture 3 – Middleware Solutions Cont.– 50 s 2 : “price < 600” 3 2 4 8 7 6 5 9 S IENA Content-Based Routing Subscription Merging s1:1 s1:2 s1:6 s1:3 s1:1 s2s2 b s1:3 s1:2 s1:5 s1:1 s2:5 s1:1 s2:5 s1:2 s2:8 s1:2 s2:8 s1:5 s2:b s1:5 s2:b a s 1 covers s 2 1 s1:a s2:2 s1:a s2:2

51. SWE 622 – Distributed Software Engineering © MalekLecture 3 – Middleware Solutions Cont.– 51 3 2 4 8 1 7 6 5 9 S IENA Content-Based Routing Notification Delivery b s1:1 s2:5 s1:1 s2:5 s1:2 s1:6 s1:3 s1:1 s1:3 s1:2 s2:8 s1:2 s2:8 a s1:a s2:2 s1:a s2:2 s1:5 s2:b s1:5 s2:b n 1 : “price = 550” n1n1

52. SWE 622 – Distributed Software Engineering © MalekLecture 2 – Middleware Solutions Cont. – 52 Summary: different styles of conceptual model address different problems data volume interaction complexity protocols call/return read/write messages RPC/RMI streamingdata store middleware is more generic app writer works harder middleware is more specialized app writer is more constrained