Model Based Software Development Tools from Microsoft
Hello,
My name is Keith Short, and I’m an Architect in the Visual Studio Enterprise Tools Group. I’m responsible for driving Microsoft’s model based development tools initiative. Some of you may have seen the first evidence of what we’re doing in this area at the PDC or in papers we have published since then here and here. The work we spoke about at the PDC was named the “Whitehorse“ project. The first three designers that are built on our model based development tool framework will ship in the Visual Studio Whidbey release. Here’s a brief description of Whitehorse written by my colleague and old friend Bill Gibson who is a PM on the team.
Whitehorse is a suite of graphical design tools to be delivered in ‘Whidbey’ that supports the design and validation of service-oriented applications based on web services, and is targeted at architects, designers, developers and operations analysts. Whitehorse is an early deliverable from the Distributed Systems Initiative, aimed at improving the design, deployment and management of enterprise-class distributed applications. Whitehorse includes tools for designing and configuring composable application systems, as well as tools for describing a logical view of a datacenter. Further tools enable the design time validation of an application system against the topology and configuration of a target datacenter. These allow a user to identify and correct costly errors that would prevent the successful deployment of the application. Whitehorse supports both forward and reverse engineering of application designs to code – once generated, design and code are continuously synchronized. Datacenter definitions can be input via the design tools or reverse engineered from existing server configurations . While Whitehorse will ship with a core set of application and host/server types defined by the Whitehorse team and other groups within Microsoft, it is built on an extensible platform, that will allow customers or third parties to add additional application and host types.
Bill and I go back a long way – we were part of the original design team for Texas Instruments Software’s IEF product (born in the mid-1980’s) for anyone out there who remembers the heady days of the origins of the CASE tool industry. Incidentally, another old buddy and designer of IEF is Dennis Minium who is also at Microsoft working on Enterprise Tools for Whidbey. IEF was quite a success story in it’s time (around $500M per year when I was last involved in 1997 – it now languishes in CA under the name Advantage/Gen, I think), but became tarred with the same brush that most (unsuccessful CASE tools) were compromised with in the demise of CASE tools a decade or so ago. I’d be happy to explore why that all happened and why IEF was different if there’s anyone out here who still cares J
But back to the PDC announcement of Whitehorse and its underlying technology. Microsoft is building model based development tools!! ”Shock, Horror” said some. “Well, welcome to the party, at last Microsoft gets it” said others. Well I think we do get it (I have the privilege and pleasure of leading a team of architects whose combined experience of model based development is probably second to none - Jack Greenfield, Steve Cook, Stuart Kent and Alan Wills).
So what are model based software development tools? Well our short answer is any techniques that allow a developer (or an architect, lead, tester, analyst etc) to work with abstractions that simplify the tasks they are trying to perform in the course of building computer systems. We believe that this is possible without interfering with modern agile development approaches, without having to learn obscure and complex general-purpose “modeling languages”, and without generating loads of unfathomable hard-to-debug code. But we have a lot to do to make sure that the forthcoming generation of model based dev tools does not fall foul of the problems of the last generation CASE tools. We have to make sure that tools that offer higher-level abstractions actually do so in a way that adds value to what developers do, and doesn’t just waste their time with complex procedures to keep “diagrams” in line with code. And it’s about more than just diagrams-to-code. It’s also about how source control systems can be improved with higher-level abstractions, or debuggers, or test tools, or project management tools. For us, that’s what Whitehorse is really about in the long run.
I’m new to blogging, but very keen to make contact with folks in our community who share my interests.
Looking forward to hearing from you.
Comments
- Anonymous
February 12, 2004
I really like the looks of "Whitehorse", but it seems to missing one really important facet of distributed enterprise systems: it doesn't really support designing the messages that the systems send and receive. Sure, it allows you to specify RPC-like web methods, but it doesn't encourage message-based systems. I would love to see "Whitehorse" extended with a tool for modeling messages and message exchanges. This could tie-in nicely with the support that Indigo has message-based programming (and raise the profile of those Indigo concepts to their appropriate architectural level, instead of the "low-level", "only appropriate to hard-core bitheads" reputation that they now have). - Anonymous
February 13, 2004
This is an excellent point John. Two comments:
First, for Whitehorse shipping at Whidbey, we could not rely on Indigo being available and therefore are restricted to Web Service technology available today and in the Whidbey timeframe. But your point about higher levels of abstraction is well taken. Indeed it is a principle of Whitehorse to promote higher levels of abstraction as you'll see if you follow the links in my posting. When we support Indigo with Whitehorse, I think it's pretty sure that the tools will be extended to support contracts (message schemas and interaction patterns) in some way.
Second, we are working on some additional features for the Service Designer at Whidbey that allows a focus on the "contract first" development approach that will present a better experience that includes designing message schemas as part of defining the wsdl for a service endpoint. - Anonymous
February 18, 2004
The comment has been removed - Anonymous
February 23, 2004
The comment has been removed - Anonymous
February 23, 2004
Sounds interesting - I need to understand how Contracts and Services will be modelled. UML2 seems weak in that area. Have you got thoughts on how to represent these concepts? Also how they can be integrated with business processes via BPMN? - Anonymous
February 24, 2004
The comment has been removed - Anonymous
March 02, 2004
Pascal, like I said above, the best place for some more details on the Service Designer is the paper on MSDN: http://www.msdn.microsoft.com/vstudio/productinfo/enterprise/enterpriseroadmap/default.aspx?pull=/library/en-us/dnvsent/html/vsent_soadover.asp
Our current plan is to make some functionality avaible at Whidbey Beta 1. - Anonymous
March 06, 2004
I have already read this paper. Currently, I try to understand where Whitehorse is positionned compared to the 4+1 approach : logical view (Functional requirement), Process view, Implementation view, Deploiement view. Whitehorse aims only implementation view and deploiement view. For the others views, it must wait for tiers products based on Whitehorse SDK ?
I'm agree with you about UML, I encourage you in your project and I would be happy if I find the modeling tool for which I wait for a long time.
Thanks. - Anonymous
May 03, 2004
Whitehorse - Anonymous
May 04, 2004
Whitehorse - Anonymous
June 09, 2009
PingBack from http://quickdietsite.info/story.php?id=809