Discussions

News: Tutorial on the Keel Meta-framework posted on TheServerSide

  1. Keel is an open source meta-framework that provides a thin backbone, and a set of core interfaces for common services, which can be implemented using various other open source frameworks and libraries. This hands-on tutorial walks you through how to install Keel, set up infrastructure for a typical application, add configuration, authorization, persistence, and a Struts user-interface.

    Read The Keel Meta-framework: A Hands-On Tutorial

    Threaded Messages (5)

  2. Smells like a type of coffee I know[ Go to top ]

    I haven't read the 42 page tutorial but from a quick glance it looks a lot like Expresso? Maybe because the author was once a contributor on the Expresso framework and that quite a few developers on that project once came from the Expresso project. As a developer on Expresso myself I have seen some of the work those developers have done and it is good so I look forward to taking a look at this (gulp) 42 page tutorial. Glad to see they are still cranking out some open source code.

    Kris Thompson
  3. Better coffee :-)[ Go to top ]

    Kris,

    Give Keel and the tutorial a shot. A big part of the 42 pages is screenshots and examples.

    As far as Expresso goes, Mike Nash was the founder/inventor/lead-developer of Expresso, and is the technical inspiration and lead-developer behind Keel.
    So, his mark is there in both and there are plenty of good things in Expresso. But, the similarity ends there.

    You could say Keel is the result of lessons learnt while developing Expresso.
    The core idea is a very simple one, separate interfaces versus implementation,
    do not build a monolith, and allow quick adaptation to the valuable tools sprouting up everywhere in OpenSource world. Right off the bat, you'll notice the flexibility of service creation and use in Keel, a direct result of Inversion of Control (IOC) and Separation of Concern (SOC) patterns, as well as the general approach of COP, all integrated in Keel through use of Avalon/Fortress as a base. To demonstrate switchability of services in practice, many services in Keel have two implementations. For instance, Keel has its own native Persistence/OR impl. as well as one based on Hibernate, switchable by configuration only. In addition, there is a JDO service. You'll also note that out of the box, Keel comes integrated with Struts, Cocoon, Velocity, CLI as UI choices, and the architecture makes it simple to adpat other technologies.

    Anyway, the 42-page tutorial barely scratches the surface on Keel. But I am probably biased. I am very interested to hear your opinion on the comparision after you get a chance to try it out.

    Shash
  4. Better coffee :-)[ Go to top ]

    I checked the docu and have read it.

    My opinion:

    1)Business Layer:

    <quote>
    The core idea is a very simple one, separate interfaces versus implementation,
    </quote>
    This is indeed a very good idea, what I also always do in all my projects. I call this building the Specification API for my domain. This activity should be done as a stand-alone activity (never think about the implementation at this point!).

    <quote>
    Right off the bat, you'll notice the flexibility of service creation and use in Keel, a direct result of Inversion of Control (IOC) and Separation of Concern (SOC) patterns, as well as the general approach of COP, all integrated in Keel through use of Avalon/Fortress as a base. To demonstrate switchability of services in practice, many services in Keel have two implementations. For instance, Keel has its own native Persistence/OR impl. as well as one based on Hibernate, switchable by configuration only.
    </quote>
    If
    - you are doing all of your Specification API in standard Java Interfaces,
    - your Presentation Layer or other Component accesses should only touch the Specification API and never touch the implementation directly,
    - just using a simple Factory for creating the "real" implementation,
    -> you can exchange your Business Layer implementation, which implements the Specification API, very easy.

    So, my question, why so complicated, adding dependency to Avalon, etc., if you can just use standard Java Interfaces and have no dependency?

    This is surely another story for the Presentation Layer.

    2)Presentation Layer:

    Until now you are directly dependent on one or more Frameworks and View Techniques (Struts, JSP, Enhydra, XMLC, etc.). You can surely create independent standard Java classes for doing all the actions and events (Command Pattern) so you can exchange at least the Frameworks faster. But you will always have dependencies on the view technique. I think the solution in this layer is the Portlet API, so you never care about the Frameworks and View Techniques.

    My last question:
    Is that worth it to add such a complexity and dependencies for using your framework?

    Thanx and regards,
    Lofi.
  5. Better coffee :-)[ Go to top ]

    Lofi,

    > - you are doing all of your Specification API in standard Java Interfaces,
    > - your Presentation Layer or other Component accesses should only touch the Specification API and never touch the implementation directly,

    You are correct in both of the above. The core of Keel is entirely standard Java interfaces, in a separately packaged JAR call keel-core. All the service interfaces are defined here. You could write your own interfaces and still use the services technology of Avalon. But the whole point of frameworks is to not reinvent the wheel whenever possible.

    The implementation of the server side is in keel-server, for the infra-structure that takes some input, performs the business logic (Model in Keel terminology) and produces some output. This can be embedded in a single JVM, and even in a webapp. Or, you could partition the presentation layer in its own JVM and/or machine and use JMS or SOAP to talk to the business logic. The comm-part is also abstracted through interfaces for you to use Keel's or roll your own.

    The rest of the service modules are all entirely optional. You could use Keel's implementation of a service or implement your own. Nothing ties you to Keel's implementations (based on other OpenSource projects whenever possible) at all. In the end all code is written to interfaces. Even the implementations you use are not determined at compile time, but by run-time configuration.

    > - just using a simple Factory for creating the "real" implementation,

    Again, you could roll your own factories. But Avalon in essence gives you the same function: to instantiate a particular instance of a service. It also provides life-cycle support that lets you standardize on how to configure, initialize, provide loggers, start, stop, dispose, etc. etc.

    > -> you can exchange your Business Layer implementation, which implements the Specification API, very easy.
    >
    Exactly!

    > So, my question, why so complicated, adding dependency to Avalon, etc., if you can just use standard Java Interfaces and have no dependency?
    >
    It is not very complicated. The idea is to not write your own, unless absolutely necessary. With writing comes testing and maintenance. Keel does not suffer from NIH (not invented here) syndrome. Whenever possible, use technologies already proven, used by others, and therefore, bug-fixed and maintained, leveraging a much larger developer and tester base than is possible by one individual or company. But in the end, nothing in Keel prevents you from writing and using custom interfaces/implementation at all...it is all POJO after all.

    The other benefit of using Avalon-compliant services is the ability to reuse components. We could use services from other Avalon-compliant projects such as Cocoon, Phoenix/Excalibur, James, Turbine, among others, as they could visa-versa. Right now you would have to alter configuration or meta-data to reuse, but there is work going on in standardizing meta-data which would make this reuse completely transparent.

    > This is surely another story for the Presentation Layer.
    >
    > 2)Presentation Layer:
    >
    > Until now you are directly dependent on one or more Frameworks and View Techniques (Struts, JSP, Enhydra, XMLC, etc.). You can surely create independent standard Java classes for doing all the actions and events (Command Pattern) so you can exchange at least the Frameworks faster. But you will always have dependencies on the view technique. I think the solution in this layer is the Portlet API, so you never care about the Frameworks and View Techniques.
    >
    Keel has a presentation layer, but Keel is not a presentation layer framework. Keel internally abstracts objects such as Inputs, Outputs and Commands (actions) that are related to Models (business logic) via a Keel request/response pair. We then have adapters that bridge presentation layers such as a command-line interface or webapps into the generic request/response. For example, in a webapp env., the HttpRequest/Response pair is converted to/from a KeelRequest/Response pair. Then for each of Struts, Cocoon, Velocity all we have to do is to take their particular controller mechanism (like a Struts Action) and extract and convert to/from their request/response objects. Can't comment on the Portlet API, since I haven't looked at it.
     
    > My last question:
    > Is that worth it to add such a complexity and dependencies for using your framework?

    We started working on Keel exactly because we did not want to get tied down to any particular framework or library (hence the move towards interfaces). But, the answer to your question depends on your application. For simple applications, probably not. But the bigger your application gets, and the more services you need, the more sense it makes. Also, there is benefit in all your small projects following the same pattern. If they follow the same pattern and that happens to be your own framework, then the question is would you benefit from using a framework that leverages proven open-source technologies to do most of its function? In terms of user-base all the open-source projects we use in Keel have a huge following and we are putting in a mechanism to harness them seamlessly.

    Shash
  6. How could I ...[ Go to top ]

    http://www.theserverside.com/resources/articles/KeelTutorial/HandsOn.pdf gives a blank page. Why ?