Minor developments & design notes
It’s been a little slow going the last few days with my sister and another friend in town, but I’ve added a few little touches:
OCUnit Testing There’s really no complex code to test yet, but I added a OCUnit bundle target to the Xcode project. It’s pretty nice—tests automatically get run as part of the build process.
Xgrid Bonjour Browsing Really the first part of the code that actually, well, does something (rather than being purely structural). On initialization, the XgridDRMAASystem class starts up a Bonjour service browser for _xgrid._tcp on a secondary thread, and an array gets updated as services get discovered. Pretty standard stuff. (It’s always fun to learn from sample code I wrote four years ago as an Apple Tech Pubs intern…)
This basic structure of having a secondary thread with an active NSRunLoop will carry over to actual Xgrid-to-DRMAA communication: from DRMAA’s perspective, everything’s nice and procedural; in parallel on another thread, an event-based run loop will be getting delegate messages from the Xgrid system and (in a thread-safe manner) updating the data structures read by the DRMAA method calls. It should be pretty straightforward, and pretty much what Charles suggested off the top of his head on the Xgrid list a few months ago.
A few notes on the class hierarchy of my Objective-C DRMAA bindings vs. the Java bindings:
The Java bindings mimic the C bindings quite closely, which makes sense—the closest thing to a reference implementation is a JNI wrapper around the SGE C implementation. One downside to this is that where the C bindings lack elegant object-orientation, so do the Java bindings.
Case in point: the getDrmaaImplementation(), getDrmSystem() and getContact() methods return different things depending on if they’re called before or after init()—beforehand, they return a list of possibilities; afterwards, they return the choice selected. I set up a class relationship so that the possibilities are available at the appropriate level of representation, and the choices made are attached to an object corresponding to that choice.
From the top, you have class (”static” in Java parlance) methods of the DRMAASystem class: systems, which returns an array of available systems; as well as systemsString, implementationsString, and contactsString, included only to make the mapping to the standard C bindings a little easier. There will also be methods to retrieve a specific DRM system (so far just system, which returns the default Xgrid implementation—eventually this will be more configurable).
On the next level, once you have a specific DRM system, you can query that system for its specific systemString, implementationString, or contactStrings, and retrieve a particular DRMAASession object, which contains the methods for actually interacting with a session: begin:, end:, jobTemplate, controlJobId:withAction:error:, etc.
Now, it might seem like this adds unnecessary verbosity to the code, but for the default case, it’s really not that bad:
DRMAASession *session = [[DRMAASystem system] session];
etc.
June 10th, 2006 at 10:21 pm
I will be interested in how you are using OCUnit on this. I have not used it so far with my Xgrid core stuff, as it seemed hard to deal with asynchronous calls, network issues,… Are you going to use “mock” objects to simulate the Xgrid controllers and jobs? One problem might be to make sure that the test will run fine when other people compile your code. Maybe one simple requirement is to suppose you have an Xgrid server running on ‘localhost’.
Anyway, you don’t have to answer all of this now. I am just curious to see how you will deal with it, but I can wait just wait for the code