Developing a TSQL Domain Specific Language with "M" and the Microsoft Oslo SDK

• facebook
• twitter
• google+
• in
• Email

My last article explained why a developer chooses a Domain Specific Language (DSL) and how an M DSL can be incorporated into a Windows application. The article was a starting point for a Visual Studio developer interested in DSLs, M, the Oslo SDK, and how all the components collaborate to render a solution.

In this article, I'm going to demonstrate some more advanced material. In particular, I'll delve more into how a runtime can more effectively leverage the Oslo SDK data structures generated by M.

What is "Oslo"?

If you've been following my articles Oslo's goals and technologies are familiar to you. If not, here is a brief summary. Oslo is composed of the following components displayed in Figure 1.

Click here for larger image
Source: "Microsoft PDC 2008 - A Lap Around Olso" Figure 1 Oslo Architecture

• "M", a language for composing models and DSLs
• 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. Models are application metadata formatted for runtime consumption. Separate Microsoft initiatives aim to build runtimes and tooling into applications like Visual Studio that are Oslo model aware.

The M Language is composed of MSchema, MGraph, and MGrammar. A complete introduction to M is beyond the scope of this article. I introduced MSchema, MGraph, and MGrammar in my prior articles.

There is an underlying set of .NET Framework classes supporting all the functionality above. In my last article I demonstrated how some of these .NET Framework classes work. As I mentioned earlier, in this article I'm taking the demonstration a step further and delivering something more advanced.

Something "Advanced"

It's no surprise that the best way to demonstrate some more advanced features is to do something, well, "advanced". The sample application demonstrating more advanced features is depicted below.

Click here for larger image
Figure 2: SQL MGrammar application

Using a DSL syntax developed in M, the runtime parses the syntax, generates a TSQL SELECT statement from the parsed data, executes the SELECT against the SQL Server AdventureWorks database, and displays the Resultset in a WPF GridView.

The sample application is built on top of the January 2009 Oslo SDK CTP.

If you're new to TSQL and unfamiliar with SELECT statements, later in the article I'll dissect the SELECT statement.

As I mentioned earlier, one of the application components is a DSL written in M. Sample DSL code I call "Simple SQL" is below.

  (Employee)
  (Contact AS Contact)
  (Employee AS Manager)
  
  (Employee AT ContactId INTERSECT Contact AT ContactId)
  (Employee AT ManagerId INTERSECT Manager AT EmployeeId)
  
  Data: Employee.NationalIdNumber
  Employee.LoginId
  Contact.LastName
  Manager.LoginId

There are three parts to the "Simple SQL" DSL program structure:

• A section declaring the tables. Tables must be between "()". Repeated tables must use the "AS" statement to recast the table with a new name. A TSQL concept called aliasing.
• An "INTERSECT" section indicating how the relational data is joined between table.
• A "Data" section containing the fields and the table with the originating field.

Like many DSLs, the syntax is expressed using the domain's "business language", making development more approachable to a wider audience. As long as a business user understands some basic relational concepts they'll be capable of writing "Simple SQL" DSL code.

There's one more topic I need to cover before exploring the sample runtime anatomy.

Page 1 of 4