De DSL Tools a Oslo

Moving to English this page is a hard work for me. It will be done, but, in the meantime, use Google for a basic translation.

A partir de Visual Studio 2005, Microsoft presenta sus DSL Tools, incluída en el paquete de Visual Studio Team System. DSL Tools es una herramienta inscripta en el concepto de lenguajes específicos de dominio. Con ellas Microsoft propone por primera vez una capa de abstracción como auxilio en la generación de aplicaciones, muy asociada a la idea que en ese momento sostenía de Factorías de Software. Su propósito fue el de utilizar un lenguaje específico del dominio para realizar una tarea en el alcance de un determinado problema; construir a medida herramientas de modelado para un propósito definido, de tal forma de aprovechar la estrecha proximidad entre el dominio y el lenguaje, en lugar de recurrir a lenguajes genéricos, difíciles de adaptar a ambientes muy delimitados. Valen para esta idea las observaciones que se hagan en general sobre DSL/DSM, tratados en otra parte. En ese momento, estas herramientas eran defendidas como una salida contradictoria y superior al estandar MDA y otros de diseño orientado por modelos de tipo general, particularmente a aquellos soportados sobre UML.

Sin embargo, a partir de octubre de 2008, Microsoft comienza a difundir una nueva orientación, que parece reconocer el limitado alcance de su iniciativa anterior. Por primera vez se habla del proyecto Oslo, y se dan a conocer algunos adelantos de sus objetivos. Oslo es presentado como el unificador de las tecnologías de modelado de Microsoft, y por primera vez se habla de la integración de UML. En su revisión temprana, tan pronto como el proyecto fuera anunciado, David Chappell lo presentaba así:

A group of technologies, codenamed “Oslo”, aimed at creating and running model-driven applications and more. The “Oslo” technologies include a repository, providing a common place to store a range of information about your IT environment; a modeling language family, codenamed “M”, for describing that information; and a modeling tool, codenamed Visual Studio “Quadrant”, for working with repository information. [...] A primary goal of “Oslo” is to make models a fundamental part of how applications are created, deployed, and managed. In “Oslo”, a model is an abstract representation of something, such as a business process, an application, or a workflow. (Don’t confuse this use of “model” with how the term is used in other contexts, such as the Unified Modeling Language—it’s not quite the same idea.) Rather than limiting models to descriptive diagrams used solely during the design process, “Oslo” can allow a model to be part of the application itself. For example, a WF workflow can be created using “Quadrant” and stored in the repository. This workflow is a model—it’s in the repository—but it’s also the actual logic of the workflow. Changing the model means changing the workflow itself, which means that the model and this part of the application can’t get out of sync. The “Oslo” repository can hold models for more than applications, of course, and parts of an application might still reside outside of the repository. Still, the idea of moving models from just describing an application to actually being the application is fundamental to “Oslo”.

A un año completo de su presentación, Oslo todavía es un proyecto en curso, sin fecha oficial de lanzamiento, aunque ha hecho progresos en su definición y alcance. Desde el inicio, algunos aspectos han variado, y otros se han incorporado. Oslo representa el primer intento reciente de Microsoft de apoyar sus herramientas de desarrollo en un marco que permita un mayor grado de abstracción y generalización en la construcción de aplicaciones

En su versión temprana, el proyecto Oslo era definido como una plataforma de modelado, compuesta de varios elementos, y compartiendo intereses con otros proyectos de Microsoft: tempranamente se habló de puntos de contacto entre Windows Workflow Foundation, Dublin, y Oslo (1), pero especialmente se habló de Oslo como una herramienta para la generación de aplicaciones orientadas a servicios (SOA). A lo largo del año transcurrido desde su lanzamiento público , esto ha sufrido algunos cambios, pasándose a poner el acento más en la función de modelado de aplicaciones, para luego abrir su construcción al diseño o manejo de datos (2).

Teniendo en cuenta que se trata de un proyecto en curso, como lo demuestra la incorporación de nuevos aspectos a su definición, y que aún no tiene fecha de lanzamiento, sin embargo tres elementos se han mantenido constantes como partes del proyecto:

Los objetivos de Oslo, el papel del modelado y la abstracción en la construcción de aplicaciones

Tomado de la documentación provisoria de Oslo:

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. (3)

Models are representations of some idea or thing that is used as a tool to interact with that thing efficiently and quickly. In code name “Oslo” modeling technologies, the word model refers to the data structures (also called model schemas) described by a SQL schema in the code name “Oslo” repository. The act of creating new applications creates instances (called model instances) of these “Oslo” repository model schemas. The instance-specific data is stored in the “Oslo” repository as row data in the appropriate tables.(4)

Actualización a noviembre de 2009

El 10 de noviembre de 2009, Douglas Purdy debió salir a declarar un nuevo cambio en los planes de Oslo, que practicamente representa la declaración de defunción del proyecto: en su artículo From “Oslo” to SQL Server Modeling, Purdy declara que el proyecto Oslo pasa a ser definitivamente parte del ambiente de modelado de SQL Server:

Of the key things we observed over the last year was the real, tangible customer value in applying “Oslo” to working with SQL Server. Time after time we heard that “M” would make interacting with the database easier, provided we offered a good end to end experience with tools (VS) and frameworks (Entity Framework and Data Services) that developers use today. We heard that developers wanted to use the novel data navigation/editing approach offered by “Quadrant” to access their data in whatever SQL Server they wanted, not just the “Repository”. We heard that the notion of a “Repository” as something other than SQL Server was getting in the way of our conversations with customers.
Another thing we learned was that most of the customers that we wanted to leverage the modeling platform were already using SQL Server as their “repository”. Take an application like SharePoint. It is already model-driven. It already stores its application definition in a database. Dynamics is the same way. Windows Azure is the same way. System Center is the same way. What we didn’t have was a common language, tools or models that spanned all of these applications, although they were all leveraging the same database runtime. The simplest path to get all of these customers sharing a common modeling platform seemed obvious.
Lastly, we learned that the folks on the SQL Server team were hearing the need for additional mechanisms to make the database more approachable to developers. Developers did not want use three different languages to build their database applications (T-SQL, a .NET language and a XML mapping file). Developers wanted new tools that let them deal with the truly massive amount of data they need to handle on a daily basis. Developers wanted to radically simplify their interactions with the database, with a straightforward way of writing down data and getting an application as quickly as possible.

Así, la redefinición de Oslo reduce su alcance a una herramienta de propósito específico, con el agravante de "caer" a SQL Server por descarte, sin haber nacido de planes para el producto. La nueva definición de Oslo reduce a ésto sus componentes:

The components of the SQL Server Modeling CTP are:
* “M” is a highly productive, developer friendly, textual language for defining schemas, queries, values, functions and DSLs for SQL Server databases
* “Quadrant” is a customizable tool for interacting with large datasets stored in SQL Server databases
* “Repository” is a SQL Server role for the the secure sharing of models between applications and systems

We will announce the official names for these components as we land them, but the key thing is that all of these components are now part of SQL Server and will ship with a future release of that product.
At PDC, we will unify the “Oslo” Developer Center and the Data Developer Center. You will be able to find the new SQL Server Modeling CTP at our new home (http://msdn.microsoft.com/data) the first day of PDC.

Este nuevo alcance en general quita a Oslo del grupo de herramientas que aquí se mencionan. La misma evolución del proyecto pone dudas incluso sobre su permanencia en el Data Development Center,área de destino según Purdy .


(1) "Creating Modern Applications: Workflows, Services, and Models", David Chappell, Chappell & Associates, Octubre 2008, Microsoft.

(2) "Darryl Taft reveals that Microsoft has been shifting Oslo, originally intended to support SOA development, toward the database. He quotes Microsoft engineer Doug Purdy, who admits that the reference to Oslo as a new version of BizTalk “really confused customers.” He adds that “We started using the term ‘Oslo’ for only the modeling platform pieces of the overall vision.” [...] Purdy notes that over the past year, “it has become increasing clear to us that the modeling platform is aligned in a deep and fundamental way with the data programmability stack (ADO.NET, EF/EDM, [Entity Framework/Entity Data Model] Astoria, etc.).” As a result, the focus of Oslo has shifted to the database, emphasizing its role of supporting metadata stored within the database. For this reason Microsoft has decided to merge Oslo with its Data Programmability team, which includes EDM, EDM, EF, Astoria, XML, ADO.NET, and tools and designers." En ZDNet, "Microsoft Oslo shifting to the data side", Joe McKendrick, 18 de agosto 2009.
(3) "Oslo and Model-Driven Applications", documentación pre-release.
(4) "Building Applications in Oslo", documentación pre-release.