Introducing: The Agatha Project

4 commentsWritten on November 19th, 2009 by
Categories: agatha, Request/Response Service Layer

As i mentioned earlier in some of the comments, i've received permission from my employer to release our Request/Response Service Layer implementation in a new open source library named Agatha.

If you're interested in trying it out, be sure to download it because i've already made a 1.0 beta 1 release available. Why 1.0 already? Well, because we have been using it in production for over a year now, so it's definitely ready for serious usage already. The only thing that kept me from releasing an official 1.0 version already is that i want to add some small examples in the project: a service layer with 3 different clients (synchronous, asynchronous through Silverlight, and asynchronous through a regular .NET application). The example will be very small, basically just a hello world example but it should be enough to get you going very quickly.

The other thing that is still missing is an abstraction of the logging framework that is used. It's currently still using log4net directly but that's going to change soon. The IOC container usage has already been changed so it doesn't directly depend on Castle Windsor anymore, and it should be very easy to plug in your preferred IOC container. Configuration of the library should be very easy as well, and if you look at the source code you'll notice pretty quickly how easy it can be done. I do plan to make it even easier to configure the thing though. Unfortunately, you still need your typical WCF configuration although i'm going to try to reduce that as much as possible in a future version.

Also, if you look at the source code you'll notice that there are no tests included. I do have tests for it, but i've chosen not to include them in this library since i really want to cover most of it with QuickNet. Regular unit tests will only be written for stuff that really doesn't benefit from using QuickNet.

You're obviously more than welcome to contribute to this project, though i hope you understand that i won't just give anyone commit access right away (apart from the 2 people that already have access at this point) and that you sort of need to earn it. I will happily accept and apply patches, as long as they don't break backwards compatibility, which is obviously pretty important considering the fact that we have quite a few projects that already depend on this. You're obviously also welcome to join the mailinglist where both the usage and the further development of the library can be discussed.

  • Pingback: Reflective Perspective - Chris Alcock » The Morning Brew #481

  • http://fabiomaulo.blogspot.com/ Fabio Maulo

    Why not use CommonServiceLocator ?
    Why not use CommonLogging ?

    • http://davybrion.com Davy Brion

      @Fabio

      for logging i intend to use the commons logging project

      but the CommonServiceLocator project is useless to me since the interface they define is only about resolving components… i need mine to be about registering them as well since i want the library to do that for you automatically… the basic idea is explained here

  • Peter Karouzos

    Hi David,

    I have also taken a similar approach of defining services with a single operation. Looking forward seeing how you have put together the framework.

    Cheers
    Peter