I'm overdue for a rambling post, so here you go...
Just saw this article: InfoQ - Interview: Dino Chiesa on Microsoft's SOA Strategy (from BizTalk Server Team blog).
Of particular interest is the Microsoft ESB Guidance and the eBook ‘SOA in the Real World’. By the very nature of BizTalk, much of the work we do falls into the ‘service oriented’ design category.
However, BizTalk does not an SOA (or ESB) make. BizTalk can certainly be a core platform for delivering service oriented solutions and it certainly can be a key component for building a service bus.
This isn't a dive into how to develop service oriented solutions with BizTalk, or how to build an ESB with BizTalk. Its mainly about what skills you need to develop in order to swim in a sea of technology.
One thing that continues to be evident that it is not really possible to be just a 'BizTalk' developer without having a good grasp on at least the Microsoft technology stack.
The breadth of the technologies I've had to keep up with just seems to overwhelm compared to back when I was either just the 'UI Guy' (C++, Win32, MFC, a good understanding of the message pump and subclassing windows controls) or a 'Server Guy' (C++, Win32, STL and UI technologies be damned).
This is the short list:
- .NET Framework - BizTalk is built on .NET and without a good understanding of .NET you won't be able to fully leverage the extensibility of BizTalk.
- Sql Server - who doesn't need to store data? Who hasn't done this badly? A badly implemented data tier (including data access logic) can quickly become one of the most insidious of bottlenecks.
- Xml - this is a technology stack unto itself. A working knowledge of Xml, Xml Schema, XPath and Xslt is pretty much required.
- SOAP, WS-* - Pay attention to WS-BasicProfile and WS-Security. The rest are worth a look if your situation calls for it. Be wary about your interoperability story if you have heterogeneous clients consuming your services.
- .NET Web Services (a.k.a. ASMX) - if you have any services in production, they are likely of the ASMX flavor. The initial service workhorse. Getting at least a passing familiarity of tcp/ip and http protocols really helps to understand what's going on at the 'wire'.
- Windows Communication Foundation (WCF) - the WCF adapter is baked into the BizTalk 2006 R2 release. If your writing services today, WCF is the 'foundation' your likely starting with. Understanding the WCF programming model is key.
- Windows Workflow - likely successor to the BizTalk orchestration engine. Actually, Tomas Restrepo has a good post that will make you go hmmmm... check out 'The Future of BizTalk/WCF/WF'. I've not realized the full potential for WF yet...but I know I want some of the IDE features with BizTalk! This is an area to keep an eye on for growth.
- Debugging - learning what to do when it hits the fan, and it will hit the fan. Its a just a matter of time and it won't always be nice enough to occur in a development environment. Oh, no siree, it will wait to occur until your businesses critical time of the year/month/week/day, and it will hurt and you will have to fix it.
And lets not forget the plethora of bits that sit above these on the stack: Enterprise Library, the aforementioned Microsoft ESB Guidance, Testing, Source Control (e.g. TFS or Subversion), Security, the list goes on.
Oh yeah...that's why they pay us. Ok, then. Well, where do you start? Check out the following resources:
- MSDN Architecture Center - Service Oriented Architecture
- Jeffrey Richter - CLR Via C#
- Jeffrey Richter - Applied Microsoft .NET Framework Programming
- John Sharp - Windows Communication Foundation, Step by Step
- W3C - World Wide Web Consortium
- John Robbins - Debugging Microsoft .NET 2.0 Applications
- Debugging Tools for Windows
It starts with code. code. code. Build it. Analyze it. Learn from it. Rinse and Repeat.
Well, I've rambled enough for one night.
No comments:
Post a Comment