Open Source EAI solution

Open source should not be the question imo...

These programs (ETL apps n the likes) are all set to have a gui which will render all programming obsolete. That's their strength. The way it's coded should be of no issue to you.

But that's just my $0.02

A lot of the EAI products have a GUI that lets you put together sources and sinks and experiment with passing messages around. The first such GUI that I saw was Vitria's which had simple drag-and-drop adaptors and many ways of doing transformations in between (a 'lite' imitation of that is immediately (and FREEly) accessible in OpenAdaptor).

When it comes to real-world EAI, the question becomes less "How do I connect the pieces" and more, "What do I put in the messages ?". A typical project may start with analyzing the information available in the various systems but soon develops into an Object-Modelling exercise where the messages are the 'objects' and the entire EAI system with connected legacy apps becomes a single, massive distributed-object application. EnyWare has an 'event' model which is designed for an Energy Trading business so if you're in that business, you're in luck. If you're in another business, the concepts should translate quite easily. OpenAdaptor took a different approach and have a single DataObject which encapsulates your message and simply moves it through the system. Despite being based on a banking business, there is no banking model built into the OpenAdaptor message structure; it is entirely generic.

Anyone buying or downloading Tibco, Vitria, JBoss or BEA Weblogic will understand the analogy of having a kit car delivered to you without design or assembly instructions. Some things are easy to get started on but to get the entire vehicle working takes a lot of intelligence and specialized understanding: for a car there's the electrical system, the fuel system, the suspension and steering; for an EAI system there's the message bus, the application server, the common model and mapping.  

It is difficult to avoid the 'spaghetti' of point-to-point systems especially when that is exactly what most people implement as their first venture into EAI - "Let's first connect the sales system to the stock control system so we can have real-time stock balances for sales instead of nightly updates, and we'll work on getting the accounting system in the loop, too". So, do you write one adaptor at the stock control system that broadcasts generic stock information to both systems or write a specific message for the sales system because you want to get that one off your to-do list, then start afresh on the financial system ?

Another concern is the proprietary implementations - all EAI solutions provide the standards of J2EE, JMS, EJB's but to get performance out of Tibco, you'll be writing in C++, not Java and the overhead of creating EJB's will be left behind with the pretty GUI. Now you're left with the bare bones of a high-speed messaging system and a load-balanced App Server passing around XML as fast as possible. The beauty of this is that you can still build your EJB's to populate your object model off the same bus as Tibco have thoughtfully provided a JMS add-on that will read the same XML from the bus and plug right into your J2EE components.

I would not say that any of the available solutions obviate the need for programming - if you look at the overall connected systems as a distrbuted-object application, there is a huge amount of analysis and design and very little coding, but the faster-throughput systems such as online trading systems cannot be built via drag-and-drop alone.