Will this be the last place on the web that trumpets the BizTalk 2006 beta?
Likely not, but I did see it in quite a few places today.
Head to http://beta.microsoft.com with your
passport and ‘BizTalkBetaTeam’ for a guest ID, and then wait patiently. (While
you’re waiting, consider building out a VPC image with VS2005 beta 2 and, presumably,
the latest SQL 2005 bits. SQL 2000 would be fine as well, as BizTalk 2006 will
not require SQL 2005.)
This…is going to be a great release. Nothing so revolutionary that you can’t
leverage all the skills that you (or your staff) have already learned.
Yet, there are many, many important feature additions and “rough edges” removed.
Rattling off a few of the new items:
In-order delivery for any adapter that supports it (i.e. MSMQ, MQSeries, etc.)
In 2004, only MSMQ/T supported this. (Of course, a faulty orchestration can
break first-in-first-out – more on that in a later post.)
The introduction of an “Application” concept for grouping BizTalk assets
– which extends to orchestrations, role links, send port groups, send ports, receive
ports, receive locations, policies, schemas, maps, pipelines, other resources
(e.g. soap proxies), you name it! Just as importantly, the management
infrastructure understands applications – so health/management views can be narrowed
The management infrastructure has been completely encapsulated in an MMC – HAT is
largely hidden. More interesting is that the MMC can manage multiple BizTalk
groups – and can do so remotely (by definition…)
A packaging/deployment solution that looks good – we’ll have more to say about that
in the coming weeks! The developer experience in particular looks to be quite
good. Likely still some value-add to be done on the server side.
- Ability to route failed messages – and subscribe in your orchestrations.
Calling pipelines from within orchestrations (no more loopback adapter or similar
Zoom and expand/collapse-state-preservation within orchestrations. (So when
you collapse that big group or scope shape, it will stay collapsed across
- BAM integration with SQL Notification Services.
“Operator Role” has been defined to make allocating administration tasks a bit easier
from a security perspective.
Pipelines can have per-instance configuration – saving you from recreating what were
essentially a lot of duplicate pipelines! (This was possible in 2004, I believe
– but not exposed cleanly.)
This will be fun…I look forward to exploring the beta bits (man, the CTP was pretty