Move over frameworks, here come the meta frameworks
This is somewhat old news, but it’s been festering and gnawing at me for months now, and I can contain myself no longer. A while ago I noticed an announcement for some incredible new product. This product goes by the name of the keel framework.
So what, you might wonder. Who the hell cares that a bunch of asshats got together and are trying to pretend that lumping together a bunch of open source droppings makes for a good business plan? Well, nobody. However, the approach these guys (or guy, I find it too incredible that a bunch of people would agree on such a ridiculous idea) took is somewhat….innovative. Given that there are so many frameworks and solutions out there, they figured the perfect product would be a…meta-framework!
Yep, you heard that right. A new framework that lets you work with many frameworks! Webwork with struts, hibernate with ofbiz, tapestry with…cocoon! Lump in EJB’s, Avalon, JBoss, axis, and every other jakarta project and you start to get an idea of what keel is.
Reading the ‘white paper’ justifying keel’s existence fills me with regret that I don’t have a printer that takes in toilet paper. Had I such a wondrous device, this paper would the the leading candidate for printing on said medium, and I’d rush to ingest as much vindaloo curry as I can to ensure that this printed material gets the usage it so richly deserves.
For a start, the whole thing brags about how it derives all its magic from being built on that modern day miracle, Avalon. Someone should inform these poor saps that even Avalon developers these days are filled with doubt and remorse over what they’ve done. We also of course have the usual jbossian opensource thoughtspeak noises littered throughout the white paper. He also babbles on about how you’re not tying yourself to any particular anything, neglecting to mention that in reality, you’re not just tying yourself to a million frameworks of questionable merit, you’re also tying yourself to Avalon and keel interfaces.
The pitiful buzzword compliance effort is also laughable. I mean really, ‘Keel is ready made server side infrastructure’?!? Of course, that doesn’t seem nearly offensive enough when you consider the first keel design objective: ‘Don’t re-invent the wheel, invent to axle’. How can someone so thoroughly misunderstand the wheel reinvention expression? Michael Nash, you are a dimwit of the highest order. As amazing as it might be, modern science has already invented axles, so run along now and save yourself the bother of having to invent it yourself, Mr Nash.
It’s indeed a sad sad state of affairs when anyone would take such a ridiculous idea seriously. How low have we sunk, us java lot? Are there no depths to be left unplumbed? How do you people manage to go to bed at night? Have you no shame?
April 8th, 2004 at 12:06 pm
First Post :)
April 8th, 2004 at 12:11 pm
But isn’t Keel in Java? I thought that Hani was going to .NET…
April 8th, 2004 at 12:12 pm
There once was a biler named Hani,
Whose name was in fashion quite funny
He took a big dump,
And got a sore rump,
And now has a sphincter quite tawny.
April 8th, 2004 at 2:10 pm
april fools!
April 8th, 2004 at 2:16 pm
while it may suck that there is such a profusion of shite frameworks out there, at least there’s competition in almost every arena, and potential for the strong to survive and the weak to be destroyed. and inspiration to do things better. the only obstacle to meritocratic javaspace of course is marketing, and the silly wonks who believe it.
April 8th, 2004 at 3:18 pm
But isn’t it stupid to litter the landscape with weak frameworks that will obviously die in an attempt to make “best of breed” seem better than it is?
April 8th, 2004 at 4:38 pm
I’m going for a game of meta-wank-word bingo. Anyone want to play ?
April 8th, 2004 at 5:45 pm
wow…keel gets biled…must be coming up on the radar then :-D
April 8th, 2004 at 6:16 pm
and here i was hoping your april fool’s joke would not be a joke after all, what a disappointment
April 9th, 2004 at 3:20 am
I never meta-framework that I liked.
I’m a bit worried about tying myself to Keel in case another meta-framework comes along and dominates.
Let’s write an abstraction layer that will allow us to use meta-frameworks interchangably. Think of it as inventing the chasis.
April 9th, 2004 at 4:14 am
I sincerely hope you are, Leo, your Jicarilla framework looks incredibly conceited to me. How can one write something like the following and not being immediately exposed to the public mockery?: “PicoContainer, Spring Framework, XWork, Keel. Jicarilla is different from each of these in many subtle ways, but also in a very obvious way: Jicarilla natively supports the use of each of these frameworks and/or components developed for them”: components developed for them are, in 3 cases out of four, pure javabeans!!!! Moreover: I have a bunch of beans in my Spring infrastructure that benefit from the features it offers for declarative transactionality and hibernate integration. Can I run them in Jicarilla (without having it simply wrap Spring, of course) and have the same behaviour? “One framework to rule them all”: I hope you are doomed to fail.
April 9th, 2004 at 9:38 am
Silent Bob - that sounds like MDA
April 9th, 2004 at 10:43 am
It seems these meta-frameworks are written by some java developer’s little brother who is still watching and playing with power rangers and is somehow applying the whole “mega-zord” concept to aggregate several tiers (a pink pteradactyle being say the web-work tier). You see, once keel has it’s “server side infrastructure” “ready made”, it will be invincible and wield the powerful “zord sword” to destroy any .net weenies that happen to come by.
April 10th, 2004 at 5:47 am
some French wizard wrote…”Can I run component for framework X in framework Y (without having it simply wrap framework X, of course)?”
basically, nope. The smaller framework X and Y, the higher the chance of success, especially if Y is bigger than X.
“components developed for them are, in 3 cases out of four, pure javabeans!!!!”
so why can’t one run “component for framework X” in “framework Y”? That’s the javabeans idea, innit?
“(…) I hope you are doomed to fail.”
thanks for reminding me why I never comment here :-D
April 10th, 2004 at 9:19 am
> some French wizard wrote…
(n.b.: I know I could appear as a Spring zealot, but I’m a simple Spring user - italian and not french, just for the sake of clarity)
>basically, nope. The smaller framework X and Y, the higher the chance of success, especially if Y is bigger than X.
Ok, so I understand the sentence “Jicarilla natively supports the use of each of these frameworks” should read “Jicarilla has some chances of success trying to embed components of smaller frameworks”, instead.
Now, since Jicarilla seems to me much smaller than, for example, Spring, I understand that the chances Jicarilla has to embed Spring components are near zero, and are only concrete when the components one uses in Spring are pure javabeans used without expectations for features offered by the framework. So, as the chances approach zero, the sentence “Jicarilla natively supports Spring components” approaches falsity. Am I wrong?
>>”components developed for them are, in 3 cases out of four, pure javabeans!!!!”
>so why can’t one run “component for framework X”
>in “framework Y”? That’s the javabeans idea, innit?
Of course it is: that’s why writing a “framework where you can run components of other frameworks” is ridiculous, if this turns out to be “using them as the pure javabeans they are”, and simply false (”basically, nope”) if you consider that (some of) the frameworks you are saying jicarilla supports are much more than IOC containers.
>> “(…) I hope you are doomed to fail.”
> thanks for reminding me why I never comment here
I agree it’s somewhat unpleasant being exposed to the inconsistency of one’s own statements…
Not commenting here wouldn’t change my hopes: it’s things such as the one I’ve pasted before, that you should keep yourself from writing.
April 11th, 2004 at 4:39 pm
man, this is almost turning into civilized debate! Can’t have that on Hani’s blog, can we?
Seriously, you really should try to look at some code before having such a strong opinion :-D
If your components are simple javabeans, yes, you can run them in jicarilla. If they are complex beans using lots of springframework features, of course you can only run them inside spring. Just like you basically can’t run EJBs inside a servlet engine.
That can be a kind of annoying situation, since you might also have some components that run only in (say) avalon’s fortress, and you can’t make components from spring use components from fortress, nor vice versa.
So you run your spring components in spring, your avalon components in avalon, and you put some glue in between (could be jicarilla) to make things work together. That’s it. I love that axle quote.
April 12th, 2004 at 10:42 am
My new meta-framework is think-once deploy anywhere, anytime, any server, any client, and has transparent loose coupling with inversion of control, declarative programming, B2B, P2P, E2E, C2C, and is e-Capable, open standards, cross-functional, full-lifecycle, continuous integration, extreme, portable, 100% pure java, blogspace configurable content management i-document delivery system with extremely high ROIs that comes BPO ready for e-commerce and ERP on extranet or intranet on any ISV or SCM. We connect people!
April 12th, 2004 at 10:43 am
Top that!
April 12th, 2004 at 10:43 am
I forgot the word “portal” and “container” (damn!)
April 12th, 2004 at 11:07 am
Nice to know that I’m considered “of the highest order” at least :-)
I think that’s all the comment this rant deserves, other than to say that I’m definitely not the only “dimwit” involved in Keel, there really are a bunch of us!
Mike
April 12th, 2004 at 11:56 am
Fortunately for bilers everywhere, Keel is not designed to make your app a success, it is only designed to slightly decrease failure by slightly limiting your use of dead end interfaces.
This, in turn, only puts the responsibility of good architecture on the developer.
If we could make Keel not even exist at all, and still accomplish this very simple objective, we probably would. If this contradiction is too much to grasp, then ‘marry the first girl you meet’ and couple to that codebase of the moment. At least you will never run out of work, once you are tightly coupled to that perfect girl, er uh, code base….
April 13th, 2004 at 5:11 pm
>>”Michael Nash, you are a dimwit of the highest order.”
Darn! I want that title.
Does anyone know how I can get a job as a “Dimwit of the highest order”.
I image that it’s a great job with even better bene’s and pay!
–Not to mention the cool title that I’d have on my business card.
-Phil
(An even dimmer-witted keeler)
April 13th, 2004 at 6:21 pm
> man, this is almost turning into civilized
> debate! Can’t have that on Hani’s blog, can we?
We could, but flamewars are funnier, IMHO. Hani would agree, if commenting on his own blog wouldn’t be strictly prohibited to him by the little green man that lives in his head. ;)
> Seriously, you really should try to look at some
> code before having such a strong opinion :-D
Let’s put it this way: should I ever have the need to integrate some of my Spring components with, uhm, a javabean named “PicoBean” written for pico, or a pojo for xwork named “XworkPojo”, I’d definitely think about using Jicarilla, before venturing into the perilous deeps of code lines such as
PicoBean bean = new PicoBean(); or
XworkPojo pojo = new XworkPojo();
or before having the foolest idea of them all, and try to integrate those components using Spring prototype IOC features.
;-)
> If your components are simple javabeans, yes, you > can run them in jicarilla.
Ah, ok, I see jicarilla’s value, now.
> If they are complex beans using lots of
> springframework features, of course you can only
> run them inside spring. Just like you basically
> can’t run EJBs inside a servlet engine.
That’s what I suspected, too.
> That can be a kind of annoying situation, since
> you might also have some components that run only
> in (say) avalon’s fortress, and you can’t make
> components from spring use components from
> fortress, nor vice versa.
This scenario is so horrible that I will have problems at falling asleep tonight: hopefully I won’t have to integrate fortress (or Merlin, or Phoenix, or ECM, …) for the rest of my life. Listen: I’ve been trying to follow the evolution of those projects for years, and all I got from it was the sad and frustrating feeling of being way too stupid to understand what they were meant for.
One day I started using Turbine, and all of a sudden I understood what was missing, and what was missing were IOC, and AOP, and neat declarative features if compared to EJBs…: then I turned back to Avalon trying to have what Turbine was missing… and before I could even have my first instance of Merlin running with anything reasonable inside Spring was here, and my life changed to a better thing, since all was clear, and there were plenty of examples, and the APIs were stable and didn’t change from one point release to the next, and the container features were immediately useful, and well documented, and Hibernate integration was simply perfect… and, ok, you understand what I feel, I think. ;) Fortress: no. Spring: yes.
>So you run your spring components in spring, your
>avalon components in avalon, and you put some glue
>in between (could be jicarilla) to make things
>work together. That’s it. I love that axle quote.
Ok. I’m happy I don’t have any Avalon component to integrate in my current architecture. If I had one, rather than keeping all those support interfaces I would strip them out and refactor the logic in beans that I could use from Spring. At this moment, what I’d like to integrate is a layer of Turbine services, where all I will have to do is convert a couple of “interceptor-ish” tricks I had done in a pre-AOP world, remove a couple of TurbineService interfaces (or TurbineSupport, don’t remember) and for the rest they will be ready to be used in a Spring world.
p.s.: you keelers trying to act as if you weren’t pissed off are really funny.
April 14th, 2004 at 3:22 pm
What is the point of this rant? You do not like the phrase “meta-framework”? You do not like the concept, and therefor you do not think the project should exist, no matter how effective or valuable the end result is?
Then don’t fucking use it if you don’t need it. I can completely understand if you think the added complexity is not worth the tradeoff. If you are developing a shopping cart web application, use PHP. If you are building a J2EE app for an environment that you are reasonably certain is not going to change, use the JDK, sprinkle in some Struts or other comfort tools that you can easily understand and go to work.
However, if you are developing multiple enterprise applications, and you do not know if you are going to be authenticating against an NT domain or an LDAP directory or an Oracle table for the next project, it makes a lot of sense to use a meta-framework that will let you reuse the same code, write to the same authentication interface, and switch the implementation out for each new deployment requirement. The added complexity of learning the framework and developing cleanly using SOC, IOC, etc. does add to the initial learning curve, but can pay off in a big way as the complexity of your requirements or deployment environment increases.
You seem to be hung up on the idea more than the actual project.
April 19th, 2004 at 5:19 am
Frameworks are being blogified. Noone wants to write applications, everybody just wants to reference eachothers framework.
Value by reference
August 7th, 2007 at 3:37 pm
[...] someone created a framework-framework, the Keel Framework. Happily, it didn’t last long (see bile blog’s writeup if you don’t mind strong language). In fact, there is so much platform proliferation [...]