Chris Garty's Weblog : Architecture

Conceptual Thinking Around Services: Which representation is the 'right' one?

chrisgarty — Tue, 15 Feb 2005 19:03:00 GMT

I have been doing a lot of work with Indigo and Service Orientation recently. I've been keeping quiet partly because Indigo was just about to have its big party, but mostly just because I've been busy.

Like any programming language or development style, I like to think of a service oriented style as a combination of conceptual models (what), implementation details (how), and tooling (assistance).

We are some way down the road to having solid options for all three, but one of the more interesting discussions to follow right now is in the conceptual space.

Steve Maine has made an excellent post about conceptual models and the interplay between the conceptual models and implementation. Its so good that even Don Box linked to it.

And if that kind of thing interests you, Steve has a bunch of links in his post that will give you hours of reading material :)

Jon Eaves: Infotainment

chrisgarty — Wed, 08 Dec 2004 21:18:00 GMT

I love geek humor, and Jon Eaves spits it out on a daily basis. Check out his latest contribution to world of patterns; Bulimic Domain Model.

Spring has arrived!

chrisgarty — Tue, 05 Oct 2004 19:42:00 GMT

In the land down-under, it is springtime. The birds are chirping louder, the days are getting longer, and the sun is getting hotter. I even got sunburnt playing soccer on Sunday :).

And for .Net developers Spring in another form has arrived in joyous splendor... Spring.Net 0.6 RC1 has been released.

The arrival of Spring.Net gives .Net developers another solid choice on the road to more loosely coupled component-based systems. Spring.Net will soon be MUCH more than just a lightweight container, but even just as a lightweight dependency injection container it is an excellent offering for the .Net development community.

Martin Fowler’s recent article on lightweight containers and dependency injection highlighted two excellent Java offerings; Spring and PicoContainer. Now both of these alternatives are available to the .Net world.

Whether you use a dedicated dependency injection container like PicoContainer, a service locator offering like .Net's own System.ComponentModel namespace, a pluggable model like the provider pattern, or a dependency injection container ‘with more’ like Spring.Net the important goal of separating configuration from use during .Net software development has never been more widely supported or easier to achieve.

MBF and WinFS: A view of the world I am entering

chrisgarty — Wed, 22 Sep 2004 21:43:00 GMT

Tim Brookins is an Architect on the MBF team (and he is based in Fargo). When I got impatient waiting for a reply about the position in the MBF team, an email to Tim was the thing that sparked it all off ;).

I just read a post from Tim (two days old) that explains the tie between MBF and WinFS and answers a few questions people might have about the scope of the MBF effort.

I'm sure after reading that, you can understand why I'm really excited about getting over there and getting into it!

MDNUG: DotNetNuke on the 28th of September

chrisgarty — Wed, 15 Sep 2004 19:52:00 GMT

The next MDNUG (Melbourne Microsoft Developer Group) meeting will be on the 28th of September.

Frank Arrigo just posted a good summary:

Microsoft joins forces with local user groups and brings you the DotNetNuke Development Team (Scott McCulloch and Phil Beadle). Don't miss this introduction to DotNetNuke and why this open source, solution kit portal application has become one of the most successful open source projects utilizing Microsoft ASP.NET.

The session will start with an overview of the DotNetNuke Features then take a look at the High-Level Architecture before diving into some advanced topics such as Skinning and Module Development and finish with Open Source Challenges.

It sounds great and it should cover the whole meeting time. That would make this the first meeting in four months where I haven't given a presentation ;)

I hope you can all make it!

Dependency Injection: World changing concept or nothing special?

chrisgarty — Thu, 19 Aug 2004 09:23:00 GMT

That was the question that I got asked about a month ago. My response was "something in the middle". I like Dependency Injection. It facilitates testing, it facilitates change, and it facilitates clean design.

I have been thinking about container assisted dependency injection lately and have been playing around with PicoContainer. I've been trying to justify the use of PicoContainer to facilitate dependency injection versus just injecting dependencies manually. My primary aim was to facilitate testing and good design, so the manual passing of dependencies was sufficient, but there was this nagging voice in my head telling me that the design would be more open to change if the rigidity of the dependency injections was placed in just one spot. However, I couldn't quite articulate that idea and had just left it hanging for a little while.

Enter Mr Oberg.

Rickard Oberg is a very smart guy that I first found out about when he did an interview on TheServerSide.com back in 2001 when he was a core architect and developer on the JBoss (then version 2.0) J2EE server. Rickard has made some great posts on his blog over the past year that have helped me better understand Aspect Oriented Programming (I'm watching the development of Spring.Net with some interest) and the value it can bring to software development.

Rickard just made a great post on "Dependency injection and open vs. closed designs" that has helped bring clarity to my thoughts on dependency injection and design. Go read his post for the full story, but I had a number of 'oh yeah' moments while I read this part:

So, is an "open design preferable to a "closed" design? Well, I like to compare this to house building. Using a "closed" design is like building a house where the rooms have no doors. Whenever you decide that there needs to be a door between two rooms you punch out the wall and insert a door. It's not something you would do easily. On the other hand, using an entirely "open" design is like building a house where the rooms have no walls, only doors. This makes for great flexibility, but don't be surprised if the roof comes crashing down. The conclusion of this analogy is that you'd probably want both: the rigidity of walls combined with the flexibility of doors. In Pico terms, the foundation of the house is provided by the Container, while the rigidity is provided by a ContainerComposer. The composer is the place where all decisions are made, and essentially it has to know about all the things that Foo knew in the "closed" design version: whether Bar is a class or interface, how to instantiate Bar, and what parameters to provide to it. If you let it do this for all components in the system, then all of our assumptions have been put into one place, and if any assumption would be wrong, that is the only place which would be affected by it.

Got it?

Dependency injection = 'open'. Specific injection decisions = 'closed'. Pico + ContainerComposer = isolate the 'closed' parts in one 'easy to maintain' place. Biggest value of a Dependency Injection container = maintainability.

Got it.