EMC eRoom is going away.  It has been marked as End of Life (EOL) so what next?  EMC Documentum have 2 options: EMC Documentum Collaboration Services; EMC Documentum Centerstage.  Armedia’s immediate goal is to support Collaboration Services, then Centerstage but why stop there?  Why limit a client’s choice.

Armedia’s eRoom migration story is in 3 acts (and yes, I have been listening to some test pieces that I used to play in my brass banding days – check out Year of the Dragon by Philip Sparke).

Act I – The Export

Getting the content out of eRoom into an understandable format.  Of course, its not just the content, there is  a large quantity of metadata in eRoom as well.  Act I – The Export deals solely with interrogating eRoom and generating a document detailing everything about eRoom.  From communities to Files.  From eRoom Setup to databases – we mean everything.  The result: a well-formed XML document

Act II – The Transformation

As with any classic performance, after the captivating opening, Act II deals with getting to know the characters.  In this case, the transformation gets to know the XML document and gains a deep understanding of the objects held within.  The transformation is responsible for also generating a secondary XML document. This is formed to support the ingestion to a new Content Management System (CMS) and / or Collaboration System.  Currently the supported transformation is for EMC Documentum Collaboration Services.  This can easily be extended due to the flexible architecture of this utility and is simply a case of transforming XML.

Act III – The Load

The closing act is the build up to the dramatic climax which leaves the audience going “WOW!”.  eRoom Migration aims to achieve the same “WOW!”.  Now that the XML has been transformed you can sit back and let the load run automatically.  That’s it.  By using the ingestion engine of Caliente! loading all the content and metadata is simple.  Just let eRoom Migration take care of everything for you.  The only thing it does not do is say “WOW!” – we leave that to you.

Over the next few weeks I plan to talk in more detail about the approach taken and dig deeper into the 3 different pieces of the migration effort.  For those eRoom users, what do you see yourselves using in the near future?

If you are a Java developer, or the administrator for a JEE system, most likely you are using OSGi already.  The Eclipse development environment is OSGi-based: Eclipse modules are OSGI components.  Almost every application server is based on OSGi: JBoss, Weblogic, WebSphere.

Using OSGi for a business application should affect your design.  Most systems allocate technical requirements to components.  For the most part, these components live only in the architecture and design.  In most all the projects I’ve ever worked on, the deliverable Java code lives in big honkin’ jar files with little or no traceability back to the architecture and design.  Inside the jar file, every class has access to every other class, and the internal dependencies end up spreading all over the place.  Reasoning about the code base, or pulling out smaller features for reuse elsewhere, becomes very difficult.

In a well-designed OSGi architecture, each logical component from the architecture and design should become one OSGi bundle (the OSGi jargon for component).  Clients have access only to the public interface of each bundle; the implementation remains inaccessible.  Instead of a handful of big honkin’ monolithic jar files, you end up with many small well-defined bundles.  This direct correspondence of one architecture/design artifact (a component) to one development/runtime artifact (a bundle) is what I like the most about OSGi.

Some benefits of a network of well-defined, small components:

1. Easy to support different implementations of the same interface.  When development starts, you can quickly release stub bundles of the interfaces your team is responsible for; other teams consume your stub bundle to write their own bundles.  As you complete real implementations of each interface, your clients can replace their stubs with the real thing, without missing a beat.
2. Clients can upgrade only the bundles they’re interested in.  With one big honkin’ jar file, every client has to upgrade every time you release, even if they don’t need the defect fixes or new features in this release.  With a network of small bundles, each client only gets what they really need.
3. An end to classpath hell.  The OSGi runtime can host different versions of each bundle.
4. Supposing you are a software vendor, you can package your applications as a set of bundles.  You can offer a basic cheaper system with a few bundles, and value-added features implemented as extra bundles.  Your clients that don’t want or need a NIEM interface, and your clients that want it very much, are both happy.

There are some drawbacks to OSGi for business applications.

1. Currently using OSGi with plain ol’ Web applications can take some work.  Products like the SpringSource dm Server aim to make this easier.  Also, the OSGi Alliance is working on Enterprise specifications to define how OSGi can be used with JNDI, data sources, JPA, etc.
2. Java developers have to become a little more aware of design issues.  Most Java programmers I work with want to get their features implemented and defects resolved with as little time and thought as possible.  This is the very genesis of the big honkin’ jar files I keep mentioning… It takes little time or thought to slam out one more class and add it to the one big honkin’ jar file.  This problem should get easier with better tool support.  For example, the Spring Tool Suite and IntelliJ IDEA have first-class support for OSGi development.

InfoQ has an excellent series of blogs to help you get started with OSGi development: Part 1, Part 2, Part 3, Part 4.  Peter Kriens’ blog is a great way to keep up with OSGi news and events.