Paper Guidelines

No

Guidelines for the paper/Implementation for Networked Objects

The paper should be similar to a conference or magazine article. It should have the usual parts, like Abstract, table of contents, introduction, a proper sectioning, and a bibliography which should be referenced in the text where appropriate. It should be of academic quality. The length should be at least 12 pages, with a 10 or 11pt letter, not including table of contents, blibliography etc. This will come down to some 5000-6000 words.

The paper/implemantation should be your own work, done individually. Copying is forbidden. If you want to quote from other literature this should be clearly indicated with a reference to the original work and the reason to quote should be to give your comments on it.

You can write a paper on any of the patterns in the book or the variants mentioned or the additional subjects in the Literature page. The contents should go beyond what is in the book (if you have a book subject) or a single article for the other subjects.

Instead of a paper you can also write an implementation of one of the patterns or an implementation of a secure distributed objects application. The implementation should be your own work, but you can use existing libraries. The implementation should be non-trivial. E.g. in Java a monitor can be made with a class with synchronized methods. This is too trivial and therefore not acceptable. But an implementation where the monitor is implemented by means of semaphores would be acceptable. Please note that an implementation of an easy subject will get a lower grade than a difficult one. In case of a secure distributed objects application the application should accept or deny method calls based on some authentication criteria from the client. You should use one of the existing security frameworks, like Corba Security, Java Authentication and Authorization Service (JAAS), WS-security or similar ones. In case of doubt please ask if your subject is acceptable.

There should be an accompanying document explaining the implementation and the relationship with the theory in the book or the literature.

Below I give some suggestions how you could extend some subjects. Apply similar things to the other subjects:

  • Wrapper Facade: If you make an implementation it should not be a simple straightforward API that you implement. Take for example an API that has different semantics on different platforms and show how you can reconcile these.
  • Wrapper Facade: One aspect of Wrapper Facade is that it gives an object-oriented interface. An important part of object orientation is inheritance. Show how inheritance can be used to create a more useful wrapper facade.
  • Reactor: In the seminar we have seen a demo which had problems (endless loop of 'Key is writable'). Make a correct implementation where the key is writable only at times when this is useful. Invent a good abstraction mechanism for this.
  • Reactor: Sometimes it is impossible to wait for all relevant events in a single event loop. For example Emacs uses a Reactor to wait for events on sockets. On Unix systems with X11 all keyboard and mouse events are passed to the application also through a socket so this nicely fits. However, on Mac OSX keyboard and mouse events have their own delivery mechanism and there isn't a synchronous multiplexer that can handle both event types at the same time. Discuss possible solutions to this problem.
  • Proactor: Write a Java simulation of the Proactor.
  • In general: do something extra.

The subject for the paper/implementation must be different from the two presentation that you give/have given.

The paper/implementation should be submitted before the end of week 5 (Feb 1, 2009) bij email. You can submit a draft version before Jan 11 to get comments. Documents should be in PDF format. If there is more than 1 file they should be packed in a zipfile.

-- PietVanOostrum - 11 Dec 2008