I was (still am) extremely disappointed at not having made the trip to Las Vegas to present my bit on OSGi at theserverside.com Java Symposium. To date, I am still waiting for my USA visa 😦 The TSS folk and myself have had a quick exchange about me doing a webcast later on this topic. Let’s hope we can pull it off.
Well, the event has come and gone, but you can download my presentation at http://wiki.javasymposium.com/download/attachments/501/Aslam+Khan-OSGiPresentation.pdf
I’ve been struggling with the problem of modules for almost my entire working life. And I am convinced that this area of architecture is one of the most underrated challenges. By definition, a module is a set of parts that can be used to construct a more complex structure. Let’s work backwards. Given a complete design or architecture for a problem domain, we should be able to break into parts and then reassemble these parts to reconstitute the original architecture. We, most probably, can justify any form of decomposition strategy, be it functional, sub-system boundaries, sources and sinks of data, etc. Working forwards is a lot more difficult. Creating parts from nothing that can then be assembled into a complex structure is not easy because we often don’t know what the final structure will look like. This exercise is complicated further when working in an agile manner, where a big design up front is against the grain of short, sharp iterations of analysis, design, test, code, release.
Now think back to the start of a new project, those days where you first tackled a new problem domain. Those days are spent analyzing the domain. And if it was complex domain, you most likely started fragmenting it so that it was conceptually possible to understand little parts at a time. Eventually, you reach a single point where everything clicks into place. That’s your light-bulb moment. It’s an immensely satisfying moment that is filled with a great sense of achievement. And with this fulfilling sense of accomplishment, you naturally carry that conceptual decomposition into the design exercises.
In this very act lurks the conflict. Our modular decompositions created for conceptual understanding is often carried, unconsciously, into architectural designs. In my experience, it is very seldom that the conceptual parts are left alone for conceptual understanding of the problem domain and that a separate effort is expended to focus on modular decomposition for architectural soundness. This resonates back to the days when a huge database design was created early in the project and it was the most static design artifact of the solution. Anything that came afterwards, was morphed to fit in with uber-database design.
I think that the reason for trying to maintain that static set of modules (or that database-design-cast-in-stone) is that refactoring of modules is very immature. At best, it is downright painful because it often results in pruning your source tree. Domain Driven Design is very explicit about modules. There are modules of varying granularity. Tiny modules made up of aggregates or an aggregate and its repository. Big, fat modules based on bounded contexts. Medium sized modules that cohesively fit together because they tell a story in the domain. This is great, but refactoring modules as you discover more of the domain is still frightening. But I digress and will elaborate on module refactoring in another post.
I do view modules as parts that can be assembled to construct the complex whole. But I also view modules as part of a graph, kind of. Every module has a meaningful domain relationship to another module. Each module needs another module to fulfill some feature that is required of the complex structure. It is rare for a module to be completely disassociated from every other module. If a module is disassociated, then is it part of the whole? Hence, the module graph perspective. The graph of modules is likely to be significantly different to the modules that are the result of conceptual decomposition during analysis. This graph of modules is a design exercise, not an analysis exercise. By focusing on domain correctness and meaningful relationships that are true within the problem domain, we can still achieve sound architectural principles. Each module has a public interface and shields internal complexity from its neighbors. This gives us low coupling and good separation of concerns that reflect the reality within the problem domain.
I also believe that using a domain driven design approach that focuses on reflecting reality, will allow for less painful experiences in refactoring modules because the domain must change significantly to force changes to the natural interconnection of its parts. Sure enough, when a business changes strategy, its domain changes which will result in significant changes to modules. But that’s an exception.
So, ask yourself these questions:
There is a thought that has been floating in my mind like an infectious song over the last few weeks and it is Niclas Nilsson’s fault! He posed the question “AOP- Why don’t people get it?” The essence of AOP is the application of old fashioned patterns, mixins and interceptors, using, most commonly, run-time sub-classing techniques. Also, important is that the mixins and interceptors (i.e. the aspects) can be weaved into any object, immaterial of it’s type, place in a class hierarchy, etc. The fact that this happens at run-time in a non-linear fashion (sort of) creates this air of magic around AOP. Not to mention that AOP has some really weird terminology to describe previously well understood concepts.
Andrea Provaglio also participated in the discussion and made the observation that a style class in CSS is, perhaps, an aspect because it alters the appearance of the HTML element to which the CSS style is applied at run-time. Again, I think that if CSS was explained in the language of AOP, it would probably have taken a longer time to gain wide-spread acceptance. What CSS succeeded in doing was to apply a language set consistently, introducing new terms that could be explained using existing, easily understood terms. Even though certain terms (e.g. class) have different meanings when used in the CSS domain, these terms have a foundation in clearly understood concepts.
From a DDD perspective, the use of ubiquitous language is very apparent and thorough in the domain of AOP (i.e point cuts, join points, introductions, advices, etc.). However, I think that the bridge between the language set in the AOP domain and language set of the patterns domain and object orientation domain, from which AOP is derived, is missing. Let me clarify my point with another question: “Would AOP have gained greater acceptance and understanding if it adopted a ubiquitous language set that transitioned already understood concepts (interceptor, mixin, subclassing, etc.) to introduce the newer terms (point cut, join point, advice, etc.)?”
There are three DDD subtleties lurking here:
Earlier this year Jimmy Nilsson of factor10 presented a great talk entitled “Domain Driven Design – Is it more than just Entities and Repositories?” at PBT Group in Cape Town. I certainly agree with Jimmy: it is more than just entities and repositories. While the entity, value object, repository, factory and other patterns are commonly sprinkled in a rich domain model, the subtleties of DDD such as bounded contexts in strategic design are easily forgotten.
A recent article on infoq.com raised the question Can DDD be adequately implemented with DI and AOP? The arguments are valid in that infrastructure code can be best isolated from a rich domain model using AOP and DI. This is not at all different to Mats Helander’s earlier article on Looking after your domain model.
However, I cannot help the aching feeling that a large part of DDD is being lost with an often blinkered focus on the lifecycle patterns (repositories, aggregates, factories, etc.) and structural patterns (entities, value objects, services, etc.). For example, I am currently focusing a lot of energy with Tania van Niekerk (a work colleague) on the issue of designing for modularity. Modularity is deceptively complex and DDD’s strategic design (bounded contexts, anti-corruption layers, transformations, etc) is certainly helping in us finding a solution.
My take: I agree that AOP and DI do contribute in keeping infrastructure out of a domain model but, more importantly, I agree with Jimmy that there is a lot more to DDD than entities and repositories.
This is something that I have been meaning to do for some time now, i.e. an OSGi cookbook. So this is the first in a series of recipes, with each one building on the next in usefulness and complexity. This recipe is really for newbies, just to take some of the mystery out of OSGi and to introduce some of the emerging tools for OSGi development. If you have never done anything with OSGi before, then I recommend that you work through Neil Bartlett’s excellent series on getting started with OSGi.
Ensure that you have maven andthe pax-construct scripts installed.The installation is straight forward, just follow the instructions on their respective web sites.
This recipe creates a service out of a simple POJO. The service doesn’t do anything useful, but the recipe is a simple way to getyour development environment up and running.
net.aslamkhan and artifactId of osgi-simplebean.
/> pax-create-project -g net.aslamkhan -a osgi-simplebean
...
[INFO] Archetype created in dir: /Users/aslam/projects/osgi/osgi-simplebean
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
/> cd osgi-simplebean
/> ls -l
-rw-r--r-- 1 aslam aslam 2354 Jan 9 10:26 pom.xml
drwxr-xr-x 5 aslam aslam 170 Jan 9 10:26 poms
drwxr-xr-x 3 aslam aslam 102 Jan 9 10:26 provision
/> mvn package
...
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] ------------------------------------------------------------------------
[INFO] net.aslamkhan.osgi-simplebean (OSGi project) .......... SUCCESS [1.689s]
[INFO] osgi-simplebean - plugin configuration ................ SUCCESS [0.004s]
[INFO] osgi-simplebean - wrapper instructions................. SUCCESS [32.144s]
[INFO] osgi-simplebean - bundle instructions ................. SUCCESS [0.003s]
[INFO] osgi-simplebean - imported bundles .................... SUCCESS [0.002s]
...
pom.xml file(s), we again use a pax-construct script to add the repositoriesfor the Spring distributions. From this point onwards, I will not show the output of commands unless it helps to illustrate a point.
/> pax-add-repository -i spring-milestones
-u http://s3.amazonaws.com/maven.springframework.org/milestone
/> pax-add-repository -i spring-snapshots
-u http://static.springframework.org/maven2-snapshots
-- -Dsnapshots "-Dreleases=false"
/> pax-import-bundle -g org.springframework.osgi
-a spring-osgi-extender -v 1.0-rc1
-- -DwidenScope -DimportTransitive
If you look at the contents of the provision/pom.xml file, you will see a bunch of dependencies that have been pulled inthe moment we imported the spring-osgi-extender bundle.
<dependency>
<groupId>org.springframework.osgi</groupId>
<artifactId>spring-osgi-extender</artifactId>
<version>1.0-rc1</version>
<scope>provided</scope>
</dependency>
...
pax-create-bundle script. In this instance, we will create a sample bean with the necessaryboilerplate files needed for Spring Dynamic Modules.
/> pax-create-bundle -p org.example.bean
-- -Dspring -Djunit
Notice that another directory org.example.bean has been created. Furthermore, this maven module has been added to the root (i.e. parent) ./pom.xml file. Also conveniently created, is asample bean and associated unit tests in org.example.bean/src directory.Edit the org.example.bean/src/main/resources/META-INF/spring/bundle-context-osgi.xml file to contain the following.
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
...
xmlns:osgi="http://www.springframework.org/schema/osgi"
...>
<osgi:service ref="myExampleBean">
<osgi:interfaces>
<value>org.example.bean.ExampleBean</value>
</osgi:interfaces>
</osgi:service>
</beans>
pax:provision goal.
/> mvn clean install pax:provision
... properties (org.springframework.context.service.name=org.example.bean)
->
Let’s check if our org.example.bean bundle is installed and active. From the Felix console, enter the following.Also notice that the spring-osgi-extender bundle and spring 2.5 jars are now available as bundles as well.
-> ps
START LEVEL 6 ID State Level Name
[ 0] [Active ] [ 0] System Bundle (1.0.1)
[ 1] [Active ] [ 1] org.osgi.r4.compendium (1.0.0)
[ 2] [Active ] [ 1] Apache Felix Shell Service (1.0.0)
[ 3] [Active ] [ 1] Apache Felix Shell TUI (1.0.0)
[ 4] [Active ] [ 5] spring-osgi-extender (1.0.0.rc1)
[ 5] [Active ] [ 5] jcl104-over-slf4j (1.4.3)
[ 6] [Active ] [ 5] slf4j-api (1.4.3)
[ 7] [Active ] [ 5] spring-osgi-core (1.0.0.rc1)
[ 8] [Active ] [ 5] spring-osgi-io (1.0.0.rc1)
[ 9] [Active ] [ 5] spring-aop (2.5.0)
[ 10] [Active ] [ 5] spring-beans (2.5.0)
[ 11] [Active ] [ 5] spring-context (2.5.0)
[ 12] [Active ] [ 5] spring-core (2.5.0)
[ 13] [Active ] [ 5] spring-web (2.5.0)
[ 14] [Active ] [ 5] spring-test (2.5.0)
[ 15] [Active ] [ 5] aopalliance.osgi (1.0.0.SNAPSHOT)
[ 16] [Active ] [ 5] backport-util-concurrent.osgi (3.0.0.SNAPSHOT)
[ 17] [Active ] [ 5] slf4j-simple (1.4.3)
[ 18] [Active ] [ 5] org.example.bean (1.0.0.SNAPSHOT)
->
Now, check that the service is available.
-> services
...
org.example.bean (18) provides:
-------------------------------
org.example.bean.ExampleBean
org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext,
...
That’s it for this recipe. Overall, pax makes it really painless to get your OSGi implementation up and running in your developmentenvironment. Combined with the convenience of spring-dm, we have the start of something really productive.
The next software architecture workshop (SAW) originally convened by Jimmy Nilsson is being hosted in South Africa this year between 21 January and 24 January 2008. This is my second SAW and if it is anything like the one last year, then it is going to be a heady mixture of geek-speak, constructive debate and fun.From a PBT Group perspective, we are taking advantage of having a few of the leading software architects in the South Africa. In conjunction with the Johanessburg Centre for Software Engineering, we will be hosting a JRuby Master Class in Johannesburg (16 January 2008) and Cape Town (29 January 2008). Andrea Provaglio will be giving up his time for the JRuby events. You still have time to register for the Cape Town JRuby Master Class.The second event is Aiming for a factor10 being hosted by PBT in Cape Town on 30 January 2008. Jimmy Nilsson will be talking about Domain Driven Design and Niclas Nilsson will be talking on dynamic languages. Registration is on the PBT website and is still open.
Mats Helander has written an excellent article on how to manage your domain model with some intelligent design trade-offs. It’s a lengthy article that even manages to introduce AOP as well. If you start reading it and wonder where it’s going, just carry on reading…it is written in an evolutionary style. Nice article, Mats! UPDATE: I have written the Java equivalent of the listing in Mats’ article and attached it. The AOP part uses SpringFramework 2.5 and AspectJ.
As part of PBT Group, we are hosting a morning with Jimmy Nilsson and Niclas Nilsson, both of factor10, working out of Sweden. Jimmy is one of the leading thinkers in the field of Domain Driven Design and his topic is Is Domain Driven Design more than just Entities?. Niclas is a highly respected architect and his topic is Dynamic Languages for Statically Typed Minds.This event is a freebie and is scheduled for 30 January 2008 at our PBT Group offices in Cape Town. Registration for the event is on the PBT Group website.See you there!
PBT Group and the Johannesburg Centre for Software Engineering are hosting a JRuby master class led by Andrea Provaglio. I met Andrea at the Software Architecture Workshop in Arosa, Switzerland this year and I cannot speak more highly of him. Just check out his web site for details. It’s not often that we get a chance to have such learned architects and practitioners in South Africa. Let’s take advantage of this opportunity. The greater the support, the easier it is for us to pull in heavy hitters in this industry for future events.There is a class scheduled for Johannesburg on 16 January 2008 and Cape Town on 29 January 2008. Registration is online at the JCSE website. Just follow the links from the front page.See you there!
I will be speaking at the next TheServerSide Java Symposium in Las Vegas in March 2008. The presentation will be part of the FrontLine Java track and will cover OSGi and its use in Enterprise Application Development. This is a more detailed presentation of what I was intending to cover at the *Camp in Cape Town.
f3yourmind 