Recently I finished (in so much as any software I develop is actually ever finished) a tool that allows bulk jACT-R model runs to be submitted to a remote server. All in all, it was an amazingly painless experience made possible by ECF, a protocol neutral communications library in the latest release of Eclipse. To be completely honest, while I’ve had dreams about this tool for a long time, it wasn’t until I saw the webinar for ECF that I realized just how feasible this project was.

What follows are my thoughts and impressions on using ECF. Before I begin, let me include this disclaimer: for all things networking, I am self-taught. And like all self-taught men, I had an idiot for a teacher. However, I do have a great deal of experience building networked tools for robotics, modeling and my own edification. Up until this point I have relied upon MINA, another slick networking framework – but one that sticks closer to more traditional networking models.

I’d like to start off with the positive points.

  • The use of the IContainer and adapter paradigm makes it really quick to get started using the framework, particularly for those familiar with Eclipse.
  • The generic (and serializable) IDs make the tracking of connections absurdly easy (e.g. I use them as map keys to keep track of processing jobs and the clients & servers they are associated with across invocations of the IDE. Quit, start up again, and everything is right back the way it was).
  • The discovery api is incredibly simple. Having tried to use zeroconf years back, this is a dramatic improvement.
  • Retrieving files via known standard protocols is also a snap (I use it to fetch the archives of the runs and results, with a dynamic Jetty instance to server them). From what I can tell, virtually all container instances support a configurable url file fetch mechanism (file:, http:, scp even).
  • The use of channels makes arbitrary messaging (read as: serialized POJO) quick and painless, particularly since most containers support it with relatively little difficulty.

Before I present my gripes, let me just say that the folks behind this project have done an awesome job. It took about a week to get this whole tool up and running. But there were some headaches, mostly due to documentation (availability, when it’s there it’s good) and mental model mismatches.

Clients as Servers

If you want to build a server, you’ll probably look at the “ecf.generic.server” container, thinking that you’ll hook up to it some connection policies, channel handlers and be done with it. Not exactly. The ecf generic server acts as a hub. Your actual server will be a client that connects to the ecf server in order to talk to the actual clients that connect to it as well. I can understand the reasoning here, but this doesn’t map very cleanly onto most conceptions of a server. Looking through the developer mailing list, I see that I’m not the only one who’s gotten a bit confused.

This is magnified by how the generic server handles channel communications. When a client connects to it, it is assigned a unique ID, it will be up to you to determine which IDs correspond to the server-client and the clients-proper.

I am somewhat surprised that there is no IServerContainerAdapter that permits the setting of connection policies and the like. Something that more closely maps onto the traditional concept of a server. Something less general than the ecf generic server that can be extended into something very specific. As it stands, I don’t see a way to quickly build a server that non-ECF clients can access. (But I’m probably wrong).

Services

I love them OSGi services, and ECF is supporting them as well. But I’ll be damned if I could find any of the file sharing services. I don’t know if it’s missing or I’m clueless, but I wasted a couple of hours looking for said services. Fortunately, they, like all good Eclipse citizens, include their source code. In there I discovered that most containers support the url file transfers right out of the gate. Doh!

Where are those container names?

ContainerFactory.getDefault().createContainer(String) is the most document method for creating a new container, yet finding the list of current container names can be a pain (short of PDE extension point search). There is a providers list, but it doesn’t include the names. After digging I finally found it on the eclipse site proper. Since the wiki is actually the first place the ECF project page on Eclipse.org directs you to, stumbling back to the eclipse site again seemed like the wrong path to me. I dunno. If it were me, it would be at the top of the providers list and maintained regularly (ecf.generic.fileshare” is apparently a vestigial remnant from earlier versions).

Anyway, as I mentioned, these are small gripes for what is an otherwise exceptional piece of work, particularly when you consider all the functionality that this is permitting. Good job, guys.