Archive for July, 2008
Oslo, SOA, BizTalk Express & crossing the chasm.
So what exactly are MS up to with the Oslo initiative? We certainly know a fair bit about the Internet Service Bus (ISB) but that isn’t the whole story. WCF has been with us now for some time and is certainly being adopted with a fair amount of vigour, however, lets be fair, the amount of ’stuff we need to know’ that has crept into developing services (WS* etc) is becoming increasingly burdensome for software teams to maintain, heck Juval is saying that it’s (WCF) as big as .NET itself (I should learn 2 .NET’s?). Where should I turn? BizTalk? Yikes! In all seriousness I am currently investing more time to master BizTalk, but let me say it’s a narrowly focused and targeted strategy, where I plan to take advantage of the products sweet spots where the right circumstances are present. It is simply not realistic to choose WCF or BizTalk as an exclusive method of messaging. Scaling BizTalk is an expensive option and if I’m looking to use messaging (not the WCF or ASMX RPC styled request / response) then I need some options.
Variety is the spice of life.
NServiceBus is a great option (and it’s free), other vendors provide more heavy weight (smart network ESB products) and Microsoft currently offer BizTalk & Service Broker when it comes to messaging frameworks / products. Lets face it the Microsoft options are expensive if you want out of the box Pub / Sub across the organisation or Enterprise. I could roll my own bussing architecture but that’s expensive and risky, I recently called for BizTalk Express so I could distribute a messaging solution without the expense but something tells me that I might not see that product in the near future. What I want is a simple bus framework that isn’t overly weighed down in complexity (NServiceBus fits the bill again) and I get the feeling that Oslo will provide me with a set of tools that are not going to be very different from a technological aspect, rather will deliver a set of guidance with some new frameworks & integration points that utilise current technology - the ISB working hand in hand WCF everywhere and BizTalk for arguments sake.
Good things come to those that wait?
Certainly I will continue to use WCF and WF where it makes sense and I will use NServiceBus where warranted but in the meantime I will continue to wonder about what Oslo will deliver. How far will it reach into the tooling and the API? All this is yet to be seen but we live in hope and anticipation. Certainly BizTalk is now beginning to cross the chasm but an Express version would have it make leaps farther than Carl Lewis on Ben Johnson’s dietary fibres.
LINQ to SQL, the Specification Pattern and Dynamic Queries
A while back Udi posted on Fetching Strategies that he implemented with NHibernate. I have just finished working on an implementation of the Specification Pattern that will work with LINQ (to objects) using Lambdas to provide the test logic and in the case of LINQ to SQL using the same testing predicates as search predicates when querying the database.
1: public static void SpecForLambdaWithDatabase()
2: {
3: Specification<Customer> coNameSpec =
4: new Specification<Customer>
5: (c => c.CompanyName == “Blauer See Delikatessen”);
6:
7: NorthwindDataContext ctx = new NorthwindDataContext();
8:
9: //TODO: Turn this into a fetching strategy that
10: //can be loaded when a Repository method is called
11: //using a role. Dependancy Injection will be useful
12: //in allowing us slot in different fetching strategies
13: //over time if required.
14: DataLoadOptions options = new DataLoadOptions();
15: options.LoadWith<Customer>(c => c.Orders);
16: options.LoadWith<Order>(o => o.OrderLines);
17: ctx.LoadOptions = options;
18:
19: //Note: the specification passes it’s EvalPredicate
20: //as a Func<T,bool> argument to the ‘Where’
21: //extension method
22: var exp = from c in ctx.Customers
23: .Where<Customer>(coNameSpec.EvalPredicate)
24: select c;
25:
26: foreach(var c in exp)
27: {
28: Console.WriteLine(“The Customer ID ‘{0}’ “ +
29: “AND NAME ‘{1}’”,
30: c.CustomerID, c.CompanyName);
31: }
32: }
My next goal is to enable the eager and lazy loading in these scenarios dealt with by using something similar to Fetching Strategies and have the Repository load them using dependency injection which will enable me to plug in the correct fetching strategy at will.
Shortly I will post some code that demonstrates all this with a Repository and not the standard .DBML file, DataContext way of doing things as per above.
The musical programmer phenomenon
Occasionally people ask me if I miss being in the Music Industry and sometimes the answer surprises people. Software development and music production share many things in common, therefore I don’t miss the music job too much because Software development can be such a creative business and I find that side of my personality is being fulfilled.
What I do miss about music is the musicians (sometimes) and the whole bunker warfare of recording studio. Everyone huddled inside a dark space with LED lights flashing constantly and the constant musical debate.
Unsurprisingly many musicians (not sure on the percentage per`se, but lets call it ‘many’), find themselves career swapping into IT. I tend to think that because music can be such a hard place to earn a reasonable living, that many artsy types opt for software development because it is creative and offers better remuneration prospects (comparatively speaking).
To back this assertion up, I remember being asked to attend a focus group of sorts (back when I was studying in a private institution) and answering some marketer questions about product choices with respect to training providers. I did note that one of the marketing group remarked that a high number of musicians are in the development business and that they (the marketers) target that group specifically in the advertising and marketing materials. I wonder how many of the good developers are the musos? Nah maybe not! How many good developers are now musos, maybe that would be a more interesting question?
