Eclipse Summit Europe Day Two: Big Models

Well, I'm exhausted from today's Big Models work group! Here's a snap shot of the group and of the room in which I spent most of the day:


The "let's pick on EMF" day ended well! But I'm too tired to say much about it. Axel, Simon, and Diego were the major instigators from SAP but they, and all the other folks, picked on EMF in such a nice way, it almost didn't feel like critique (much). Actually, it wasn't really so much picking on EMF, it's just that scaling problems are hard no matter what technology you use.

I got to meet some of the managers from SAP as well, so I'm very hopeful that the SAP executives will overcome their conservative ways and take the EMF plunge. You have to take risks in life to reap it's greatest benefits. It was just great getting to meet Axel, Simon, and Diego in person. It will be so cool if they get to work on and with EMF...

Rich and my demo also went well, I think, but it's best to let the audience be the judge.

And I finally got to meet Tom Schindl, though only for a few minutes. But I know what he looks like now, so I'll track him down tomorrow. He can run, but he can't hide!

The reception was nice as well, though I found out a disturbing secret. Mike Milinkovich is a closet Modeling Redneck. Apparently he believes, and I quote, "Modeling is stupid" . Rich and I were going to bitch slap him; actually mostly just me, but Rich probably would have helped because he's ever so helpful. Instead I did the politically correct thing and explained that the only thing more stupid than drawing a box called X with a compartment called y, would be to write an interface called X with getY and setY methods, a class classed XImpl, with a getY and setY methods as well as a y field and method bodies to update y, a factory to create an XImpl, some code to serialize X's y feature, and finally some code to deserialize an X's y feature. Around this point he started to glaze over so I'm sure I was highly convincing that not only is not modeling stupid, but so is Ed. He's a very insightful person!

Tomorrow I'll get to go to some of the talks so that will be cool. Stay tuned...

Eclipse Summit Europe Day One: The Modeling Symposium

The Modeling Symposium was really well attended with roughly 35 people. We traded for a larger room with one of the less well attended symposiums. I got a snap shot of all the folks in the room.




Markus Voelter gave a quick introduction and I talked very briefly about what's happening in EMF and the other Modeling projects. Then Bernd Kolb and Peter Friese talked about the Model Workflow Engine. It provides a language to write scripts that drive Bean-like classes representing the components within a workflow. It includes debug framework integration so you can track the activity of a flow. Folks were interested to see a sample running under debug control, so Bernd was under the gun to produce that quickly. Someone asked why not use Ant? MWE has more specialized control mechanisms; it also has an Ant task and they are working on being able to call out to Ant.

There was a presentation about Product Line Unified Modeler by Aitor Aldazabal of the European Software Institute. This involves managing variability of a line of related products via a decision model. Eclipse was a good choice because they wanted OSGi support for deploying on devices. They use Ecore to define models and generate a basic editor as well as using GMF for graphical support. They also use OCL for defining constraints on configuration validity as well as oAW for scripting the process. They need a distributed architecture so are looking into MDDi.

Then Bernd and Peter came back with a quick demo. It's very cool that you can step into the various parts of the flow processing!

Holger Papajewski of Pure Systems presented about Integrating Model-Driven development and Software Product Line Engineering. It was quite closely related to Aitor's talk. They are very happy with the choice to use Eclipse, which was a choice made very early in Eclipse's public life. We noticed a pattern that the talks all used oAW, but Markus denied selecting based on oAW usage, but that just made it more fun to tease him about it. This project manages variants and variability using feature models. The variants are generated using a decision model. They use BIRT for report generation. They are moving over to using Ecore to describe their models.
And they have a need for scripting the types of changes they commonly make.

During the break, I talked to Stephan Eberle who is at TNI-software now. I also chatted with Miguel Garcia and helped him set up his OCL tools demo on my machine. This was the only meeting I've ever been too that was ahead of schedule. Markus runs a tight ship! I also talked to Reinhold Bihler about the C# component for translating EMF's runtime for .NET; Mikael from INRIA was quite interested in this.

Dimitros Kolovos of University of York, an Epsilon committer, talked about automating repetitive tasks. Their project provides infrastructure for implementing task-specific languages. Epsilon Object Language is based on OCL and includes support for comparison, validation, merging, and transformation. He showed how to extract a class into an interface automatically, transforming references to the existing class to refer to the new interface instead. They plan to look at converting a recorded change description into a generated wizard skeleton.

Gabriele Taentzer of Philipps-Univeristat talked about supporting complex editing operations using in-place transformations based on a Transformation Rule Model that lets you describe what needs to be done to transform a graph. When I spoke with her at lunch, she expressed an interest in starting a model refactoring component in EMFT. Cool!

Maarten Steen of Telematica Institute talked about using Business Process Designs to generate code. They use QVT to transform between models. There was quite a bit of discussions about what parts of QVT are currently being supported or planned in the Modeling project.

Miguel Garcia give his impromptu presentation about his OCL tools and the Emfatic work referring to his home page: http://www.sts.tu-harburg.de/~mi.garcia/Promotionsprojekt.html

At the end of the morning, Markus collected topic for afternoon break out discussions.

1. Would be a nice to have one QVT implementation.
   
2. Dashboard for model users; making the tools more usable.
3. Organization of the Modeling project. How to make the overall project more organized?
4. IP? Autosar has a private metamodel...
5. Validation and OCL constraints.
6. Scripting and orchestrating the tools.
7. Scalable support for big models.
8. What's happening with M2T?
9. Textual modeling framework.
10. Integration of textual and graphical aspects of DSLs.
11. Weaving instances and determining correspondence between instances.
12. Visualization of complex models.

We voted on our favorite topics and used that to determine which discussions should happen sequentially. After that we had lunch.

As part of the "Better organization" discussion lots of issue were raised. How to use all the different projects in a cohesive way to achieve a particular result? Many people invest a lot of time learning poorly documented tools to understand which ones will help contribute useful capability for their task at hand. We need better summaries of what projects really provide. It's hard to find the information you need. The ability to use all the frameworks in an end-to-end solution is an important need to address. I pointed out that what would be really good would be if users help to focus on building up the information base that documents what they've learned to help make life easier for the next set of users. I.e., the community can contribute to the solution via the wiki.

Markus argued that we need better leadership, i.e., folks who understands and promote the big picture with less particular focus on a specific project. I think that comment was directed mostly at me rather than at Rich, who is busy working on a book for how to use the various Modeling project technologies to build a domain specific language. Hey, if the shoe fits, I put it on! There is also a problem of reinventing technology; researchers tend to like to do this. Overall, a dashboard for technology in Modeling project, like the one for GMF would be appreciated. It was observed that it's not necessarily in the funding company's best interests to make open source so competitive it competes with their products or services, so the community really needs to step in to help polish the open source results. It was also observed that academic research funding is often driven by folks relabeling their work to fit into the special interest of the day without actually changing what they are doing. Folks were also concerned about competition with Microsoft's DSL tooling; obviously Microsoft knows how to polish their results. In general, there are perceived to be too many projects with overlapping scope and with vague interrelations. In the end, we don't need yet more solutions to the same problems, we need a smaller number of well-integrated high-quality solutions. I'll need to think about all this a lot...

As a prelude to tomorrow's Big Models meeting, the issue of scalability was raised. Solutions that work well for smaller models will often not work so well for larger models. It was noted that unloading a large model will actually increase the memory consumption by converting objects to proxies. The objects are detached from the resource but they maintain all their connections,
including their containment tree so any reference to any object in the tree will keep the whole tree in memory. One could unset features to eliminate the containment connections between the objects and thereby allow the individual unreferenced ones to be collected. Fragment paths are seen to be quite large and fragile, though that space is transient while the ID overhead stays around longer. Some folks need to track all instances of some specific type so I pointed out at a specialized EContentAdapter could maintain that information on the fly to avoid visiting the whole model each time.

The issue of large models that are too big to fit all in memory came up, but even without EMF, there is really no solution to this problem. One needs to split them into smaller pieces to make working with them manageable and to reduce change conflicts; cross resource containment can help with splitting large models into smaller pieces. Repositories can be a solution for the search and query problems by maintaining caches and indexes; it can understand the deep structure of what is saved. Also, the EStore API can be useful for separating the data from the EObjects that carry the data; CDO is using this approach. In the end, the best way to make things scale is to have a larger number of smaller resources rather than a small number of very large resources. One can always process the smaller resources one at a time, but a large resource taxes pretty much any technology.

There was a slightly confusing discussion about end user integration because defining an end-user is tricky in this meta meta world. But we decided that by end-users, we mean the modelers, i.e., those folks who will use the Modeling project infrastructure to build models, tools driven by those models, and utilities to manipulate those models. It would be awfully nice to make the tools feel more like the JDT with proper end to end integration to handle common issues easily. Scripting or workflows to perform more complex tasks as part of a build would be a time saver and error preventer as well. Make tools simpler by hiding incidental complexity...

It was a very interesting but tiring day. Rich arrived at the end and I sat down with him to go over the demo we do tomorrow. I'm a little ill prepared. I hope I don't screw it up too much!

Finally we went out for the sponsors dinner organized by Ralph.


Tomorrow's Big Models meeting should prove fun as well. Stay tuned...

Eclipse Summit Europe: The Day Before

My flight from Toronto to Frankfurt yesterday afternoon was on time and very nice. Out of tact, I won't describe just how nice it was. The flight from Frankfurt to Stuttgart this morning was only slightly late. And the taxi ride was fast, i.e., 170km/h at times. I certainly got to the hotel in good time and they had my room ready when I arrived, so I could catch up on a bit of lost sleep.

I had a little bit of time to explore before dinner. The forum looks to be a nice venue.


It didn't take me long to find a cool garden too.


I ran into Don and Lynn, but they were eating early so I walked with them to their restaurant. Later, this snake caught my eye on the way to dinner with the Architecture Council folks, Michael, Pavel (I hope I spelled it right), Bjorn, the two Dougs, and Jeff.


It was a small but tasteful group and later we were joined by Ralph, Wayne and company, so it got to be a big group. Some of us left to make room for the late arrivals, and we strolled through the pretty town in the dark.


I'm looking forward to the modeling symposium and the sponsor's dinner tomorrow night.

Stay tuned for the next chapter!

Is EMF going to replace MOF?

Ian Bull directed my attention to a Model Driven Engineering poll which asks "Is EMF going to replace MOF?" The four choices are quite amusing:

• Yes, MOF is about dead. That's really sad. I didn't even know it was ill!
• It may influence it, but both will stay. This sounds a bit too future tense to me. EMOF and Ecore are effectively equivalent---we can read and write Ecore as an EMOF serialization---and that's not an accident. MOF was split into EMOF and CMOF (essential and complete) because of Ecore's influence. When we started work on EMF, MOF seemed to have a lot of nonessential things, so we eliminated those.
• EMF will never supplant MOF, MOF is great. Since Ecore is an implementation of EMOF and existed before EMOF, I'll be just as happy if we compliment MOF rather than supplant it. If MOF is great, so is EMOF, and so is Ecore. Transitivity is such a useful property!
• EMF is just for Java, it is too specific, MOF is great. Well, EMF is clearly a MOF implementation targeted to Java. I'm not sure if a Java implementation can be too specific for Java, but if so, I guess it could also be not specific enough, or it could hit the Goldilocks target of being specific but not too specific. Coincidentally, Reinhold Bihler is working on a .NET version of EMF and I know other folks have generated C from it. His version will be just for C# so it might be too C# specific but I expect it will be just specific enough. I'm still waiting to find out from Mike if a C# project can be hosted at Eclipse. That would be a first I think...
  

So in the end, I think all the choices are good ones, except maybe the first half of the last choice.

Like so many other folks, I'm very much looking forward to Eclipse Summit Europe next week. The Architecture Council group, of which I am a member, is planning to have dinner, which will of course accomplish next to nothing and hence will completely live up to the expectations based on the council's past performance. Oops, did I say that out loud? Just a little joke! Besides, I'm just quoting Bjorn who's never afraid to say what needs to be said. In all seriousness, the newly reformed council has yet to meet, so time will tell if we can become a functional body. If we can just become good mentors for the community we will have taken a positive step in the right direction.

On Tuesday there will be an all day Eclipse Modeling Symposium. Last year's symposium was way cool, so I'm particularly looking forward to this one. On Wednesday there are all day meetings about Big Models to look closely at issues of how EMF can best help support a massive collection of interrelated models. And by the way, don't ever Google for "big models". Oh my eyes. Some images are hard to erase after having been seared onto your retinas. My partner in crime, Rich Gronback, and I will be giving a cool demo. And of course modeling is ever so popular in Europe so there will be cool talks about oAW and compare. I'd never heard about Medany Platform before, so I'll be interested to find out about that!

Lots of people I've never met will be there, and meeting people is more than half the fun. I'm particularly excited to meet Tom Schindl. He's so incredibly helpful on the newsgroups and is doing such cool things. I can't wait.

So no garden pictures this time, but I'll leave you with this photo I took a few years back in Grenda with a rainbow to remind us that diversity in our community is the key to its long term growth:

Predation, Parasitism, Commensalism, and Mutualism in the Garden and in the Community

Every fall death stalks my garden in the form of this beautiful but deadly predator, the Great Blue Heron. No frog or fish is safe and often one or two of the careless will disappear before I can dispatch Ruby to chase it away.


Predators come in many shapes and sizes, like this cute little toad:


Ruby had heard that toad licking was all the latest rage, but she tells me that no, licking a toad doesn't actually give you a good buzz.


The praying mantis is one of my favorite insect predators.


Predators serve a role, but they result in the death of the prey. Predators in the community are something we'd all like to live without, but predation is a fact of business life just as it is in our environment.

My garden is also full of parasites and of all these, the leech is the most disliked.


Parasites don't actually kill their victim, but they do cause harm. Apparently leeches have medicinal use because of the anti-clotting agents in their saliva but I'd still don't like them. Often a community will have a few parasites as well. There are always a few people who are just like leeches, i.e., they drain away your lifeblood until sated giving nothing in return but a scar.

But, in a community, commensalism is the norm. The users of open source software benefit and in doing so cause no harm. Just as this frog uses a lily as a convenient platform from which to ambush its prey without harming the flower.

What we'd like to achieve in a community is mutualism where both parties in the interaction benefit. This bee on a sunflower is a prime example, benefitting from the nectar and the pollen while ensuring the diversity of the sunflower gene pool by transporting the pollen from flower to flower:


A thriving community is driven by mutually beneficial behaviors. Users help test the software and help make it better with suggestions. Some individuals eventually become contributors and will directly enhance the software. Others might help document it thereby making it more consumable for others. A few will even strive to become committers to invest even more of themselves.

For quite a few weeks now I've been watching the geese practice flying in formation. They tend to do this every evening for the late weeks of summer.


I find this a particularly striking example of mutually beneficial behavior at work. Most folks probably know why geese fly in formation and it's not because they just love to hang out together. The goose flying the front has to do the most work, and those behind benefit by virtue of getting a little bit of extra lift from the turbulence created by the goose in front. They need quite a bit of practice to learn how to fly in this way. Each goose will take turns leading, and when it tires, it will peel away, falling back to the rear, allowing the next goose in line to take the lead. In this way, all the geese benefit and get to their destination with less effort than it would take to get there alone.

Let's try to be like the geese and act cohesively for the mutual benefit of our whole community.

Diversity is More Than Just a Symbol

With all this recent talk about diversity, imagine my surprise when I got up just past the crack of dawn this morning to see the very symbol of diversity arching across my backyard.


This is just too coincidental and clearly something that I feel compelled to share with those who sleep in well past the crack of dawn.


Do you see how all the different colors of the flowers are complimented by all the different colors in the rainbow? Diversity isn't just nice. It's pretty too. And for a successful project at Eclipse, it's even expected if not absolutely required.

The World Reflected in the Eyes of Another

The unofficial end of summer is always a time for reflection, so it's kind of cool to see myself reflected in the eyes of a frog:


From this perspective, it's clear that I'm rather large and intimidating which helps to remind me that others are likely to perceive me very differently from how I might intend...

It's also apparent that I'm not the only one always on the lookout for bugs!


The bugs themselves are busy too. This bee is absolutely covered with summer's bountiful harvest of pollen.


I'll bet most people have never stopped to notice how many kinds of bees are really buzzing around out there. This one's busy lapping up sweet nectar as well as collecting protein rich pollen on her hind legs.


I'm sure that even fewer people notice that the flies too are rather pretty if you take the time to look really closely.


Life is a rich tapestry full of the unexpected. I don't even know what kind of bug this is, but it's certainly fierce looking!


Contrary to popular believe, I don't spend my whole life answering newsgroup questions. It's certainly one of the gardens I nurture with perhaps a little too much zeal. But I do have time for my other gardens too.

In EMF-land, we're just finishing off polishing the final chapters of the second edition of the book and we've decided that since it's been so incredibly painful we should prolong the short term pain by writing an appendix to describe the new features of EMF 2.3 so that we can avoid the longer term pain of ever having to write a third edition. Like my hardy Hibiscus, it's taken a long time to bloom.


I'm also pleased to have finished a prototype for a more flexible and powerful URI converter along with support for content types; please see 191077 for patches. The enhanced URI converter APIs support things like exists, delete, timeStamp, and isReadOnly to allow one to build a fully functional application without hard dependencies on the backing store APIs used to prop up your resources. In addition, it supports contentType to allow one to define resource factories based on resource content rather than on file extensions. I'll need to write some documentation to describe how best to exploit these new capabilities. Probably it will be easier for folks to provide feedback once we commit the changes and start providing builds for EMF 2.4. Just as the garden gets better each year based on experiences from previous years, so too EMF keeps getting better.

So let's say goodbye to summer with the attitude that there will always be more summers and likely even better summers. These sunflowers are most certainly a very lovely way to say goodbye.