There are three basic challenges to getting your head around Keel.

1. Keel is not a framework.
2. Keel is a great framework.
3. Keel is an app - no - Keel is a service.

Brain Twister Number 1:

Keelframework is not a framework.

Before you start cracking jokes about Zen Buddism and the sound of one hand clapping, allow us to explain.   It's a meta-framework.  It connects things from many different frameworks, without necessarily duplicating or overriding the frameworks own innate functionality. So you don't have to think about "Keel vs Turbine" or "Keel vs OSCore". Instead, it's "Keel and Turbine", "Keel and OSCore", that kind of thing.   It could even be argued that Keel is nothing at all, as it can be used with any combination of services, or no services at all. But then you would be able to crack the Zen Buddism jokes again, so we won't stress this point.   Keep thinking about the basics: You are coding to the Black Box interface, not the implementation behind the interface.

So exaclty what is wrong with straight Object Oriented code? It's brittle. Whatever you start with pretty much owns you, unless you want to invest a bunch of time disconnecting everything and making sure it all still works after you're done.
OO like this means tight coupling
* Everything talks straight to everything.
* Everything instantiates whatever and whenever it wants of anything else.
* Standard interfaces may or may not exist.
In this paradigm, things work great for the guy that creates it, at least for that day. But  the next guy, the next day, finds a big ball of mud. Plugging and unplugging pieces, for instance, becomes a huge ordeal, because one thing might be connected in 20 different ways.
Keel uses Apache Avalon to acheive the decoupling that allows Keel to furnish a Black Box at each of these Service Boundaries.
* Messaging goes through the Keel Container.
* Instantiation of components happens via the Keel Container.
* Standard interfaces become more feasible. 

Brain Twister Number 2:

Keel is a great framework.

First we say it is not a framework at all, then we say it is a great framework. With every major feature you need to get your job done.   So which is it? Security, database abstraction layer, client layer, all the major pieces are there and integrated together. Again it's not just that all the pieces are there, you can get that with many frameworks.  Having all the pieces there working together is a nice thing. Even nicer is that it is all done at the interface layer, so you can switch out the various implemenations and the other Black Boxes don't even know better.

Brain Twister Number 3:

Keel apps are quite different from Keel services.
Keel comes set up with a number of applications, including pieces such as Registration or Poll that you can use within your own application, or modify however you wish.
These applications are not Services that Keel speaks of when it describes the Black Box, rather these applications require and cross most Service Boundaries. So it can be somewhat confusing if you do not separate the two when you are first getting your head around Keel.

Summary

Basics

The basic idea behind Keel is the black box.

By taking this one extra step, the Keel meta-framework affords a permanent kind of freedom from code many forms of code lock-ins.

Home | Benefits | Partners & Training | Appeal | Basics | History | Been There ... | SourceForge/Download | Mail List | User/Contributor Contract
Documentation | Contributors, Supporters & Sponsors | Testimonials, Deployments & Projects