Exercises in Remote Calls

1. Exercises in Remote Calls

2. Organizational I have located the draft of the birman book. Can we make copies and get them bound? Design Patterns: are you familiar with them? (e.g. Doug Schmidt et. Al. Design patterns for distributed applications (c++ but useful for java people too)

3. Books HDM needs to order for Distributed Systems • Doug Lea, Concurrent Java Processing (get a handle on threads!) • Middleware für verteilte Systeme (MIKO ORB, CORBA) (deutsch) • Ken Birman, Building Secure and Reliable Network Applications • Jack Shirazi, Java Performance Tuning • Adam Bien, Java J2EE Frameworks (deutsch) Please tell me about others!

4. Looking back at our socket exercises • Slides on www.kriha.de • Where have we been cheating?(hardware assumptions, protocol) • What was the Naming Service? • A natural next step: servlets!

5. Newsletters and DMOZ • Theserverside.com • Javaworld.com • www.developers.ibm.com (developers connection of IBM • www.alphaworks.ibm.com (research programs) • www.jguru.com • Java delelopers connection (JDC) • www.dmoz.org Open Directory Project (for the non-search type people. Look for distributed computing.

6. Exercises (1) • Design the INTERFACE of a stack class for use in a single threaded environment and one for use in multi-threaded environments. Can it be the same? Can the behavior (implementation) be the same? Should it be? Can you create a remote stack object for use by a procedural language (using the RPC model?)

7. Stack API Interface Stack { push(object); object pop(); int count(); } A fairly generic stack api.

8. Single-threaded case Interface Stack { push(object); object pop(); // if stack is empty? int count(); } The only problem is what we do in case the stack is empty and pop() is called. Return “null” or throw an exception? “Null” is a surprise to the caller (the interface does not say anything about this possibility). An exception would suggest that the proper use of the interface is to always check “count()” before calling pop();

9. Multi-threaded case Interface Stack { push(object); object pop(); // if stack is empty? int count(); // how long is the result valid? } Again the problem is what we do in case the stack is empty and pop() is called. In addition to returning “null” or throwing an exception we could now wait (blocking) for another thread to call push(object). This would allow the stack to be used as a work order queue between two threads. And how useful is count()? Its result is immediately outdated and cannot be used to make a save pop() call (other threads might have emptied the stack in the meantime)

10. Result (1): Interfaces • The interface for single- and multi-threaded stacks should be different, not only the implementation. (Waldo’s point is true) • We cannot build an interface that is ideal for both cases. • Threading is “orthogonal” to regular interface design!

11. Result (2): Pre-and Postconditions • How does the problem look if we specify the exact pre- and postconditions of every method? • For a further discussion see: Bertrand Meyer, Object-Oriented Software Construction. (look at his stack example – he assumes single-threaded of course (;-) • The concept of pre and postconditions (invariants) will (hopefully) make it into Java as a new feature.

12. Exercises (2) Which of the following operations are idempotent? • Pressing an elevator button? • Writing data to a file? • Appending data to a file?

13. Results (1) Which of the following operations are idempotent? • Pressing an elevator button? YES • Writing data to a file? YES, always starts writing from offset 0 and thereby overwriting the old content. • Appending data to a file? NO, each request will append its data and the file grows.

14. Exercises (3) Which of the following technologies is better suited for “data schlepping” (transfer of large volumes of data)? • Socket based programs • Remote Procedure Calls • Remote Method Invocation (RMI, CORBA)

15. Exercises (3) Which of the following technologies is better suited for “data schlepping” (transfer of large volumes of data)? • Socket based programs (e.g. ftp) Many projects tried to use e.g. CORBA for large transfers. Remote procedure calls are NOT made for this – too many layers between sender and receiver (marshaling, reliable request-reply etc). I’ve even seen the EVENT service used for large volume data transmission – this is nonsense! But it shows the importance of “best practices” which have to be learnt first with all new middleware.

16. Exercises (4) Two applications exchange some information through a file. Design a message format • Not self-describing • Self-describing

17. Inter-application data transfer using files While simple at the first glance synchronization issues pop up quickly: • When does the receiver know that it can read the new file (aka sender is done with writing)? • Who can remove the used files? • When can someone remove the used files? Add a new field. What needs to change in both cases?

18. Non-self-describing format Walter Kriha 79424711 Reader Parser: Read(0,29,firstName) Read(30,10,lastName) Read(40,4, zipCode) Read(44,4,account) Writer: Write(firstName, 0) Write (lastName,30) WriteZipcode(zip,40) WriteAccnt(accnt,44) Both reader and writer know the byte position and order of the elements. If an element changes (5 number zipcode) the reader parser breaks (it has an extra character at the end) and (error prone) code on both sides needs to change

19. Self-describing format <someformat> <firstname>Walter</firstname> <lastname>Kriha</lastname> <zipcode type=numeric len=4>7942</zipcode> <account>7411</account> </someformat> This structure allows the receiver parser not only to check the validity of each message against a common schema or dtd (document type description). It also allows the construction of a small framework that deals with new elements automatically.

20. Writer adds a new element: • Receiver can fail the transaction and cry foul: validation error against schema! • Alternatively, the receiver can deal only with known elements and ignore the new ones that it has no code (behavior) for. • Alternatively, the receiver can ask a factory for a class that can deal with each new element. New classes are loaded dynamically from a directory. The addition of new elements is now very easy and does NOT need ANY code changes, just a new class per new element. No parser changes either!

21. Use of factory pattern to supply classes for new elements startElementEvent(“newelement”); DOM Factory contains different node types XML App createElement(“newelement”,…) Element : Node Tree of DOM nodes

22. More interesting questions on flexibility: • How does the factory know which class to return for which element? Either the classes are started automatically after load and register themselves with the factory, telling it which element will be handled – or a configuration info will map classes and elements. • When does the factory know to look for new classes? For applications of dynamic class loading see: Ted Neward, server side java programming

23. Projects • Can we make groups already? • Servlets are also OK.

24. Web-Services

25. Enterprise Java Beans Start with Java Reference Implementation. Solve Infrastructure Problems for other EJB Server (Database, Installation etc.) www.theserverside.com (book an EJBs etc.)

26. Message Oriented Middleware Look at: MQSeries, SwiftMQ, SonicMQ, iBus

27. Peer-to-Peer www.openp2p.com (portal for p2p), Andy Oram book. www.jxta.org (SUN’s new p2p layer)

28. RMI www.javaskyline.com (portal for RMI and other java technologies)

29. Hints • When you start searching for technology or installing middleware: take notes about the steps you’ve chosen and why you did things the way you did. • Write down your installation decisions. • Write down your questions (e.g. “what is middleware XXX good for?)

30. Next Exercises: • RMI (possibly some CORBA stuff) Prepare: javaskyline.com/learnrmi.html Has many links to demos and tutorials