On Eclipse, Oslo, and how to invent the future together…
Lars Corneliussen wrote an open letter to me last week. You can find the post at here. I appreciate the effort Lars put into the letter and wanted to take an opportunity to respond to the following points:
· Terminology
· Runtime vs. Code Generation
· Open Microsoft and the Eclipse Modeling Project
Terminology
As I highlighted at PDC, we currently divide modeling into three segments:
1. Drawings: Human to human communication using a model
2. Model-assisted: Code generation from a model and model creation from code
3. Model-driven: Direct execution of a model by a runtime
For any given project, you can use any or all of these. In fact, most .Net projects I have seen use all in one form or another. In addition, approaches #1 and #2 have a long history on the Microsoft platform; I recall using both of these on Windows projects long before the advent of .Net.
“Oslo” is primarily focused on the model-driven segment, but certainly many of the “Oslo” technologies will help with the other two. For example, we are working toward modeling various domains that support model-assisted development including UML and the DSL Toolkit. In addition, it is certainly possible to do drawings with “Oslo”. All you need to do is write a model and a visual DSL; no need for a textual DSL or runtime in that scenario.
The key thing is that Microsoft is committed across the application lifecycle (including software development, management, etc.) to modeling in all its forms. “Oslo” is bring important new capabilities to bear, especially in the space of model-driven frameworks and applications, which in my opinion changes the whole landscape about how we think about the power and applicability of modeling in software development.
In my experience, when you a birth a new product, naming/teminology is often the most difficult aspect of the process. I am sure that we will have some tweeks in how we talk about things as we go along. i am also sure that I will have my share of “misspoken” statements. That said, I am open for feedback across the board on this terminology. The key thing is that our customers/partners understand the space and how “Oslo” will help them.
Runtime vs. Code Generation
We do not think that every domain needs a runtime, although many will. Once the decision is maded to build a runtime, the complexity of the runtime is a function of the complexity of the domain. Thus, how hard it is to build a runtime is going to be something that needs to be determined on a domain by domain basis. For example, the Web domain (HTML) is a hard domain and the effort to build a runtime is thereby correspondingly hard.
The potential difficulty of writing a domain is one of the reason that we think that writing domains, inclusive of DSLs, is largely a something an ISV or framework author will do. Microsoft (an ISV) is going to invest in writing many domains across a broad spectrum of our assets, including the domains of application development & management. We believe that most application developers will spend their time using our application development domains. That said, if you are big enterprise and you write tools and frameworks for your own projects (effectively making some aspect of the enterprise an “ISV”), “Oslo” will be a powerful toolkit for you.
In terms of code generation, we are just at the beginning of figuring out how to tie our model-assisted assets together with “Oslo”. I could absolutely see us modeling these domains and building a runtime that did code-generation. We’ll see how things work out.
Open Microsoft and the Eclipse Modeling Project
I do want “M” to be as broad as possible. For example, I want to ensure that we have a great browser story, in addition to having a great .Net, Java, C/C++, etc. story. The OSP announcement of the specification (which includes MGrammar, MGraph, MSchema, our SQL & XML mappings and the System.Language model) is just the beginning of our engagement toward making that true. Stay tuned.
Based on what we have already said, there is nothing preventing Eclipse or another other organization from implementing “M” once the specification is complete. That is something that I would absolutely love to see and I would support in any way I could.
In terms of “bridges” for EMF/xText/OAW, this is something that I am interested in exploring with the Eclipse community. I am happy to talk to Ed Merks, Sven Efftinge, Markus Völter, Peter Friese or anyone else about the possibility (we can use the thread that Lars already kicked off for that).
I think runtime is the future. Either in the form of an SaaS or in the form of a custom SaaS that produces SaaS. Businesses have been required to be bogged down with technology when technology is not their business. Yet, technology is an enabler of business. For a techie, the “cool thing” is a new language or some form of complex technolgy to justify a means. For a business owner/stakeholder this means, high cost, who do I hire, how do I get my current people trained, how long is this going take and how much is this going to cost?
The techie terms and complexity are great for our marketability in this day and time as what we sell is complexity. Could you imagine if we had to build a TV each time we wanted a new one - in contrast is wasn’t that long that many of us were assembling our home computers.
Code generation is mostly duct tape for what we have not yet abstracted and is no more than a temporary solution to yet something else that will have to be reengineered in a coming year, which has been the way of the software industry for as long as I can remember - we need to upgrade.
The answer is Runtime.
Web6GL
19 Nov 08 at 12:14
I’m afraid I’ve heard good intentions from Microsoft on “openness” before, and seen this fall into a heap once a project becomes strategically important to a mainstream Microsoft platform. (e.g. .Net’s inability or unwillingness to import WSDLs that are not designed within the .Net framework - leading to a loss of iteroperability).
If Oslo was serious about openness, then it would adopt the MOF/eCore metamodel, and use the HUTN specification from OMG for its “M” syntax. The work is already done, and you’re choosing to reinvent the wheel - not necessarily in order to break interoperability - more likely because of the Not Invented Here syndrome. The outcome will be semantic mismatches and no interoperability - as usual!
|<
Keith Duddy
20 Nov 08 at 02:35
@Keith Duddy
Please send me any WS-I Profile WSDL that WCF doesn’t support. If WCF can’t implement or talk to a service that implements it, it is a bug and we will fix it.
I would also encourage you to look at “M” and the facilities it provides. It operates at a different level than eCore. A more reasonable comparsion is to XML, XSD and XSLT.
In addition, “Oslo” is not about code generation — it is about models that are executed directly by the runtimes — which is not something I have seen formalized in anything related to eCore, etc. — but I am happy to be educated.
One other cynical point, if I wasn’t serious about openness, I would not have spent a bunch of my own personal time jumping through all the hoops need to get this specification OSP’d. It is not a trivial process and I don’t have any time to spend on things I don’t believe in or take seriously.
metadouglasp
20 Nov 08 at 05:03
Hi Doug,
I really appreciate and wanted to encourage you to keep up the great work on Oslo and making it interoperable. Its often a trade off between academic theory and pratical application (not to mention industry expection). Sometimes one is driving the other.
Strategy I would argue is set well in advance and the investments Microsoft seem to be making are concerned with hitting the market first and innovating to support its strategy. In response to Keith there simply are no “bad guys” working to stop interoperability. All I see is much effort being added to standardise communications and separate functionality.
On the duct tape from Web6GL I would agree. Moreover the business is looking for agility - seeing a picture of what the system actually does, rather than how it runs.
David McGhee
21 Nov 08 at 21:27
Thanks for your answer, Douglas! I absolutely agree, that Runtimes are great and also the future. But for now building runtimes is more expensive than generating code - while generating code yields the same benefits on both design time (modeling) and runtime (quality code). Still there are some unshared advantages of code generation especially for distributed scenarios and/or in mixed-technology environments.
@Web6GL: >Code generation is mostly duct tape for what we have not yet abstracted.
Doesn’t the C#-compiler “generate” IL and JIT “generate” ASM? Would a .NET Runtime that ran a CodeDom be better? I abolutely see scenarios where code generation is the better design.
So I still hope for some code generation tooling.
More on the eCore/EMF bridging later.
Lars Corneliussen
24 Nov 08 at 10:00
> A more reasonable comparsion is to XML, XSD and XSLT.
I’ve heard this comparison a couple of times now, but I cant see where XSLT comes in. MGrammar projects “unstructured” text into models, while XSLT transforms models into models or text.
Forum discussions:
-> http://social.msdn.microsoft.com/Forums/en-US/oslo/thread/fb633bba-e922-4642-9f88-2a942f114224
-> http://social.msdn.microsoft.com/Forums/en-US/oslo/thread/ae08521d-c61b-4622-9a12-3d572bd97b6a
Lars Corneliussen
24 Nov 08 at 10:41
MDA/MDD in concept is a giant step forward, but I never see more than another layer of complexity with a different set of limitations on each implementation. In an ideal world, it would be nice to keep this generalized but that’s not easy as I believe the following complexity, at minimum, will occur within OSLO as well:
- how does OSLO relate the business logic to the data and presentation logic during design/development?
- how does OSLO relate the context of user, group or individual during design/development to that of the business/presentation/data logic?
- how does OSLO simplify integration to legacy systems or for that matter recent systems with differing security context and integration mechanisms or is OSLO meant to be for new applications?
- how does OSLO reconcile models or design when requiring an update to that model or design?
- how is OSLO knowing of workflow/process, web forms, SLA or other technical relationships while being capable of driving the development of a solution through the process as this is necessary to be “Model Driven”?
- how does OSLO control deployment of Models and how does OSLO reconcile the integration of existing and deployed Model A to the association of the new Model B - is there a concept of integration point during MDD/MDA?
There are answers to all of these questions, and if these questions are answered by going in and tweaking the code or building this set of classes or that set of classes then we have once again just created another layer - it’s simply that parts of the problem are generated quicker.
Now, if code is generated, then the aforementioned complexities are just that much more complex and business person will gain how much?. If there is a runtime that’s aware of architectural concerns (this is what you mean by runtime is it not?), then the relationships are presented to the user, which could be a business user as this will then “Drive the Design/Development”. Anything less, then Design/Development drives the technology and business user will get their resulting solution at some point in time.
We do not reprogram a web page everytime we want to use it, but we do reprogram/reenginner the code behind, business classes, dal etc each time we want the functionality to change. However, with an SaaS this repromming/reengineering is usually satisifed through configuration - (a little closer to runtime).
What I find even more fascinating is the economic sustainability of large technical corporations when the web provides the ubiquitous ability to provide business solutions and the only requirement is a standard browser.
Web6GL
30 Nov 08 at 15:45
Hello
I’m a bit suprised about your statements for DSL’s and eCore.
Your statement about DSL’s would mean there is always a general way to describe a domain specific language and it is always something technical; so Microsoft creates it in general for making developers life a bit easier (webservices, workflows), other big vendors create it for configuring their technical frameworks… In my perspective, DSL is the great chance to have more business relation in IT. Business people have their languages; sometimes it is even older than the IT history. E.g. an accounting record is nothing else than a business specific DSL executed at runtime. With a DSL you can specify something for the business with their own words, and if it is model based, it is possible to make it more consistency proofed even before the first line of code is created.
I think there are indeed general DSL’s like the quoted ones, but there is always an area where there will be domain languages specific bound in the requirements (engineering) area of every individual software for customers.
Also it wouldn’t surprise me if further business standardizations would be more and more model based on their own meta models (e.g. iso20022 looks like it goes in this direction).
About eCore:
If I understand it the right way, OSLO has three different (meta?)metamodels: for drawings, for model-assistence and for model-driven. Is this correct? If it is, I’m sure this way just looks easier for the beginning, but will reach some complex area in interoperability for the model(ing) software elements in OSLO.
Now the great thing about eCore is, it is the base of all models in the modeling-area of eclipse. It looks like an eclipse-bound technology, but in fact there is no reason why Microsoft shouldn’t use eCore itself for their models in their tools. The base is EMOF from OMG, which itself looks mainly driven by eCore. It is not technology locked. It’s just a fact, that eclipse has a lot of tools for it. And what this common base enables is really amazing: making a textual DSL with xText and also create a graphical editor of the same metamodel with GMF (both projects are from different teams; this is not just the community who makes it possible). If OSLO would have the same base for all models, it should be possible to share the metamodels on a model bus. This would be similar what webservices is today in interoperability of application interfaces. So I wouldn’t say it’s not possible to do the base of OSLO models with eCore before it would be proofed so.
I for myself wouldn’t try to make “the own (E)MOF” if I had the chance to influence such big project for the modeling area like OSLO.
Studer
8 Feb 09 at 18:02