OSGi Zone - Comments for "Creating a Domain Specific Language for OSGi"

I think the point that this

rh21685 — Tue, 11 Mar 2008 14:32:47 -0400

I think the point that this DSL could be used as configuration language for iPOJO is valid, especially since iPOJO separates out the configuration language for just this purpose (e.g., currently it supports manifest entries, an XML file, and annotations).

The real issue is whether you prefer to learn yet another language or yet another XML markup format. That is probably a personal choice.

The type safety aspect of the DSL is nice, but since iPOJO is integrated into the Maven build process, it at least is able to perform type checking during the packaging process, so you are not completely out in the cold with respect to type checking even if you select the XML approach.

Your article about DSL gives

clement.escoffier — Mon, 10 Mar 2008 13:23:24 -0400

Your article about DSL gives a good overview. IMO, DSL are really useful when they abstract technical details. But, of course, all languages are a DSL (just sometimes finding the domain is difficult).

In fact, what I tried to point out is that component (type) description is a kind of technical DSL too. More precisely, in the case of iPOJO, it's a composition of DSLs: each handler provides its own DSL for its own purpose and they are composed together. I don't believe that one DSL only is enough to describe any OSGi applications (in an efficient way). So, do you plan to investigate how adding other features to your DSL?

IMO, the challenge is to ease the development of OSGi applications to be modular, and dynamic. So for this purpose, I see two different interesting directions (it is not exhaustive) : simplify the development model and externalize a maximum of non-functional concerns, and provide integrated tools (i.e. IDE, SCM, ...) providing guidelines, generation tools, and architecture styles.

BTW, iPOJO is able to sends event too. This is not often used as the Event Admin service is very simple to use. The handler intercept when a field is set. The set value is considered as the event (either your field is an Event, either your value is added to an event created by the handler). It has the advantage to externalize the synchronous/asynchronous publication, the topic...

Clement, there is no need to

roman.roelofsen — Mon, 10 Mar 2008 11:30:30 -0400

Clement, there is no need to defend iPOJO since I said nothing bad about it ;-) But you must seperate between the features offered by iPOJO and the way to configure them. Otherwise you will compare apples and oranges. Take for example the handler mechanism you described. There is no reason not to use this handler with a DSL. Well written, the handler API could be even used as the DSL. That was the whole point of my article.

IMHO, a DSL does not need to be business oriented. It is a language dedicated to special domain (here OSGi) that, of course, can be a technical one. So instead of dealing with objects and methods we are creating a fluent interface for dealing with services, events, etc. The code

context event "TOPIC" ! new MyEvent

is a good example for a fluent interface. Here: Sending an event. While iPOJO helps receiving events, it does not help sending events.

You are free to think different about the term DSL (all IMHO here, of course ;-) but I think this article gives a good overview.

I agree that this is not

pauls — Mon, 10 Mar 2008 11:07:45 -0400

I agree that this is not really my understanding of a DSL either - this is more like syntactic sugar.

Interesting to note that iPOJO however, actually does make for a foundation of a DSL because of its service level dependencies...

First, to improve Karl's

clement.escoffier — Mon, 10 Mar 2008 10:52:31 -0400

First, to improve Karl's comment ( ;-) ), iPOJO provides a quiet simple programming model hiding all interactions with the OSGi framework. In addition, iPOJO is extensible, and so is able to manage the event interaction that you described.

To achieve this, iPOJO instances are executed inside a container. This container is composed by "handlers". A handler is a special POJO which aims to manage one non-functional concern. As you mentioned, it could be an event based interaction (refer to http://felix.apache.org/site/ipojo-event-handler.html).

By using this mechanism, the POJO stills a very simple class despite it uses event based interactions. IPOJO handlers can be developed separately from the iPOJO core and so allow customizing containers for any requirement (persistence, security, event, wire admin ...).

I agree that iPOJO component type description (using XML) is not very elegant despite it tries to be the simplest as possible. For example, to provide a service just write:

<component classname="...MyClassName">
	<provides/> 
</component>

It is not necessary to describe provided interface as they can be computed by iPOJO (the POJO must implement the service interface). By using the same mechanism, requiring a service is quiet simple:

<component classname="...MyClassName">
<requires field="myService"/>
</component>

The service objects will automatically be injected inside the “myService” field. No need to describe the required interface as iPOJO can compute it automatically. The POJO can just use the myService field as any other field of the class.

So, to go further, we can use an "external" handler (developped and provided separately) to allow receiving events:

<component className="...MyClassName">
<ev:subscriber topic="mytopic" callback="receive"/>
</component>

Event published on the “mytopic” topic will be received automatically. At each time a new event is published, the receive method is called.

Secondly, you’re proposing a DSL to develop OSGi applications. Perhaps I'm wrong but a DSL should be in terms of the business logic of your application, not in technical terms such as pointed out

http://www-adele.imag.fr/Les.Publications/intConferences/SCC2007Mar.pdf

Yes, there is some overlap

roman.roelofsen — Mon, 10 Mar 2008 09:50:39 -0400

Yes, there is some overlap with iPOJO, DS, etc when it comes to an interaction with the service registry. However, there are still several use-cases where you need this direct interaction. For example if you want to register a service in the case of certain events. Additionally, a DSL is helpful whenever you need to use an API, e.g.:

context event "TOPIC" ! new MyEvent

is much more readable than doing an event service lookup, null check, sending, "ungetting", ...

Of course, this DSL is an alternative to the XML approach of Spring, DS, etc. But because its dedicated to OSGi I would always prefer the DSL rather than "yet another XML syntax". Additionally, I get type-checking for free and can validate my configuration a priori.

This DSL does not need to be a competitor to iPOJO. Instead, iPOJO could offer a configuration in XML and DSL. Since iPOJO adds more to OSGi than just the configuration (e.g. the component model) I really would like to see a combination.

Regarding your comment on a possible NPE, I assume you meant the Java code for

context service classOf[SuperService] get {s =>
println(s.msg)
}

And yes, thanks for pointing this out. So the Java equivalent would be even longer than the DSL version!

In general, I think this is

pauls — Mon, 10 Mar 2008 09:01:10 -0400

In general, I think this is an interesting idea, however, somewhat obsolete due to the current IOC frameworks around. iPOJO, DS, DependencyManager, and Spring-DM do go a long way when it comes to avoiding direct interaction with the OSGi service registry. Regarding your last examples, iPOJO does a pretty good job in doing all of this and more declaratively - might be interesting to see whether iPOJO's xml approach could be turned into a more readable DSL?

As an aside, your java code for context service classOf[SuperService] add new String("A fake super service") actually does have the potential for a NPE due to the fact that context.getService(ServiceReference) is allowed to return null if the service is not available anymore :-)