JXTA Object Store

1. JXTA Object Store Tom Boyles SE692 Masters Project

2. Project Goals • Create a peer to peer object store application • Provide for object storing, modifying and removing • Integrate JXTA and Dr.Jia’s Object Store technologies • Provide integrity of any one object accessed from many places

3. Description • In looking for a suitable area for a Masters Project, I ran onto some articles on JXTA, a Sun sponsored specification to define its vision of how peer to peer computing should occur. They wrote an application in Java that met all their specifications and provided all the basic functionality to implement the specification. They also made it open source and sponsored a JXTA web site for developers to post their projects and contributions to the technology. I was drawn to one project on distributed storage and after discussions with Dr. Jia, decided that I could build this type application using the JXTA core and Dr. Jia's Objectstore application.

4. Competitive Analysis • Competing technologies include all spread data schemes such as RAID • A strength of this application is the incorporation of peer to peer technology in object storage • Another is its scalability allowing objects to be stored in a large number of places • Weaknesses include speed of operation and maintaining data integrity

5. Application Components • JXTA Core implementation • Object Store implementation • Peer client • Peer server

6. Application Structure • Client contains Client GUI, Client Manager, Client Utililities, Object Store and JXTA Core • Server contains Server Manager, Object Store and JXTA Core

7. JXTA Object Store Advantages • Uses the “Edge” bandwidth • Easily Scaleable by adding more peers • Fault tolerant with proper design • Few limits on network configuration • Centralized Naming service not required

8. Client-Server RAID Advantages • It Works • Known network structure • Specialized Hardware is available • Large knowledge base • Available in many configurations

9. JXTA Object Store Issues • Peers connect and disconnect from the network at will • Message delivery is not guaranteed • New technology is involved • Many to many to many operations • Understanding Object Store • Understanding JXTA • Sequence of events • Data integrity for one object stored in multiple places.

10. JXTA Object Store Solution • Use client - server idioms for components • Assume server peers will have a high degree of connectivity • Use JXTA messaging to confirm all connections • Track all objects and transactions to flag missed operations. • Define operation sequence to incorporate object checking for all transactions

11. Peer to Peer • Decentralized communications and services • Scalability requires more peers • Few limits on network configuration • Naming service and user address are not required

12. Project Requirements • Competitors • Strengths • Weaknesses. • Functions required • .Understanding Objectstore • .Understanding JXTA • .Sequence of events • .Data integrity for one object stored in multiple places. • .Getting up my morale • .Actually doing something • .Limiting the scope • .Finding the time • .Doing the design • .Picking my nose • .Avoiding it like the plague • Clock watching

13. Technology • New technology - The JXTA core application • New technology - Dr. Jia’s Object Store application. • Additional technology - JavaSpaces protocol

14. Team/Resources • State assumptions about resources allocated to this project • people • equipment • locations • support & outside services • manufacturing • sales

15. Procedures • Highlight any procedural differences from regular projects of this type • Discuss requirements, benefits, and issues of using new procedures FOR MORE INFO... List location or contact for procedures document (or other related documents) here

16. Schedule • Review high-level schedule milestones here FOR MORE INFO... List location or contact for detailed schedule (or other related documents) here

17. Transactions • Dirty Reads - one transaction reads uncomitted changes made by a second transaction • Repeatable Reads - when the data read is guaranteed to look the same if read again during the same transaction • Phantom Reads - when new records added are not detectable by transactions that started prior to the insert

18. JavaSpaces Usage Rules • Entries - objects that are used to synchronize, coordinate and communicate in JavaSpaces • Read - function to read Entries in JavaSpaces and return after a specified time searching • ReadIfExists - function to read Entries in JavaSpaces and return immediately • Take - function to remove Entries from JavaSpaces and return after a certain time searching • TakeIfExists - function to take Entries from JavaSpaces and return immediately • Write - function that write Entries to JavaSpaces

19. Current Status • Research on JXTA and the Object Store completed • Project structure has been determined • Detail design approximately 60% complete • Project time line in place

20. Related Documents • marketing plan • location or contact name/phone • budget • location or contact name/phone • post mortem • location or contact name/phone • submit questions • location or contact name/phone