Where is “Oslo” going?
I was just reading Where is Oslo going? over at ebPML.org.
I normally try to send email when I see posts like these (I have an open email thread with Ayende and Alex, for example) as having a blog conversation is hard and most of the time there is some sort of miscommunication involved, but I think I am going to just start replying with posts, so everyone gets the data.
So let’s talk first on the approach that the Oslo team is taking to drive its direction and requirements. If I understand it correctly, they are using "FTA". … IMHO, it is not a good start.
We are not using FTA to drive anything. FTA was the name of an app that was being built on top of “Oslo” back in the days when “Oslo” == Modeling + WF 4 + what is now Dublin + what is now .Net Services. I should get Adam to take that blog down.
In case you have not noticed MOP has already happened, all the annotations in Java or C# is MOP layered on top of OO. But MOP layered on top of OO does not provide a clean separation between Architecture and Programming Models.
I couldn’t agree more. This is the reason that we are doing “Oslo” in the first place. Having to use CLR attributes in WCF was a painful thing for many us and “Oslo” is largely a logical extension of our work in the space.
It is probably Doug Purdy who is answering these questions.
Nope, but I will take credit for the blah blah blah.
But frankly I am a bit scared by this sentence [“Oslo” will bring together a connected view of today’s models, which are often built in vertical, isolated silos.], MOP is not about stitching together the programming models across the layers of an architecture, MOP is the other way around, it is about creating and deploying a unified programming model onto all the layers of an architecture (whatever this architecture is, SOA, WOA, EDA…).
You are misunderstanding this sentence and it you are forgetting about an important aspect of this technology: managing the application. Applications are in silos today (how do you think about the apps on a box when you are managing them?), the applications themselves are composed of different silos (the presentation silo, the middle-tier silo, the data silo, etc.). Our hope is to make it easier to design, develop and manage the applications across all of these silos. In the limit, we will have a unified model for all aspects of the application. Pragmatically, there are going to be N models (legacy silos, silos that are “opaque”, etc.) and we want to have some level of support for all of these.
Oslo can’t eat its own dog food: "EF and EDM are important technologies for Microsoft. “Oslo” full embraces EF/EDM as a primary mechanism for “Oslo”-based runtimes to access the repository. "
What makes you think this means we don’t eat our own dogfood? We absolutely do. This is statement around how .Net developers can access the models in a repository (which is just a database).
Doug Purdy touts 10X improvement as a great achievement, he obviously has not done any homework on what IT needs and Cloud Computing provides today in terms of a programming model that abstracts architecture and provides already 10X or more
I’ll ask for the data backing this claim. I don’t think I am the one that hasn’t done their homework.
"M lets developers build out domain-specific languages (DSLs) relatively easily" is no longer the problem, Microsoft has DSL tools for that, the question that the Oslo team should ask itself is does M stands for Model or Metamodel?
The current DSL tools (the DSL Toolkit) are for visual DSLs, not for textual DSLs. We want an architecture that supports both both textual and visual DSLs operating over the same model. Speaking of model, M is for model and metamodel and metametamodel. Since my Smalltalk days, I have grown tired of using the meta prefix, as it often confuses more than helps the conversation with developers.
It seems that the Oslo team is heavily (and emotionally) involved in REST, actually let me rephrase that, involved in both lo-REST and CRUD-REST. That’s pretty pathetic for a team that think they are working on models. One of the key foundation of MDE is precisely to avoid CRUDing at the programming level.
We are involved (emotionally and otherwise) in anything that works for our customers. We did this little thing called WS-*, which has model written all over it. Some customers love that. Some customers love CRUDing over their models. It turns out that MService was geared to Web developers that just want do something simple like Rails. That doesn’t mean we don’t love and support all the other ways of doing building services. BTW: We do Hi-REST in MService.
…completely missing the mark on MOP.
I like many aspects of your MOP formulation. I do not like the explicit transformation, but otherwise it seems reasonably sound at a high-level after skimming it. The example you give of WCF attributes is actually one of the key driving factors of our work.
Hi Doug,
In your post you comment that ‘We want an architecture that supports both both textual and visual DSLs operating over the same model’. How is it proposed that an MGrammar textual dsl instance will keep in sync with its repository model instance which is changed via another projection e.g. a visual or another textual representation?
Thanks,
Pete
PeteGoo
9 Apr 09 at 03:39
Doug,
IF ““Oslo” == Modeling + WF 4 + what is now Dublin + what is now .Net Services” is a past tense now
AND what Adam Denning has been written between February 4 and March 23 should be taken down from the http://blogs.msdn.com/e2eblog/default.aspx
THEN:
1. What is Oslo as of today?
2. What happened to Adam Denning’s group and/or his mission?
Sándor Nacsa
9 Apr 09 at 05:25
Adam wrote than last year. We are still in the process of figuring out how to take to market several of these technologies then. At that time, “Oslo” was composed of the next-generation workflow engine, the VS designers for that, the repository, Quadrant, the app server, and the cloud services. Prior to PDC, we made a decision to decouple many of these from the Oslo name and schedule as they were better aligned with the Dev10 and Azure. We decided at that time to continue to use the Oslo name for the modeling aspects of that platform (I decision I sometimes question, frankly).
These are all pragmatic customer driven decisions. We make our decisions based on delivering customer value as soon as possible, even it means we are going to take a “hit” in how to talk about it. In Dev10, the Oslo initiative birthed a new workflow engine, new designers for that, new XAML stack (with DevDiv), new component model (MEF, with DevDiv) and other improvements to other components of .NET like WCF, etc. In Azure, the Oslo initiative birthed the .Net Services part of the Azure Service Platform and influence the overall strategy broadly.
The term “Oslo” today refers to a modeling stack — which is just technology jargon for a data stack. We have a language (”M”) for writing down other languages, instance data, schemas, expressions and functions. We have a repository (which is just a SQL Server database with a “catalog” in it) for storing data. We have a tool (”Quadrant”) for getting N views (graphical and textual over that data). We have a set of base “models” that people can use and extend to help people write down and access data. We are then taking that stack and working with teams all over Microsoft to move the application lifecycle (design, build, manage) to top of this stack.
The E2E team is still functioning, they are working broadly across the all the technologies offered by the Microsoft (but with special focus on the technologies birthed as part of the Oslo initiative).
douglasp
9 Apr 09 at 05:51
Good question.
We use an optimistic concurrency model with the repository.
While in memory, the observation system handles any update between N views
When you go to commit and the data has changed, we guide you through conflict resolution.
If you think dataset with N views on top, that is close to right mental model, although we do a lot of work to help the user in the tool.
douglasp
9 Apr 09 at 05:56
Doug, thanks for clarification.
Compared to the March 2009 “Oslo” FAQ (http://msdn.microsoft.com/en-us/library/dd129873.aspx) your statement of “The term “Oslo” today refers to a modeling stack — which is just technology jargon for a data stack. … taking that stack and working with teams all over Microsoft to move the application lifecycle (design, build, manage) to top of this stack.” is ways better than what you could find in the FAQ. I would suggest to add this ASAP to the extremely broad “”Oslo” is the code name for Microsoft’s platform for model-driven applications” answer what is in the FAQ now to the “What is “Oslo”?” question.
Regarding the E2E team I would like to see some public release/communication from them since such an all technologies end-to-end work is quite essential. This could also clarify that their current mission is not completely in contradiction to the original FTA one (which BTW was communicated by Adam not as to drive the old “Oslo” but just provide an all-up scenario based approach to the development of the diverse set of technologies involved in the quite broad initial “Oslo”). With such an update on their blog the old entries could remain unchanged I think.
I will also add to my comment on the Infoq article that the E2E group communication was last year.
Sándor Nacsa
9 Apr 09 at 06:47
Hi Doug,
My previous question about syncing model projections was more around the idea of a projection in a textual dsl using MGrammar. How could this be kept in sync with graphical changes if the parse is one way?
Not sure if I’m missing something obvious here.
PeteGoo
9 Apr 09 at 09:20
see my comments: http://www.ebpml.org/blog/181.htm
Jean-Jacques Dubray
9 Apr 09 at 11:02
If it is internal DSL, it falls out of the system.
External DSLs are harder as the transform is one way right now.
It is on our backlog, but that is a much harder problem, so I don’t know if we get there for v1.
douglasp
9 Apr 09 at 15:12
[...] for dummies! JSON replacement! all of the above!). Douglas Purdy makes a valiant 4-part effort (1, 2, 3, 4) but it’s still not crisp enough for my small brain. Even David Chapell, explainer [...]
William Vambenepe’s blog » Blog Archive » With M (Oslo), is Microsoft on the path to reinventing RDF?
12 Jun 09 at 07:20
[...] for dummies! JSON replacement! all of the above!). Douglas Purdy makes a valiant 4-part effort (1, 2, 3, 4) but it’s still not crisp enough for my small brain. Even David Chapell, explainer [...]
With M (Oslo), is Microsoft on the path to reinventing RDF? | Oracle
11 Aug 09 at 09:12