I tend to liking simple things, and to suspicion of big “enterprisey” software frameworks. I am dimly aware that up in the clouds there are platforms built on platforms built on platforms built on Java, towering edifices where acronyms like “JBI” and “ESB” and “SCA” live. Except for, I could never figure out what they actually, you know, did. Let’s be honest; the complexity and the high-level arm-waving about “Integration” scared me away and I never really tried. Well, I’ve stumbled into a closer look and am beginning to think there’s some there there.
I’ve been talking to Andi Egloff, who lives up there among the floating acronyms in these enterprisey clouds. I asked “Well, what does this software actually do?” After some talk he said “Let me show you what we’re working on.” Showing is so much better than telling.
They’re calling their work-in-progress “Fuji”. Here’s a screencast where they hook together an RSS feed, an XMPP stream, and a log-file, with an interposing a Ruby filter, using Fuji and a bit of DSL voodoo.
They’re also thinking of a visual interface; here’s the same logic, only with little boxes and arrows instead of DSLs. Personally I prefer the DSL.
It’s all based on OSGI, hmmm.
Now, in a world that already has Yahoo Pipes and simple Ruby POP-to-Twitter mashups, one wonders if you need a big honking Java howitzer to squish this particular ant.
So I asked Andi that, and he said “Yes, but then with JBI you can also talk to ESBs and other traditional enterprise integration points”. Which I’m not sure that YPipes or little Ruby scripts are built for. I asked him to show me that and he said they’re going to. I’m interested; stay tuned.
Contributions
Comment feed for ongoing:
From: ed (Jun 02 2008, at 13:04)
is it april 1st?
you can talk to esbs with rest and http, too. jbi is a train wreck. run away.
[link]
From: Daniel Haran (Jun 02 2008, at 15:15)
That was astonishing, and brought back so many bad memories.
Secondly, that application was far too complicated for what it was. Why can't I do:
get -t 20 "http://rss.cnn.com/feed.xml" | grep "buffet" | file '/tmp/archive.xml'
tail '/tmp/archive.xml' | im -from "bot@sun.com:pass" "me@gmail.com"
Feed entries are the standard in of the web. We shouldn't have to write software to deal with them.
I was also suprised Netbeans didn't indent a do / end block properly; that's pretty ghetto.
[link]
From: Tony Fisk (Jun 02 2008, at 17:25)
This is a good example of what I call the 'middle man' anti-pattern.
(ie middle men are often essential for getting the details of a complex activity working smoothly, but one sometimes has to ask just how complicated the activity needs to be, and rather too often the response comes in the form of priestly incantations and obscure acronyms... I sometimes think that half of being certified consists of knowing the jargon!)
eg: for a long time, I was vaguely aware of this impressive sounding webby thing called AJAX. It wasn't until I actually started using it that I realised it was a callback principle familiar to anyone used to working with client-server architectures.
...but up 'till then, it sure sounded impressive! (and still very handy!)
[link]
From: Keith Babo (Jun 02 2008, at 17:28)
Hi Daniel,
First, as one of the folks responsible for Fuji, I want to apologize for bringing back bad memories. I promise that was not one of our design goals when the project started. ;-)
I think you really make a good point w/r/t simple solutions for easy problems, and I wholeheartedly agree that the series of piped commands you listed is more straightforward. The aspect that I don't believe was immediately apparent in the Fuji screencast is that the filters (RSS, JRuby, XMPP, RSS) we pipe together are merely examples. Fuji (and the JBI-standard implementation at its core) allow users to select from a wide variety of protocol adapters and application engines to suit their particular environment. While it's possible that there is a straightforward and interoperable set of *nix commands for connecting CORBA, CICS, SAP, JMS, etc., etc., I have yet to find them. It's also kind of nice that Fuji is Java-based and hence platform-independent.
So one of the design goals of Fuji is to make piping these various integration technologies together as easy as possible. As Tim noted, we have some other demonstrations in the pipeline that I believe will elaborate on this point. I hope that you will check us out again in the near future and share your feedback.
Oh, btw, the indentation bug is actually a problem with our NetBeans plugin for Fuji and not an issue with the core NetBeans platform. Didn't want someone else to take the fall for our bad practice. :-)
[link]
From: Andi (Jun 03 2008, at 12:39)
Great the hear some heart felt feedback.
Daniel, I actually think your proposal is a logical extension of the Fuji philosophy; that is, solve it in the most productive way (and the technology) that best suits your problem.
Clearly it is a challenge to choose a simple enough demo for integration so that a) technologies are familiar (not everyone speaks CICS, SAP or CORBA in their sleep) and b) it's quick enough for a quick screen cast; hence we did a trivial filter and stayed away from more involved transformation/enrichment/mash-ups etc. for a first intro.
As such, I hope we didn't give the impression that this is somehow focused on RSS feeds, but that it illustrates some of the key concepts of how to route and manipulate messages you want to send amongst different systems *if* your needs go beyond simple scripts. That is, typically you would also have some business logic in there that's not necessarily expressed in a shell script and you might also want to take advantage of features and mediation the platform adds such as reliability, fail-over, alerting...
Tony, agreed that the main attraction of such a platform is when you want a middleman to add more value (e.g. if you want mediation to be able to dynamically add to and change the system); and at a lower cost then it would take to do it manually. This value can come in the form of being easier or quicker to develop; or being easier to achieve the non-functional requirements, but it can also come in the form of being easier to operate and maintain in production. Clearly our intent for the demo above is to show the principles and basic constructs of the platform, not an ultimate solution or recommendation for the specific scnenario.
Ed, clearly Sun seems to have messed up (IMO) with the initial messaging around JBI and has left many developers wondering as to what it could possibly be good for. My question: did you see JBI anywhere in that application? You shouldn't have, it's not exposed to the user at all. It should just be an underlying enabling technology. Then I would be curious, why would you care if the underlying system is built on a standard, rather than a proprietary invention of some middle ware vendor? The only difference would be that you might benefit from getting some additional containers and adapters from other vendors/open source projects you can plug in, is that so bad?
[link]
From: Daniel Haran (Jun 04 2008, at 13:50)
Keith, Andi,
Thanks for the answers. I'll watch for future release announcements.
I'm not talking about *nix commands, but a DSL. That would be far more important IMO - and far more usable - than any Yahoo Pipes look-alike GUI.
[link]