Oslo models - really executable?

Question

In the documentation of Oslo you read a lot about this vision that ...

- Oslo models are actually executable and help to reduce the amount of code,
- the declarative approach of DSLs are better than general purpose code which tends to be opaque

This is an honorable goal, however I don't right get it how Oslo could change this :)

It's true: Oslo made it a lot easier to write DSLs, the repository is a great idea to keep all models in a versioned, synchronized, common database. Quadrant is a great extensible tool to visualize these models.

So far, so good.

But at the end, we almost always need some behavior that determines what to do with these models. It's NOT always about data only. And when you look at the existing Oslo examples out there, most of them have some backing-code (and often not little) to consume the models and interpret it.

So we end up writing this very evil, non-declarative C# or VB code again :)


Don't get me wrong, I really like Oslo and I'm excited where the journey goes - It's just when reading the documentation around Oslo I sometimes feel that it wants to make believe us that Oslo would magically eliminate the need of traditional, general-purpose languages.
For me, it's natural that you need to write some amount of code to consume the models. A pure data model describing some domain does never make up the application alone, it's not executable by itself. I don't even expect this from a modeling platform, this would be illusionary.

Oslo will surely ease the development of models and the ability to keep them in sync during the development process, but models for itself do not make up an application, do they?

Again, maybe it's just my personal impression that Oslo wants to tell us something else. Or maybe I just don't understand the big picture yet. :)


Edit:
For example, I don't understand this sentence (taken from http://msdn.microsoft.com/en-us/library/dd129513(VS.85).aspx) :

"An “Oslo” model is not limited to abstractions, however its ultimate purpose is to solve a problem or implement a process, not just to characterize it. You can use an “Oslo” model not only to define the business process in an abstract sense, but also to define how to execute that process."

How could I use an "Oslo" model to define how to execute a process? From my understanding, an (instance) model contains just the plain data describing our domain, e.g. a collection of tasks of a Workflow Activity. Do you mean by "to define how to execute that process" to provide additional meta information, telling for example a Workflow engine how to execute it?

Answer 1

Definitely good questions, but I was hoping for someone else to give you a more official answer but I'll try to give you something at least. Maybe this response will spark more answers.

It sounds to me like you're asking how you actually specify the business logic in addition to the data? The first example that comes to mind is validation. Suppose you have some Employee entities with Salary as one of the data points and you want to implement some type of rule that says no employee's salary can be greater than their boss's salary.

So I think one way to look at things is to view the data in the repository as the definition of the application. In this case your runtime would be able to read the repository to create the Employee but part of that runtime might be a "SalaryIsLessThanBossRule". In that case you would declare, as part of the employee, that this is one of the validation rules it must adhere to (however you want to do that). If you wanted custom rules your runtime would probably have to have a mechanism for allowing you to "plug-in" custom rules.

So I think the answer is to say that the actual logic, the executable code, is all part of the application runtime. Which is completely abstract intentionally, then your modelling declares which parts of the logic are appropriate for which models. Does that make sense? You're heavily dependent upon the runtime being flexible enough to handle all you want to do but you really only need to do that once. Then your infinitley varied applications are simply all about modeling.

Answer 2

Sly, this is a good question. You definately can't have an "executable model" unless there's a runtime to execute it. Such a runtime is meant to read data from a database (either an Oslo Repository or something else) and produce behavior based on that data, e.g. your average CRM application. You're right, also, that we don't ship any runtimes with the current Oslo SDK. However, we have been building some sample runtimes, e.g. Spork, Wix, PhotoStore, the Event Pattern Mesh, etc. We're also building some others that we plan on showing off as soon as they're ready.

Ultimately I'd love it if Oslo was just the core set of capabilities for a rich set of model-driven application domains, like the CLR is the core of .NET. People hardly ever think of the CLR at all -- it's just the thing that makes ASP.NET, WPF and web services work. If Oslo ends up just being a thing that makes your client applications and services work, that's a very good place for us to be.

Answer 3

Thanks for your answers.

I get your point. Just some more thoughts...

You're right, also, that we don't ship any runtimes with the current Oslo SDK. However, we have been building some sample runtimes, e.g. Spork, Wix, PhotoStore, the Event Pattern Mesh, etc. We're also building some others that we plan on showing off as soon as they're ready.

I have some concerns that, at the end, we have hundreds of different runtimes for all our custom DSLs...isn't that a drawback of DSLs in general?

Answer 4

The idea of runtimes is that they implement not a single application, but a potentially broad class of applications. In other words, if I was to go to all the trouble of creating models and whatnot, then implement a "runtime" that only produces a single application, how is that different from any other stock data-driven application of today? It's not, and frankly I wouldn't see much benefit to trying to break everything up and complicate the whole build process; I'd just implement the single application in .NET and be done with it.

But when a runtime can support a class of applications, by offering a more generic set of abstractions in which many different (but similar, obviously) applications can be defined, then there's a definite benefit to writing that runtime such that the specific applications can be written much more quickly than building each one from scratch. It's the same thing as what's going on in the M toolchain, that most of the work of creating a language/parser/compiler is universalized and need only be "configured" with a grammar. The M toolchain has, in other words, already taken are of 90% of the effort of creating a language. I see that when there are good runtimes available, they too will eliminate 90% of the effort needed to write applications in their respective classes, thereby delivering on the "Oslo's" promise of 10x productivity gain.

This means, of course, that people have to develop suitably abstract runtimes; as Chris said, more are in the works.

Now with all this in mind, there can be many DSLs that all feed into models that are then executed by a single runtime; given any single set of models, any number of DSLs can be written to populate instances of those models. Thus, there is more of a a many-to-one relationship between DSLs and runtimes, not a one-to-one as your post implied. Writing a DSL does not mean writing a specific runtime for it: you write a DSL against a particular set of models, not against a runtime that happns to understand those models.

Admittedly, all of this really doesn't come out clearly in the current sample set, because really, to build a real runtime means to build an application development framework rather than just a single application. The Spork sample is really the closest thing we have, because it's runtime is meant to be a generic text-adventure engine. And its DSL, "Visual Basic for Adventures" is just one potentual language that can be used to populate model instances that the engine would consume.

Again, at this stage in "Oslo's" development we don't have any full commercial-quality runtimes out there with which one can start cranking out applications at a rapid pace. That's really the big need/opportunity of the moment and yes, those who write these runtimes will be using C#, VB, etc. But once they've made that effort, anyone that comes along and creates models for those runtimes to consume will not need to go into traditional coding at all, and will stay entirely within the context of a DSL.

By the way, thanks for this and all your other posts, slyVx. That you take the time to work through these questions really helps us direct our ongoing efforts to explain "Oslo" more clearly.

.Kraig

Answer 5

Hi Kraig,

I discovered your answer just now because I've not been around here for a while.

I just wanted to say this was probably the best explanation regarding Olso's notion of DSLs and their relation to runtimes. It really made it clearer to me.

You guys should include something similar like this in the Olso documentation :)

Answer 6

I'm delighted to hear that! Thank you for your kind words. And yes, I work closely with our documentation folks, and as things keep getting clearer for all of us we keep improving the docs.

.Kraig