MSDN Magazine - February 2009 - (Page 64)

Metadata What makes metadata distinct from your application data is that the metadata for an application seldom changes—it’s typically something that even in the wildest startups only changes once a day when a new version of a Web site is pushed live. On the other hand, the data for an application often changes quite a lot—it’s what users are manipulating all day, every day on a popular Web site. Taking this further, the metadata that describes the word processor I’m using to type this article hasn’t changed since 2007 when Metadata is written so seldom that in many cases it’s delivered in read-only packages. it was released, but the data has changed thousands of times just today as I type characters and move the mouse to manipulate the documents I’m working on. In fact, metadata is written so seldom that in many cases it’s delivered in read-only packages, like the class definitions in a .NET assembly or the precompiled XAML files embedded as resources into an assembly. Since developers often write their applications depending on the static nature of metadata, like the event handlers for a button defined in an ASP.NET page, changing an application’s metadata seldomly isn’t a bad thing. However, the thing that is kind of bad about our current metadata infrastructure is that the tools for defining and reading metadata are so different from those you would use for application data. I can develop an application to read and write data via a relational database, giving me a powerful set of tools for things like querying, securing, replicating, and versioning. But if I want to query .NET Framework metadata, I have a much more limited set of tools: the Reflection API, basically. Further, the .NET Framework tools for manipulating metadata are very different from the tools I use to crack open SQL metadata. If I want to query between an application’s data and metadata—query across the workflows currently being executed with the definitions of those workflows—I’ve got to build my own tools because the data sources are different: SQL versus Extensible Object Markup Language (XOML) files. Building on “Oslo” There are many things that you can build with “Oslo.” When we talk about scenarios internally, the discussion often boils down to building applications that involve data. However, you’ll notice that in the set of things that I listed as part of “Olso” I didn’t mention any runtimes. In fact, .aspx files aren’t too useful without ASP.NET, and XOML files without WF would be much less compelling. There are a number of runtimes and services being developed that will take advantage of “Oslo.” These include a new version of ASP.NET supporting the MWeb Domain Specific Language (DSL) and the “Quadrant” Web editor, the “Dublin” Windows Server extensions supporting the “MService” DSL and the “Quadrant” service editor, the Entity Framework supporting the MEntity DSL and the “Quadrant” entity editor, and SQL Server 2008 with the MSchema language (discussed later in this article) and the “Quadrant” schema editor. You’ll be able to load data into the repository and drive those runtimes. The “Oslo” repository is geared toward apps where enterprise developers have built their own repository-like things for storing “Olso”: a New Way to implement an Old idea The idea of data-driven frameworks is nothing new. Consider another example: Windows Presentation Foundation (WPF). The way most WPF applications are written, much of the application is composed of XAML, which is loaded at run time and interpreted by the XAML parser. This is the metadata that drives the definition of a WPF application. You can even change the definition of a WPF application by loading or generating XAML at run time that the developer didn’t know about at compile time. However, there’s nothing magical about the XAML (compiled into a form known as BAML) being bundled into a resource with your application code—it could as easily be loaded into a separate file or even into a relational database. If it were loaded into a database, the WPF loader would perform SQL queries to access application definitions instead of loading resources, but the user would otherwise be unaware of the difference. And if an application definition would loaded from a database, all of that data could be updated centrally, giving the developers of the application the ability to propagate changes without re-deploying the application to every client that wanted to run it. This is, in fact, the killer feature of the Web and one worth driving towards for all kinds of applications, whether they run in the browser or not. Now, as soon as you load an application into a central location, you’re going to want multi-user features such as replication, securit,y and versioning. You’ll also want support for disconnected users and for users in different locales around the world. And finally, application definitions can be used for more than just driving an instance of an application. They can be used at development time to test whether particular parts of an application are running according to specifications. They can be used at run time to show what parts are getting usage or having trouble. They can be used to tag issues so developers can see specifically what’s causing the trouble. Having an application’s metadata provides all the query power of a modern, indexed, tuned, replicated, secured, versioned, localized, offline-capable database. And that’s essentially what “Oslo” is all about—using the power of SQL Server to store an application’s metadata. Using the metadata to drive the behavior of an application has been used on Windows at least since we started tagging binaries with the console bit to get a console window without writing the code. “Oslo” is simply about formalizing and generalizing the metadata of your application and providing the same power and tools used for the data of your applications. “Oslo” Basics 64 msdn magazine

Table of Contents Feed for the Digital Edition of MSDN Magazine - February 2009

MSDN Magazine - February 2009 Contents Toolbox CLR Inside Out Data Points Cutting Edge Patterns In Practice Best Practices .Net Interop "Oslo" Basics Patterns Silverlight Under The Table Foundations Windows With C++ .NET Matters Going Places { End Bracket }

MSDN Magazine - February 2009

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.