The thing we didn’t get to show was the invoke syntax for MService. You can invoke whatever logic you want from an M function.

Creating (modelling) simple RESTful services or creating full WCF services with business logic? If it is the last, where do I put those business logic?

I think I will need to write a top level post about this, but here is the nutshell.

A repository is just a database that has domain models in it. Full stop. Those models can apply to any domain: applications, services, web sites (things we are modeling) as well as purchase order, employees, etc (things an enterprise customer would model).

Notice that above a said “A repository”, not “The repository”. There is no “one repository” in our architecture. There lots and lots and lots of them. Just like there are lots and lots of databases.

In terms of metadata, every repository has a collection of tables in it that we call the “catalog”. The catalog is composed of a number of things, but the most important is the M4M models. These models are populated when ever you build a domain model with “M” and load it into the repository (nee database).

This is the information that we use to “drive” our tools (the M compiler, Quadrant) and runtimes (things like MService).

Now we are also providing a number of patterns, tools, etc. that enable us and third parties to configure and use a repository for specific purposes: storing metadata, storing operational data, etc.

In the world of SOA, a repository normally stores metadata about services, etc. That is ABSOLUTELY a use case we are going after, but imagine using that same functionality for your operational databases and application domain, that is also ABSOLUTELY a user case we are going after.

Or, to say it differently, are you planning that Oslo will replace the existing practise of using ADO.Net style data access? Is this the new attempt of WinFS, entity, all new DB stack? Just mightily confused about that.