"MService": Part II
One thing I want to make clear, especially to people new to "M", the MService example I showed in my first post uses a database to store all values.
In fact the exact SQL for the People extent is below.
There is no O/R mapping to write. There is no O/X mapping to write (notice that we are using “M” on the wire).
As I said previously, our hope is that we can build a language and associated set of runtimes that we can use to ensure that application developers can focus on the domain.
To make that concrete: less time on mappings/transformations and repeating validation rules – more time on business problems and (hopefully) your friends/family.
This is the number one thing I don’t understand right now about Oslo. The database you are talking about there is the repository, right? So, are we going to save all our data in the repository from now on? In all the exmaples I have seen so fare the repository in the end was not only used for meta data type stuff, but for the actual user data as well.
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.
davidacoder
21 Mar 09 at 13:15
@davidacoder
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.
douglasp
22 Mar 09 at 01:36
Thanks, this helps a lot and I think a top level post would be terrific. I have quite a lot of questions/comments on that scenario, but I’ll keep them for the top level posting. I think a key issue for me that I would like to see some guidance on is the relationship to Entities Framework, with the info you just provided it seems to me that Oslo might be a complete superset, and one could just drop entities entirely.
davidacoder
23 Mar 09 at 13:11
This is very nice! After reading your post and seeing your MIX video I still have some question. What is the goal you have with MService?
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?
Rick
25 Mar 09 at 15:21
Ideally, both.
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.
douglasp
25 Mar 09 at 17:24
[...] Prereading: Part I, Part II [...]
“MService”: Part III at Douglas Purdy
30 Mar 09 at 02:28