Berkeley Bits

For the most part, I’ve been pretty happy with the distributed OSGi programming model.  Unfortunately, there are a couple of areas where the reference implementation is getting under my skin:

1. WSDLs are not easily usable outside DOSGI
2. There is no obvious way to handle cross-cutting concerns

It may be possible to fix my WSDL gripe by modifying the CXF DOSGi implementation to use JAXB and JAX-WS annotations.  This would make the WSDLs more usable, but there was quite a bit of disagreement on the CXF mailing list about the wisdom of annotating the service interfaces.  Still, I might spend some time investigating whether this is a workable solution.

To handle  cross-cutting concerns, I’m about to take a look at Equinox Aspects, but I’m hesitant to go down that path for two reasons.  First, it seems to be designed specifically for the equinox container.  And second, it is yet another pre-1.0 project, and I’m hesitant to keep building upon such bleeding-edge technologies.

I’ve been thinking a bit about the media capture, processing, and distribution software ecosystem.  Most of the available systems are proprietary, and the open source options are typically licensed under the GPL.  Matterhorn’s major value proposition at this point (that would be the vapor-ware point) consists of the community and the license, both being Apache-style.

But we can’t stop there.  The software itself needs to add value, and I think flexibility is where we should focus.  We know that we can not make any assumptions about the deployment topologies of Matterhorn capture devices or application servers.  Depending on their needs, institutions will choose the number of capture devices per venue, the number of venues, the number of encoding nodes, and the number of media analysis nodes needed to handle the quantity and types of media captured and processed.  It seems that the Matterhorn partners are in agreement about the need for this type of flexibility.

What we haven’t talked much about yet is flexibility of storage.  Storage presents a fundamental budget and IT challenge for any institution intending to produce and manage many terabytes of content per semester.  Institutions should be able to utilize a SAN or a content repository if they choose, but neither of these should be a requirement.  Considering the ever expanding cloud computing options, a distributed file system such as Hadoop’s HDFS might be an attractive choice as well.

The implications of this kind of infrastructure flexibility will necessarily impact the software design.  Direct access to java.io.File will simply not be an option.  It remains to be seen whether the performance penalty of streaming multi-gigabyte files between capture clients, repositories, and application servers will be acceptable.

I’ve neither read Cooper’s books nor seen/heard him speak before today, when I found a this interview recorded at “Agile 2008″.  It’s a discussion of agile programming, why it came about, and what it’s popularity says about the converging motivations of programmers and interaction designers.  It’s long (~45 min), but I found it worthwhile.
(more…)

I did a bit of fiddling with RESTEasy yesterday.  Following the examples in the jboss source, I was able to resolve a URL via RESTEasy after about 30 min of pom and web.xml wrangling.  Not too bad.

RESTEasy pulled the following jars into my testing webapp (I chose the gradebook, since I’m familiar with its structure):

(more…)

Matterhorn must provide a mechanism to allow institutions to easily configure workflows that match their local business processes for capturing, processing, and distributing media.  I’ve been looking at some open source workflow engines, hoping that one of them will meet our needs.  This is a cursory review of the engines I’ve found to date:

(more…)

I’ve been using JWebUnit to put load on our sakai instance in order to work through some performance problems we’re seeing in production, but can’t seem to reproduce on dev or qa.  JWebUnit has been a pleasure to work with, creating 100+ concurrent users is a snap.  With code like:

(more…)