Exploring the Oslo Repository
Earlier, I alluded to "item.id" working a lot like a TSQL foreign key constraint. In fact, that's exactly what the M statement is translated into when it becomes TSQL.
I also mentioned that there is no object-orientededness in M. In the M declaration Application conformed to Manageable and DerivedItem. Instead of expressing the TSQL as a complete copy of these other types, the conformity becomes keys matching the keys on the other types.
Folders are a feature built into the Repository. According to the SDK documentation, Folders allow for security and versioning. Folders are arranged in a hierarchy. More general Folders appear at the top and version numbered folders appear at the bottom of the hierarchy.
Collections like "Applications" declared in the System.Application.Application module are implemented in views. The TSQL code appears below.
create view [System.Application].[Applications] ( [Id], [DefinedInApplication], [Folder], [LifecycleState] ) as select top ( 9223372036854775807) [AT].[Id] as [Id], [AT].[DefinedInApplication] as [DefinedInApplication], [AT].[Folder] as [Folder], [AT].[LifecycleState] as [LifecycleState] from [System.Application].[ApplicationsTable] as [AT] with (readcommitted) inner join [Item].[ReadableFolders]() as [RCV] on [AT].[Folder] = [RCV].[Folder];
The INNER JOIN to Item.ReadableFolders enforces Folder Security and versionining.
At this point, one lingering question is why "create" new tables in the Repository? Why not leverage some existing internal tables and store the data in these tables?
Creating all of these tables is a lot of heavy lifting to store data in the database. SQL Server includes XML data types; why not leverage the new datatypes? Why wasn't Oslo implemented using more flexible datatypes?
From what I've gathered and what I understand about the XML datatype, there's one big reason: performance. Relational data can be queried and written faster to the database. Consider how a developer will query and write to the database. Also, reporting tools are tuned to Relational data.
Another reason is enforcement. Relational databases include foreign keys, primary keys, views, and triggers. These are all simple, mature constructs for enforcing scalable data relationships. Plus, often it's better to enforce relationships in the database rather than forcing some intermediate layer to do the enforcement, especially when you want to open the database to 3rd party tools.
Oslo is Microsoft's model-driven future. The Repository is one of the many architectural components debuting in the Oslo SDK. M is the Oslo model building language. M is translated to TSQL and the resulting Data Definitions create tables and views in the Oslo Repository.
Sources: Oslo SDK—Documentation and Source Code
- "Oslo Repository:" http://blogs.msdn.com/anthonybloesch/archive/2007/11/05/oslo-repository.aspx
- "Oslo Repository and Models:" http://channel9.msdn.com/pdc2008/TL28/
- "A Lap around Olso:" http://channel9.msdn.com/pdc2008/TL23/
- "Oslo: The Language:" http://channel9.msdn.com/pdc2008/TL27/
About the Author
Jeffrey Juday is a software developer specializing in enterprise 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. You can reach Jeff at email@example.com.
Page 3 of 3