coms w3156: software engineering, fall 2001 lecture #15: distributed objects ii, network event...
Post on 21-Dec-2015
214 Views
Preview:
TRANSCRIPT
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
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!
top related