xmlhack: Two open source projects for EAI

The open source projects Proteus and Babeldoc both announced new releases. Although they look very different (one is a "framework", the other is a "system"), both are written in Java, support XML, EJBs and JDBC databases and do not hide that EAI is their vocation.

Proteus

Proteus is presented as a framework, ie more as a library to integrate with your application than as a complete environment:

Proteus is a framework for creating messaging applications, and a message broker built upon that framework. Proteus has adapters that allow databases, message queues, ftp servers, email and other message sources and sinks to be addressed in a simple, uniform fashion. It differs in approach from most other toolkits in supporting both centralized and point to point implementations with a minimal footprint.

Proteus is built on a small number of basic components (message sources and sinks, filters, routers and brokers) which assembly may be described in XML documents. The documentation of its API shows that these components are defined as very simple interfaces and this should make this framework highly extensible. Proteus appears to plan using this extensibility to add new features and its home page announces that new adapters for e-mail messages, flat files, Tibco Rendezvous and WebMethods will be available soon.

Despite detailed documentation, I found no mention about administration tools or processes.

Babeldoc

Babeldoc is presented as a system to process documents which is "not a replacement for webmethods (yet)" and puts a lot of emphasis on its admin and journaling features:

Babeldoc is a document processing system. Babeldoc is especially suited for Business-to-Business (B2B) environments and similar integration projects. Babeldoc has a flexible and reconfigurable processing pipeline through which documents flow. These pipelines transform the document. Additionally Babeldoc has a sophisticated and extensible journaling system so that documents may be reprocessed and resubmitted as well as tracked through the system. Its runtime environment is flexible so that it can run standalone, in a web container or in a J2EE container (currently tested on Jboss 2.4.x and JBoss 3.0.x). Babeldoc has both a Web console, a number of GUI tools and a command-line console to control the document flow.

As might be expected, the description of these pipelines is written in XML and, despite Babeldoc's "complete system" intent, I found no Javadoc for its API online.

BIE (www.brunswickwdi.com/bie) is a lot further along than either of these projects. I also tried open adaptor (www.openadaptor.org).

Hi there, if I look at BabelDoc and Proteus it looks somehow similar to Open-XML-Framework http://www.orbeon.com/oxf/ Do these 3 initiative ave the potential to benefit from each other and how could that be? :-) stw

The website is now much "fresher" with links to the generated documentation and the javadocs. I have just been laid off so I will be able to hack on this with renewed vigor. The next thing that will get to the documentation page is a "Developers Guide" this already exists but needs lots of care.

Check out the sourceforge website at http://sourceforge.net/projects/babeldoc The mailing list is useful.

I'm glad that this article introduced me to Babeldoc, a fascinating project I had somehow overlooked. Examining Babeldoc I found capabilities not discussed in the article or in Babeldoc's own self-description: interfaces with databases, FTP servers, HTTP and SOAP, and a routing capability based on XPath queries.

Some thoughts on the differences between Proteus and Babeldoc:

1. Proteus is very simple, and is designed to be used and extended by an EAI team that is primarily composed of people comfortable with Java programming (who don't mind, and indeed prefer, seeing complete JVM stack traces in their logs if there is a problem). Babeldoc, while simple in outline, emphasizes robustness and usability by non-programmers (though I think a familiarity with XSLT and XPath is a prerequisite for doing useful work).

2. Babeldoc, as the name implies, is document-centric. It is meant for processing documents, and primarily XML documents. Non-XML documents are handled by first converting them to XML. Proteus is based around the idea of sending and receiving messages, and the question of what constitutes a message is deliberately left open. It turns out, for example, that in some contexts a "message" is a JDBC resultset. A Proteus broker which consists entirely of JDBC sources and sinks can pass Resultsets back and forth between them without ever going to the bother of serializing their contents as XML or anything else.

3. I don't think the properties-file-vs-xml config issue is all that important, since xml and extended properties are equivalent in expressive power and can be interconverted. When I'm writing a complex broker description I usually prefer to do it in a Lispish syntax and convert it to XML when I'm done.

4. Proteus in future will be moving in the direction of process management, incorporating some notion of an Agent. Ultimately we expect to be able to convert any of the various xml process description standards like BPML or BPEL4WS to a Proteus broker description without loss of meaning. Of course, the Babeldoc folks might be thinking along the same lines.

5. I wonder if the Babeldoc team has given any thought to handling EDI X.12 documents? This would seem to be a good fit.

Currently babeldoc is being used to integrate data flows for the banks in Serbia to the Serbian central bank.

It looks as if these two projects should merge! Babeldoc's more advanced concrete implementations (GUI etc) are let down by the properties-based configuration - whereas Proteus' XML model is far clearer.