Status Report: jini (6-3-2001)


Last Week

Summary:  
 

Ian

  • Got POP3 server up and running
  • Helped integrate storage and POP3 server with Sherif and Boris' components
  • Began work on SMTP server

Sherif

  • Added Remote Events, as soon as an account is added or updated
    the responsible thread is either started, or stopped SAFELY then
    restarted with the new data.
  • Added Task Manager, Service Discovery is handled by a seperate thread
    to avoid blocking of the one.box core components
  • Much more reliable system (Exception handling)

Boris

  • Did a little testing.
  • Changing services to activatable.
  • My files are javadoc compatible.
  • Changed the router to support some of the recent storage changes.

This Week

Summary:  
 

Ian

  • SMTP server working
  • Make TSpaces store things persistently (it's only storing stuff in memory right now)
  • Begin work on Fridge

Sherif

  • Finalize the system, start writing the paper.
  • Take a look at Activation

 

Boris

  • Finish leftover implementation.
  • Do testing of the entire system.
  • Evaluate one.box.
  • Work on the final report.

Deliverables for next tuesday

Summary:  

Ian

  • SMTP server working
  • TSpaces storing persistently
  • Fridge beginnings

Sherif

  • Work on fixing any bugs.
  • Testing the whole system
 

Boris

  • Finished report (group effort)
  • Finished essential one.box stuff

Time spent

Ian

Please go to my time tracker, click on "Universal Inbox", and log in as "guest" (no password). (I'll work put this page on this site in the future.) 

Sherif

Ian's time tracker contains my information as well.

Boris

Ian's time tracker contains my information as well.

Comments

Ian

Sherif

Boris

          Pros:

          -- It's incredibly easy to create a basic Jini service.

          -- It's easy to convert some existing code into a simple Jini service.

          -- In a lot of ways, once a Jini service wrapper is created for a class, it can then scale to enormous proportions without requiring much more jini-specific coding.

          -- Leasing provides the basis for recovery from disconnects and crashes.

          -- Multicasting lookup discovery makes it possible to locate the lookup services without prior knowledge of the network structure.

          -- Jini is built with the thought that it would have as its basis many already developed tools.  Since Jini is based on such tested APIs that have already infiltrated the industry, it should have less trouble establishing itself in the industry.

          -- Most of the ideas used in jini are either very simple or are natural extensions of the well-understood concepts.

 

         Cons:

         -- Though one can convert some existing code into a Jini service, more demanding requirements will force one to look for optimizations that will require additional modifications to an  existing service.

         -- Multicast lookup discovery can be a source of problems as its effectiveness is highly dependent on network topology (as was mentioned and demonstrated previously).

         -- Jini is built using synchronous communication.  Though RPC is a well understood form of communication and is suitable for some tasks, it seems to go against Jini's purpose as a framework for highly dynamic distributed systems.  As we discovered, in some cases even a small network is likely to have services whose robustness is questionable.  In these cases, synchronous communication endangers other network components.  Though it may seem that Jini also supports events, these only simulated using callback functions, and are, therefore, not asynchronous.

         -- Jini lacks administration mechanisms.  The only thing it provides in that respect is a few administrative interfaces.  These are really nothing more than suggestions and involve absolutely no security considerations.

         -- In my opinion, Jini could benefit greatly from checkpointing.  Having manual log is a poor substitute for checkpointing.

Ian Shafer
Sherif Fanous
Boris Startsev