Questions and Answers – SQL Server Modeling Services

Last Updated: November 2009

Q. At PDC 2008 the repository and domains were part of code name "Oslo". What is the status now that “Oslo” has transitioned to SQL Server Modeling?

A. What was formerly known as the “Oslo” repository and the built-in domains has become SQL Server Modeling Services.  SQL Server Modeling Services is a role for SQL Server that stores shared models in a database for use by Microsoft, third-party and customer applications and tools.

Q: Why is the name of the “Oslo” repository changing to “SQL Server Modeling Services?”

A. “Oslo” was a coded project name.  As the features developed under that project transitioned into products they have been given names consistent with the other parts of the SQL Server product family.  The name “SQL Server Modeling Services” is consistent with other SQL Server “Services” such as Reporting Services, Analysis Services, and Integration Services.

Q. When will SQL Server Modeling Services surface in SQL Server?

A. SQL Server Modeling Services will be included in a future version of SQL Server.

Q. What is the UML domain and why is Microsoft building it?

A. The Object Management Group’s (OMG) Unified Modeling Language (UML) defines a standard way of modeling not only application structure, behavior, and architecture, but also business process and data structure. The UML addresses many of the modeling needs of business analysts, architects, developers, testers and IT staff. While often used only for sketching, UML models can also be an important asset in application development. By including UML as a domain in SQL Server Modeling Services, Microsoft is demonstrating a commitment to the UML and encouraging increased use of UML models during the application development lifecycle by treating them as a first class development artifact. Microsoft wants to enable the kinds of scenarios in a modeling space that are often only thought about in source code and software components, including maintaining catalogs of commonly used models, providing impact analysis across models, and potentially traceability between software deliverables and the models that describe them. 

Microsoft is building the UML domain using as source the UML 2.1.1 definition provided as a CMOF XMI file by the OMG. Microsoft’s goal is to deliver a UML level 3 compliant store for UML. As the UML is an open standard it is not advantageous to have many implementations in the SQL Server Modeling Services database that might differ. Microsoft is building this implementation as part of its commitment to UML.

Q. How does the UML domain in SQL Server Modeling Services relate to new UML Designers available in Visual Studio 2010? How does it relate to Visual Studio 2010 Layer Diagram?

A. SQL Server Modeling Services will support the UML domain including a full implementation of the UML 2.1.1 specification and support for import and export of UML-compliant XMI files from any vendor.   Visual Studio 2010 introduces support for several UML diagrams.  Visual Studio plans to introduce support for XMI import and export for these UML diagrams in a release post VS 2010.  Subject to the limitations of coverage in Visual Studio 2010, it will be possible to interchange models between Visual Studio 2010 and the SQL Server Modeling Services database as well as 3rd party UML tools that support XMI import and export.

The Layer Diagram is a Visual Studio construct and not related to UML.

Q. When would I use the Visual Studio vs. the SQL Server Modeling Services technologies? Are they integrated?

A. SQL Server Modeling Services is a database and it integrates with Visual Studio like other databases.

Q. What is the System.Runtime domain and why is Microsoft building it?

A. SQL Server Modeling Services database will support a variety of metadata about application during its lifecycle for enhanced visibility and traceability, including metadata about .NET binaries. SQL Server Modeling Services CLR domain provides the model schema for .NET Common Language Runtime (CLR), with an assembly loader tool that can load the metadata from .NET assemblies and executables into the SQL Server Modeling Services database. Many modern applications are multi-tiered, distributed, and complex in nature. SQL Server Modeling Services can store the metadata about assemblies involved in these applications into a central database. This database provides a more all-encompassing view over the code assets that make up IT systems in large enterprises. 

Q.  How does the System.Runtime domain in SQL Server Modeling Services relate to Architecture Explorer and Code Analysis in Visual Studio 2010?

A.  In Visual Studio 2010, there is no direct relationship between the VS Architecture Explorer and SQL Server Modeling Services. SQL Server Modeling Services provides the infrastructure for storing application metadata across the lifecycle. Tools such as Visual Studio Architecture Explorer and Code Analysis increase developer productivity by enabling them to understand the code and the relationships between them better. In a future release, a SQL Server Modeling Services provider in VS Architecture Explorer can potentially be added to enable developers and architects to browse and explore shared metadata available in the SQL Server Modeling Services database.

Just like code analysis rules can be created in VS for developers to validate their code, System.Runtime “cop” rules can be defined over the System.Runtime metadata in the database to flag applications that fail certain enterprise policies.

Q. Can third parties create additional models in the SQL Server Modeling Services database? How can these models be linked to existing models in the Repository?

A. Yes, third parties can create additional models in the SQL Server Modeling Services database.

Q. How does SQL Server Modeling Services database relate to Configuration Management Databases (CMDBs)?

A. SQL Server Modeling Services provides the core functionality to implement CMDBs. When combined with discovery agents and associated domains it forms a CMDB. Modeling Services may also be used for other metadata storage purposes (for example, a Software Component Library or Registry).

Q. Specifically, how is application lifecycle management (ALM) being improved by shipping the SQL Server Modeling Services database? What gap or gaps is it filling?

A. The models in the Modeling Services database can be relevant to various development and operations roles in an enterprise – such as technical managers, business analysts, architects, developers, testers and IT Professionals. Currently the knowledge about applications, their relationship to business and their deployment artifacts are spread out over several SCM systems. Having the entire definition of an application and its related metadata in a database provides knowledge management and business intelligence within the enterprise. Modeling Services database captures, manages, and provides access to enterprise knowledge to tools and people in an organization.

Q. How do I use SQL Server Modeling Services with an existing application or database? Most applications are not built from scratch.

A. Many different types of software artifacts are created and consumed during a software development, deployment and servicing lifecycle. SQL Server Modeling Services stores metadata about your applications in a central store, so that it can be accessed, identified and retrieved quickly when needed. Timely retrieval can be difficult when all these artifacts are stored in multiple different repositories and databases. Since the Modeling Services database is a SQL Server database, it is easy to get at your metadata and models, and it is easy to build tools on top of that database. Using SQL Server Modeling CTP, the model schemas can be designed using the database schema authoring languages such as EDM and “M” that provide increased productivity over the data modeling techniques such as T-SQL. Developers can program against the Repository via SQL Server ADO.NET, Entity Framework (EF) and Data Services REST-based interfaces.

Q. How does SQL Server Modeling Services support versioning of metadata?

A. Repository supports versioning of schema as well as data.  More information is available on the following MSDN page:  http://msdn.microsoft.com/en-us/library/dd129565(VS.85).aspx

Q. What is SQL Server Modeling Services and how will it be leveraged?

A. SQL Server Modeling Services delivers a platform to manage application metadata. Built on SQL Server 2008, these services provide a common set of features that enable model-driven applications to leverage a platform investment made by Microsoft.

SQL Server Modeling Services builds naturally upon the SQL Server database and provides optimizations for storing and sharing models. Customers can thus easily leverage the existing SQL Server database ecosystem (e.g. tools, reporting, Business Intelligence, etc). Modeling Services manages end-to-end system models across the lifecycle, including support for both design and run-time views of application metadata. Pre-built models will be delivered as a starting point for building your full application, with extensibility points so that your models can be augmented as needed.

Q. Which version of SQL Server do you support and which form factors?

A. SQL Server Modeling Services makes intensive use of the latest capabilities of SQL Server. We do, however, support all editions of SQL Server, except for SQL Server Compact.

Q. What benefit will SQL Server Modeling Services bring to customers?

A. SQL Server Modeling services helps customers focus on solutions rather than the infrastructure. IT Operations also benefit from storing groups of related information together in the Modeling Services database. With Modeling Services shared models, the tools can continue to provide right level of abstraction for their respective users while using a shared metadata store as the bridge. This allows stakeholders to have access to current, accurate and appropriate representations of the organization’s systems expressed and visualized in languages/tools with which each is familiar. Further uses on top of this metadata are possible which provide direct benefit to our customers:

• Impact analysis, forensic analysis and traceability
• Change management, reuse and governance
• Knowledge management
• Business Intelligence

Q. What’s special about a centralized database as used in SQL Server Modeling Services? Why isn’t this just another database?

A. Every database application is designed with a set of performance, scale, access, and extensibility characteristics in mind. The SQL Server Modeling Services “repository” is just a database, that’s true, but it’s a database that’s been designed to scale from the special usage characteristics of a multi-user, collaborative development environment to the management needs of a model-driven application.

It seems improbable that one database can scale that entire range. That’s where the “M” tools come in. Using the “M” compiler, domain model designers can “link in” the set of runtime services that make sense for that application at runtime. The modeler chooses the set of features that make sense for his or her application domain. For example, it may be important for a model to support highly-scalable identifiers. Another model may prefer the transportability of GUIDs. The set of design-time services, domain models, and runtime “libraries” and services together comprise the SQL Server Modeling Services.

Q. What kind of data lives in the SQL Server Modeling Services database?

A. The first pre-built models that will be delivered with SQL Server Modeling Services are used to design, configure, deploy, execute, and manage applications for web, web services, and data domains. The repository will contain your application definition along with the related deployment and configuration information. As you evolve the design of your application, the Modeling Services database will enable you to track and manage changes to your application.

Q. Is the SQL Server Modeling Services database a single store for Microsoft or are there multiple? Who else is going to use it and how? Will I have to license something new to use it?

A. It’s too early to talk about any specific packaging or licensing details. However, we believe there does need to be a unified approach to managing metadata across Microsoft, and are actively working towards aligning our product visions and roadmaps across products to leverage a common repository solution. Having a common approach does not necessarily correlate to one physical store, but more of a federated model.

Q. Is there only one SQL Server Modeling Services database in an enterprise?

A. No. We expect your organizations to isolate development environments, test environments, and runtime environments. Likewise, you may have repositories for your development organizations. Applications built in a development organization can be deployed into test and runtime repositories using tools provided by the “M” toolkit or SQL Server tools such as SQL Server Integration Services (SSIS).

Q. Will I be able to store some parts of my application elsewhere? What data do you foresee not being in the metadata store?

A. Not everything will be in the repository. Much of your application will be referenced from it, and implemented in code managed by Microsoft Team Foundation Server (TFS), just like today. Documents may be on a project portal built on SharePoint. As our metadata roadmap evolves over time, we will work to help align and unify the metadata store, configuration management databases (CMDB), and TFS to provide a unified customer experience.

Q. What if my application metadata already exists in another database?

A. You can certainly leave the metadata where it is. However if you want easy querying across all the metadata in the SQL Server Modeling services repository and your application’s metadata you will either have to migrate the application’s metadata to the repository, or periodically copy it to the repository. This is not dissimilar to data warehousing techniques used today.

Q. Do applications share repositories?

A. SQL Server Modeling Services leverages SQL Server's advanced change tracking and management facilities, as well as a claims-based security model that lets you set policy for who can see, use, or modify an application. During application development, there is added benefit to organizations that share components, designs, and specifications, and we recommend that development organizations create team repositories for exchanging applications and components.

You may make different decisions for your runtime repositories. The most secure, reliable performance can be achieved by running each application from its own repository. The cost is primarily an administration and maintenance cost. Over time we will recommend best-practices for different application profiles. At this time it is too early for Microsoft to make a recommendation.

Q. Who can access my application data in the repository?

A. Your organization can set access policies for data in the repository, in the same way that you set access to any of your corporate databases.

Q. Is the repository database secure?

A. Yes. Moreover the repository database allows a finer grained security model than SQL Server’s standard model. This allows repository administrators and runtimes to apply the principal of least privilege.

Q. What role does SQL Server Modeling Services play in model-driven engineering/architecture (MDE/MDA)?

A. In model-driven architecture approach to software development, there are multiple layers of software application abstractions including Platform Independent Model (PIM), Platform Specific Model (PSM) and Code.   Modeling Services provide a store for models, including models used in MDD. Modeling Services database allows more value to accrue to MDD because it makes it easy to query and report on enterprise wide MDD assets as well as other metadata like service configurations.

Q. What role does SQL Server Modeling Services play in domain-driven design (DDD)?

A. Domain driven design is an approach to software design.  It encourages careful upfront thinking about the domain and a certain architectural pattern the ADO.NET Entity Framework (EF) promotes.  The basic idea behind a domain in DDD is to group together business knowledge of an application and separate it from the application and its infrastructure.  A UML class model, an Entity Relationship (ER) diagram, an Entity Data Model (EDM) or a Class Responsibility Collaborator (CRC) models can be used to represent the domain model.  Modeling Services provide a model store for UML models.   Customers and our ISV partners can create other model schemas and add to the models in Modeling Services infrastructure. 

Q. You mention that SQL Server Modeling Services is a SQL role for secure sharing of “models” between application and systems. To many, modeling means raising the level of abstraction and not tying the models with the database. How do SQL Server Modeling Services provide separation between conceptual, logical and physical models?

A. There seems to be confusion between implementation technology of Modeling Services and what you can store in it. With Modeling Services, customers are free to add a variety of conceptual, logical and physical models to the Modeling Services store.  Microsoft will supply many of them. The infrastructure for storing models needs to be well defined in order to facilitate tools and easy integration of models.  Customers and our ISV partners can add to a wide variety of models in this infrastructure.  

Q. Who is target customer for SQL Server Modeling Services database?

A. Anyone who needs a store for metadata that could benefit from integration with other metadata in the enterprise. Few concrete applications of SQL Server Modeling Services database include Configuration Management Databases (CMDBs), Registries (UDDI, WS-Discovery) and Master Data Management (MDM).