Oslo (part 2)

…continued from part 1. 

About the demo’s

The demo’s in this post are done with the VPC distributed at PDC 2008. It’s a Windows Server 2008 system with pre-alpha version of Oslo installed, together with CTP’s of WCF 4.0 and WF 4.0. For Belgian users: if you start up the VPC, the password on a azerty keyboard is: pqss(SHIFT2)zord&. The first time you start up the VPC, change the keyboard layout to Dutch (Belgium) so that it switches to AZERTY.
 
To work easier include all needed executables in the path by typing the following in the command prompt:

path %PATH%;"C:\Program Files\Microsoft Oslo SDK 1.0\Bin"

Demo 1: creating a model

In this demo we will model the schema for a Customer. This means that we will define how a Customer  will look like (what kind of data it contains).

Create Customer model

Define Customer

A Customer is a complex type that contains other fields like CustomerID (primary key), FirstName, LastName, BirthDate, Address and so on. We are also going to put some constraints on the fields. We will now define our model using the domain specific language MSchema, which provides us with a simple way to describe information that will be stored in the repository. So, MSchema is about schematizing data. Start up the v irtual machine and click the Intellipad link on the desktop:

Oslo VPC

First select File -> Save as and save the file as Customer.m, so that Intellipad knows it’s a model. Then model our Customer as follows (we’ll keep it simple):

Customer model

If you click the menu item M Mode -> Reach Sql Preview then you see the generated sql statements for the model: 

Generated SQL statements

Compile model

The next thing we’ll need to do is compile this model. We’ll do that in the command prompt using the m-compiler:

m.exe Customer.m /p:image -nologo -t:repository

This command will create an image file called Customer.mx from our source file Customer.m.

Populate repository

The next step is then to populate the repository with the generated image using mx.exe: 

mx.exe /i:Customer.mx /db:repository /ig /f /verbose

What mx.exe will do is generate some SQL and then use that to store the model in the repository.

View model

Now that our model is in the repository, we can use any data access tool to view it. Let’s open up Excel, select the Data menu item and choose From other sources -> From Sql Server:

Inserted from SQL Server

The Data Connection Wizard appears:

Data connection wizard

To connect to the local host type ‘.’ as server name and click Next.

Select database tables

Select Repository for the database, and then you will get a list of tables that are already in the repository. Find and click the Customers table and then click Finish.

Import data

Click OK and our model will be visualized in Excel:

Model in excel

Of course, we haven’t any data entered yet, so that’s what we will do next.

Enter data for Customer model

Entering data for the Customer model means that we want to enter data that conforms to the Customer schema that we defined in the previous step.

Describe data

We’ll use Intellipad again and enter the data using the domain specific language MGraph, which provides us with a simple way to enter instance data for a given schema; this data will then be stored in the repository. So, MGraph is about representing data. Create a new file in Intellipad called CustomerList.m:

MGraph CustomerList

If you click the menu item M Mode -> Reach Sql Preview then you see the generated sql statements for the model: 

Generated sql statements for the model

Compile data

To enter the data that we defined into the repository, we use the same tools as we did before. First use m.exe to compile the data into an image file: 

m.exe CustomerList.m /p:image -r:Customer.mx -nologo -t:repository

This will take the set of values (the data) that we defined in CustomerList.m, and create an image file CustomerList.mx.

Populate repository

The next step is then to populate the repository with this image file using mx.exe:

mx.exe /i:CustomerList.mx /db:repository /ig /f /verbose

This will enter the data into the repository if it’s valid, meaning if it validates against the Customer schema we defined.

View model

Let’s have a look at the model in the same way we did earlier, using Excel. We see that the data has been added to the repository: 

Model in excel

 

Oslo (part 1)

Oslo is the codename for the next generation of Microsoft’s SOA platform. It’s all about model driven development (MDD), and as a software architect I’m obviously very intrigued by this new approach; so I contacted Microsoft and was able to copy the virtual PC that was distributed at the Professional Developers Conference of October; and started experimenting. This VPC contains Visual Studio Team System 2010 with .NET 4.0, Sql Server 2008, WF 4.0, WCF 4.0, Microsoft Office 2007, code name Oslo and code name Dublin. These are all preliminary releases, and things may change, but the model-driven development idea will of course stay.

What is a model?

In short, a model is a description of data. It’s an abstract description of the reality. And if we talk about models, we can see a certain evolution of the meaning of a model.

Models used for communication

Imagine that you are in a meeting and you are drawing diagrams on a whiteboard to explain a business process to others. The idea is that you draw something that everyone understands and agree upon. It’s a type of communication where the diagram is the model, and the whiteboard is the tool. This is a very simple example of modeling; and in fact what you do is design an abstract description of a particular domain. A wide-spread example of such models can be found in the Unified Modeling Language (UML), where you can draw a Use Case Diagram (as the model) to define the functionalities of a system using Microsoft Visio (as the tool).

File Validator use case diagram

Models to assist development

Other models are used to generate code and run that code; and vice versa, turn an existing piece of code into a model. An example of this is the class diagram in Visual Studio Architect edition, which is a graphical representation of the underlying code. The goal of such models is to assist in development and create a relation between models and underlying code. 

Models to assist development

Models in model-driven development

In model-driven development, the model is not just a means to assist in development. Instead, it drives development. You model your application in terms of data.

Model-driven development

Writing applications with the model-driven mindset is all about focusing on the ‘what’ instead of on the ‘how’. As an example, take a simple windows form that contains fields that a user can fill in to describe a person. If we model this, we first think in terms of data. What kind of data should be presented, how does the data look like and what are its constraints? For example:

Person:
   FirstName is some text of maximum length 30
   LastName is some text of maximum length 30
   Age is an integer greater than 0 and smaller than 120

At this point we are not interested in how that data is presented, for example whether FirstName should be presented by a text box on the form or where it is located on the form.
 
Another important aspect in model-driven development is domain-specific language (DSL). We need a human-friendly way to interact with the model, some kind of language that is understood by our target audiance and is intended for a specific domain or business area. Such language can be a textual DSL which provides a textual way to interact with the data, or a visual DSL to interact visually with the data. And finally the runtime is responsible for executing the system. In fact, you are probably already doing model-driven development! An example is web site design: HTML is the DSL to describe a specific UI domain, and the ASP.NET runtime is able to execute that model. Another example is WPF: XAML is the DSL to describe the UI domain, and the WPF runtime is able to execute it.

Model-driven development

This approach gives you three important advantages:

• transparency: better understanding of your processes, bringing humans and computers closer together
• flexibility: faster changes of your processes
• productivity: more essence, less ceremony

The goal of model-driven development is to bring together business analysts, architects, developers, testers, users, hardware and software and all other participants.

What is Oslo?

Oslo is the platform for model-driven applications. In fact, models are used to describe the platform and applications. Even further we can say that the platform is the model! This means that all models are closely integrated and as such, every model has an impact on another model. As you can guess consistency is critical in such a data-centric environment.
 
It exists of three parts: a modeling language called ‘M’, a modeling tool called ‘Quadrant’ and the repository.

• M is the language to write down models in the form of transparent data, which then can be executed by some runtime. It’s a textual language to define models and DSL’s. Typically a developper is going to use M directly. In M we have three parts: MGraph (for modeling data), MSchema (for defining data and relationships) and MGrammar (to define your own domain specific language).
• Quadrant is the designer tool to build models and DSL’s in a visual way, typically used by the architect or IT-professional.  
• The repository is the heart of the system. It’s just a Sql Server database and the place where the models are stored centrally.

Important to know is that in Oslo ‘nothing goes away’, meaning that current investments in technology and skills will not be compromised. I have seen people asking whether some technologies like BizTalk Server will disappear. The short answer is no. Companies have invested a lot of money in these tools, so it’s very unlikely that Microsoft will not support them anymore. However I do believe that there might be a shift in focus to workflow foundation. Anyway it’s hard to say at this time, because Microsoft does not have all the answers yet – actually, there’s still a lot of research and development going on.

Continued in part 2…