Archive for the ‘Castle’ Category

MR3 – *very* high level overview

February 26th, 2012

Picture = thousands of words, right?


February 25th, 2012

One of the good things – of a few – of my tenure at the CLR team was being exposed to the metal. One of my interest areas was the loader, PM’ed by one of the most arrogant person I’ve ever met. Fortunately the senior dev in charge of it is an awesome person, and helped me with some explorations I was doing on my own, which I’ve blogged before. At that time, pre nuget, I pitched an idea to the leadership team of using runtime packages, similar to win8′s deployment system and OSGi. The idea gained some traction, but in order to have a composable framework many things would have to change, starting with mvc. A very charismatic and public known person whom should remain unnamed blocked the effort saying “no customers were asking for this”. Faulty logic since no customers were asking for cars, for iPads, for .net… Not to mention the “if-I-don’t-understand-it-must-be-a-hack” person, still in that team. So they settle for a simpler solution: Nuget.

Anyway, left MS but the lack of a framework that enforced a stronger modularity was an itchy to be scratched. In the end, the ultimate experience I wanted is to have an app shell that can be composed in runtime with additional functionality, in any level of granularity. To some extend, VS is like that. It’s a dumb shell, and the functionality we all know and enjoy is delivered through “packages”. Those themselves can be composed to augment in features and additional support plugins and vsix extensions (although it’s composed through COM aggregates, which is just sad)

However, Eclipse is far ahead by combining physical packages with isolated scoped: enters OSGi. In OSGi a bundle is a unit of deployment, versioning and execution. In contain all the artifacts required to its execution, including a declaration of its external world dependencies. In runtime, a class loader trick is used to load a bundle in an isolated context, so if you load a bundle that say, uses nhibernate 3.1, it won’t interfere with another loaded bundle that is using nhibernate 3.3. (no jar hell, and no remoting). This problem is also known to .net folks. Clashing of dependencies requires either recompilation of many dependencies or assembly binding redirects. Not fun!

Castle Extensibility aims to solve exactly this problem. Since it’s a complex space, I dont think I can fully explain how to use it or how it works in a single brief blog post. So I’ll save more details for later. It’s worth mentioning that MonoRail 3 is integrated with it, so it’s able to run several “copies” of itself in the same app domain, hosting then many isolated applications in a single web site. Also worth mentioned it’s being used on the stuff I’m working on.

Oh, and obviously it was built in F# :-)

Categories: Castle, OS | Top Of Page | 6 Comments » |

MR 3 update / Castle Blade

July 18th, 2011

Fun times! Since I’ve left MS I’ve been working on a real web site/backend/frontend – you know, doing actual work instead of long meaningless meetings, doc writing and one-on-ones with managers setting you up for failure (I wonder if I should make one of my ‘reviews’ public, so you’ll see the amount of BS I had to put up with).


Anyway, the first work was to create a websockets server. That was fun especially since F# offers its async workflow support and MailboxProcessor. It’s fun to think about it. While at MS, one of my friends there wouldn’t stop bitching about how F# is incredibly superior to C#. Gosh, he was right..

The company I’m doing the work for and I are discussing whether we will make the websocket server available commercially. It’s a PITA to implement the protocols, to test them and keep up, since the spec is in progress. So, sorry, won’t be doing all this work for free.

Ideas playground

On the MonoRail end, we’ve been using it extensively and coding up functionality as needed – by we I mean Henry and I. It’s been quite a journey to reassess all the design decisions in MR1/2, and also evaluate what’s out there. I’m sure we learn more from our mistakes than anything else. Mauricio is pushing some interesting ideas on web frameworks that are making me reevaluate our proposed API over and over again. Now that I’m quite familiar with FParsec, the idea of using combinators to compose forms (formlets) is enticing. It’s just strike me as something hard to expose in C#, we would need a different API and I’m sure it would be awfully verbose.

Castle.Blade = ++Razor

I love Razor’s simplicity and tooling support. Achieving simplicity is a major accomplishment, and the guys at the ASP.NET team did it. I remember when Scott Hunter gave us a preview of what at the time was code named Plan9. Awesome work!

I’ve then decided to make Razor the main view engine for MR3. However, when I started to experiment with a better API for our helpers library I bumped into some not-so-nice limitations from Razor. For example, I wanted to be able to express something like:

 Rails |  copy code |? 
@Form.For(..., {
	// this is a block
        @builder.EditorFor(m => m.Name)

Well, Razor does support translating a mix of content and code block into a delegate – which is neat. The limitation is that they cannot be nested, and the parameter name is restricted to “item”

 Rails |  copy code |? 
@Form.For(..., @{
        @item.EditorFor(m => m.Name)

The issue is that “item” is not very expression. I’ve spent many hours digging into Razor’s code trying for find a way to work-around this limitation (by using its extension points, not changing their code). At some point it was clear that coding up my own parser and translator would be easier. Castle Blade then came to fruition.

Blade intends to be 100% backward compatible with Razor, and introduces a few (one?) different transition marks to overcome Razor’s limitations. For the example above, we would use:

 Rails |  copy code |? 
@Form.For(..., @=> builder {
        @builder.EditorFor(m => m.Name)

The @=> transition signals that a delegate will be created for the block, and the parameter name is the one that follows. In theory more than a single parameter is supported.

We also support nested blocks, which allows for the something like the following:

 Rails |  copy code |? 
@Form.For(..., @=> builder {
        builder.FormTemplate(@=> t {
                    @t.Label(): @t.Field()
        <fieldset id="contactForm">    
        @builder.TemplateFor( m => m.Name )
        @builder.TemplateFor( m => m.Email )

Feel free to give it a try.


MonoRail’s 3 goal is based on our my experience and perception of the “state of the union” and trends. If I could put them in three simple statements:

I’m mentally tired of crafting web sites despite huge functionality overlaps (combine/compose). I’m tired of REST being an afterthought to existing websites (rest support from the beginning). I’m tired of frameworks created by people without *actual* website building experience (frictionless).

The goals/roadmap/value-proposition were discussed in the past in our development list.

  • Since our underlying runtime (CLR) is keen on static typing then fully embrace it
  • Move forward: embrace HTML 5
  • Simplify special render for different form factors
  • Strive for simplicity, but no simpler

I’ll dive into what’s been done in practice to address each of the above bullets in upcoming blog posts.


September 13th, 2010

It’s been more than six years since the first prototype of MonoRail appeared on Castle’s SVN repository. By then our website was hosted in a linux machine, the web server was Webrick, running a beta version of Rails, and had to be restarted once per day (at least) due to memory leaks. WebForms was the winner in the .net space, Struts the winner in the java space (unbelievable!), cocoon committers were toying with the idea of implementing continuations, probably inspired by Seaside.

Back then I was fresh back from London (now you know where Windsor’s name came from), jobless, and entertaining with the idea of setting up a small software shop with Carlos and Rodrigo. One of the first challenges was to pick the technology to invest and potentially create a small product. Rodrigo was obviously biased towards .net with boo. I was playing with Ruby/Nitro. Carlos was inclined towards webforms with c#. We decided to pick one each, build somewhat similar and compare/contrast. AFAIK Rodrigo picked up some Java tech, Carlos chose boo, and I went with Rails.

I fell in love with Rails and became a strong advocate. However, as “our product” grew in complexity, Rails – by then – didn’t catch up. Big refactorings were hard due to the dynamic nature of Ruby, lack of unicode was a red flag for i18n, leaks and bad performance (couldn’t get fastcgi to work on apache!). Also, the ecosystem, the libraries for dynamic image generation were badly maintained, if ever…

That’s when I decided to combine the philosophy of Rails with the solid foundation of .net. By then it was called Castle on Rails.

Things have changed since then. MonoRail seems to have greatly inspired Microsoft’s take on Model-View-Controller for the web. Mongrel, Merb and REST ascendance, a ton of great ideas continue to appear in the Ruby community. Same in a slower pace for other communities.


Web apps then and now

While there was dynamicity in web apps six years ago, my perception is that today they have an aspect of multi-faceted apps. Html is just one of the multiple supported outputs of resource-based web sites. They expose services that can be used by your mother or another service. Twitter and Facebook are the greatest examples.

Bringing that to our work and especially the MS platform is somewhat puzzling. Who wants to maintain two entry points? Why a web app and a WCF Soap/Rest interface? Why it’s so unnatural to deal with syndication on web apps?


The reuse dilemma

Reuse has always been an OOP challenge. Many programming practices support designs that yield subsystems (size/complexity can vary) that can be reused. Not too many programmers embrace those programming practices, though.

As the complexity of web applications grow we see subteams owing subsystem with the same web application. Their technological choices are restricted by the common denominator. There ought to be a solution for this.


MonoRail 3.0

This and other interesting discussions are taking place with the Castle team. I try hard to influence them over the big picture – it’s easy to get distract by what seems to be cool and interesting but deliver no value. In the last two months I drafted and propose a new enhanced design that should deal with the common challenges of web apps of today – and hopefully of tomorrow! Today I completed a working prototype.


Minimal core

The core is based on MicroKernel pattern. It’s a truly example of Open-Closed principle. It works by orchestrating a minimal set of extension points. Those are called primitives as they represent core abstract concepts.

The core is split into three architecture layers:

Layer 1: ASP.NET core augmentation

The layer 1 replaces the HttpHandler and HttpModule in ASP.NET with composable equivalents. You can then implement a new “handler” that has “dependencies”, and be sure that those will be satisfied.

Layer 2: Orchestrator

Layer 2 defines a minimal set of primitives and pipeline execution process. It establishes the minimal policy (behavior) but does not make assumptions over the implementation – remember the Dependency Inversion Principle?

Layer 3: Model-View-Controller

Finally, the third layer is an implementation of layer 2 that exposes the common behavior of Model-View-Controller we all know and love. It also exposes extension points, such as an execution sink for controller execution.


Side-by-side extensions

Windsor turned out to be successful because it delivered a rich extensibility mechanism and a minimal but useful combination of default behaviors. MonoRail 3 is built with the same principles. In fact, its Model-View-Controller capabilities are just one implementation over a set of “primitive” contracts. Behavior can be modified, added or removed by using a small set of extension points.

The design supports side-by-side extensions, which means that extensions do not replace one-another, but instead are always additive. For example, I can have a WindsorIntegration and AutofacIntegration running at the same time. I can add to the mix Razor View Engine and IronRuby support. Not a single line of configuration code or xml.


Composition by default, even in your code

Yes, you can turn off or replace it, but by default your app will have an IoC Container (well, MEF) composing your controllers. The composition is not limited to your types, in fact, you can express dependencies over framework components and request level objects.

Maximized simplicity

The following is a valid controller:

public class ProductsController
    public ActionResult Index()
        var products = // fetch list
        return new ViewResult() { Model = products };

    public Product View(int id)
        var product = // fetch by id
        if (product == null)
            throw new HttpException(404, "product not found");
        return product;
    public Product New()
        return new Product();

    public ActionResult Create(Product product)
        // pretend to save
        var product = new Product();
        return RespondTo( format => 
              Xml( new ViewResult("create.xml") ).

If access to some response, request (or similar) objects are necessary, no worry, you have two options: use the Controller base class or specify the dependencies in your constructor.

Powered by MEF

One of my goals is to demonstrate how MEF can be used to enhance your frameworks, instead of just your applications. By using MEF I could easily skip any “registration” step usually required by typical IoC Containers. I can also discover extensions easily in runtime without extra code.


I’m planning to release a first drop later this week. Note I’m kinda extra busy as I’m getting married next weekend, but watch out for a preview drop.

Workshop on Inversion of Control Containers

February 18th, 2009

Next Friday (Feb-27) I’ll be in Seattle doing a workshop on one of my favorite topics: Inversion of Control Containers. Expect some digressions on the story of ioc containers, how they evolved, what problems they solve and what problems they introduce. Also why I think the DI term should be banished – call me a purist. Windsor, MEF and maybe others will be on my radar.

If you want to attend, keep an eye on this page. Currently registrations are closed, but should open in a few days.

I truly hope I dont have a cold next week :-)

Some Castle related news

January 5th, 2009

During the holiday – and between Wow quests and dungeons – I’ve managed to apply a bunch of patches and to fix some outstanding bugs on the Components and Windsor projects.

Another interesting accomplishment is some contributions finally made in and Castle.Core, Castle.MicroKernel and Castle.Windsor are now Silverlight ready.

Last but not least, I recently applied a patch that made Castle.DynamicProxy 2 also available for Silverlight.

The pending items now are:

- Fix the build so the bits targeting SL will be correctly build and made available through our build server

- Change Windsor to use the SL version of DynProxy.

Thanks for all the patches, people. Keep them coming! :-)

Castle Windsor and the WCF Facility

December 2nd, 2008

If I recall correctly, Ayende started the WCF Facility several months ago and Craig took over and have been improving it almost daily since then. As a completely ignorant on WCF, I have no idea on how it works and how to use it.. so Mike’s post sure came handy :-)

Given the amount of changes in Craig’s last commit there’s a lot to blog about..

Session on Windsor

November 4th, 2008

Great talk on Castle Windsor from Gojko and Mike.

I especially appreciate that Mike was careful on the terms, patterns and principles – even though I have my disagreements :-) But I’ll refrain from nitpicking. Great talk again, I could never do it better.

Changes to Castle Project

October 31st, 2008

I’m happy to announce a few changes that the PMC agreed upon regarding how Castle Project will be led from now on. These changes are long overdue, and intend to fix our release and documentation debts.

Projects will be split

Until now each Castle release was a bundle release. This is good and problematic. Some unstable projects drag the release of stable ones. We lose momentum and everybody’s miserable.

From now on, each project will be a top-level project, having its own release cycle.

Each project will have its leader

We have always had collective ownership, if you’re a committer you can make changes to whatever you want.

One can be more attached to a project than others. We decided that each top-level project should be led by a committer. He should oversee the project in near and long terms, keep the documentation, take care of patches, set goals and roadmaps, seek collaboration and release the bits.

Project list – with leader

Here is a list of the projects and who is leading them:

Main projects

  • ActiveRecord (Markus Zywitza)
  • MonoRail (Ken Egozi)
  • MicroKernel/Windsor (Ayende)


  • DynamicProxy (Jonathon Rossi)
  • NVelocity (Jonathon Rossi)
  • Visual Studio Integration (Jonathon Rossi)


  • ActiveRecordIntegration
  • AutomaticTransactionManagement
  • BatchRegistration (Alex Henderson)
  • db40 Integration (Henry Conceicao)
  • EventWiring (Henry Conceicao)
  • FactorySupport (Alex Henderson)
  • Logging (Alex Henderson)
  • NHibernateIntegration (Tuna Toksöz)
  • Remoting (Henry Conceicao)
  • Startable (Richard Fleming)
  • Synchronize (Craig Neuwirt)
  • TypedFactory (Alex Henderson)
  • Wcf Integration (Craig Neuwirt)


  • Validator (Andrew Hallock)
  • Transaction Services (Ernst Naezer)
  • Logging Services (Ernst Naezer)
  • DictionaryAdapter (Craig Neuwirt)
  • Binder (Ernst Naezer)
  • Email/TemplateEngine
  • Scheduler
  • Pagination (Colin Ramsay)

Notice two things: some of the people are not yet committers – we will see how it goes – and that some projects are still waiting for a leader.

Finally, I think this will bring energy and a bright future to the project as a whole. Exciting times!

Categories: Castle | Top Of Page | 7 Comments » |

Multi-dimensional Separation of Concerns

October 2nd, 2008

Some things seems to be way ahead of its time and are completely ignored. IMHO Multidimensional SoC seems to be one of this cases. Before diving into it, let me give you some context.

Back in 2002 (or 03?) I was in a very challenging project team, working with Java/j2ee. Our client at the time, a big insurance company knew exactly what they wanted, but not exactly how to achieve it. Fundamentally the app need to quote and process insurance premiums. There were three channels: web site, branches and partners. Each channel could interfere in different ways on the workflow of the insurance processing and the actual calculation operation – which was big.

Some of the requirements were ludicrous, but real. Things like: we don’t do motorcycle insurance. But any director’s children can have insurance for their motorcycle. Can you believe it?

The obvious solution suggested was to parametrize everything. On each deploy package (one for web, CDs for branches, CDs for partners) we would tweak the configuration, and that would affect the workflow and calculation. Didn’t take long to prove that it wouldn’t work. Back to research…

Someone suggested AOP. Remember, that was back in 02/03. We had aspectj – and others – but they were on their early stages. The experiments demonstrated that, as long as we put the right extensibility points, we could use AOP to produce a proper package to the right channel. It wasn’t that better compared to parametrization, but still…

It was then that I bumped into Hyper/J.

Hyper/J (or Hyperspaces) brings some interesting concepts. It states that each concern of your app (or in the most basic level, your class) is a dimension. You can compose several dimensions and have a final product.

This is extremely powerful.

Imagine that you have an app up and running, and at some point it becomes a requirement to have a set a classes supporting custom serialization. All you need to do is start a new dimension made of abstract classes matching the namespace/name of the target classes, that would implement that support. You can introduce new methods, fields, implement interfaces.

Later, for some reason you’d want xml serialization. Another dimension and you’re set.

All of that keeping your core code untangled of these new concerns.

Porting to our scenario at the time

  • We would concentrate effort into building the core of our app. The generic workflow, the default calculation. By breaking the wf and calculation into several methods, we enabled the extension points
  • Each new concern that affect any aspect is a new dimension. e.g. web_flavor.
  • We compile and assembly the core plus each dimension required for each channel package

Benefits: Complete separation of concerns that would allow the app to evolve with no friction; simple to test assembled package; parallelization of work.

Hyper/J worked in byte-code level. You would normally compile the core and each dimension individually, and run it to compose the final package.

For some reason, though, Hyper/J seems to be dead. It wasn’t popular even when it was very active. Shame. An overview page on alphaworks says it has evolved to another project: Concern Manipulation Environment. CME seems to go more into the AOP concepts, whilst chasing the same goal. Haven’t used it, though, so no opinions.

I’m quite happy to see that Fabian and Stefan are going in this exact direction with the re:motion project, which seems to use Castle DynamicProxy, so the composition happens in runtime. I’ve been thinking into support something like this natively on Windsor 2.0 as well, albeit I believe it’s easier to manage composition in development time.

Before someone jump in and say “you can do the same thing with partial classes” think again. You can’t. You can’t create a separated assembly with MyApp.CustomizationsForMyGoldClient made of partials. Conceptually it solves a different problem.