PDC 2008 Experience: Day 3: Session = "Oslo: Repository and Models"

A Repository Database

• Optimized for storing and sharing models
• designed for extensibility
• allows fro query, linkage, impact assessment across models
• supports common tasks such as versioning, access control
• extensible meta data enables rich tooling
• includes end-to-end system/lifecycle models
• out of the box models
• design-time , run-time
• "Natural" SQL Server database
• approach leverages database eco-system
• It is an application that sits on top of SQL Server

Repository capabilities

• Repository features are built on SQL Server
• Repository install also turns on useful features

Oslo Models

• Identity
• System.Identity
• Application
• System.Runtime
• System.Application
• Document
• ServiceModel
• System.ServiceModel
• Transactions
• System.Transactions
• WorkflowModel
• System.WorkflowModel
• Ssytem.Workflow.Activities
• WorkflowServiceModel
• System.WorkflowServiceModel
• System.WorkflowServiceModel.Activities
• Messaging
• System.Messaging.Adapters
• Security
• System.Security

... and more

Adding Your Models to the Repository

• The Oslo SDK provides tools to
• Define new models:
• Intellipad
• Visual Studio language services
• Compile models
• m.exe
• msbuild build task
• Deploy Models
• mx.exe
• Once they're in the database, it is just SQL

Core Services of the Repository

• Deployments
• Security
• Catalog
• Versioning

Deployment

• MX.exe packages SQL for deployments to Repository Nodes
• Packages can come from M files
• Packages can be exported from Repository nodes
• Application model can be used to define applications to be deployed
• define a web service in the Repository and deploy it without writing a line of code

Security

• Security is claimed based
• Identity becomes just one of several possible claims
• Claims presented to authorize operations against resources
• Repository tables keep track of claims, resources and operations
• Triggers implemented on  /t:Repository generated views to check claims.
• Views protect against direct access to tables.
• Domain Specifc security containers
• Use folders to partition data
• Apps decide which data goes into what folder
• Security check happen on folder boundaries
• Must call the field "Folder" for compiler to find it
• Folder ID must exist the Item.Folders table

   1: model Friendship

   2: {

   3:     type F

   4:     {

   5:         Id: Integer32

   6:         Name : String

   7:         Folder: Integer

   8:     }

   9: }

Catalog

• SQL Server has a catalog
• List of tables
• List of Views
• List of Stored Procedures
• and the relations between them
• Repository has its own catalog
• Extends SQL Server catalog
• Adds information about relationships modules, types and extends
• Useful for
• Rich export
• Impact Analysis
• Enriched SQL data access code.

Versioning

• Data change synchronization
• Between nodes using SQL Server Replication and Occasionally Connect Systems (OCS)
• Import/Export using SQL Server Change Tracking
• repository <-> file system
• Schema evolution
• Extend M type and provide backwards compatibilities for old client with computed values
• SQL Server Integration Services for data migration

Where are we?

• Repository is optimized for many reads few writes
• Contains models for "Oslo" app domains
• Can be extended with M
• Models can be deployed, secured and versioned