Simon Zambrovski

After Microsoft joined OMG the move towards model-driven software development became obvious. Microsoft already put some effort on the development of DSL technologies. But OSLO is something much bigger, so let’s try to predict what it could be….I’m not employed by Microsoft. I’m not working on OSLO. Still, I’m interesting in MDSD and the technology bunch around it. It was difficult to oversee, that Microsoft left the “very confidential” stage and allowed several people to tell a little bit about the OSLO project. The official statement says that OSLO is: a language, a tool, a repository… For me, the questions about these terms have the following priority: language, repository, tool. I think the latter two are the way, how Microsoft will earn money. The language is the most interesting part for me.The advertising machine is running and the Microsoft celebrities are inviting everyone to the Professional Developer Conferences (PDCs):

Don Box

Don Box (here) intoduces an intersting list:

• COM Type libraries
• .NET metadata attributes
• XAML
• OSLO

This means to me, that we speak about a declarative language, with own type system, that allows to develop own types in order to describe entities from my domain. I have no clue, why the link to XAML is present. Maybe, if we speak about a language for data modeling, the representation can be created using XAML.Then Don says, that Microsoft develops a textual internal DSL for modeling. In the same time, he speaks about “visual design” that is applicable to the same model. This seems a little wierd for Microsoft, but is well adopted in Eclipse Ecosystem (e.g with a combination of Xtext and GMF used as two representations linked to the same metamodel). The model repository emerges as a database, which can be compared with Teneo Approach.The next paragraph seems very confusing to me, I’ll try to remove buzzwords out of it: I can write an application by populating the repositry with the definition of my app. Our goal is to make it possible to build apps purely out of data. If not possible, the goal is to make the transition to traditional code easy.

Douglas Purdy

Douglas Purdy is another one who is allowed to natter about OSLO. It seems that the tool chain is pretty ready, because of his wish to use community feedback in order to improve it. Apart of this, he does not reveal any details.

David Chappell

So, I searched a little in the Internet and finally found the following interview with David Chappell. He reveals much more details:

• The language is a designed to create so-called schemas. (or metamodels, how I understood this)
• A schema is something, to that models (schema instances) are conform.
• Both schemas and models (schema instances) are stored in repository.
• There is a way to use the tool (the editor) with both: schemas and schema instances.
• There are some predefined schemas (DSLs, metamodels), which can be used to describe: activities, workslows, systems, etc..
• There are some additional tools that are built upon the DSLs (e.g. process server)

From this point, the OSLO stuff begins to make sense for me. The basic language seems to be a kind of a meta language (meta-meta-model) for definition of DSLs for different purposes. The produced DSLs seems to be defined in a way, that the instances have the same form as the schemas - because of uniform repository and bindings of visual and textual editor. Still, I have no clue how dynamics can be realized.

Darryl K. Tafft

Darryl K. Taft writes on eWeek. Here things gets names, and technical details beging ta make sence. The language is in fact declarative and is called D (has nothing to do with another language called D). Now, after the words of David Chappell, the following text makes more sense: “We’re trying to make it simple to get an idea out of your brain and onto a hard disk” - he is not speaking about a DSL, but about D, which is designed to develop DSLs. Finally, another very important sentence: An Oslo user need not learn the D language to use Oslo, however. “The language is a technical detail for a certain audience,” Lovering said. - this is something clear to me, because you don’t have to understand the DSL definition in order to be able to use a DSL. In addition, if the DSL is both, graphical and textual, you possibly only need to understand the pictures (I argue if the productivity can really be boosted in that way, but this is another story).Then, after I thought that I got the idea, a very strange sentence apears: The Oslo language also is partially based on TLA+, a language developed by Microsoft researcher Leslie Lamport, Lovering said. In fact, I know what TLA+ is, because I used to work with it. TLA+ is untyped formal language for description of dynamics of concurrent systems. It uses actions (arbitary mathematical statements) to describe the change of system behaviour. Leslie Lamport and his team developed a model checker, that can verify temporal and logical properties of the modeled system. The only link I know is tha fact, that Leslie Lamport worked together with David Langworthy, who is working in “Connected Systems Division” and seems to be involved in the development of the D language (he is one of the speaker on PDC).Maybe there is a kind of a action dynamics defined on top of schemas stored in repository. In fact I hope that D is not a behaviour description language.

Mary Jo Foley

Finally, the last source I reviewed for information were several posts ( 1, 2, 3) of Mary Jo Foley.Microsoft is planning to ship a set of predefined schemas within the repository, but customers and software vendors will be able to add their own. - this seems to be the idea of multiple predefined DSLs, because otherwise we will just speak about simple structure of a database.

Summaries

I think in this point of time it does not make sense to gather more sources of OSLO. OSLO seems definitly interesting, and will be published in the end of October. Microsoft entered the modeling arena - this will create a new army of people who understand the words model, DSL and generator. I’m still interesting in the D language: it seams to be declarative, text-based schema definition language with a graphical representation. The defined schemas can somehow be stored in a repository, based on a RDBMS. There are still many open questions like: How to handle dynamics? How to create applications from data? What is the relationship between D and TLA+, I’m familiar with? The best thing is to wait, they will answer the questions soon.

Yesterday, the second Adam Bien event in Lehmanns Bookstore took place. Again, the event was a full success. I arrived half-an-hour earlier and got a seat only in the tenth row. Adam spoke about new features of EJB 3.1 and Glassfish. He showed examples running on a developer build of Glassfish V3, promising that the features will work without exceptions… Here are some topics, I remember:

• Singleton Beans: usefull a s a central point of the application, e.G. central cache etc…
• Async Methods: allows asynchronous execution of time-consuming methods. Especially, it is possible to abort the execution
• Deploying Beans in WARs: could be helpful for small applications
• Global JNDI-Namespace
• No interface view: simplifies the access to beans, if needed
• EJBCOntainer.getEJBContainer().getContext(): allows external initialization of bean context, which is nice for testing

Later, Adam discussed some Core J2EE patters, that become absolete with EJB 3.1 and others which are still valid. After the talk, I spoke with Adam about the OSGi as a module architecture inside JEE application, which seems interesting to me. The pictures are as usual available in my FlickR Gallery.

Yesterday, the OSGi session took place in Hotel East in Hamburg. Peter Kriens, the OSGi evangelist showed a wonderful Zen Presentation on OSGi. I wrote a lot during his talk which happens to me very seldom. Here are the core statements I understood:

• The core difference between usual plugin architectures and OSGi is that OSGi concentrates on collaboration of the components.
• OSGi delivers a controlled environment, in which the question if a component runs or not can be answered in beforehand.
• OSGi bundles use metadata (about versions, dependencies, etc) to predict an error, not discover it in runtime.
• OSGi has a very narrow API containing the minimal common part.
• OSGi consists of module, life cycle and services layers. The initially developed services layer required smart class loading mechanisms (module layer).

1. The module layer is desigend to control the class loading machanisms (e.G. structureal class loader hierarchies instead of a linear classpath)
2. Life cycle layer adds a management API (e.G. inform the others about installation event)
3. Separation of concerns is promoted by definition of services for different tasks.

• Services are used for decoupling of system parts (This is a standard application of service-orientation).
• OSGI makes dependencies explicit (private, import, export)
• OSGI tries to make the system managable, taking dynamics and lifecycle as fisrst-class citizens
• OSGI will be extended to support distribution: the team works on policies, SLAs, etc…

I liked the talk and the way how Peter Kriens addressed the problems of OO in big systems. I was confirmed in some ideas about coupling that will be layed out in my thesis. After the presentation we had a delicious meal and wraped up the evening with interesting discussion about pros and contras of OSGi. Peter Friese showed me some remote OSGi staff, he was playing with. The lack of documentation in this area makes it a little difficult, but I hope he will post some news on it. As usual, you can find other pictures in my FlickR gallery.

Yesterday, the second Eclipse Stammtisch Hamburg took place. It was nice to see the Hamburger community again. I had the opportunity to speak with Ralph about the activities in consortium and about the innovation netoworks, about German education system and other subjects. It was a very interesting discussion, even it was a non-technical one.  Later, we discussed the xText development with Peter.

As usually the rest of pictures can be found in my flickr gallery.

The vacation time of most people is over, so it is time to meet and discuss a little. A good opportunity to do this will be given on September 1st in Roxie, Hamburg during the Eclipse Stammtisch. The event name translates into regular’s table and indicates a regularity of the happening. Even if the upcoming event is only the second in series I expect to meet many people after the great feedback after the last one.

Details:

• When: Monday, September 1st, 19:00 CET
• Where: Roxie, Hamburg, Germany
• Directions: http://www.roxie-hamburg.com/roxieway.htm 
• Who’s comming: Doodle Poll

See you next Monday.