Yesterday, I mentioned in my post about MonoRail that I would make the source of the framework available to the community. Today I found some time to build a sample application demonstrating the framework.

You can view the sample application by navigating to: http://breadcrumbs.premotion.nl and you can get the source by clicking here: Download here. The framework is by no means complete or stable and must not be used in any other application than test applications. Neither me nor Premotion can be held responsible for damage caused by the usage of the framework.

I know the framework contains a lot of bugs, but I am not going to fix them before I have a clear idea of what features the framework should contain. If you have any suggestions, ideas or comments, please let me know!

This post is not about some train riding one single track and a big fortified building but about the Monorail MVC (Model View Controller) framework of the Castle Project.

This is not going to be an introduction to Monorail but rather a story about my workflow for this particular project. Although I might write an article about Monorail in the future, for now I will point you to the Castle Project website for information about Monorail.

Last week I had to build a web application for the Van der Werff project, which allows users to view project information online and report malfunctions. The access to the information must be protected from anonymous users and only be accessible for authenticated users. The project information comes from the WCF web service, which also provides the security.

In the next paragraphs you can read how I implemented the application.

Read the rest of this entry »

Hello, how are you? I am fine, thanks for asking. :S, anyway, in this post I will tell you about my first experience… with Windsor Castle interceptors that is. This morning, way to early, I tried to solve an access control problem: I needed to protect several WCF web services from unauthorized users. I was not very awake at the time so I came up with an easy, yet elegant, solution: use interceptors.

What are interceptors you might think, well, interceptors are class which intercept method calls for other classes. The purpose is to implement a common action, like: logging or authorization, they basically act as proxies. Castle Windsor allows you to configure interceptors in the application configuration file which solved my problem of having to modify all the service code myself.

Writing an interceptor for the Castle Windsor container is actually a simple and straightforward process: Create a new class and implement the IInterceptor interface which defines one single method: Intercept(IInvocation). The only thing left to do is to configure the component on which you want to apply the interceptor. That is it.

I am not going to explain all the details now, however I might write an article in the near future. That is it for now, until next time.

In the previous hour I wrote a real simple web application with the purpose of CRUD (Create, Read, Update and Delete) log entries. When you use ASP.NET and ADO.NET that would typically take a couple of hours. First you would have to create the database scheme then you would have to write the business logic and finally you need to create the pages.

However I decided to leverage the power of some components of the Castle project [1]: Castle MonoRail [2] and Castle ActiveRecord [3]. Castle Monorail is a MVC (Model View Controller) framework and Castle ActiveRecord is a framework based on the active record[4] pattern. The components integrate very nicely as you will see.

Read the rest of this entry »

Here is some more information about the messaging framework I have been working on the last couple of weeks. Although I had less time to work on the framework then I had expected, I managed to get some work done on message filtering, but that is a subject for a next post.

In this post I will explain how you implement a message sender and receiver class. I tried to keep the framework as simple as possible and I think I did a pretty good job, however if you have any comments or ideas, please let me know.

Anyway, enough talk, lets get down to business.

Implementing a message sender

Implementing a sender is very easy, there are two things to do: The first step is to implement the IMessageSender interface or derive from the SenderBase class. Then you need to decorate the sender class with the MessageSenderAttribute. That is it.

Example:

[MessageSender()]
public class TestSender: SenderBase
{
	public void SendMessage()
	{
		TestMessage msg = new TestMessage();
		base.DoSend(msg);
	}
}

The TestMessage which is send in the example code does not contain any information, but you can define your own message class which contains any information you can imagine.

Implementing a message receiver

The implementation of a receiver class is not equal easy as the implementation of the sender class. There are two steps as well: The first step is to implement the IMessageReceiver interface and the second step is to decorate the class with the MessageReceiverAttribute.

Example:

[MessageReceiver()]
public class TestReceiver: IMessageReceiver
{
	public void Receive(IMessage message)
	{
		// do something with the message
	}
}

The receive function will be called when a message is received.

Currently I am working on the implementation of the message filters. The idea is that you can do pre-processing on messages using some clean C# constructs. When I got an implementation ready I will post it on this weblog. That is it for now. See you next time.

At the moment I am working on a framework which provides loose coupled internal messaging support for components that live in the Castle Windsor IoC container. This messaging framework stimulates the decoupling of components by providing loose coupled messages.

The messages can be sent from any component that is declared to be a message sender to any component that is declared to be a message receiver. The components, for the senders, do not know to which components receive the message or, for the receivers, where the message originated from.

The messages contain Meta information describing the payload of the message. Currently I am working on the messages themselves. Here is an example of how you can extract information from a message without knowing its explicit content.

Firs we will create a message and its payload:

// creating the message and it's payload
Person person1			= new Person("Bert");
IContentMetaInfo metaInfo1	= new ContentMetaInfoBase(typeof(Person));
IContent content1			= new ContentBase(person1, metaInfo1);
Person person2			= new Person("Trilobyte");
IContentMetaInfo metaInfo2	= new ContentMetaInfoBase(typeof(Person));
IContent content2			= new ContentBase(person2, metaInfo2);
MessageBase msg			= new MessageBase(new IContent[] {content1,content2});

Image the message is send to somewhere and then take a look at the receive code below:

// get the payload from the message
foreach (IContent personContent in msg.FindContentByMetaInfo(delegate (IContentMetaInfo inf) {return inf.ContentType == typeof(Person);}))
{
	// process the person content
	Person p	= (Person)personContent.Content;
	Console.WriteLine(p.Name);
}

As you can see, I only extracted the data I discovered, for all I know the message contains tons of other information, but I do not care about that.

Although my current implementation is not completed yet and there is a lot of stuff still to do, I really wanted to share this sample with you, because I think this method is a good way to decrease coupling between components in the system.

I will keep working on the framework as much as I can, so expect more information about it soon. In the mean time reactions about ideas, questions or comments are very welcome!

Ik ben sinds enige tijd bezig met het ontwikkelen van een softwarepakket met behulp van een Inversion of Control container en ik ben er erg enthousiast over, vandaar deze post.

Read the rest of this entry »