When you want both Open Source and consistent results
Open Source doesn't sit and wait. More fun to just do something than to set up a repeatable, sharable system such as a language or a package or a framework or methodology.

Keel developers are intimately familiar with the chaos of Open Source, so we try to set up a system or framework to control the inevitable anarchy.

But any new attempt at control can produce its own negative pattern: Tail wags dog. A new system can create as many problems as the ones it solves. Rather than freeing us from the chaos, it just adds another layer.

What follows is a summary of Anti-Patterns we don't wish to repeat.

Keel solutions to anti-patterns attempt to hit a midpoint, between the chaos at one extreme, and the Tail Wags Dog pattern at the other..

Anti-Pattern: Tight Coupling

Tight coupling to objects
Tight coupling to vendors or contributors
Tight coupling to APIs, standard or not standard.

Tightly coupled code is like a damp box of broken peanut brittle - sticky, hard, glommed together, and tough to bite into, all at the same time. Maybe not as bad as procedural code, but the promise of OO isn't as great, once the code gets to be a big ball of mud.

Solution:
Keel addresses this by using the Avalon framework, a set of patterns and practices designed to keep software loosely coupled - and very functional.

Anti-Pattern: Not Integrated

Servers are for business, and that means you need lots of standard functionality integrated to work together. Problematical when everyone does it themselves in their own non-standard way. Most of us use the same 80% of functionality anyway. But when we do it individually, any two packages usually work fine, but each addititional package increases the challenge exponentially. This is definitely the wrong place to have the Not Invented Here disease.

Solution:
Following the pattern set in the terrific Expresso framework, Keel is a collection of packages already integrated to work with each other. You don't have to integrate the core collection of business server functionality, it is already there, and most importantly, working.

Anti-Pattern: RDBMS not taken seriously

If there was a dirty little secret to the IT world, it would be this: The relational database is the core of virtually every serious server application written. Yet it is typically dealt with as an afterthought. The abstraction layer is often inadequate or non-existant, and solutions are often hard coded to proprietary rather than generic databases.  Straight JDBC and ODBC are often used where an object relational layer would be much more powerful.

Solution:
Keel follows the Expresso pattern, and makes secured, generic, object relational layer the very core of its services. Just as importantly, Keel lets you switch between database vendors almost as easily as changing your clothes.

Anti-Pattern: Un-even Security

Security was a network specific problem, until the web came along. Now, everything needs it. But does everything have it? And in a universally useable way?

Solution:
Keel starts by making every single data object, and every controller securable. We use a single programmable role based security mechanism. Once again, this pattern was started in Expresso years ago, and has proven to be a tremedously successful approach. Keel uses the JAAS security interfaces.

Anti-Pattern: Too Many Opportunities

With 50,000+ projects in SourceForge, not to mention Apache and countless independents, how much duplication of functionality would you suspect to find? So which XXXX package is best for you?

Solution:
Keel starts with the most successful package it can find in each category, regardless of which Open Source family it comes from. We vacinate against our natural human instinct to reinvent every wheel. We are delighted to give credit to the best - by using it !

Additionally, if you want to bring in your own package in a category, we encourage you bring it in as an optional package, because Avalon provides for this kind of plugabillity. Either way, you are working with a winner in every case.

Anti-Pattern: Half Finished Packages

The good news is XXX package keeps adding neat features. The bad news is that it may not be stable in its current form.

Solution:
It seems like an overly simple solution, but we try to limit our use of a package to a stable release. You might not find all the very latest bells and whistles in a Keel distribution, but at least you can have a relative degree of confidence that it will stay up and running.

Anti-Pattern: Mixed-Up Domain Logic, Data, Presentation

Our jobs would be easier if it was absolute - but Domain Logic, Data, and Presentation layers are just now beginning to be segregated. Vendors, developers and everyone else are kicking and screaming every inch of the way, but it is slowly becoming a standard practice. Open source is maybe ahead, in this area, but only by a little.

Solution:
MVC is perhaps the most over-used buzz-acronym in the industry. Every major vendor and famous author seems to have their own different name or definition for it. In Keel, we take our segregation of data, domain logic, and presentation layers seriously. In practice, not just in the acronyms.

Anti-Pattern: Non-Standard

Everybody wants everyone else to follow standards, but it is hard to do when it comes to your own work. It can be so restricting.... Meanwhile, non standard means tightly coupled, because you can't switch something out when it has a unique call signature. You're stuck with it, or with a ton of work to switch it out, either one.

Solution:
Keel attempts to bite the bullet and follow standard API's, even when it is a royal pain to do so. But combined with the benefits of loose coupling that Avalon provides, this may give Keel users greater chance at longevity and code stability than anything else.

This doesn't mean implentations are API specific, because a non standard implementation can be retrofitted with the Decorator pattern to match the required API. This allows a package to retain its unique signature internally, and still work within the signature of the required API when called through the decorator.

Anti-Pattern: Untested, Unrefactored code

So far, the only ones winning this race are the XP guys. If it isn't regression tested after every new feature is added, you just don't know, do you? And refactoring is rarely put ahead of that new feature list.

Solution:
It remains to be seen wether Keel will be able to enforce those XP practices that insist every design start with the test first, and then build the code to the test. Refactoring is even more questionable, enforcement wise. But if it can be done within the bounds of volunteer human behaviour, we will attempt to do it.  And re-do it, and re-do it.....

Anti-Pattern: Documentation Problems

The best feature of open source is also its downfall - wildly varied forms of documentation, with its most important form also being its most problematical - mail lists. Funny thing is, most of the time it isn't just a lack of documentation, there is usually too much, and you can't find what you need without going through email archives for hours at a time.

Solution:
Keel attempts to reduce documentation to javadocs, and online FAQ's editable by users, such as with Wiki. Email is the big problem, and we request users to not use it for documentation - if you answer a question, answer it in the Wiki FAQ, and use email only to furnish a link to right place in the Wiki FAQ.

Anti-Pattern: Build Opportunities

With all the great stuff going on since Ant, one might think it odd to declare it a problem, the state of the art is already far ahead of where it was a few years ago. Despite this fact, there is a lot that can be done to improve the build process, everything from re-building documentation to checking jar dependencies.

Solution:
Keel will be watching progress in Centipede, Maven, Forrest, Gump, AntHeap and other similar projects to see and adopt whichever best practices emerge from this new work.

Anti-Pattern: Code Styling

Inevitable differences in code styling, from placement of the curly braces on out, do not need to distract us from our work.

Solution:
Keel may make use of the checkstyle project to keep our code compliant with the Sun Code Conventions, or whatever conventions we end up with.

Anti-Pattern: Buzzword Non-Compliant

There are lots of issues which become deal killers if a business server doesn't have them. These include, but are certainly not limited to EJBs.  Our experience tells us that focusing on scalability and distributed transactions, for example can be rather goofy before getting the fundamentals down. But it is just as silly to ignore them altogether just because they aren't as important to us as a generic O/R or security layer.

Solution:
Keel, due to its independance on any one implementation or service, is fully "Buzzword Compliant" without adding any unnecessary complexity. We also include services for all relevant standards as they become available and stable, including the entire J2EE stack - but, like nearly everything else in Keel, they're optional, not required, so you can start simple and access the "big guns" when you need them.