At this year’s PDC, Microsoft announced a new technology called “Oslo”. This article aims to help you understand the vision of “Oslo”, how it fits into the bigger picture as a Microsoft developer, and some of the key features it will ultimately provide in the years ahead.
What is “Oslo”?
“Oslo” is a new modeling platform being developed by the Connected Systems Division (CSD) at Microsoft. CSD includes the teams responsible for Windows Communication Foundation (WCF), Windows Workflow Foundation (WF), BizTalk Server, and other related technologies. The “Oslo” modeling platform promises to simplify the way we design, build, and manage systems using these CSD technologies, as well as potentially many others down the road. It’s an incredibly ambitious endeavor by Microsoft to finally tackle the modeling space.
The initiative encompasses an entire group of forthcoming products and technologies that will be released by CSD over time. In order to lay the technical foundation for the “Oslo” modeling platform, CSD will first ship a new version of the .NET Framework and Visual Studio – currently referred to as .NET Framework 4.0 and Visual Studio 2010 – containing some key updates to WCF and WF that make it possible to author declarative workflows and services (think of these as XAML-based “models”).
In addition to these advances, the “Oslo” modeling platform provides a revolutionary model-driven approach for building distributed applications. The modeling platform consists of three main components: the “Oslo” modeling language (also known as “M”), the “Oslo” repository, and the “Oslo” modeling tool (also known as “Quadrant”), described here:
Repository
A store for distributed application “metadata”. The data in the repository describes the entities that make up your system, which other “Oslo” components can take advantage of to simplify the user experience for the different stakeholders involved.
Modeling Language (“M”)
A new text-based data modeling language, designed for developers, for describing the data stored in the repository and for generating SQL. The repository will come with numerous pre-defined schemas that represent common distributed application constructs. “M” also provides a grammar for creating custom Domain Specific Languages (DSL).
Modeling Tool (“Quadrant”)
A new visual editor for interacting with the data found in the repository. It provides a “visual” experience for the less technical stakeholders. You can both view & edit repository data using this tool. It even supports custom views for different stakeholders.
In a nutshell, developers use the modeling language to define new models – they could be data models, workflow models (e.g., XAML-based workflows), or even IT infrastructure models. Models are ultimately stored in the repository. The various stakeholders (analysts, architects, developers, and IT pros) can use the “Oslo” modeling tool to interact with the models found in the repository.
Runtime environments can then be built on top of the “Oslo” repository for executing models. One of the first runtimes to build on the “Oslo” modeling platform will be “Dublin”, the codename for some new capabilities being packaged into Windows within the “Application Server” role (it may end up being loosely referred to as the Windows Application Server). “Dublin” provides an enterprise-level hosting platform for WCF and WF applications and it will eventually use “Oslo” to simplify the deployment, scale-out, and various operations and management tasks (final details TBD).
Other Microsoft products and technologies are expected to build on “Oslo” to provide other runtimes. A few that have already been announced include Microsoft System Center (Operations Manager) and Team Foundation Server (TFS) in Visual Studio Team System. It’s important to note that the next version of BizTalk Server – BizTalk Server 2009 – will release well before “Oslo” so it will not include “Oslo” integration in the 2009 release.
Microsoft hasn’t yet provided official dates for when these various “Oslo”-related pieces will be released. All we know is that first they’ll release .NET Framework 4.0 and Visual Studio 2010, and then at some point after they’ll release the “Oslo” modeling platform and the first version of “Dublin”. PDC attendees received an initial “Oslo” CTP – they handed out at VPC at the show – for everyone else, keep your eyes on MSDN and the Microsoft Connect site. There will be a public Visual Studio 2010 CTP at some point but unfortunately, it may not contain the WCF and WF 4.0 bits according to my sources. It’s still unclear at what point WCF and WF 4.0, “Oslo”, and “Dublin” will be made publicly available.
The “Oslo” Modeling Platform
A typical distributed application is a complex beast. Part of this complexity stems from the fact that there are many moving parts – different types of data, different servers and environments, and different line-of-business applications running on different platforms – creating a complex heterogeneous environment to manage. In addition, there are numerous stakeholders involved in a typical distributed application – business analysts, enterprise architects, developers, and IT professionals – all of whom must work together to accomplish the goals of the system. Unfortunately different stakeholders have different concerns and priorities. This makes it difficult for the business to move forward towards common goals, especially when the technology is fighting against the business each step of the way.
For example, when someone notices that a key SLA isn’t being met, how does one go about tracking down the problem within a large distributed application? Which business process is it related to? Who is the business analyst responsible for that particular business process? What application actually supports the business process and what server is it running on? And more specifically, what component or service within that application is ultimately responsible for the problem preventing the business from meeting the SLA? Given today’s technologies, situations like this can be extremely difficult to resolve – yet they’re all too common – welcome to the wonderful world of distributed applications.
What many organizations need is a platform that addresses the complexities of distributed applications head-on. They need a platform that allows analysts to model business data and processes, architects to design the system, and developers to implement system components, while collaborating effectively with one another along the way. And perhaps more importantly, they need a platform that provides visibility into the applications and tools that make it easy to manage the system especially when problems arise. It should facilitate identifying problems, tracking down the cause, and resolving things quickly. They need a platform for managing the distributed application lifecycle more effectively.
This is precisely the type of support that the “Oslo” modeling platform promises to provide. “Oslo” provides the technical foundation for designing, building, and managing distributed applications while improving collaboration across the various stakeholders. Ultimately, the full “Oslo” vision will be realized by the various products that build on the “Oslo” platform like Windows Application Server (“Dublin”), Microsoft System Center (Operations Manager), Team Foundation Server (TFS), and potentially BizTalk Server. If successful, “Oslo” may radically change the face of distributed applications in the years ahead.
Understanding “Models”
The term “model” often comes with negative connotations. This is because the promise of “model-driven” architectures has long been touted but never fully-realized. The various attempts always seem to start with some great hype, but that hype quickly fizzles away once organizations try putting it to use. Hopefully that will not be the case with the “Oslo” platform. Ultimately, the success of “Oslo” will be judged by the companies that put it to use and are able to measure real business value.
There’s a lot of baggage that comes with the term “model”. It’s a term that can actually mean different things to different people. When Microsoft uses the term “model”, they’re using the term in the broadest sense – it’s an abstract representation of something – it could take many forms such as a picture, written text, or perhaps a concrete schema definition. Because of the real issues surrounding the term “model”, Microsoft often uses the term “schema” instead of “model”. So in the context of “Oslo”, when you hear the term “model” or “schema”, they’re probably referring to the same thing.
You can think of “Oslo” models as distributed application “metadata” or, in other words, data that describes the distributed application itself. One of the great lessons we’ve learned over the past few decades is that metadata is incredibly valuable to a platform. The more data we make available within our code, the more possibilities we open up to the runtime during execution. For example, a runtime can inspect the data found within our code to make execution and behavioral decisions dynamically.
We’ve experienced an incredible evolution of metadata technology over the last decade – from traditional DLLs, to COM type libraries, to .NET metadata attributes, and culminating in XAML in .NET 4.0 – each transition has moved us closer to the vision of “code as data”. A declarative workflow service, encoded in XAML, is nothing more than data that can be treated as code within a WF runtime. And since it’s just data, it can also be queried, tooled, stored, and deployed in a lot of different ways.
The repository is a place to store declarative programs along with other types of distributed application metadata – you can store models for things like IT infrastructure (e.g., physical machines and their environments), business processes (e.g. workflows), and even service level agreements (SLA). “Dublin”, on the other hand, is a runtime environment for deploying, executing, and managing these models (primarily XAML-based workflows, which are also considered “models” by “Oslo”).
The fact that you can actually “run” a model sets the “Oslo” modeling platform apart from those of the past. This completely removes the gap between the model and the resulting code that is often problematic in today’s modeling environments. “Oslo” makes it possible for a variety of different stakeholders to collaborate on the same model definition, which can be executed in a model runtime without losing any fidelity. In this sense, “Oslo” gives you a more direct path for getting thoughts out of your head and into a running system. As Microsoft likes to put it, “Oslo” attempts to move from a world where models describe the application to a world where models are the application.
Ultimately, models sit at the heart of the “Oslo” platform. You store models in the “Oslo” repository and stakeholders interact with models found in the system through the “Oslo” Visual Editor (“Quadrant”). And when you need to extend the “Oslo” repository with domain specific models, your developers can use “Oslo” modeling language (“M”) to define them. Let’s dig into each one of these below.
The “Oslo” Repository
The repository is really the central nervous system of the “Oslo” modeling platform. It’s what the various stakeholders and system components look at to figure out what to do. It enables everyone to work from a common information set, thereby improving communication and cross-stakeholder collaboration.
Ultimately, the repository is just a SQL Server database that contains a bunch of tables and rows. Developers can use the “Oslo” modeling language to define new models to be incorporated into the repository. However, the “Oslo” modeling platform will initially ship with numerous pre-defined models common to all distributed applications, thereby reducing the need for custom models to some degree. The repository makes some exciting things possible. It’s ultimately what allows different stakeholders in a distributed application to collaborate with one another throughout the application lifecycle.
For example, the analysts can define the data models, business processes, and SLAs that drive the business, without getting into any technical details (they’ll typically do this by using the “Oslo” modeling tool we’re about to discuss). They can also define the events they’ll want to monitor and track over time. All of this information is stored in the repository. At the same time, the IT pros can describe the infrastructure landscape (e.g., data centers, clusters, computers, etc) and store that information in the repository. Developers can then access the models in the repository and implement them with Visual Studio using declarative WCF and WF code. Once they’re done, they’ll store their XAML-based models back in the repository. An architect can then define an application model for how the various software models should be deployed onto the IT infrastructure and store the resulting model in the repository.
Once the repository contains these valuable models, IT pros can use Windows Application Server (“Dublin”) to deploy, execute, monitor, and manage the application across a set of managed servers. While the application is running, the business analysts will be able to gather valuable tracking information and business analytics. And when problems arise, IT pros can identify problems through the monitoring and tracking features, and figure out who to talk to by navigating the repository.
What I’ve just described is the long-term vision for the “Oslo” repository – the initial release will have a much more model scope in terms of functionality (so everything I’ve described here may not be possible in v1). Once TFS and System Center support “Oslo”, we’ll get closer to the full “Oslo” vision.
The “Oslo” Modeling Tool (“Quadrant”)
The other major component that makes up the “Oslo” modeling platform is the “Oslo” modeling tool – also referred by its codename of “Quadrant”. The goal of this tool was to provide an intuitive visual user experience for interacting with the models found in the repository. For example, “Quadrant” can be used to view data models, business processes, or even IT infrastructure models with appropriate views for each type. The tool also highlights the relationships between different models, making it easy to navigate and explore all of the valuable information found in the repository.
“Quadrant” was designed to be highly customizable for the different types of stakeholders involved in a distributed application. Every model in the repository comes with a default view but users can create custom views while they’re using the tool, in ways that are important to each stakeholder.
In addition to viewing information found in the repository, “Quadrant” also makes it possible for users to “edit” repository information. This will be the primary user experience for less technical users (like business analysts and IT pros) to add information to the repository or to make necessary changes in response to system feedback without having to work with the modeling language (“M”) directly. It also gives developers an easier way to track things down and find models of interest within the repository.
Without a tool like “Quadrant”, the “Oslo” modeling platform wouldn’t have be complete. The initial version seems to have great potential for bridging the gap between the stakeholders in a distributed application, and it’s great to see Microsoft investing in it up front. Hopefully this tool will continue to evolve into something that makes “Oslo” truly shine in the world of model-driven development.
The “Oslo” Modeling Language (“M”)
The “Oslo” modeling language – also referred to as “M” – is a developer-centric language for defining models without using a visual editor but without getting too bogged down in details either. “M” was specifically designed for developers to type and read, and it was meant to provide a nice middle ground between the worlds of visual modeling tools (which many developers don’t like) and the very low-level worlds of T-SQL and XAML. The primary reason Microsoft invented “M” was because their developers needed something like it for defining the myriad of models that will ship within “Oslo” and according to Microsoft, their developers didn’t want to work directly with T-SQL or a visual modeling tool.
It’s important to note that “M” does not mandate how data is stored or accessed, nor does it mandate a specific implementation technology. Rather, “M” was designed to allow users to write down what they want from their data without having to specify how those desires are met against a given technology or platform. However, the models are ultimately stored in the “Oslo” repository, which is a SQL Server database so we’ll need some tools for translating the “M” definitions into SQL constructs.
Once you’ve defined a model using “M”, you can use the tools found in the “Oslo” SDK to generate the resulting SQL and a repository installation package. The SDK comes with several tools for working with “M” models. There’s a tool for compiling “M” files into installable packages. And there’s another tool for installing models into the repository. The SDK also comes with a Notepad-style editor called Intellipad (IPad) targeted at developers working with “M” files (it’s actually more like Emacs than Notepad). It provides features like syntax highlighting, validation, and a command mode for using the "Oslo" SDK tools within an integrate buffer window.
If you’re savvy with SQL, you can actually bypass “M” and write data straight into the repository but I don’t expect that to be very common given the repository’s inherent complexity. Also, the repository will ship with a bunch of predefined models common to all distributed applications, further reducing the need for custom models. Hence, using “M” won’t be a requirement for building “Oslo” applications.
You’ll only need to use “M” when you wish to extend the “Oslo” platform with domain-specific models. You can use “M” to define a variety of different models – new data models, business process models (workflows), or even IT infrastructure models (describing physical hardware). You can even use “M” to define custom DSL's to further simplify the authoring of domain-specific models, which is one of the most compelling use cases in my opinion). You could use “M” to define a DSL for authoring domain-specific workflows that makes perfect sense to business workers.
Summary
“Oslo” provides a powerful new platform for designing, developing, and managing distributed applications on the Windows platform with key features that target unifying stakeholders, increasing visibility, and simplifying various development and management tasks. Whatever your role happens to be – whether business analyst, architect, developer, or IT pro – “Oslo” has something to offer you.
However, it’s important to note that you’re seeing a very early glimpse of “Oslo” in its longer-term roadmap. There’s a lot of work left to do on the “Oslo” front and the real business value won't become fully evident until other products have successfully used it to provide additional capabilities. Remember, “Oslo” is a platform for other things to build on. As a result, it probably won’t be very useful to you right now unless you’re an ISV looking for a new business opportunity. Before “Oslo” becomes immediately actionable at large, it needs to directly translate into decreased costs, additional capabilities, or improved business agility, and that's probably going to take some time for Microsoft to pull off.
There are numerous teams at Microsoft anxiously engaged in making this happen by using “Oslo” to improve their capabilities. Some of these include Windows Application Server (“Dublin”), Microsoft Systems Center, and TFS. Once they ship “Oslo” enabled versions, the business value of “Oslo” should become much clearer. It’s just hard to say at this point exactly when that might come to fruition. As always, “Oslo” could be the start of something big, and then again, it could just be another blip on the radar of “model-driven” hype. I guess only time will tell.
Additional Resources
- Models Remixed
- MSDN "Oslo" Developer Center
- "Oslo" PDC Sessions