Introducing "Oslo"

by community-syndication | Nov 3, 2008 | BizTalk Community Blogs via Syndication

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

Screen Shots of Oslo, Dublin, and .Net 4.0 Workflow

by community-syndication | Nov 3, 2008 | BizTalk Community Blogs via Syndication

I’ve put together a series of First Look blog posts covering Oslo, Dublin, and Workflow 4.0.

These posts include several screen shots of the new Microsoft Technologies and gives you a high level overview of some of the new features.

Check them out here:

First Look Dublin (Windows Application Server)

First Look Oslo (Quadrant and M Modeling Language)

First Look Workflow 4.0

Do not forget to check out all the great videos on these same subjects at BizTalkGurus.com media gallery.

Interview Series: Four Questions With Yossi Dahan

by community-syndication | Nov 3, 2008 | BizTalk Community Blogs via Syndication

We continue our monthly look at thought leaders in the “connected systems” space by interviewing Yossi Dahan.  Yossi is a great technologist,  prolific blogger, Microsoft MVP as well as a good tipper.  Yossi recently attending Microsoft’s PDC conference in Los Angeles, and I wanted to get some insight from him as to what he saw […]

Microsoft "Oslo": What’s in a Name?

by community-syndication | Nov 3, 2008 | BizTalk Community Blogs via Syndication

When I blogged about the .NET Framework 4.0/Dublin announcement recently, I also mentioned that the code name “Oslo” has taken on a refined meaning. Since then, I’ve seen some confusion out there, and thought I would do a post that specifically addresses just this change.

First off, the vision of what this new wave of technologies has not changed. The term “Oslo” used to refer to the entire technology stack that will make it so much easier to develop applications. Now, as we move through the development lifecycle, some items are migrating, quite naturally, into their ultimate ship vehicles. Some examples of things that were once under the “Oslo” umbrella, but have since migrated, include:

• WCF/WF enhancements (part of the .NET 4.0 framework)
• The runtime hosts for WCF/WF and models (part of the Windows Server application server, will be shipped as part of “Dublin” and beyond)
• Improved WCF/WF design/authoring experience (now part of Visual Studio 2010)

A nice side effect of all this is that the separate pieces are now decoupled from each other. There will be no “Big Bang Release” that will appear one day, the decoupled pieces can be delivered independent of each other. However, as all of this work is being done by Microsoft’s Connected Systems Division, everybody’s is talking to each other, and the end-goal remains the same.

So, with those things out from under Oslo, what is Oslo? Oslo today is now the modeling platform, which consists of three things:

• the repository
• the modeling language
• tooling (to author/deploy models)

Hopefully this helps to clear up some confusion.

Another name change from last week… if you’ve been following the work at labs.biztalk.net, which has been live for over a year, well…. that was the incubation project, it morphed into Zurich, and was re-unveiled last week as .NET Services. It consists of an identity system, a service bus and a workflow engine. I looked at this some months back, and my experience at the time was it took about an hour from the time I downloaded the SDK until I had my first customized workflow running in the cloud. It was a defining moment for me, and my mind started reeling, when I sat back and let the potential implications of what I had done sink in. With a few quick browser clicks, I had a workflow running in the cloud. A few years down the road, it would just take a credit card number to scale that and have it running on hundreds of machines…. Intrigued? Check it out, you can sign up for an early preview.

Another name change from last week, the poorly kept secret code name of “D” for the modeling language in Oslo is no more, it’s now “M” (for models), as well as the related MGrammar for creating DSLs. I’ll have much more to say about these soon….

Yet another name change – sort of… if you follow my blog you know I really like Live Mesh and use it a lot (see: Adventures with Live Mesh (CTP), More cool tricks with Live Mesh). Live Mesh is now integrated into the Live Services part of the Azure Services Platform. They also moved from CTP to Beta stage last week, and the geeky-cool part of the new release is Windows Mobile support. I take a picture with my phone, and it automagically appears in the “mobile photos” folder of my Live Mesh desktop-in-the-cloud, as well as any other devices that are synchronizing that folder.

IIS7.0 and beyond Web Platform Installer Tool (beta)

by community-syndication | Nov 3, 2008 | BizTalk Community Blogs via Syndication

Folks – while setting up some IIS servers for a BTS production environment I came
across this handy little tool.

Basically gives you a Tree View of what things you’d like to install on your IIS Web
Server from MS (mother ship).

Includes things like Service Packs, etc etc. – handy spot to grab all the new files
in one spot.
(as opposed to the piece meal approach – of install asp.net, oh you need
the .net 3.5 framework – install…oh…you also need SP1 ..with maybe a few reboots
inbetween)

– single place for all the tools and other components that you’ll need.

– great way to do them all at once.

Here’s what you’re after –

http://www.microsoft.com/web/channel/products/WebPlatformInstaller.aspx

Data Modelling in “M” Webcast

by community-syndication | Nov 2, 2008 | BizTalk Community Blogs via Syndication

"Using the Windows Communication Foundation (WCF) Adapters in BizTalk Server" Whitepaper

by community-syndication | Nov 2, 2008 | BizTalk Community Blogs via Syndication

Written by Aaron Skonnard, this was originally named “Integrating Microsoft BizTalk Server 2006 R2 with the Windows Communication Foundation”. It has been renamed to “Using the Windows Communication Foundation (WCF) Adapters in Biztalk Server”. It can be found  on MSDN at  http://msdn.microsoft.com/en-us/library/bb967002.aspx, or directly from the download center at http://www.microsoft.com/downloads/details.aspx?familyid=a976dc7d-2296-4f88-be4d-0d314fca9e59&displaylang=en&tm.

"Consuming and Hosting WCF Services with Custom Bindings in BizTalk Server" Whitepaper

by community-syndication | Nov 2, 2008 | BizTalk Community Blogs via Syndication

“Consuming and Hosting WCF Services with Custom Bindings in BizTalk Server is a new WCF whitepaper.  You can find the download page from MSDN at http://msdn.microsoft.com/en-us/library/dd203050.aspx, or download it directly from the download center at http://www.microsoft.com/downloads/details.aspx?FamilyID=70badd79-ce7e-4ccb-be5c-3ff74ca3a8c4&displaylang=en. 

Here are the first few paragraphs from the paper giving a brief introduction of it’s content.

IntelliPad (IPad): adding commands

by community-syndication | Nov 1, 2008 | BizTalk Community Blogs via Syndication

Last week at the PDC was Oslo’s big
coming out party.  If you haven’t heard Oslo is a new set of technologies from
Microsoft relating to model-driven development.  The three main parts of Oslo
are:

1) A language:  The M language is a language for writing stuff down.  You
write down the things you need to drive your application.  The things could be
application configuration data, or application specific data, or data which is actually
your application.  How exactly you use M is largely up to you.  There is
also MGrammar which I’ll be covering more in future posts.

2) A repository: There needs to be a place to hold all this data, so Oslo has a SQL
Server 2008 database named the "Repository".  The Repository is full
of models, both models that Microsoft has created, as well as models you might want
to create.  Microsoft has created a large number of models that they think will
be useful for us as developers.  Things like endpoints, service contracts, workflows,
as well as other data our applications will need.  You can choose to put your
models made in M into the Repository, or you can put your models into your own database. 
The choice I think will largely be based on whether you want your models to be able
interact with Microsoft’s models, and whether the Repository becomes your main application
database.

3) A visual tool:  To view the models in the Repository they’ve create a visual
tool named "Quadrant" (this is a code-name hence the quotes).  "Quadrant"
is a tool for viewing models for those of you who are visual/spatial people. 
Some people like text – so they have M.  Some people like drawings – so they
Quadrant.  Quadrant is a highly customizable general purpose data viewing and
editing tool.

Those are the three "main" pieces, but there are other pieces as well. 
To create a great editing experience for M, the Oslo team built a tool called IntelliPad
(or IPad) for short.  IPad is a customizable text editor that has support for
the M language.  Here is a screenshot of IPad in action:

In this picture I’m using M to generate "Reach SQL" which is SQL that isn’t
limited to the Repository.  The test.m buffer is in "MMode" which means
there are additional commands available that wouldn’t be available if I where editing
any other kind of text file.  The other buffer is generated from the M in the
test.m buffer, and I made this happen by going to the MMode menu and selecting "Reach
SQL". 

If you want to see Repository SQL you can use the MMode menu and select "Repository
SQL".

In this case I am beginning a model to represent a blog.  I’ve created an M type
named BlogEntryType, and then an extent (the name for storage space in M) named BlogEntry. 
You can see on the right that the M will generate a table named BlogEntry with the
appropriate columns.  As Scott points
out one of the nice features of this system for developers even if you aren’t using
the Repository is that you will be able to check-in the m file to source control and
doing all the usual source control type things on it.

That’s all a brief introduction to Oslo and IPad.  The purpose of this post (indicated
by the title) is that IPad is super customizable.  When I was at the last Oslo
"SDR" like event a few weeks ago, I asked for a feature in IPad – the "Open
Folder in Windows Explorer" feature from Visual Studio 2008 which I find to be
the most useful simple feature in Visual Studio I think for all time.

Chris Sells (who is a
PM on Oslo) said "You add it".  Which is a very typical Chris response,
but at least in this case it is possible since IPad’s whole system of commands is
totally customizable.

Harry will happy that this is
forcing me to learn about IronPython, although I have to admit I was able to make
it work without much actual learning of the IronPython language.

Almost all of IPad’s commands are actually written in Python.  These commands
are registered with IPad when IPad first starts, and the commands are implemented
by manipulating the interface to IPad’s object model. 

The main command file is Commands.py which is in the Oslo install directory under
Bin\Intellipad\Settings.  It contains almost all of the standard mode commands. 
To add a new command, all I had to do was add a new .py file to that directory. 
IPad seems to search at least that directory for .py files and loads up all the commands
found inside into the environment.

Each command has at least one IronPython function, which represents the "Execution"
of method of the command.  This function is annotated with an "attribute"
(which I think may be added by the IPad team, I can’t seem to find any reference to
attribute support in IronPython – Harry?).

The Metadata.CommandExecuted "attribute" tells IPad this is a definition
of a command.  It has three parameters,  the IPad object that should execute
the command, the name of the command, and the keyboard shortcut (which is optional). 
Here is my CommandExecuted function defintion from the MyCommands.py file I created
in the settings directory:

import sys
import System
import Microsoft
import Common



@Metadata.CommandExecuted('{Microsoft.Intellipad}BufferView', '{Microsoft.Intellipad}OpenExplorerAtBuffer', 'Ctrl+B')
def OpenExplorerAtBufferExecute(target, sender, args): from System.Diagnostics import
Process from System.IO import Path, File exists = False file = sender.Buffer.Uri.AbsolutePath
exists = File.Exists(file) if exists: Process.Start(Path.GetDirectoryName(file))

The first argument of the CommandExecuted can either be (as far as I can tell so far)
the BufferView object which represents the current buffer, or the HostWindow object
which seems to represent IPad itself.  OpenExplorerAtBuffer is the name I gave
this command, and Ctrl+B is the keyboard short cut.  The code is pretty easy,
I just find the path of the buffer and if it exists (since a buffer in IPad might
not have been saved yet) I just call Process.Start at the directory to open explorer.

Each command can optionally have a function that IPad will call to find out if the
command should even be available at a particular time, so I added that one as well:

@Metadata.CommandCanExecute('{Microsoft.Intellipad}BufferView', '{Microsoft.Intellipad}OpenExplorerAtBuffer')
def CanOpenExplorerAtBuffer(target, sender, args): from System.IO import Path, File
file = sender.Buffer.Uri.AbsolutePath args.CanExecute = File.Exists(file)

The "CommandCanExecute" function just checks to see if the file exists and
returns the args.CanExecute as true or false, if true the command is active, if false
the command is not. 

The next step was to add my command to a menu, since I tend to be a mouse/keyboard
developer (sometimes I use the mouse at odd times – just the way my hands work I guess). 
To add a command to IPad at all times,  I edited the MenuBar.xcml file which
is in the Intellipad\Settings\VisualStudio folder, and drives the default menu (other
IPad "Modes" can have additional menu items merged, as the MMode mode does
with the MMode menu).  I added a new item under the File menu:

<act:Exports
      xmlns='http://schemas.microsoft.com/winfx/2006/xaml/presentation' xmlns:x='http://schemas.microsoft.com/winfx/2006/xaml' xmlns:act='clr-namespace:System.ComponentModel.Activation;assembly=Activation' xmlns:mis='clr-namespace:Microsoft.Intellipad.Shell;assembly=Microsoft.Intellipad.Framework' xmlns:mi='clr-namespace:Microsoft.Intellipad;assembly=Microsoft.Intellipad.Core' xmlns:mih='clr-namespace:Microsoft.Intellipad.Host;assembly=Microsoft.Intellipad.Core' >
<act:Export Name='{}{Microsoft.Intellipad}MenuBar' xmlns:mti='Microsoft.Intellipad' >
<Menu> <Menu.Resources> <mi:FileNameConverter x:Key='fileNameConverter' />
<mi:ModeToMenuItemConverter x:Key='modeToMenuItemConverter' />
</Menu.Resources> <MenuItem Header='_File'>
<MenuItem Header='_New' Command='{mis:NamedCommand
Name=mti:New}' /> <MenuItem Header='_Open' Command='{mis:NamedCommand
Name=mti:Open}' /> <MenuItem Header='Open
_Project' Command='{mis:NamedCommand Name=mti:OpenProject}' />
<MenuItem Header='_Save' Command='{mis:NamedCommand
Name=mti:Save}' /> <MenuItem Header='Save
_As' Command='{mis:NamedCommand Name=mti:SaveAs}' />
<MenuItem Header='_Close Buffer' Command='{mis:NamedCommand
Name=mti:CloseBuffer}' /> <MenuItem Header='Open
_Buffer Folder In Explorer' Command='{mis:NamedCommand
Name=mti:OpenExplorerAtBuffer}' /> <Separator /> <!-- rest of file
omitted--> </act:Exports>

So adding the command allowed me to to Ctrl+B from any buffer and get the windows
explorer folder of the current buffer to open.  Changing the MenuBar.xcml file
enabled me to get the menu item on the File Menu:

All in all I find IPad to be a really interesting and powerful text editor – but being
able to customize the menus and commands with such ease I think is just another example
of the cool work the Oslo team is doing for us as developers.

Check out my new book on REST.

TFS/Scrum Podcast…

by community-syndication | Oct 30, 2008 | BizTalk Community Blogs via Syndication

I had a chance to sit down with Jeff
Brand while down in Omaha for my presentation
at the HDC.  We recorded a podcast on all (most) things Scrum and TFS –
you can check it out here. 
It was great fun – thanks Jeff!