Kai Kreuzer

Code and Data in the Light of DSLs

Posted on July 3, 2007

In the keynote at TSSJS, Martin Fowler talked about one of his favorite topics: Domain Specific Languages (DSLs). In his point of view this is all about writing readable code that speaks for itself and doesn't need any further inline documentation to be understood. That general purpose languages such as Java do not fulfill this requirement can be at the vast number of proprietary XML configuration files, each of which is based on his own little DSL, according to Fowler. I agree with him that extensive XML configurations do not help the readability at all and rather result in the infamous XML configuration hell. With the advent of Spring, more and more information is moved from the code to XML files and although the Spring team doesn't see any problem with this, projects like the SpringIDE hint that there is some lack of readability in these files and that a tool-supported representation of the information might be of help.

But didn't we just mix up two different things: Java and XML? Java is used to write code, while XML merely holds some configuration data. Is that really the case? And what is actually the difference between code and data?

Code vs. Data
On machine level, its all just bytes. A memory range can store machine code and/or data, and there is no sign on what the information is supposed to be. It is easy to execute data - buffer overflow exploits demonstrate this daily. Higher level programming languages such as Java introduce a strong separation of code and data in order to prevent such security holes. XML is widely used for configuration data and for the exchange of runtime data (think of web services or message queues). But then there are things like HTML, BPEL, etc. Do these merely hold configuration data or are they actually code? What about a script that is stored inside a database and executed via the Java Scripting API? And what is a rule in jRules? The boundaries between pure code that defines the sequence of the operations and data that influences the decisions in this sequence has become completely blurred. It is a matter of personal taste where configuration ends and code starts - only the power of the syntax might be used here as a guide and as a starting point for discussions.

Use Cases of DSLs
Let's come back to DSLs. Do they now address code or configuration? After aboves elaboration, the answer is both. Although the general discussion of DSLs often refers to DSL-enabling languages like Lisp and Ruby, and by this at the description of code, there are also frameworks like openArchitectureWares xText that help to describe models, i.e. data structures with a DSL. Fowler distinguishes between external and internal DSLs. Not wanting to draw a line here, I am still tempted to say that internal DSLs are usually a better match for code, while external DSLs are a good candidate for data.

DSLs and XML
So will DSLs be a solution to the XML configuration hell? I do not believe so. As I said, on the one hand the public discussion is much more about dynamic languages that are seen as the saviour for many problems - for code. On the other hand, XML languages still spread unmolestedly and there is no end in sight - but that's what XML was about right? Having an XML Schema as your DSL simply gives you a platform independent format with tool support (XML editors and parsers) for all you ever wanted to express. What is just lacking is the readibility that Fowler asks for. But instead of replacing XML and XML Schema with some well-readable DSL, the market seems to strive for a different solution: It regards XML merely as the serialisation format and provides graphical editors on top of these. Now that is readable as a diagram looks so much better than XML code. We just might now end up in an editor hell - you will need a vast set of editors (all with a different user experience of course) just to configure your application. So how will we change this if we just have "vi" available on a remote console? Well, let's hope that the XML format is still human-readable and that the XSD is somewhere near!

Summary
The dilemma is that XML Schemas are the most widespread DSLs, while not offering a good readability. The current discussions on DSLs won't have any impact on this fact - in contrast, in our heterogeneous world XML will continue to spread not only as a configuration or data format, but also to express programmatic logic (e.g. BPEL). Instead of having an easily readable format, more and more graphical editors will become available to ease the work with these XML formats and to make them available to (business-oriented) people that are not at ease with XML.

OSGi - the new Java enterprise container?

Posted on July 2, 2007

Counting the number of sessions on OSGi, one could get the impression that this is just in its trigger phase of the Gartner hype cycle. But looking a bit closer, this technology does not seem to follow the usual pattern: OSGi is around already since 2000, at that time targeted mainly at the embedded systems world. Slowly but steadily, it has crept into more and more markets. It has by now already proved to be a stable and well-functioning platform for Eclipse and it is used in many software products like IBM Websphere Application Server (WAS) or Adobe Version Cue without anyone taking great notice. How mature OSGi already is, is demonstrated best by the fact that the OSGi Alliance has admitted that the abbreviation OSGi doesn't actually mean anything in special (formerly it should stand for "Open Service Gateway initiative").

So what is OSGi then all about? The OSGi Alliance defines it as a "dynamic module system for Java" and as a "Universal Middleware". It indeed is a component container, specialized on the clear separation of the components and their flexible lifecycle management.

OSGi and Java EE
Originating from the embedded world it is per se lightweight, in absolute contrast to an Java EE compliant application server stack. That should not say that OSGi tries to compete with Java EE, though there are many scenarios where OSGi might be the better (because lighter and leaner) choice altogether. Instead, it can also improve current Java EE architectures by modularising existing EARs and by introducing strict dependency management rules. Using an OSGi container on top of an application server brings benefits like the possibility to transparently replace a module during runtime or to run multiple different versions of a module at the same time.

OSGi and Spring
Talking of lightweight containers, Spring quickly comes into ones mind. Although Spring proponents will argue that one cannot compare Spring with OSGi as both try to achieve different things, they yet do not intervene when somebody says that Spring will be the next Java EE. So as we have already compared OSGi to Java EE, it must be allowed to compare it with Spring likewise. They both are lightweight containers, trying to decouple the parts of a modern software architecture. While Spring tries to reach this goal on a very fine-grained (object) level with dependency injection and aspects, OSGi introduces a rigorous dependency management and a runtime seperation of modules using different classloaders.. Where Spring declares its beans in the application context xml, OSGi declares its exports and services in its manifest. Both containers therefore do similar things - but with quite different means. Both approaches are beneficial for the software architecture and therefore it is legal to say that Spring and OSGi are a perfect match - with the reservation that the configuration has to be merged (and redundancies removed) and that Spring lets itself deploy inside an OSGi container. This is what the Spring-OSGi project is all about, which is scheduled to be released in August.

OSGi and Maven2
Alright, Maven2 is definitely no container by any means, but still it has one striking similarity to OSGi: The profound dependency management with automatic resolution of sub-dependencies and different versions. Maven users are blessed by not having to care about where to retrieve their dependencies from and how to put them all correctly in the build path. The dependency declarations in Mavens pom.xml is very similar to the information in OSGis manifest file. Wouldn't it be great to automatically map this information? Luckily, somebody is already working on this: There is a Maven2 OSGi plugin hosted by Apache Felix, an open source OSGi implementation project. Unfortunately this currently seems to work only one way - to generate manifest information from the pom.xml. Developers who are used to implement Eclipse plugins and therefore like the tool support to maintain the dependency information in the manifest file will still have to find some solution how to sync this information.

OSGi and the JCP
OSGi and its concepts have already a long history in the Java Community Process: Already in 1999 the JSR-8 has been submitted in order to specify OSGi within the JCP. Out of some reason that was withdrawn and the OSGi Alliance did the specification on their own. Currently, there are the JSR-277 and the JSR-291 which address modularity and dependency management (JSR-277) resp. dynamic lifecycle management (JSR-291) for Java. While JSR-277 is trying to do something very similar as OSGi already offers, the Expert Group of JSR-291 has decided to fully adopt the OSGi specification a few weeks ago. It is therefore very likely that OSGi is going to be part of Java 7.

Summary
Whereever there is the need to modularize a complex system or to dynamically start/stop/replace single modules, OSGi is definitely worth a try. There are stable and mature implementations available like Equinox which builds the core of Eclipse, with which it is easy to start and to have some first results in a matter of a couple of hours. Having the JCP now embracing the OSGi specification, it is obvious that OSGi is a key concept for the future of Java in general.

TLAs around SOA - is it all just hype? (Part 3)

Posted on July 1, 2007

Besides the rather negative impressions of JBI and BPEL (see parts 1 and 2), I also enjoyed a refreshingly positive session of Gregor Hohpe from Google about Event Driven Architectures (EDA). Having heard of them so far only in the context of SOA, I didn't expect much at all. Instead, Gregor presented a pragmatic example of how EDA can work - without any complicated containers, service infrastructure or anything like that - simply with pure Java. The core consisted out of one single class called "Channel" which allowed sending and subscribing events. On this he has built an application that is very loosely coupled as there are hardly any method invocations. Instead, all application flow is caused by the exchange of events. He pointed out some big benefits like the possibility to easily switch between two modules with the same functionality or even run them at the same time for test purposes. Furthermore it is possible to replay the event chain and therefore reproduce states from the past. And of course, this programming model makes logging as easy as with AOP (or even easier?) as all one needs is a class that subscribes and logs simply all events.
Certainly this approach is not applicable to any kind of problem, but it is definitely worth to be considered in many cases.

TLAs around SOA - is it all just hype? (Part 2)

Posted on June 30, 2007

The next TLA - well here we have a rather a rare occation of a FLA - is BPEL. Reading sales brochures, BPEL is already used everywhere and the swiss army knife for your service orchestration. Talking to Tom Baeyens at breakfast, he pointed out that he is happy that nobody really yet succeeds with SOA, so his jPDL solution has had a good chance to spread without much competition. We seem to be on the right track with our proprietary tooling at Odyssey as nobody else really has anything much more sophisticated to offer, while suffering the same problems like not being able to factor out the technical details from the model used for the graphical designer. There is no good solution yet to easily exchange the technical part of the model by another one, e.g. for a different platform. This becomes very obvious when looking at the jBoss jBPM solution: Although using a common runtime platform, there are two designers for BPEL and jPDL that are completely independent from each other. Tom agreed that it is not feasible trying to have one graphical designer that can be used to create files for different execution languages. Therefore I don't feel so bad anymore about the fact that we didn't really manage to define a platform independent model (PIM) for the graphical designers of our in-house pageflow and workflow solutions. The current BPEL tools are meant to improve the communication between IT and business by allowing business people to sketch their ideas and have the developers fill out the details. From this moment on, the BPEL artifacts are read-only for the business to have a ground for discussion, but changes should only be done by developers. In our case, where we ship a default version of a diagram, the business consultants are supposed to specify the necessary customisations for a specific customer. Our goal is therefore even higher than the usual BPEL use case. Time will tell whether this is at all a feasible approach!

TLAs around SOA - is it all just hype? (Part 1)

Posted on June 29, 2007

One expects of conferences that one is thrown at with all the latest TLAs. SOA being one of these for a while already and in the SOA context one also hears about things like ESB, EDA, JBI, SCA, BPEL and so on. Having tried to make any sense of these by reading magazines or listening to podcasts, I truely must admit that attending the TSSJS really helped me to get a clearer picture. E.g. it seems to me that one can forget about JBI - it is one of the technologies being speced and tried out in the real world only afterwards. Sadly however, the spec mainly aims at vendors, while they show no interest (only Sun backs it, while IBM and BEA stop their participation in the JSR). Trying to be yet-another-service-container, this mission is likely to fail and so I come to my personal conclusion that it's not worth the effort to dive into. Another clear sign for me was that none of the attendees of a JBI session was actually using JBI nor considering the use for the future...
Instead, SCA seems to have much stronger industry support, also being some kind of service container, but targeted rather towards the application developer than at the platform vendors. Nonetheless it is in its early stages and one will have to see how the adoption rate is going to look like.