Living in the Tech Avalanche Generation

PDC announcements have been made that begin to shed some light (small aperture stuff) on the whole mystery on OSLO. However before I get into discussing what might become apparent at the PDC let me digress a moment into a discussion on what constitutes an Enterprise and whether SOA is exclusively a valid Enterprise concept.

What constitutes an Enterprise?

3 Developers, 80 staff, 12 million per annum revenue == Enterprise ?

5 Developers, 120 staff, 17 million per annum revenue == Enterprise ?

7 Developers, 200 staff, 22 million per annum revenue == Enterprise ?

10, Developers, 300 staff, 50 million per annum revenue == Enterprise ?

15 Developers, 1000 staff, etc ?

What’s interesting to me is that you will find development teams and managers in any of the categories above, that want to connect applications in the organisation  (enterprise or whatever you want to call it) and believe that they are equally entitled to be thinking about SOA as the CIO of any large Telco or public / private Utility.

Recently I posted a suggestion that if BizTalk had an express version, then it would have "crossed the chasm" en masse some time ago. The question I pose now is what are Microsoft’s plan for BizTalk licensing given the positioning they have given the product within the context of Oslo? Based on the official documentation to date and working on the assumption that there is no change to the status quo to the licensing strategy around BizTalk, then Oslo seems to be limiting it’s audience somewhat. Quite a few of the organisations (Enterprise) listed above, will have a hard time justifying the cost of BizTalk licensing and will be faced with finding alternatives. Let’s face it, there are more businesses in these categories above than any other and it’s also representative of the vast majority of Microsoft’s constituency, so the questions have to be asked, just how central to Oslo will BizTalk be and what will it cost? I note that the roadmap does not include answers to these questions and I dare say that the PDC wont devote a lot of attention to it either but here’s hoping.

The technology that lies at the heart of Oslo is being listed as BizTalk Server V6, System Centre V5, Visual Studio V10, BizTalk Services V1, and the .NET 4.0  Framework. Oslo seems constrained to providing updates to existing technology and providing some new ones, both forming the parts in creating your own SOA soup. Certainly there seems to be no mention or evidence of a framework per se and I cant help but wonder if this isn’t one of the missing elements in their general approach. Certainly it has opened up the way for both open source and 3rd party commercial frameworks / products such as nServiceBus, Simple Service Bus, Neudesic Neuron ESB, Mass Transit and Linxter amongst them. I know nServiceBus reasonable well and it  addresses some of the key problems when faced with building a fluent service based eco system in your organisation and whilst it is early days yet, I can help but notice that Redmond would appear to be taking a heavily technological approach to the problem space. My hope is that the idea of messaging being about web services ‘everywhere’ with a whole lot of orchestration, becomes consigned to the past and that we become the beneficiaries of real pub sub with WCF providing the message transports and perhaps even BizTalk Express filling in the durable pub / sub piece of the architecture?

Some of the things imagineered into Oslo so far are BizTalk deployment of Workflow to Server farms, BAM type monitoring of Workflow, more visual Workflow design tools and an online repository for storage of message contracts , workflow’s, service publications /subscriptions and discovery (ciao UDDI?).

I look forward to seeing what the PDC will unveil and hopefully Microsoft will keep the process open to some rich community input.

A while back, Windows Communication Foundation (WCF) uber master Juval Lowy, was doing the rounds and proclaiming that every class we DotNet developers wrote could and should be WCF Services. This was all part of the assertion that WCF is as big as .NET itself and in some respects the next .Net. A very interesting idea but nothing I am about to start doing and certainly something I have yet to see embraced. Jimmy Nilsson wrote of a ‘default architecture’, in reference to the use of DDD, but defaulting to a position of ‘every class a WCF class’, just feels wrong.

Udi pointed out a while back that this approach gave cause for concern with regards to performance. If I make every class a WCF Service I am going to end up with heaps of potentially redundant configuration code and or files and significantly pollute my objects with WCF attributes and for me that does not effectively express my intent. Are we meant to make our domain model classes services too? Surely not.

As far as WCF goes for messaging, it does provide an excellent way to move my message over various transports quite simply and uniformly, however it still encourages an RPC way of working and most development I see with WCF does in fact employ that approach. Now I haven’t seen Juval’s training session or presentation on this idea but it seems to me that if every class is a WCF service then I’m pretty likely to end up with JABOWS and frankly pilling up the the Web Services in my architecture is definitely not something I want to do.

Juval was recently in Sydney training and I couldn’t help but wonder if he is promoting this idea as part of his WCF master class now?

In a pod cast on DNR sometime back, with guest Aaron Skonnard, Richard Campbell suggested that it was time for BTS to be made free or at least parts of it. Richard also proposed that such a free product should be tooled as a part of the VS.Net out of the box experience.

I must concur with Richard on this view of the future for BizTalk Server. BTS includes some outstanding tools that developers would find incredibly useful and lowering the price barrier to entry would no doubt see a surge of solutions deployed using BizTalk and increase developer adoption of the product vastly and with haste.

Personally I find the BizTalk Mapper a compelling tool and have found it very useful in transforming data where it would have required significantly more effort to code a solution. One of the interesting byproducts of this tool is that it produces XSLT which can be reused outside of the BTS environment and executed out of band in any CLR process. NICE!

Recently Microsoft also announced the coming release of the R3 CTP for BizTalk 2006 and it included several ’so called’ SOA features. Personally I believe MS should make BizTalk available to developers to deploy at any point of their solutions, whether it be clients or service hosts etc. Give us a tool with BTS like functionality and allow us to deploy it anywhere in our architecture (free of course - just like WCF et-al) and watch the product uptake go through the roof. No doubt Microsoft would be able to find a way to support a free license version and allow for a continued Enterprise version at the more costly prices.