Douglas Purdy

JJD responded.  I’ll do the same.

Productivity

I think we are really talking past each other here.  “Oslo” is just as valuable as an approach in the cloud as on-premise.  In fact, the nice thing about the cloud is that most of the management and some of the application infrastructure is already model-driven, so it makes the adoption easier.

The thing I find most interesting is that you think we are not being ambitious enough.  I think that is the first time that claim as has leveled in our direction.  I don’t know quite how to respond, as our team is often considered much too ambitious.

DSLs

The distinction between vDSL and tDSL is purely stylistic and frankly totally uninteresting.

Perhaps not to you, but this is key value to many customers.  The ability for a user, architect, developer or administrator to view/edit the same data via N pluggable and easily creatable textual or visual projections is a important capability of the system.  How much of an application is actually just providing different representations and transforms over the same data?  In my experience a great deal.  Modulo validation and workflow logic, it may be the big spend across a given application.

If you think you need all this machinery to CRUD or to convert a 3-line code snippet into an HTTP request, that’s quite overkill.

The examples I used at MIX were to make concrete to developers writing REST services some of the benefits of this approach in terms of developer productivity.  I didn’t show how easy it was the manage the service.  I didn’t show how easy it was to design the service, etc.  That was not the goal for this audience.  That said, I think you are seriously downplaying the productivity win for a developer writing and consuming these services.  Go watch the demo and then trying writing the same client and service in C# using the existing frameworks.  It is still early in the development of this particular domain and we have a lot more to flush out, but the results to date are promising.

Which product more than Oslo could afford not to deal with this heterogeneity.

“Oslo” is all about embracing heterogeneity.  We assuming nothing about the underlying runtimes.  In addition, we are doing more to encourage cross-vendor and cross-platform involvement in this approach than anything I have seen, certainly on the language front.  See the “M” Specification Community.

BTW, I am sorry, but I don’t see any hi-REST in the samples that you are providing. Hi-REST involves HATEOAS at a minimum and there is no evidence of HATEOAS in anything that I have seen.

Don defined the term Hi-REST back in 2006.  It did not include HATEOAS.  That said, I am just going to side-step this whole thing – MService is an application of “M” to define HTTP services.

This leads me to a very important point.  MService is actually just “M”.  The thing that provides the “HTTP-ness” is the MService runtime.  The MService runtime is a thin “adapter” over the .Net Framework that binds the data description of the service definition written in “M” to the machinery that does the actual computation.  This is the same architecture as what we use in WF and WCF.  In those frameworks, there is a programming model (CLR types or XAML) that builds an in-memory tree (ServiceDescription in the WCF case and WorkflowDescription in the WF case) that is evaluated by a runtime, respectively.

“Oslo” simply provides languages, tools, and runtimes to make the creation and usage of these programming models and resulting data descriptions more tractable to implementers and certainly more appealing and usable to users (be that end-users, architects, developers or ITPros).  “Oslo” is the logical extension of our work with CLR attributes and XAML.

With that in mind, we need to separate the platform aspect of “Oslo”:  languages, tools, and runtimes for building programming models/data descriptions from the “domains” (Web, Service, Database, …) that leverage these capabilities.

Strictly speaking, “Oslo” says nothing about a particular domain (how to write a service, how to build a Web applications, etc.) will work, save for the domain of writing domains (I hope that is meta enough for you ).

What “Oslo” does do is embrace an approach, provide mechanisms to do enable this approach, and then we work with teams all over Microsoft to get them on board.

Stitching

If you provide a good transformation framework to go from the programming model to these concrete models maybe this approach could yield some benefits. I would like to suggest that it would be better to focus on a "DSL connector framework" that would allow you to deploy a programming model defined and managed by Oslo into a variety of architecture layers. I spoke with Nikhil yesterday who mentioned the "metadata pipeline" in .Net RIA services, I think that this is a very important concept and ultimately you could see some integration points between the pipeline and Oslo.

One of the important aspects of our approach is that runtimes read the data description directly from either the database or some other persistent store (a file for instance).  That is to say, we do not do code generation.  We have found that approach to be very limiting toward our goals and that it ultimately leads to “drift” between the different layers of the system.  That is not to say that you couldn’t do it in our system, but it is not the center of our approach and we try to actively look for ways not to do it.  I need to be careful here, as we do generate SQL and XAML, but that is a one-way transformation, just like a typically compiler, rather than like a round-tripping modeling framework.

I have spoke to Nikhil and others about the metadata pipeline in Alexandria.  The ideal thing for me would be that Alexandria uses “M” for the definition of the business domain, inclusive of business constraints, etc. rather than XAML or CLR attributes.  In addition, there is a huge opportunity for totality of the programming model itself to be described using “Oslo” – and at a much higher level (as you no doubt want).  We have the same set of conversations with lots of other teams in the company.