COMS W3156:Software Engineering, Fall 2001

Lecture #15: Distributed Objects II, Network event infrastructures

Janak J Parekh

janak@cs.columbia.edu

Administrativia• LDAP code samples up

• Design due Tuesday!– How’s everyone doing?

• Requirements update pending (v1.2)– Will not be required to reflect updates in design

Next class

• So, we’re ahead of pace…

• Integration

• Security/Cryptography

Today’s class

• Continue on distributed objects– RMI in detail

• Serialization of Java objects

• Network-based event programming

Socket programming

• This is what you’re doing; why is it “bad”?– Need to parse input/specially generate output– Need to know whom to connect to– Synchronous (as opposed to asynchronous):

send a request, wait for response, etc…

• Having said that, still one of the most popular ways to do network programming

Alternatives

• Send the object to the other side: serialization

• Access the object remotely: remote calls and remote objects

• Use a third-party mechanism to talk to the remote party: events

Serialization (I)

• Standard mechanism to encode objects into a stream or bytearray

• “Flatten” the object out

• Problem: what to do about pointers?– Use a serial number to number objects as they

go out– Replace pointer with serial number

Serialization (II)

• C/C++ support streams, but don’t include automatic serialization: you’d have to convert the Object into a string yourself– Wouldn’t be useful enough anyway: different

systems, endianness, etc.

• Java builds it in, and automates it– Builds functionality on top of reflections

Reflection (I)

• What if you have never seen an object before? If you don’t have the .class file?

• You can’t “hardcode” method calls, etc. without having the other class

• But what happens if you get it during runtime, over a network?

• Java supports this

Reflection (II)

• Can get a “Class” object (java.lang.Class), – Object.getClass()– Class.forName()

• Then, you can inquire about its properties and perform operations– Class.newInstance()– Class.getMethods(), .getConstructors(), etc.– Returns arrays if necessary

So…

• This is cool• Serialize an object, send it over the network,

receive it, use it• Problem: just like every other technology, Sun has

made it proprietary• Why not standardize on XML or somesuch?

– Well, you can, manually– Automated methods?

• http://www.google.com/search?q=Java+XML+serialization • JDK 1.4, apparently

“Mobile code”

• Traditionally, only mobile code would have been interpreted scripting or data– JDK 1.3.0 on cunix: argh!

• Java bytecode can be moved around without fear of platform incompatibilities

• Load classes dynamically at runtime: late binding

• Allows for “software agents”

Alternative: remote calls/objects

• Instead of sending the object back and forth:– Send the parameters of the method call to the

other side– Let the other side do the work– Send the return value back

• If it’s a complex Object, or one that depends on others, much more practical alternative

• Being used heavily now…

Remote Procedure Call (RPC)

• Invented by Sun in 1988• Transport-independent: TCP, UDP, etc.• Simple security model• Uses XDR (eXtended Data Representation) to

solve the platform dependencies– Also functions as an IDL (Interface Description

Language)– Marshalling

• Used heavily by NFS (Network File System)

DCE RPC

• “Distributed Computing Environment”• Modern multivendor RPC standard• Can get complicated• Two major uses

– Large proprietary Unix projects

– Microsoft uses it heavily• NTLM authentication

• NT printing services

• Microsoft Exchange

Problems with RPC

• Procedure calls, locally, are reliable• Over a network?

– What if the remote program crashes?

– What if you lose network connectivity to the remote site?

– What if it takes a long time?

– “nfs server foo not responding”

• How to compile against remote code?– “Stubs” / “Skeletons”

• Not object-oriented…

CORBA

• Common Object Request Broker Architecture

• “RPC for the object-oriented generation”

• IDL for CORBA is object-oriented

• Wide cross-platform support

• Extremely big and complex

• Integrated Java support

Java RMI

• Java-only CORBA-like solution• Reasonably straightforward to implement• Uses stubs on the client, like RPC

– Can use skeletons, but not necessary anymore

• http://java.sun.com/j2se/1.3/docs/guide/rmi/getstart.doc.html

• Requires RMI registry– LDAP-like server to list directory of objects that clients

can access

RMI: Server

• Create an interface which the client will see– Interface extends Remote, methods throw

RemoteException

• Write the implementation behind the interface– Extend UnicastRemoteObject and implement interface

• Write a server to serve the implementation– Can combine the impl and the server

– Create a SecurityManager

– “Rebind” to RMI registry

RMI: Client

• Easier than server

• Create security manager, bind to registry

• Get reference to object using Naming.lookup(), cast it in terms of Interface

• Use it: keep track of the fact there may be exceptions

RMI: Compiling and using

• Compile source files (javac)• Use rmic to compile the stubs:

– Only need to rmic the implementation class– Supply class reference like the java command– rmic HelloImpl

• Start!– rmiregistry– Start server– Start client

XML RPC

• Why not use XML as the marshalled language?– Not the same as serialize-over-XML

• You can– http://www.xmlrpc.org– SOAP: Simple Object Access Protocol

• Deals with envelope and encoding• http://www.w3.org/TR/SOAP/• Microsoft supports it

Moving on up…

• Service discovery– LDAP– RMI registry

• Service discovery, TNG– How to deal with scattered services,

“component discovery”?– DCOM, CORBA, EJB– Transactions, scalability, deployment issues

RPC miscellany

• Interoperability?• Performance?• Transactions?• How about asynchronous RPC?

– Send a message to a server, but don’t wait for a return: have server call you back

• How about asynchronous, undirected RPC…?

Events

• Two sets of parties: “publishers” and “subscribers”

• Subscribers tell the event “bus” what they are interested in

• Publishers push content onto the bus– Event bus “calls back” subscriber and tells it

that data was received

Format of an event

• Often attribute-value pairs: hashtable-ish

• Can also be other formats, like XML

• Events usually do not specify target subscriber– The motivation: send it out, let any interested

parties get it– Security implications, of course

Events: Advantages (I)

• Asynchronous• Multicast-capable• Reduces service discovery problem

– Each party only needs to know one address: the event bus

– Content-based routing– Parties don’t need to know each other

• Allows for queueing, etc.

Events: Advantages (II)

• Easy to program for– Can start up components in any sequence: if

one party is missing, they just miss the event– Load balancing is trivial: add more servers– Need to move a party? Shut it down in one

place and start it up elsewhere

Events: Problems

• Not always easy to load-balance: how to partition tasks?

• How to support unicast/transactions over events?

• Event followups? Was it received by someone?– Wait until someone is available?

• Security?

Examples

• Many are out there– AWT/Swing actually uses events heavily– Microsoft’s COM+– etc.

• Research buses– Elvin (http://elvin.dstc.edu.au)– Siena (

http://www.cs.colorado.edu/~carzanig/siena)

Siena

• Pros– Scalable, hierarchical, content-based routing

– Extremely small and simple

– Well-documented

• Cons– Performance is lacking (Java, research-based)

– Hierarchical

– Proprietary wire format

– No status, inspection, reflection

Siena: mechanics (I)

• Start up a Siena server on a port• In your code, create a

HierarchicalDispatcher– Uses a TCPPacketReceiver– Connects to a SENP url

• senp://random-host.cs.columbia.edu:5678

• Make calls on HierarchicalDispatcher– subscribe()– publish()

Siena: mechanics (II)

• To subscribe, supply a filter and a callback object– Siena will evaluate events based on filter– Callback: implement Notifiable

• To publish, create a Notification and publish it

• That’s pretty much it!

What does this mean for you?

• You’ll have to implement both RMI and Siena for HW3

• It really is not that hard