|
||||||
|
|
|||||
|
Build Distributed Apps a New Way
VSLive! San Francisco, March 25, 2004
Visual Studio Magazine's Editor in Chief Patrick Meader spoke with Microsoft's modeling maven Keith Short recently about the new Visual Studio Distributed Architecture Designer technology, code-named "Whitehorse." Whitehorse will be included in Whidbey, which is being previewed at VSLive! this week. This is Part 2 of that interview. (Read Part 1 here.) In Part 1, Short discusses how Microsoft's product strategy differs from previous, largely unsuccessful efforts to popularize UML and other modeling tools. In Part 2, Meader asks Short why Microsoft chose not to go with a UML-based approach, the issues of using Whitehorse in heterogeneous environments, and more. Patrick Meader: How will Whitehorse handle modeling the complexities of distributed applications? I understand it uses System Definition Model (SDM) for this. Keith Short: That's right. SDM is an XML schema that describes distributed applications from a perspective of design, implementation, and deployment. SDM is a key element in an overarching initiative we call the Dynamic Systems Initiative (DSI), a long-range initiative spanning multiple releases of Windows moving forward. DSI will increase Windows' ability to provide a more dynamic allocation of application resources. And SDM is the key schema that underlies and threads through all these design-deployment-production scenarios. Think of SDM as the schema behind the two kinds of diagrams we've been talking about—the distributed service designer and the logical datacenter designer. Both are specializations of this common schema, which allows us to do validation between the two. The logical datacenter designer is all about software settings—what host software runs on which server type, what settings it has, what protocol settings you'll allow between those server types, and so on. Those settings will be extensible, and we'll provide some common definitions out of the box. For example, we'll provide definitions for configuring IIS in certain datacenters. IIS has a lot of settings, so it'll be handy to have some prepackaged bundles of settings for it. SDM is an extensible schema. For example, the facilities on the logical datacenter enable our customers to use that extensibility to add new constraints representing things they do in their datacenters. Similarly, on the distributed service side (the one used by the software architect), the information on each type of service is also extensible. That means our customers will be able to add new server attributes and values for them as they're doing their design. Furthermore, we think the distributed service designer will enable people to describe common structures of services and in fact promote those to be toolbox items. For example, a company might use a particular configuration of settings that even drill down to individual aspects of WSDL [Web Services Description Language]. That company might want to freeze these settings as toolbox items. Thereafter developers can drag that service out of the toolbox, automatically installing the settings preconfigured for that kind of service. That's the kind of extensibility we expect to support from the first Whidbey release onward. Patrick Meader: So it would allow either a system architect or someone who has the appropriate permissions to set rights regarding what can be constrained and what can't? Keith Short: That's the idea. Also, we've built an engine from which these designers are derived, and we anticipate making the engine itself available to customers and partners some time after Whidbey. Eventually we plan to enable people to build completely new designers if they wish, using the same mechanisms we built these designers on. Here's one scenario: Many developers use XML documents encapsulating best practices they employ regularly. So they handcraft code generators from those documents to automate this process. And we think it would be nice if we could offer them automated code generation, synchronization, and graphic visualization for such projects.
Integration With the .NET Framework Keith Short: The Visual Studio Distributed Architecture Designer (Whitehorse) technology is all managed code built using the .NET Framework. That's how we can handle the underlying metadata, visualization, and synchronization between model and code. It's all closely bound in with how .NET is being distributed through Visual Studio. With Whidbey we'll get to the point where it's actually an underlying public offering of part of the .NET Framework. But that's something we probably shouldn't talk about now. Patrick Meader: If I could see a block diagram of the architecture, would I see Whitehorse sitting side-by-side with Visual Studio .NET, or would I see it sitting underneath it? Keith Short: These designers will act as if they are Visual Studio packages, due to the framework we used to build them. The class designer or the distributed service designer, or whichever one you pick, runs as a package inside Visual Studio. Think of it as just another tool in Visual Studio. Patrick Meader: How about interoperability with J2EE in a heterogeneous environment? Keith Short: Let's consider each of the scenarios we've discussed for the initial designers in Whitehorse. The class designer is basically a visualization of the CLR. That's its job and that's what we're making it do well. On the other hand, the distributed service designer supports external Web services, as we discussed earlier. That means it should ultimately implement all the WS-I and WS standards, along with interoperability at the level of Web service definition. At that point you should be able to put a box in your design representing the WSDL for a Web service implemented somewhere else, including a J2EE Web service. We have virtual server types represented in the logical datacenter designer. These types are extensible, so obviously you can describe any other kind of server and host software configuration in the designer. We expect people will describe non-Microsoft platform servers with it as well. Such extensions aren't in a set of preformed SDM elements that will ship in the box, but we expect others to build them. Patrick Meader: Are you contracting with any partners now to provide this extensibility? Keith Short: It's a little early to say how that's panning out. We've just gotten to the point of seeking input from partners around SDM. However, interoperability is something we're concerned about. It's one of the things we'll make sure to do by the time the product is released—especially with the distributed service designer. We'll publish the schema exposing the information that has been described using that tool. It will be streamed out as an ordinary XML file whose schema will be available. Then anyone who wants to can do something with that information outside Visual Studio, such as bringing the information into a different tool. We don't plan on this being a closed environment. We do think it's important to make that information available. At the same time, I'll add that our primary focus is on making the services that will be implemented on the .NET platform—on making the experience of using them as delightful as possible. Where Does UML Come In? Keith Short: Let's go back to the three main scenarios we're trying to support. The class designer essentially uses UML notation or a notation that would be familiar to anyone who knows UML. We think we shouldn't deviate from UML notation, which is one of UML's greatest features. The designer doesn't use the underlying UML metamodel, but we think that's a good thing, because it enables us to provide the visualization experience I've described. And there's no precedent for UML notation in the areas of the Web service design tool and the logical datacenter design tool. So we felt it was better to come up with an intuitive notation. This notation avoids the problems caused by extending the UML metamodel with things such as stereotypes and profiles. That route produces ugly notation that doesn't clarify what's going on. As I said, the metastructures underlying the datacenter designer and Web services designer are precisely defined and enable precise relationships between the designers. That just isn't possible with any UML metamodel because of the way those models have been structured, and because of the somewhat weak extensibility methods the UML standards body has settled on. We're not against UML; we think UML has done good work in making notation consistent across different tasks and development. We expect at some point to find people building UML tools—or tools implementing parts of the UML specs—on top of our framework. That said, by and large the dozen or so diagrams UML specifies aren't widely used. That's why we chose to err on the side of notation that's helpful and underpins metamodels. It's easy to relate such models to real development artifacts that we could sync precisely. And we've seen what happened when the industry tried to implement a standard that was not precisely specified, that has difficulty mapping between different development tasks, and for which no standard notation is defined. We didn't want to repeat that. Patrick Meader: So you use UML where it makes sense to do so. Keith Short: It's not an anti-UML story; it's a pro–model-driven development story. We think we're better off focusing on how to help developers do complicated things that could be made simple by the use of designers, and which require precise, focused languages with precise, well thought-out transforms between them. It has proven difficult to pull that off with UML. I think most people now see UML as a set of impressive high-level sketching tools. That's where UML excels. Patrick Meader: Whitehorse sounds interesting, but I've heard about schedules slipping. How far off is it really? Keith Short: We're part of Whidbey, so we're along for its ride as far as release dates go. But the Whitehorse tools will be available as part of the planned Whidbey beta releases, so anyone participating in that program will get to play with our stuff. Patrick Meader: What can developers do today to prepare for Whitehorse's arrival? Keith Short: People who are thinking about how to build service-oriented applications should keep thinking about it. We know it's a fairly small number right now, but some people really are evaluating Web service technology, figuring out its strengths and weaknesses. Such people will definitely get value out of what we provide them in Whidbey's Whitehorse technology. So think Web services; think ASP.NET services; and think about the relationships between services, perhaps somewhat independently of the code inside the service. Patrick Meader: A lot of developers like to think about code first. Keith Short: That's fine too, but I think there will be more and more architect-type people saying, "Let me really flesh out the structure of my app so I understand the architectural principles on which it will be built." People who are starting to think about service orientation will get a lot of value from the diagrams. Other than that, of course, developers using .NET and CLR languages will get immediate value from the class designers. The deployment stuff obviously relates to a more specialist role. It involves some developers and others as well. Our message there will be that if people stop to think about the constraints of their datacenter, and how would they record those in an SDM-based designer, they'll see how that information could add value during development. About Keith Short |
