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.
Simon, great post! After reading it, I was inspired to write a related post on my company’s blog. The frustration of the “stuff we need to know” is a pain point we have been working to resolve. The idea of having to learn a new development platform, when all you want to do is take care of the communication plumbing, is what inspired us. Our approach basically consists of two components, an SDK that hides the complexities of WCF through simple method calls, and an Internet Service Bus. WCF is great if you want to build your own message/communication system, but not an ideal solution if you just want to implement messaging.
[Reply]
Jason, interesting that you have chosen to implement your own ISB. I will make a point of putting aside some time to check it out in the future. The further I go with WCF the more inclined I am to simply use it to receive messages at endpoints and then use the store and forward pattern and have another process (service) do the actual message handling. I am going to post this pattern with code some time soon. I am also considering switching over to REST for passive “GET” type messages where all I want is data for representation, as opposed to messages that signify a business event.
[Reply]
After shaking all these messaging pieces in a bag for awhile, the pattern you just described in your comment (WCF listeners to receive on disparate transports that don’t require pub/sub, REST for passive gets, a simple asynchronous framework in the middle to coordinate things and handle workflow, and maybe an ISB like Jason’s Linxter as a full featured transport at remote endpoints that want to take advantage of all MEPs) is what seems to make sense to me too. I look forward to seeing it laid out. It is definitely a confusing space right now, though, no question about it. Lots of voices speaking at once and saying radically different things.
[Reply]
Nathan, there certainly are many voices as you say and there is a part of me that remains unsatisfied in this quest until my team and I have rolled our own ‘lite’ framework. This quest is largely to do with a belief that the experience will lead to greater understanding and also a appreciation of the alternatives. Currently I am very fond of nServiceBus however I will be looking closely at Linxter and SimpleServiceBus soon.
[Reply]
Hello,
I am a BizTalk consultant and you stated that BizTalk is an expensive product. Well in the area where bizTalk should be used it’s not expensive at all. If you would try to implement your own message broker you would probably spend the purchase price of BizTalk on the Funtional design….
And a lot of people forget about a lot of advantages that BizTalk has over other (self implemented) brokers. Just to sum a few.
1. One GUI to handle.monitor all you endpoints.
2. A standard way of dealing with protocols. If you understand how the SQL adapter works, you will understand the SAP adapter, Axapta Adapter, Oracle Adapter etc. as well. (1 framework 1 way of dealing with messages 1 way of dealing with endpoints)
3. BizTalk itself is Fully scalable
4. Database of BizTalk is Fully scalable
5. Fully reliable. Unplug the power jack of any machine (Sql or BizTalk) at any time and BT will happily pick up the work where it was.
6. Very advanced trackig system (BAM) that is hard to build yourself.
7. A FUTURE ( Very important)
If you look the way BTS is going, it is OSLO… If you see the effort microsoft is putting into BizTalk today you know it is there to stay.
I think BizTalk will be a very important component of OSLO.
[Reply]
Patrick
You make some salient points regarding the breadth of tools and functionality that BizTalk brings to the table. My comment around it’s cost is specifically targeted at instances where I want a BUS Architecture and my message handling logic can be distributed cheaply, where the systems in conversation are not SAP and co, perhaps some home grown business systems spread throughout my enterprise. NServiceBus amongst others, is one such framework that makes this possible and yes it’s true that NServiceBus and it’s contemporaries don’t have wonderful tools such as the Mapper for arguments sake, however often I don’t need all those tools and protocols and NServiceBus is cheap and allows me to distribute on a large scale and with relative small cost. This is the equivalent opportunity I imagined for an express version of BizTalk.
I do not doubt for a moment the central position which BizTalk, WCF and WF are all taking in OSLO and look forward to seeing the possibilities. My main point was that BizTalk would have been almost uncontrollably popular amongst developers if there was a cheap or Express version largely modeled around SOAP messaging and Orchestration only. I personally am investing quite a deal of time lately into BTS and look forward to having my WCF and WF skills leveraged further as those frameworks become more central to the BTS Architecture if that indeed becomes the case as promised.
Thanks
Simon
[Reply]