Just tried to install Orcas Beta 2 with BizTalk RFID to no avail...http://support.microsoft.com/kb/942521.
"Microsoft BizTalk RFID is not supported when it is installed on the same computer as the .NET Framework 3.5 Beta 2. However, Microsoft BizTalk RFID will be supported when it is installed on the same computer as the release version of the .NET Framework 3.5."
So I guess we wait
ESB Guidance V1 on MSDN go check it out. I'd used the CTP's but the new release looks all shiny and new. Marty and the guys did a great job. More on this soon.....
Well if you hadn't heard the news, M$ is now all about the model which is great. However it's horses for courses one persons model isn't necessarily another's e.g. business analysts versus tekkie models have different goals. Translating from higher level to lower (closer to the metal) models is complex.
There were a couple of demos that showed the generation of BizTalk orchestrations from a business process model designed by an business analyst (the companies behind the tools shall remain nameless). For the uninitiated the demos look great; anyone who has been baptized in the fires of BizTalk can immediately see the danger.
A business guy describes his process but doesn't realize the operational implications of his description or decisions e.g. 'I have a business process that receives a PO and sends a request to an ERP system, then in 90 days if we don't get paid we chase the money'. Picture the model he/she could draw; you got it delay for 90 days. Do we really want an orchestration that hangs around for 90 days?
What happens if we want to upgrade this orchestration?
What happens if 90 days becomes 110 days?
What happens if someone unenlists the orchestration?
We would want to break the process into smaller shorter-running manageable steps not just one big orchestration. IMHO these tools are dangerous in the wrong hands, they should come with a 'use with care' sticker on the front.
On the flip side Jon Flanders just released a workflow to BizTalk xlang wizard. Now this is different; typically a WF workflow has been designed with a lot of the same considerations in mind that one would have when designing a BizTalk orchestration. Therefore you are converting like with like.
The dissonance between the models that business analysts and tekkies produce is difficult to reconcile. Role on Oslo ;0)
Jon Flanders did a session (sold out) last night on building a Service Monitoring Infrastructure with BAM. Great talk! He highlighted one thing that has been drifting on the edge of my consciousness over the past year; that is where is the sweet spot for BAM and where does the BizTalk tracking database play well.
After BAM was released in BizTalk 2004 it became obvious to M$ that the BAM product had as much traction with the operational people as it did as it did on the business side. The first signs of this were the embedding of BAM functionality with the M$ Operations Manager (MOM 2005 Resource Kit). The most recent evidence is that the new EDI functionality is supported from a tracking perspective by BAM. I felt compelled to ask the question then as to what to choose
or
The answer yesterday was BAM only. I'm still weighing the implications of this. Ponder for a second what happens when you turn off all tracking in BizTalk. BizTalk would scream along enabling support for lower (not low-low) latency solutions, the downside seem all related to compliance and auditing. Now the questions is how to address these gaps with BAM.
My gut feel is that Jon is onto something here. Because BAM extends the reach of how we implement tracking in a really flexible way the power to track what's interesting to your business moves back into your control. BAM really provides a more holistic approach that reflects the reality of tracking.
