Building Microsoft Oslo Models

Models and Modeling were on display everywhere at the latest Microsoft Professional Developer's conference. In fact, my guess is that the modeling lifestyle is here to stay. Before you embark on your own modeling career, an Oslo modeling primer might be helpful.

In my prior article, I explained how models are stored in the Repository, but glazed over many of the modeling details. In this article, I'm going use tools from the Oslo CTP SDK to explore model building.

Before exploring modeling, I want to explain why building models are important.

Value in Modeling

First, model-driven development is not new. If you've done HTML development, you've done model-driven development.

As you may have observed, half of the value in modeling is that it creates a new level of abstraction. Higher levels of abstraction mean less code does more. Using the HTML example, HTML user interface functionality requires less code than equivalent functionality implemented in assembly language.

Moreover, in model-driven development, the application consists of data and a runtime, and that's it. Essentially, the model is the application. Assuming the runtime has all the building blocks, there are no assemblies to compile. The application becomes a pile of data. Changing the data changes the application. So, applications can be more dynamic and tools to generate the code can have greater variability. Typically, a small amount of performance is sacrificed for flexibility. In the HTML example, the user interface changes when the HTML changes and there is a tremendous variety of HTML development tools for various development roles, skill levels, and purposes.

Finally, runtimes in model driven development do more than interpret generated code. A runtime also handles scaling, automatically adjusting without additional programming.

The value of models and model driven development is clear. Now, I'm going to talk about how Oslo fits into the picture.

Oslo Overview

Oslo is a platform for managing and developing models. Oslo is composed of the following components displayed in Figure 1.

Source: "Microsoft PDC 2008—A Lap Around Olso"

Figure 1: Oslo Architecture

  • "M", a language for composing models
  • The Repository a SQL Server database designed for storing models
  • Quadrant, a tool for editing and viewing model data

Currently, Quadrant is only available to PDC attendees. M and the Repository come with the Oslo SDK available on the Oslo Developer Center site http://msdn.microsoft.com/en-us/oslo/default.aspx.

Oslo's goal is to deliver a foundation for building and storing models of all types. Separate Microsoft initiatives aim to build runtimes and tooling into applications such as Visual Studio that are Oslo model aware. Then, by using a common modeling technique and format across all roles in the development process, information gathered by Analysts can, for example, be linked to parts of the application constructed by the developer.

Putting all these ideas and the Olso SDK to work, I'm going to show you what Olso model construction currently looks like.

Model Example

My model example doesn't just illustrate modeling, It's also intended to give you an idea of how different roles can leverage different models and then how the models can be linked.

Most of my software projects are staffed by people in the following roles:

  • Analyst or business person who defines requirements and more or less owns the application
  • Developer who builds the application based on the requirements
  • Operation or IT Professional who deploys the application and maintains the servers the application runs on

As I mentioned before, one of the goals of Oslo is to link these roles in a more streamlined way using a common Repository and modeling language to describe parts of an application. My sample model contains multiple Types each with an Extent. Each Type is targeted to capture information for one of the Roles I described above.

  • Requirement Type is for Analyst requirement data
  • ApplicationInstrumentation and ApplicationUI Type are for developer application storage
  • ServerConfiguration Type stores deployment information for the IT Professional.

In Oslo, Extents get translated into SQL Server Tables and Views. Building Models in M feels a lot like building Relational database tables. In fact, Relational database tables are what get loaded when the model is added to the Repository.

Before you examine each of the Types I described above, I'm going to start with basic conventions shared by all of the Types.

Model Conventions

There are some conventions in the Oslo SDK documentation and in the sample models. As with relational database table development, Types usually have an identity primary key. For security and versioning, models are stored in Folders. Rather than adding common fields to each Type, the sample models extend a common Type. All models in the Sample.Model Module extend the Item Type. The Item Type is below.

type Item
{
   // Surrogate primary key.
   Id : Integer64 = AutoNumber();

   // The folder that contains this stuff.
   Folder : Integer32 = 500;

} where identity Id;

Also, all Types in Sample.Model are part of an Application. So, all Extents have a foreign key constraint with the MyApplications Extent. MyApplications is based on the MyApplication Type. The MyApplication Type appears below.

type MyApplication : Item
{
   ApplicationName : Text;
}

Now, look at each Type by the Role it supports.

The Analyst Role

The Requirement Type appears below.

type Requirement : Item
{
   Description : Text?;
   ApplicationId : Integer64;
}

As I said earlier, Analysts collect requirements. Requirement Type is simple; it's just some text describing the requirement and the Application related to the requirement. As I'll explain shortly, requirements are linked to other models.

The Developer Role

ApplicationUI stores the markup for the application. As I stated earlier, a Runtime is needed to leverage the model. I envisioned a Runtime reading and executing the UImarkup. ApplicationUI appears below.

type ApplicationUI : Item
{
   RelatedRequirement : Integer64;
   UIMarkup : Text;
}

Normally, an application has a lot more moving parts than just the markup. Perusing the models shipping with the Oslo SDK reveals that models can be quite detailed. For example, if you've ever worked with Windows Workflow, the System.Workflow Module appears to be capable of storing a complete Workflow.

The Operations role is next.

Building Microsoft Oslo Models

Operations Role

ServerConfiguration, the Operations Role Type, appears below.

type ServerConfiguration : Item
{
   Server : Text;
   ApplicationId : Integer64;
}

Like the developer roles, this type is related to an Application. I envisioned a deployment runtime using this model to deploy and monitor the application. Aside from deployment and monitoring, querying for Server dependencies is a useful way to use this information.

For Future Usage

As you can see, there is still a lot to be done to fully utilize the model. I can't overstress the need for a model-aware Runtime to utilize models in the Repository. The Repository and M are just the first steps. As I mentioned earlier, initiatives are underway to leverage Olso. In particular: Dublin, Microsoft's WCF/WF future hosting service; Operations Manager; and Visual Studio.

Conclusion

Oslo is the platform for Microsoft's modeling future. Becoming a part of the modeling future starts with studying the foundation. In particular, you need to become familiar with M, the Oslo modeling language. Eventually, new runtimes and tool versions will leverage Oslo, bringing a consistent platform for Developers as well as Analysts and IT Professionals.

Sources



About the Author

Jeffrey Juday

Jeff is a software developer specializing in enterprise application integration solutions utilizing BizTalk, SharePoint, WCF, WF, and SQL Server. Jeff has been developing software with Microsoft tools for more than 15 years in a variety of industries including: military, manufacturing, financial services, management consulting, and computer security. Jeff is a Microsoft BizTalk MVP. Jeff spends his spare time with his wife Sherrill and daughter Alexandra.

Downloads

Comments

  • There are no comments yet. Be the first to comment!

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Live Event Date: September 17, 2014 @ 1:00 p.m. ET / 10:00 a.m. PT Another day, another end-of-support deadline. You've heard enough about the hazards of not migrating to Windows Server 2008 or 2012. What you may not know is that there's plenty in it for you and your business, like increased automation and performance, time-saving technical features, and a lower total cost of ownership. Check out this upcoming eSeminar and join Rich Holmes, Pomeroy's practice director of virtualization, as he discusses the …

  • Packaged application development teams frequently operate with limited testing environments due to time and labor constraints. By virtualizing the entire application stack, packaged application development teams can deliver business results faster, at higher quality, and with lower risk.

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds