[ Index ] [ Individual Project ] [ Placement Presentation ] [ Timetable ]

[ Index ] [ Research ] [ Schedule ]

Software Design

The first step is to translate Shak's project over to JMX, at least parts of it. At this moment in time I consider the follow components redundant:

• File transfer mechanism
• Method of storing versioning mechanism

The JMX Agent Architecture

The above diagram shows how the JMX agent will work. I intend to port the rule server as a agent service mbean. The GUI interface to add new versions of libraries will be a JMX enabled Swing application. Checking for binary compatibility will remain within the rule server and the GUI will be simply for adding new libraries/rules and browsing/altering what is currently in there.

All applications that want to take advantage of the automated updating to the latest binary compatible libraries will need to be JMX-enabled themselves. Hopefully this can be done via implementing an interface or extending an abstract class, ideally the former.

I also hope to implement the rest of the binary compatibility rules outlined in the Java Language Specification (JLS). Currently ten (the most common) have been implemented out of the 28 described in the JLS. Although this is bordering on 'busy implementation' work it is quite important if this type of framework is to be ever considered useful on an actual development project.

The above weaknesses were all mentioned in the 'Future Work' section of Shak's report hence make a good starting point. My examination of this report didn't discover any other problems (aside from security, which will be altered). Unfortunately I disagree with some of his suggestions:

• Define a new compressed library format

  If we expect this tool to be ever used in a real environment it needs to use jar files.

• Making updates more efficient by only downloading altered files.

  The smallest unit I was to consider is a Java package, i.e. a jar. Actually software comes as packaged wholes since, which should be guaranteed to work as such. Upgrading separate class files would require unpacking the jar, changing the files then reassembling it, while relatively straight forward adds the possibility of errors being introduced if the upgrade is not total. Since the tool is supposed to aid development by reducing the number of bugs caused by upgrading we should avoid this potential efficiency due to the risk involved.