CDO Enters the 3rd Dimension

Update: The new room is 

Ballroom B+C

(not D, as in the printed schedule!)

EclipseCon is near and I'd like to invite you to attend Martin's and my talk CDO 3D on Monday shortly after lunch time.

As you may know or not, CDO is a runtime environment for distributed shared EMF models. Especially for organizations with huge models (e.g. the NASA, banks like the UBS AG, etc.) CDO is indispensible and has become sort of modeling mainstream in the past years.

Although I've always invested a lot into cool animated Powerpoint slides and although CDO comes with really new functionality each year, we've recognized a slight tendency of the conference audience to decide for parallel talks about completely new modeling technology, if they were forced to choose one. This fact (and the guy who shouted "next year we get Pixar Studios" after my last EclipseCon talk) has made me think about new ways of presenting a complex distributed technology. That's why this year's talk is titled "CDO 3D".

We will have no Powerpoint slides anymore but fully focus on real-time demos of a distributed system with a CDO model repository server and two CDO client applications. The client applications have RCP user interfaces, as well as a self-made scripting console that we will use to demo the API usage of CDO and the immediate influence of local CDO calls on the entire system.

In addition we've developed a 3D visualization frontend, that renders the contents and activities in multiple Java virtual machines into a 3D canvas in real-time. We've instrumented these VMs so that the frontend can even visualize the method calls between the Java objects and the network traffic between the VMs. This diagram outlines the basic architecture of our presentation system:

If you're still asking yourself "What the hell is he talking about?" watch this short video:

(click here for watching a larger video)

Of course we'll also talk about some of the cool new features in CDO 4.0 like OCL queries, Blobs and Clobs, cross referencing and referential integrity checks, fail-over cluster and the brand new backend integration with MongoDB. I'm looking forward to see you in Santa Clara!

What exactly is inside that p2 repository?

Wasn't it nice when we were able to point our web browser to an Eclipse update site and instantly see what's in it? Like with this one.


Has it ever bugged you since that this is not possible anymore with p2 repositories? Like with this one.


I've spent some time (with the help of Dave) to add the generation of a similar HTML outline to the new CDO build system. See our resulting p2 repository:

I'd like to encourage you to provide something similar for your public p2 repository. I just added this Ant markup after the site.p2 generation:


The P2Content.xsl file can be found here. If you apply a nicer HTML rendering than I was able to I'd appreciate some hints or snippets.

Honor, Slides, Webinar, ...

First I'd like to thank you, the community, for electing me as this year's top committer. This is a tremendous honor for me and a real motivation to keep my effort at the same level as the last six years that I have been working with and for the community. Thank you!

During Jeff Norris' keynote at the EclipseCon it was also nice to see CDO being used for the distributed mission planning and control application of the NASA. In general it was an awesome presentation, almost impossible to top.

Taken from previous year's slides.

My own talk about CDO was not nearly as cool but the room was full and I got some nice compliments. Some asked for the download location of the slides I used. They are available here.

Who is who?

As my slides do not provide much explanation by themselves we will offer an online webinar again. If you're interested, come and learn about the CDO Model Repository and its new 3.0 features on

Thursday April, 29th, 16:00 CET.

The above picture from the Enterprise bridge shows you the moderators of the webinar. Whoever is able to tell who they are can take part in a raffle and win an Eclipse polo shirt (sizes small and medium available)!

CDO goes Offline

If you followed the catchy title because you were fearing that the CDO Model Repository project could be discontinued, well, then I've chosen the right title. Let me elaborate by starting with a little anecdote:

During a previous conference I talked about how CDO can transparently turn your file based, isolated EMF applications into a distributed cloud of nodes, all collaborating on a central shared model, immediately seeing all the changes that are committed to the repository by other clients.

I was asked what would happen when, due to network failure, a client gets disconnected from the server. Would it be able to continue working in a disconnected mode? At that time I answered that the C in CDO is for Connected (Data Objects) and that we, for this reason, do not offer an offline mode.

Well, while that caused a grin here and there it was kind of polemical and I must say that I've always understood the industrial relevance of being able to work offline. The real reason for not having this mode in CDO has always been the tremendous cost to develop it properly. As an individual full-time committer I just couldn't afford this investment on my own.

But exactly this has changed since and my new main sponsor has given me the opportunity to develop the cool new offline mode for CDO. In fact it is not only a mode, optionally provided on the client side. More exactly it's a new type of a cloned repository. This clone is continously being synchronized with a master repository and can almost be used like a normal repository. Clients are almost not impacted, normally they do not even realize whether the clone is online or offline.

The major challenge wasn't so much the background synchronization of the clone or write-through commits of clients while the clone is online. It turned out that committing to the clone during offline periods and pushing these changes to the master later is even more complex. I'm tempted to slip into the details of the technical solution that I implemented, but the whole purpose of this article is to allure you to my exciting EclipseCon talk:

Scale, Share and Store your Models with CDO

The talk is on Wednesday, starting at 14:30 and I'm going to augment the beginners' overview of the technology with a preview of all the new and the cool stuff that we'll be delivering with the upcoming CDO 3.0 in Helios. And I'm also going to explain why the new offline mode has coincidentally lead to the introduction of branching and merging support in CDO, as well.

I'm looking forward to meet you all (again) in Santa Clara!

Less EMF!

This year's Eclipse summit was a great success, again. Before I start to chatter about the modeling technologies that I found most interesting, I'd like to point out that there also seems to be some sort of anti modeling coalition. It's clear that the public statement that "Modeling sucks!", without further reasoning, is more likely to create common hilarity than constructive engagement in the challenges and opportunities. A pity that I missed the Foundation 2.0 talk!

I noticed that others took the war against modeling and EMF in particular more seriously. There seems to be a whole industry concerned with devices that shield against EMF and the like. They are sold with the slogan "Less EMF", go figure:

http://www.lessemf.com

Of course these attempts to discredit the value of modeling are doomed to failure, as the overwhelming interest in Eclipse modeling technologies at the past summit demonstrated. The tutorial about Advanced Programming Techniques with EMF and CDO was so overly crowded that the organizers had to take all tables out of the room and make place for almost 100 attendees.


At least the same amount of interested persons stayed in that room to participate in the discussions of the following modeling symposium. All the other talks (24 total) and BOFs about modeling had been extremely well attended, too. Some of them were of particular interest for me and the CDO Model Repository project:

• The new EMF Model Query provides an SQL-like query language, cool (Xtext-based?) tooling and an extensible query orchestration and interpretation framework. The SAP team announced that an integration with the CDO server side is very interesting.
  
  
• Frederic Jouault and Hugo Bruneliere compared Eclipse modeling and Microsoft Oslo technologies and had some ideas how to bridge the two worlds and transform artifacts between both. They mentioned that Oslo misses a model repository.
  
  
• Cedric Brun demonstrated the Acceleo generator tooling and gave insights to the process of bringing this project into Eclipse.org. The tooling looked so comfortable that I thought I should give generative approaches a new chance in the CDO code itself.
  
  
• Kenn Hussey and Raphael Faudougave a BOF and a talk on Papyrus, the new integrated modeling environment at Eclipse.org. These ones were really interesting because some large companies announced that they want to participate in a general initiative with the goal of providing a commercial quality modeling tool with various diagramming support, queries, refectorings and a lot more. CDO was seen in the center of this new architecture to provide client-side scalability, model storage and collaboration.
  
  
• Markus Herrmannsdoerfer gave a talk that I awaited for a long time already. It was about the COPE framework that seems to do a great job to assist with model evolution (they call it adaptation) and the subsequent instance data migration. Very interesting stuff! Many CDO users have asked for more support in this area and it's clear that we need to provide solutions in a world of changing businesses.
  
  
• Hajo Eichler demonstrated his ideas on executable models. And he did that very well. Last not least because he copied major parts of my own slides. Sure, he asked for my permission, but because he also changed the copyright to his own's Ed announced that we might send the police after him. Two minutes later we could hear their alarms from outside and he got really worried. Poor Hajo!
  
  
• Goulwen Le Fur gave an introduction to the new Extended Editing Framework project which is about generating "sexy" properties sheets and possibly object data entry forms. I really hope that they add support for reflective models soon, so that we can use this cool technology in our CDO Explorer UI.

Today it's exactly one year ago that I startet blogging and since that time I was allowed to realize how much positive impact a little marketing can have on a technology like CDO. Some of my friends startet a private competition in finding modeling talks at the summit with no mention of CDO. Not an easy task ;-)

I realize that these days more and more modelers are interested in a model repository, either for using it as a runtime platform for their own products or for storing their design time models. I'm glad that we, the CDO team, have forseen this interest and for the future I hope that we can have even more collaboration and consolidation with other efforts in this area:

Please work with us
on adding the cool features to CDO that you need!

EMF Tips #3: Why should I want to generate editors?

I thought about treating you with more of those beautiful flowers in Ed's garden but there's still material from our trip to Toronto. Thanks to Dave (Dave, the book, not the Google Bear!) and Kevin for organizing cool downtown and clubbing tours. And for demonstrating how dynamic IBM really is. Thanks also to Lynn and Kenn for showing us Ottawa. Damn, from getting almost one finger between Toronto and Ottawa on the map I deduced that it might be an hour's trip. It is not! Canada is sooo big.


So, why should I want to generate editors for my models? Have you ever thought about this? Or are you politely generating these editor plug-ins, just because it's possible? Or fun?


You might remember that I have 28 models in my workspace. Let's, for a moment, assume I generated 28 additional editor plug-ins into my workspace. A lot of code to maintain and we should be absolutely sure that this is (a) necessary and (b) appropriate!


To judge if it's necessary to generate editors on a per-model basis we need to compare the generated code of two such editor plu-ins. Interestingly, it boils down to a single difference in the initializeEditingDomain() method where the ItemProviderAdapterFactory for the model is added to the ComposedAdapterFactory. More interestingly, the editor will continue to function properly even if you remove this model-specific line! The reason is that the ComposedAdapterFactory delegates to a registry of descriptors which are contributed to the extension registry by the edit plug-ins. You see, it's clearly not necessary to have a generated editor per model.


And usually it's also not appropriate to have vast numbers of editors that are all alike. Model editors are a means to implement functionality that is orthogonal to the models. Things like ordering of nodes and properties, changing colors, fonts and so on are achieved by customizing the editor. I really don't want to duplicate all these UI-related, i.e. model-independent, aspects over 28 editors! And don't forget, your model can be used in other generated editors (other than the one that has been generated for this particular model).

All we need is a single generated editor for all our models.

Eventually we'll need additional editors for additional UI-related requirements, but not for additional models. The same arguments are certainly valid for the generated wizards. One difference between the generated editor plug-ins that I did not talk about, yet, is the editor and wizard markup in the plugin.xml. Our reusable editor would at least have to be prepared that it can be associated with different file extensions, depending on the set of deployed model or edit plug-ins.

EMF Tips #2: Tweaking my Genmodel

The major part of this month I've been on vacation in Toronto and spent a wonderful time with René, Ed and Frank. Ed's garden is as beautiful as one might expect and I was busy collecting evidence of that.


Too busy to keep up with my EMF Tips blog series. In part #1 we discussed ways to easily generate multiple models. Thanks for all the helpful comments.


This part focusses on tayloring and tweaking the outputs of a single generator model. The default Genmodel properties lead to generation of four plug-ins: model, edit, editor and tests.


We will always need the model plug-in itself but often we don't need all of the other three outputs, so how do we exclude particular plug-ins from generation?


The Genmodel has a properties category for each of the output plug-ins: Edit, Editor and Tests. Completely switching off the generation of any of these is as simple as deleting the respective Directory property.


The generator UI will immediately reflect this by disabling the respective Generate menu item. Even the Shift+Alt+G dialog from tip #1 will adjust accordingly.


The next part of this series will focus on the interesting question "Why should I want to generate editors?". For now, you'd know how to avoid it. Stay tuned.


I was just told that there are still three seats available for the Eclipse Modeling Code Camp training that Ed and I will be giving next month (starting October, 12th) in Munich. Don't miss this great opportunity to spend four days with us and become

the world's greatest modeler!