In-Depth

New Development Model: How Does Oslo Fit with Visual Studio 2010?

RDN Editor Kathleen Richards talks with Microsoft's Kris Horrocks.

• By Kathleen Richards
• 03/24/2009

RDN Editor Kathleen Richards talked with Kris Horrocks, senior product manager for Microsoft's developer platform team, in February to learn more about Oslo and how the emerging platform fits into Microsoft's tools strategy.

RDN: What's new in the January CTP?
Horrocks: We have taken a lot of time since PDC to really stabilize this preview and then we've done a fair number of modifications and updates to the M programming language based on the community review we've had so far. There is actually a list of all the specific language constructs that are now supported and so forth. The other part that is updated in the CTP is within our repository. There's a greater number of out-of-the-box models already in the repository compared to what was there at PDC.

Is "M" considered one language or multiple languages?
We're in the process of transitioning to talk about it as one language. Some of the feedback that we've gotten from PDC was that trying to talk about it as three different languages was unnecessarily complex. So at PDC we were referring to MGraph, MGrammar and MSchema and what we have chosen to do moving forward is to really just refer to those as three capabilities of the "M" language. And we found the technical reality is...that those three capabilities are merging to all be available through a common language.

Have you made any other changes since PDC?
It is mostly stability, language enhancements and additional content in a repository. There are also Improvements in our Quadrant development tool, as well. ("Quadrant" was included in the VPC distributed to PDC attendees. However, Microsoft has not released "Quadrant" in any of the CTPs available for download on MSDN.)

How is Quadrant different than the graphical DSL tools that are in Visual Studio?
It is technically a separate shell. We are working in close concert with our Visual Studio team...to understand what the experience needs to be for our customers who are doing some modeling in the DSL Toolkit and some in Oslo.

Is Oslo expected to be part of VS 2010?
Yeah. I think a great way to think about it is -- are you familiar with the project we used to refer to as WinFx? So there was a while when we were referring to WinFx as a codename that basically became Windows Communication Foundation, Workflow Foundation and Presentation Foundation. And then as we got closer to actually shipping, we made some decisions about which part of our existing developer platform to release those in and in that case, it was the .NET Framework.

We fully expect the Olso capabilities to undergo a similar process where today we refer to these three capabilities that are provided by the repository -- the repository, the language, the quadrant -- as Oslo but as we get closer to shipping our customers should expect that these capabilities will flow into their existing development platform and tools.

And that timeframe is the VS 2010 timeframe?
Well, it depends. Right now we are still getting feedback. One of the things with Oslo that we are trying to do is trying to be very early with our engagement with the community. We want to make sure that we get all the feedback that we possibly can about all of these components. And then based on their feedback, we'll chose the right ship vehicle.

Outside of consultants who are working with enterprises, most developers don't get that excited about modeling. What is Microsoft's view of model-driven development? And how does Oslo fit into that strategy?
That's a great question. You know we experience the same kind of reaction from folks when we talk about modeling. What we've observed is that there are parts of our customer base that do a ton of modeling...But you are absolutely right, when you talk to developers, in general, they tend to have a different reaction to the word modeling. Their history has been one that's kind of a love/hate. In some cases, they feel like modeling is this task that's been imposed on them by others. And a lot of them view it much in the way they view documentation, as maybe a necessary evil because of some process their organization follows.

Oslo is attempting to address that perception and actually provide developers with a modeling platform that is very relevant and ultimately core to what they do, which is build applications. And I think that's what differentiates what Oslo hopes to deliver in terms of modeling from a lot of other approaches. It is not to dismiss the value of other approaches, organizations need those as well. But Oslo is focused on providing a platform that allows models to help developers build their applications.

So when we talk about Oslo as it relates to modeling, you'll hear us talk about executable models or model-driven runtime, and that is, while the architectural space is very much focused on conceptual modeling, modeling of ideas that maybe help you get to a starting point for your code...Oslo is really focused on helping developers use models to build their apps.

The way we think Oslo can help is that we're seeing a couple trends in the development platform and tools that developers are already using. If you look at the .NET Framework as an example, there was a period where the evolution of the .NET Framework consisted mostly of the addition of new APIs to address particular capabilities...But in the last couple of years, we've seen that the way the platform is evolving is not just with APIs. What's happening now is that almost every new API and library that's added to development frameworks comes along with an associated data model.

If you look at, for example, Windows Communication Foundation as we saw customers wanting to build more and more services, and we wanted to provide a platform that gave them a first class notion of service, we delivered WCF, which is certainly an API, but along with Windows Communication Foundation is a really robust data model that is a data format that developers can use to describe how their service should behave. And so to leverage the full power of that framework, there is also this associated data that as a developer you need to understand and be able to use to build your services.

There is a workflow framework, Windows Workflow Foundation, which also defines a data model for workflow. In the Web space, ASP.NET is certainly a framework, but there is also a significant amount of information that actually drives ASP.NET that as a developer you provide through a data model. And so what we are observing is that applications developers are building are no longer just code, they are actually a combination of code and a significant amount of data that exists in config files, databases, registries.

And we believe that while our platform does a great job today of helping them define, manipulate and manage the code aspects of their solution; there isn't much in our platform that provides them a rich way to define, manage and manipulate the models that contain all this data. And so Oslo is looking to evolve our platform, to help increase their productivity in using the models that Microsoft provides that drive our frameworks and also to help developers create their own frameworks that are model driven.

Can you provide some real-world examples of how Oslo might be used?
When we talk to ISVs, a big part of the capability that an ISV needs to provide is for the customers to be able to customize the default behavior of an application. And they need a variety of roles to be able to customize their application, whether it is an IT pro having to configure it or deployment in a specific environment or whether it is a developer trying to create custom workflows that run inside the ISV's application or someone trying to modify some aspect of the user experience of the application.

Today if you look at how ISVs are building those apps, they are basically defining a set of models for whatever part of the app it is that needs to be configurable or customizable.

And what Oslo can do is Oslo can provide, essentially a default set of options with a set of best practices kind of baked in. So for example, the answer to the question of, "Well, what language should I use to define my models, to define the structure of them, the relationships and the constraints?" With Oslo, the default answer is "M." "M" is a language that is designed specifically to address that task. And that can interoperate with the many other languages that organizations are using.

And to answer the question of "Where should I store all these models?" We think the database is a great place to store models, much better in the long run than the file system because you get much more visibility than the query ability that databases provide. The Oslo repository also provides you with baseline architectures for versioning...so that you can easily tell what are your models versus models provided by another organization. It provides baseline architecture for security above and beyond what SQL Server provides out of the box.

The other thing you find in organizations of all sizes -- both ISVs and enterprises -- as soon as they've moved or defined a significant portion of their applications as data either in config or in a database, one of the first things they need to do is provide a user experience to manipulate that data. In the case of developers, they might just expose the raw config file. In the case of IT pros, they generally want some sort of management tooling experience and in the case of business users, they want more office like experience for actually manipulating business rules or business level work flows.

We see Quadrant as initially being a great place for organizations to have a default configuration experience over these models...Today, if you just start, you're your own database. You have to build your own UI on top of that data from scratch and we see that there is a lot of heavy lifting around providing really rich boxes and lines -- an experience that we can provide out-of-the-box through a tool like Quadrant. So that ISVs and enterprises can focus on just customizing that experience for the particular end user they have in mind...

And that end user could be a business type who is not a developer?
We need to be more explicit about what our v1 goals are versus what we see as the longer term vision. Initially, we're focusing on winning the hearts and minds of developers and making modeling very relevant to developers by making their life easier in their day-to-day task of building an app or a service. So, initially you'll see Quadrant have a very developer-centric focus. That is the tools, the models, and the experiences we provide, will focus a lot on domains that are relevant to a developer so as an example, technical workflows, service interfaces, UML, .NET.

However we are building Quadrant as a general purpose UI platform. We're building it to be very extensible. It is in fact kind of the Oslo app -- it is entirely model driven, it runs off of the repository, and we are doing that so that it can over time be opened up to a broader set of roles.

At this point, what should developers be paying attention to in terms of this technology? One thing I hear about Oslo is that it's a ways off.
I think it's a fair question. Today we are in CTP, so we absolutely recommend that customers go in with full recognition that it is early days. We are releasing it early and often so that we can get as much feedback as possible.

I think one of the best things that developers can do today is to look at the frameworks and tools that they are already using, to consciously take note of where they are already using data-driven approaches. And I think if most developers, certainly on our platform, but even on many others, if they look at what they are doing, they will recognize that much of what they are developing is both the code to execute against some framework, but then they are also putting a ton of information in these various data formats.

We think it is really useful for developers and development teams in general to start thinking explicitly, about the structure of those models, the way that they are running their runtime to consume it. And if they are presented with a technology choice between two options, perhaps one that is more data driven than another, if the capabilities are equivalent, we think they should strongly consider moving towards the frameworks that provide that data-driven approach. That is going to set them up in the future for being in a much better position for moving that information into an Oslo-enabled world.