In a recent thread on the EMF newsgroup, I came to realize that there are (at least) two EMFs, each belonging to a different class of product, and attending completely distinct requirements.
EMF’s native metamodel, Ecore, is a generic, lean object-oriented metamodel based on a subset of UML.
EMF’s runtime framework provides Java applications with runtime support for object models “including change notification, persistence support with default XMI serialization, and a very efficient reflective API for manipulating EMF objects generically” (source).
I am a happy user of EMF’s Ecore metamodel as a poor man’s UML (EMF team, please take that as a compliment). From Ecore-based models, using a compatible template engine, I can generate all code/artifacts that are prone to automation, be they Java code or not.
The runtime aspect of EMF is certainly useful to many applications, but certainly not to all or maybe even most. That is not to say that the EMF runtime does not provide a lot of value, as it clearly does given its popularity. Nor does it imply that the EMF runtime API has design flaws that prevent its use to be more widespread. The fact is that frameworks, while designed for extension, always impose a certain set of architectural decisions in order to provide value out-of-the-box. Those decisions are bound to make its use more suitable to some scenarios and applications than others. The goal is to make as many people happy as possible. It is clear that the EMF team has pulled off that trick. But that does not mean that using EMF-generated model code is appropriate for every Java application out there.
Model driven development maximizes reuse via a complete separation between problem domain and technological concerns. This separation is critical to allow us to build software in an obsolescence-proof way. EMF’s Ecore provides a good foundation for MDD in this sense, regardless the technology choices for the software being developed. The EMF runtime framework, albeit a valuable tool for a significant range of applications, brings with it a specific set of choices in terms of design and implementation decisions, and as such has a less universal applicability.
However, time and again I read comments in the EMF newsgroup that lead me to believe that this duality might have been accidental, and that the sole reason Ecore was created was to support the generation of Java applications based on the EMF runtime. If that is really the case, this is something that both amuses and worries me. My concern is that if the EMF team does not acknowledge the importance of Ecore as an independently useful product, technical decisions in the evolution of EMF might break the use of Ecore in contexts other than EMF-based Java applications.
Ed Merks
December 2, 2007 at 6:28amRafael, this is a well written posting. I would argue that EMF’s runtime is useful in most applications but certainly not all. As I said on the newsgroup, my experience is that time and time again, folks who start out saying they don’t need it now, later end up needing it for one of the many useful capabilities it provides. Things like the EMF4Net proposal (http://wiki.eclipse.org/EMF4Net_Proposal) demonstrate that the runtime is useful even in other languages.
In any case, folks can use EMF to generate non-EMF artifacts and it would be relatively simple to generate POJOs. I’m pretty sure Martin Taal has done that. If there was significant interest in this in the community, as opposed to the occasional negative shopper easily swayed to reconsider their approach, as well as folks willing put their development resource where there mouth is, I certainly would reconsider my position. But to me, things like supporting containment seem important even for POJO. It’s not clear if folks would still want a factory, and interface/implementation split (without which you can’t support multiple inheritance), or just plain old public constructors. Even if someone contributes an implementation, my very small team would end up needing to maintain it, so it’s important folks realize that my position also needs to be guided by wise allocation of resource.
In any case, the community has great value to me, so I’m inclined to listen when it speaks. That doesn’t mean I can do everything it asks. Certainly EMF was designed to implement the full behavior implied by Ecore’s metamodel, which includes bidirectional references and containment so most definitely generating code that supports this via a runtime is EMF’s primary goal. Generating POJOs at this time is not a secondary goal, but is definitely an interesting application for Ecore, as is generating C# code, HTML documentation, or anything else you could possibly imagine. The fact that a powerful core modeling technology that can bootstrap itself can be used for unlimited purposes isn’t an accident, it’s inherent in the model drive development paradigm.
You really don’t need to worry about us ever doing anything to break out clients.
rchaves
December 2, 2007 at 12:50pmThanks for the detailed comments, Ed.
> my experience is that time and time again, folks who
> start out saying they don’t need it now, later end up
> needing it for one of the many useful capabilities it provides
When I say that there are many cases where the EMF Runtime is not appropriate, I am talking more of cases where it is not applicable/possible due to some sort of constraint. These are often technical reasons: managed objects (EJBs), constrained environments (J2ME), non-Java apps, non-code artifacts, etc. Not to mention cases where the requirements dictate what technology is allowed to be used by the application (common if you are selling to the government).
> EMF4Net proposal (http://wiki.eclipse.org/EMF4Net_Proposal)
> demonstrate that the runtime is useful even in other languages.
Yes, I am pretty sure the same design would work for other languages. That for sure will expand the range of applications. Still, as in the case of Java, for other languages you will also have cases where it is not possible/applicable to use an EMF-style runtime.
> In any case, folks can use EMF to generate non-EMF artifacts
> and it would be relatively simple to generate POJOs.
Here you are talking about using EMF-based models and writing templates yourself, right? This is exactly how I use EMF (most of the time), and I don’t think you guys should worry about this scenario other than keeping ECore as versatile as it is today. Providing generation of POJO code out of the box should be out of scope for EMF itself, although it might make sense to cover things like that in EMFT projects. The needs for code generation when the target is not the EMF runtime are so diverse that I think most users would want to have their own templates anyway.
> In any case, the community has great value to me,
> so I’m inclined to listen when it speaks. That doesn’t
> mean I can do everything it asks.
For me, there is nothing else to be done other than preserving and evolving Ecore as an independently usable tool. Sometimes I notice features that are missing and realize that UML has. Instead of expecting more from Ecore, in those cases I think adopting the full-fledged UML2 is the best option.
> The fact that a powerful core modeling technology that can
> bootstrap itself can be used for unlimited purposes isn’t an
> accident, it’s inherent in the model drive development paradigm.
True. But one can always decide to ignore that and deem everything outside of the initial focus as “unsupported”.
> You really don’t need to worry about us ever doing
> anything to break out clients.
That is great. I was just not sure people using Ecore-based models for targetting anything other than EMF-runtime based Java apps were actually considered clients. I feel much better now. Thanks!
Jörg von Frantzius
December 3, 2007 at 2:53amJust to have mentioned it here, we are happily generating our own runtime code, which is not based on the Ecore runtime framework, but still provides containment semantics and bidirectional integrity of associations.
Ed Merks
December 3, 2007 at 3:07pmIt’s a little known fact that the EMF 2.2.x runtime works with Foundation 1.1, so it also works with J2ME. Tom Schindl, Boris Bokowski, and I are also working on GWT compatible version of the runtime; so far mostly Tom is doing all the work.
Ed Merks
December 3, 2007 at 3:12pmJörg, I forgot to submit my comments earlier and after doing so saw your additional comments. I guess this is confirmation that different folks will want different things, as Rafael says, so while some might want no runtime, some might use a different runtime. In the end, many folks will have patterns that might differ wildly in their requirements and hence are specialized to their own needs. We certainly want to ensure that we always will support this approach. We want to enable everyone, not force everyone down the path we decide is best, as if we could possibly know that for everyone in the first place…