I didn't think that there would be really any big news this time around, but they announced "Oslo" during the keynote this am. I'm not going to go into all the details of "Oslo", there aren't really all that many.
However, there are a couple of features that really get me excited: Modeling Tools and The Repository.
A significant issue during the development lifecycle is the sharing of models. Well, we share them as static copies that we pass around, or if we are lucky, host in a central location.
Part of the modeling conundrum is that they are static. Once you've got a model, you can't really do much with it. Sure, there are vendor solutions that fill this void, but for the most part there is little enforcement of fidelity between the model and the instance (e.g. code constructs) with the available tools from Microsoft. Visual Studio 2005 Team Architect was supposed to help close the gap in this area with a caveat - anyone you share the model with has to have a copy of Team Architect.
One of the promises of "Oslo" is more robust modeling tools that enable sharing of models from Analysts (Business Process Model) to Architects (Service and Contract Models) to Developers (Workflows and Orchestrations Models), to Operations (Deployment Models and Monitoring Models).
The tools that actually generate the models will still be different, yet these models will be published to The Repository where relationships can be established between the different models and reported against.
The Repository is where it all comes together. This is the host for the models, but its even more than that. It will be the centralized location for discovery, service resolution, configuration and workflows. Well, if we are storing workflows in The Repository, why not other code? It sounds like we could deploy code to The Repository where it gets picked up by a process host (defined by a deployment model) and executed.
Thats cool...no more deploying code across the enterprise, deploy it to a central location and have the deployment model define where it gets executed. Sounds too good to be true. "Oslo" is an ambitious release, time will tell how it will actually turn out. We can expect betas early in 2008.
Check out BizTalk Community Blogs via Syndication for up to date information.
This is an area that really looks interesting. I especially like the idea that I can prototype services 'in the cloud' and then move them to my own infrastructure, or another hosting provider.
BizTalk looks like it will definitely evolve around WCF and WF. That's right, you no longer need to know just .NET to pull off BizTalk development. In the future, your going to want to be comfortable with Windows Communication Foundation and Windows Workflow. Yes, the future workflow engine of BizTalk will be WF. That being said, we've got a commitment from Oliver Sharp (GM, Connected Systems Division) that there will be support for existing messaging, and orchestration assets, in the next version.
When is the next version shipping? I swear I had a verbal commitment from members of the BizTalk Product group on a product delivery every two years: 2004, 2006, 2008....uh, 2008? Doesn't look like it. It looks more like 2009. We'll see on this one as well.
Connected Systems Division Focus Group on Documentation
This was a last minute invitation to represent 'corporate' America. It was somewhat humorous to be sitting at a table with close to a dozen MVP's - I kinda felt like a party crasher, but they made us feel welcome!
My portable HD died on me this am. This thing has all my music, and more importantly, all my virtual machines. *sigh* Luckily, this is all at the house, but it leaves me limited in my experimenting with technology this week.
Phone was also on the fritz and not receiving email, which left me in an odd 'disconnected' feeling.
One last comment on today...there is definitely more vendor-speak and 'marketecture' than I remember from last year. Last year, the sessions sponsored by vendors were a little more obvious than they were today.
Once I realized that I was hearing the same repetitive why reasons for needing SOA governance, and there was no hint of how we should go about enabling governance (not counting the slides showing screenshots of a vendors product) I needed to pack up and leave but didn't. I won't make that mistake again!