BLOG 1138

The Lang.NET conference wrapped up yesterday and session recordings are now available. Full details on the talks and pointers to the recordings are here.

Ben Gillis is on the right track wrt some of the benefits we believe Oslo could help provide to IT in the long run. Specifically, his focus on the costs involved in getting answers to questions is spot on:

"Many applications are so large and complex even the most knowledgeable working on them can’t answer the above questions beyond generalities.  And, general answers aren’t good enough for a lot of development and support scenarios.

...

As for labor-skills strategies, almost always it requires not only an expert with the technologies themselves, but also the application, with all its various nuances and such.   A guru with the implemented technologies is still greatly restricted in terms of productivity until he/she knows the application.  Even the gurus can’t answer questions like those above without labor-intensive research, and it’s manual research that’s error-prone.  The consequences can be drastic if something is overlooked such as a call, something in the metadata or mentally trying to work out how code executes as you read through it.    And, there’s “walking knowledge” risk; lose a guru or two and the venture will feel the pain.

...

The time it takes to get answers is greatly reduced.  The skills it takes to get answers is greatly reduced.  The headcount needed to support an application can be reduced, sometimes drastically.  The accuracy is much greater than manual analysis.  I’ve built a couple of these the hard way and experienced all these results.  Having this out-of-the-box would be a big productivity booster."

Getting answers to questions is all about your ability to access and analyze data and the ease and speed with which you can access and analyze data is directly impacted by how you capture, relate, and store that data in first place. Today, application (meta)data is strewn across a wild west of distant, isolated towns with fractured infrastructure, poor communication, and little to no law and order. This is true both on the Microsoft platform and across the industry at large. It's time for something better. At a minimum we need to clean up our own house so Microsoft customers can get better answers to their questions about their applications built using Microsoft technology and hopefully there's an approach in here that is amenable to the broader industry so customers can get answers to questions that span implementation platforms.

There's a good discussion between Jean-Jacques Dubray, Doug Purdy, and Charles Young about if/how Oslo relates to MDA, MOP, UML, SOA, metamodels and a number of other high-science concerns related to modeling. I'll leave those discussions to the experts and too be honest I tend to look for the nearest exit when a modeling discussion goes meta. If it goes meta meta  (and it almost always does) I take out a bottle of Percoset and a hammer and spend the ensuing hours debating which to apply to my head. Eventually everyone agrees to disagree, they with each other, me with myself, and we all get back to the business of solving customer problems.

This is not intended to diminish the importance of these perspectives and concerns or clarifying Oslo's relation to them. They are a vital part of the discourse but, you won't find them here. They are not the droids I'm looking for. The droids I am looking for are shared notions of some very concrete, non-meta issues the first of which is: What Does Oslo Mean by Model-Driven?

What Oslo Means by Model-Driven: Part I

There is certainly an established cadre of model-driven * efforts in the industry and I'm not attempting to redefine anything and if after discussing Oslo you have suggestions for better terminology PLEASE send them our way. For the purposes of this discussion we'll focus on Oslo's notion of a Model-Driven Application. This notion focuses on solutions where the majority of application behavior is described in models that are consumed and executed directly by a runtime. At this point it is very tempting to try to define what we mean by "application", "behavior", "models", "directly", "executed" and "runtime" and while we will get there I'd rather not go directly down that rabbit hole and instead go through a couple concrete examples of model-driven systems. Hopefully, through some examples, a shared understanding of Oslo's notion of model-driven applications will emerge.

So, let's start with an example of a model-driven application that all of us use every day and that many of you are likely using right now: an HTML browser. From an Oslo perspective, the HTML spec is the Model Schema, an HTML page is an Instance of the model, and your browser is the Runtime. The browser consumes the HTML model instance to drive its behavior.

There are a couple aspects of the model-driven nature of HTML and browsers that you could argue have contributed to its wild success and the resulting growth of the WWW. First, the declarative nature of HTML instances lends itself to tooling. It's certainly not perfect but the rapid explosion and endurance of WYSIWYG HTML editors is evidence of this. Once these tools arrived on the scene you quickly saw a distinction emerge between "HTML programmers" and "HTML designers" and distinct tools to address their unique concerns. An HTML programmer's principal way of interacting with the model is through HTML text which Oslo would call a Textual Domain Specific Language. That is, the HTML syntax is a DSL for defining a web UI. An HTML Designer's principal way of interacting with the model is through a graphical, WSYWIG tool which Olso would call a Visual Domain Specific Language. Today, the HTML ecosystem provides a broad range of Graphical and Textual surfaces over HTML that are targeted to specific roles and, depending on how well the tools comply with the model, instances of HTML can flow between tools/roles as necessary. Here's a picture mapping these aspects of the HTML domain to Oslo terminology:

Another important characteristic of HTML’s model-driven approach is that the model instances are consumed directly by a runtime, in this case, a browser. You don’t (typically) generate code from HTML and then compile and deploy the code, you just deploy the HTML. A key benefit of this approach is flexibility. Need to make a change? Open the instance in your tool of choice, make the change, hit save. Change made and deployed. Of course if you want/need greater change management you can lay in all manner of source control, ALM, and governance systems and processes to provide those services.

At this point many of you may be thinking something like "that's not at all what I thought you meant by model-driven" or "that's certainly not what I mean by model-driven" and I think that's a basis for a great conversation moving forward. It's early days and just as we're looking for feedback on the bits and architecture we absolutely could use constructive feedback on how we describe their value, intended use cases, target customer, and longer term strategy. In part II I'll take a stab at mapping some other examples of model-driven applications into Oslo terminology.

A couple people have asked how to get Intellipad to do custom text formatting of the DSL. You do this by creating a new Classification for Intellipad. There are 3 steps. Here they are for a classification I created called X10.CommandCode.

1. Add a new ClassificationType to [Oslo SDK]\Bin\Intellipad\Settings\ClassificationTypes.xcml

<act:Export Type='mvstc:ClassificationTypeDefinition'>
    <ls:ClassificationType Name='X10.CommandCode' DerivesFrom='text' />
</act:Export>

2. Add a new ClassificationFormat to [Oslo SDK]\Bin\Intellipad\Settings\ClassificationFormats.xcml

<act:Export Name='{}{Microsoft.Intellipad}ClassificationFormat'>
    <ls:ClassificationFormat Name='X10.CommandCode'
                             FontFamily='Consolas'
                             Foreground='#FFcc3333' 
                             FontWeight='Bold'/>

3. In your grammar add a Classification attribute to the token you want the formatting applied to.

@{Classification["X10.CommandCode"]}
token CommandCode = ...

TIP: When in Intellipad you can press CTRL+ALT+F5 to reload the settings instead of having to bounce the tool.

I'm still writing up the overview post to describe the goals of the X10 solution but enough folks have asked for the grammar so I'll just get it out there. I've posted the grammar and a sample input file up to the MSDN Code Gallery. Here's the grammar in action in Intellipad with the graph the runtime consumes on the right. Open the input file in Intellipad, press CTRL+SHIFT+T, select the grammar file and you should get the same output.

Just saw this job posting for a developer in our Management division.

If you read between the lines you'll see Oslo's dirty hands all over this. :)

Job Title: Software Development Engineer

Job Category: Software Development

Product: (Not Product Specific)

Date Posted: 03/24/2009

Job Code: 254341

Location: WA - Redmond

Travel Required:

Do you want to transform the way people manage datacenters? Do you love the engineering challenges of designing software and models for use in the next generation of datacenters? Do you relish the challenge of building an extensible platform? Do you have a passion for Domain Specific Languages (DSL’s) and the power of using models?

The Management Models and Authoring Tools team is looking for a strong experienced development engineer to drive the architecture, design and implementation of the next generation of systems management knowledge tools. The team is building a world class modeling tools platform for creating and packaging the models that target our system management products. The platform will provide core services that enable an IT Professional to better manage the applications and IT infrastructure running on Windows Server and other platforms. Built around a core set of common models for systems management, the team also participates in the development of the common model library across teams within STB. The tools that utilize the platform will provide a great experience for both the creators of the management knowledge and will be extensible to cover many aspects of system management from monitoring, best practice guidance, deployment and others.

This is a great opportunity to join a team in the early phases of delivering tools and platform that are of strategic importance to the Management Systems Division and Microsoft.
You’ll be a great team influence. You will also have record of technical leadership and great planning. You’ll have experience developing development tools and with the link between IT Professionals and software developers. Exposure to operations of an application is a plus.
Take the next step in your career and come join our team!

Qualifications:
Minimum 5 years of software development experience in C, C++, and/or C# preferred.
Demonstrated experience working through the full product cycle from initial design to final product delivery.
Demonstrated experience in developing platforms (UI platforms highly desirable)
Outstanding technical, leadership, communication, and team collaboration skills.
Experience designing and developing rich client software (highly desirable)
Experience developing development tools a plus.
Experience with Visual Studio add-ins is a plus.

An interview I did with Kathleen Richards back in February just posted on Visual Studio Magazine. In it we cover some good Oslo questions like:

• What's new in the January CTP?
• Is "M" considered one language or multiple languages?
• Is Oslo expected to be part of VS 2010?
• What is Microsoft's view of model-driven development and how does Oslo fit into that strategy?
• Can you  provide some real-world examples of how Oslo might be used?
• Is Quadrant for developers?
• What should developers be paying attention to in terms of this technology?

A couple weeks ago I decided it was time to get my hands dirty and bring Oslo to bear on an area I’m becoming increasingly interested in: Home Automation. Specifically, I'm creating a home automation application/service that allows people to control household appliances and functions over the Internet. Part of my job as an Oslo product planner is to understand the gap between our vision and the current state of the bits that customers can touch and while we have many tools to help us do that, nothing beats dogfooding for directly experiencing the joy and pain of early bits.

SideNote{"This gap always exists and is generally larger for efforts that are part of a long term strategy, but more on that later."}

Aside from having a personal interest in home automation, smart grids, etc. I chose this domain as my first Oslo project for a couple reasons:

1. Broadly Accessible: we all know what it means to turn lights/appliances on and off
2. Real World: this is a real industry (just a special case of device control in general) with real ISVs building software for it
3. Manageable Scope: the X10 Specification defines a very concrete set of boundaries
4. Not Microsoft: not an example of MS using Oslo to build/drive our own frameworks (Doug Purdy's Mservice is a good example of that)
5. Not Enterprise: Oslo has value to application development in general, not just enterprise application development.

For my approach I decided to follow the bits. That is, the current state of the bits (and our words) leads one down a particular path of exploration and I want to know what that feels like. In the next post I'll lay out the details of that approach, some key capabilities the app has to deliver and mappings to specific Oslo components.

Oh yeah, Oslo really is controlling my house (at least my bedroom). Here's a screenshot of my DSL controlling an X10 device driver and displaying the output from the driver on the right.

Well, it's time to dive into the blogosphere both feet first. For now, this blog will mostly be about Microsoft's "Oslo" project, notions of models/modeling, and the application of both to solution development. Maybe a little later we'll get into how models can support next generation application management, Internet scale datacenters, and software factories. I've got a backlog of Olso topics I've wanted to cover for some time but feel free to use the comments to suggest others. I'm much more interested in discussing the topics you are interested in vs. the ones I think you are interested in. Taxes and blogging, it's all about interest.

Let's get started.