[This is prerelease documentation and is subject to change in future releases. Blank topics are included as placeholders.]
This topic describes the goals and basic features of code name “Oslo” modeling technologies, which use modeling techniques to make it possible to build .NET applications that are easier to design, develop, use, and manage.
Microsoft has worked hard to create tools such as Visual Studio, ASP.NET, and the .NET Framework to make it easier to build and deploy advanced applications, especially enterprise-scale, distributed applications that are heavily dependent upon high volume and robust data access. With these tools, businesses have built powerful applications that provide more data and features of more importance to more internal and external customers than ever before.
Of course, the ambition and vision of these applications has brought increasing development and management challenges. The complexity of design, development, and management is costly, and requires a high degree of diligence, knowledge, and experience. In response, new development and management methodologies have endeavored to address the weaknesses of earlier processes, always seeking to shorten development time and increase the robustness of complex applications. Tools and technologies such as XML, .NET managed code, .NET attributes, and XAML make it possible to describe—which is to say, model—not only data but also programmatic behavior. By modeling behavior with such metadata, much of the tedious and repetitive code is essentially universalized by an application runtime that understands how to dynamically configure itself with those models.
Indeed, this is the function that configuration files and scripts have served for many years. Such ad-hoc solutions, however, have generally been very application-specific and tend to break down as the scale of an application expands. In addition, they are usually limited to only one segment of the whole application lifecycle: implementation, or perhaps management. As such, many approaches to modeling have not really addressed the communication breakdowns that occur between those who understand the intent of the software, those who build it, and those who deploy, manage, and version it. Versioning, deployment, and management of widely distributed applications remain an extremely difficult set of tasks.
The most successful strategies, tactics, and technologies for modeling, on the other hand, help to address the problems of communication, scale, and both development and management productivity by creating a higher and more efficient level of abstraction that:
- Places control in the tool or language that is easier and less costly to use because it is closer to the mental world of the users that need to manage their complexity more efficiently. Development managers, for example, no longer need to review all source code to know what changed in the previous day or week; they can use Visual Studio Team System to see where any code changed across an entire product or multiple products.
- Builds more knowledge of specific problems into a configurable runtime that addresses it, removing the need for someone to build, and often rebuild, custom one-off solutions by hand, with both the associated possibility of inevitable defects and the ongoing cost of maintenance.
The Microsoft code name “Oslo” modeling technologies are the next iteration of this cycle; “Oslo” raises the level of abstraction more than ever, seeking again to dramatically improve developer and data management productivity.
The “Oslo” modeling technologies include:
- A storage runtime (the code name “Oslo” repository, built on SQL Server 2008) that is highly optimized to provide your data schemas and instances with system-provided best SQL Server practices for scalability, availability, security, versioning, change tracking, and localization.
- A configurable visual tool (Microsoft code name “Quadrant”) that enables you and your customers to interact with the data schemas and instances in exactly the way that is clearest to you and to them. That is, instead of having to look at data in terms of tables and rows, “Quadrant” allows every user to configure its views to naturally reveal the full richness of the higher-level relationships within that data.
- A language (Microsoft code name “M”) with features that enable you to model (or describe) your data structures, data instances, and data environment (such as storage, security, and versioning) in an interoperable way. It also offers simple yet powerful services to create new languages or transformations that are even more specific to the critical needs of your domain. This allows .NET Framework runtimes and applications to execute more of the described intent of the developer or architect while removing much of the coding and recoding necessary to enable it.
Understanding Model-Driven Development
Model-driven development in the context of “Oslo” indicates a development process that revolves around building applications primarily through metadata. This means moving more of the definition of an application out of the world of code and into the world of data, where the developer’s original intent is increasingly transparent to both the platform (and other developers). As data, the application definition can be easily viewed and quickly edited in a variety of forms, and even queried, making all the design and implementation details that much more accessible.
As discussed in this topic already, Microsoft technologies have been moving in this direction for many years; things like COM type libraries, .NET Framework metadata attributes, and XAML have all moved increasingly toward declaring one’s intentions directly as data—in ways that make sense for your problem domain—and away from encoding them into a lower-level form, such as x86 or .NET intermediate language (IL) instructions. This is what the code name “Oslo” modeling technologies are all about.
For more information about model-driven development, see Building Applications in "Oslo".
Modeled Applications and Runtimes
Modeled applications and runtimes are data-driven applications and runtimes. But whereas the phrase “data-driven” implies the use of data as the driving mechanism, a model-driven application is one in which the data is exposed and consumed as models, highly structured, interoperable data. Furthermore, while we often described the use to which data is put with the words “application state” data or “metadata,” in truth data is data. Application and state data (as well as metadata about both that application and its state data) can be equally stored, queried, and often executed by runtimes.
That said, some data is relevant only to a small part of the entire application lifecycle. Models, on the other hand, especially in “Oslo”, are relevant to the entire application lifecycle. The term “model-driven” in this documentation, then, implies a level of intent and longevity for the data in question, a level of conscious design that bridges the gaps between design, development, deployment, and versioning.
The “M” Language and Features
Use the "M" language and its features to define custom languages, schema for data (data models), and data values. Doing so brings the meaning of the code you write closer to your own domain of experience. With more of your own intent encoded in models, it becomes easier for you—and other developers working with your domain—to write code and applications faster.
- You can use the schema (or model) definition feature of “M” to design interoperable models—data schemas—for the data in your particular field of interest (called a domain). Using the schema definition feature makes statements about the structure, constraints, and relationships, but says nothing about how the data is stored or accessed, or about what specific values an instance might contain. By default, “M” models are stored in the “Oslo” repository, but you are free to modify the output to any storage or access format. If you are familiar with XML, the schema definition feature is like XSD.
- You can also use the value definition feature of “M” to create model (that is, schema) instances of your data structures. The value features make statements about the data values that are to populate instances of the models you or others have created, but again, interoperability is maintained. While the default compilation output can be inserted into SQL Server 2008 or into the “Oslo” repository, you can transform the output into any format you need to support your scenario. If you are familiar with XML, defining values is like creating an XML file that conforms to an XSD file.
- You use the language definition feature to create new, custom languages (sometimes called domain-specific languages, or DSLs) for your own domain of expertise that you control, without having to build a parser, lexer, or any other supporting infrastructure. Building a custom language makes it vastly simpler for you or your customers to express their specific desires, dramatically lowering the barrier to using your particular domains and applications built on them.
- By default, the output of “M” is either T-SQL that can be inserted in any SQL Server 2008 database, or a more customized version that takes advantage of the advanced features of the “Oslo” repository, such as security, versioning, change tracking, and so on. However, “M” languages are extensible and can output any specific format you care to implement. Model-driven applications must be interoperable, and where they interoperate depends upon your circumstances, requirements, and resources.
The “Quadrant” Model Editor
Microsoft "Quadrant" is a graphic tool for viewing, editing and exploring data found in any SQL Server database. A user can open multiple windows (called workpads) in “Quadrant”. Each workpad can contain a connection to a different database, or a different view of the same database. Each workpad also includes a query box in which users can modify the data to a single record or a set of records that match the query criteria.
“Quadrant” features a different way of visualizing data: along with simple list views and table views, data can be displayed in a tree view, in a properties view, and in variable combinations of these four basic views. An essential part of this is the ability to dynamically switch, at any time, between the simplest and the most complex views of the data. As you explore data with these views, insights and connections between data sets previously unknown may become apparent. And that has benefits for those using the Microsoft “Oslo” modeling technologies to create new models. As part of the “Oslo” modeling technologies toolset, “Quadrant” enables “Oslo” developers to view new models with “Quadrant” viewers. The “Quadrant” data viewing experience enables designers of DSLs to quickly visualize the objects that language users will work with. In this way, “Quadrant”will give developers a quick vision of their models. With this feedback, “Quadrant” can also provide a reality check for the model designer, which may in turn lead to better data structures and models.
The “Oslo” Repository
The "Oslo" Repository provides a robust, enterprise-ready storage location for the data models. It takes advantage of the best features of SQL Server 2008 to deliver on critical areas such as scalability, security, and performance. The “Oslo” repository's Base Domain Library (BDL) provides infrastructure and services, simplifying the task of creating and managing enterprise-scale databases. The repository provides the foundation for productively building models and model-driven applications with code name “Oslo” modeling technologies.
“Oslo”-Provided Domains and Models
The power and flexibility of a model-based development platform increases tremendously each time more of the models you need and want to use become available. The code name “Oslo” repository comes with a set of domain models written in the Microsoft code name “M” modeling language that is organized into modules (similar to namespaces in other languages). These help domain and model developers understand where to find models that either represent specific functionality or that you can use to create new models for your functionality. For more information about the domains and models that come with “Oslo” modeling technologies, see "Oslo"-Provided Domains.