JCP Is Dead?

After 4 years it seems Oracle broke Apache's last straw, they left the JCP. Together with the independents. Sun originally promised to make Java a free platform, and I believed them. Guess I am naive but Sun's track record was pretty good at the time. Oracle originally objected to the fields of use restrictions before they bought Java but changed their mind now they're the owner and I guess IBM was bought off. It is surprising how Oracle seems to be aiming straight at their foot, do they regard the open source community as a minor aspect of Java? Is this (long gone after Android & iPhone) mobile market worth the cost of alienating their most fervent supporters?

It is a mess because I do not want to choose. I like the big corporations because the give credence to the Java platform and provide numerous resources to work on the platform. I do not think Java could have been created in an open source environment of volunteers. However, I also like Apache and other open source foundations because they provide diversity and innovation beyond corporate interest. And then again I do not like big corporations because politics often trump best technical solutions and I do not like open source communities because they too often mix idealism and work. Working together they keep each other in a good balance.

What is needed, and what was clearly promised by Sun all those years ago, is an independent organization where industry and open source community can meet and standardize without any one party being special. The OSGi is such an organization. An organization that has a lot of experience with Java specifications as well. Maybe the OSGi Alliance needs to make some organizational changes but it is and independent and experienced place to standardize where there currently is no other place like it.

It is sad to see how a closed eco-system like Apple's iPhone and iPad is thriving and how we are going to waste a lot of energy in the next years because we direct that energy on destroying and not creation. The tragedy of the commons revisited.

Peter Kriens

P.S. Neil Bartlett and I will hold another master class int the US Bay Area on January 18-21. The first one was a very good experience (also according to the participants!), though intense.

Modularization

Reading blogs about Java modularization gives me the sincere impression that (too) few people understand what modularization really is all about and how OSGi implements it.

Modularization is a fractal, it is a process that has happened several times over the last 50 years. The reason for these disruptive process was that it allowed us to scale software development to the next level. Assembly was a clear form of modularization where the bits were hidden from us humans. Functions with local variables were the next step. The industry then went on with modules (functions + data) and objects that are basically modules that could be instantiated. Java added packages, which grouped classes, again a form of modularization.

What these efforts did was encapsulate, they created a boundary between inside and outside and controlled the internal name space by importing and exporting. You could import from the outside world and you could control what was exported. What you did on the inside was your problem, it was not visible to the outside world. For example, it is impossible to detect that the name of a local variable used in a function. This kind of encapsulation is important, it means what happens in the inside is invisible to other parts of the system. Invisibility is good, you can't be wrong about something you do not know!

Except for OSGi, other modularity efforts seem to forget about this crucial encapsulation required for the next modularization step. The efforts I've seen so far focus on accessibility. The difference between accessibility and visibility is that accessibility requires a single name space. Where in OSGi each bundle (the module) has its own name space as we've done in the past when we took a modularization step, in other forms this aspect is ignored. All other proposals I've seen so far assume that there is a single name space for classes.

A single name space works well for small to medium systems. However, today we are building systems that consists of a large number of subsystems. Forcing a single name space on these large systems is in the long run asking for problems. The clearest example is if you have two subsystems that depend on different versions of a third subsystem than you're in trouble. Unless you build on OSGi.

Peter Kriens

OSGi DevCon 2011 Submissions

I know you always like to submit your talks for OSGi DevCon/EclipseCon 2 minutes before the deadline, but it helps us all if you could submit them earlier! The deadline is November 30, 2010. So you have a few days left.

We already have a few submissions but we're really looking for more. There is so much happening with OSGi at the moment so there should be plenty of material. Are you using OSGi? Are you making tools? Are you considering OSGi? Is there something you do not like about OSGi? You think µservices are the greatest thing since sliced bread? You have the greatest idea ever for OSGi?

Really, if you use OSGi in a day to day situation you likely have something interesting to say to your peers. You got something to say but need a bit of help? Do not hesitate to ask me for some assistance.

• Submission
• OSGi DevCon information
  
• EclipseCon
  

Do not forget to mark your submission as an OSGi DevCon talk. Looking forward to see your submission, kind regards,

Peter Kriens

The History of Modularity

A few years ago Bjorn Freeman-Benson (formerly from Eclipse Foundation) asked me as an old friend (we know each other from the previous century) if OSGi was really novel, like Objects were, or if it was just good engineering. I then answered it was good engineering. Bjorn, I changed my mind lately. I think the OSGi µservices are an innovation on the same level as objects were!

So when I was was asked to give a presentation in Ludwigsburg for the User Forum Germany last week I felt µservices were a suitable subject. In my opinion µservices are the next big thing after objects, a progression in a long line of software improvements. This historic perspective is important to learn the lessons of our predecessors, what worked and what did not work. Personally I am fascinated how you see that in the last 60 years our predecessors modularized the existing model and moved software to the next plane, and we did this several times in a very similar, but different way.

Anyway, the presentation is available on slideshare. It is very much a Zen presentation (not much text) but lots of nice graphics. Enjoy and let me know.

Peter Kriens

JCP In Trouble

It seems that some in the Java community are becoming impatience with Oracle's handling of the JCP. Doug Lea wrote an open letter why he did not want another term on the JCP and Stephen Colebourne, a JCP specification leader and Apache Software Foundation member, is rallying against the JCP. Obviously the lawsuit against Google and the change of heart concerning the Apache Harmony field of use restriction did not win Oracle many new friends. Neil Bartlett even blogs about OSGi taking over the role of the JCP for the Java Community ... LOL

Hmm ...

If you think about, the OSGi is the only other organization that makes specifications for the Java community. And in many ways the OSGi Alliance has an arguably much better structure for Java specifications than JCP ever had:

1. Copyrights - In the JCP the specification lead together with Sun (now Oracle) have a special status. They're not even a bit more equal than others, they are on a whole different plane concerning ownership of the created Intellectual Property (IP). The contributions of other members in the expert groups are gladly taken for free but do not provide any rights in return.
   The OSGi is different. A member is a member, regardless if this member has 100.000 employees or 3. All created IP is licensed forever to all members under exactly the same conditions. Additionally, the specifications are completely free to implement by non-members. Simple, and more important, it is fair.
2. Patents -The OSGi Alliance and some of its key members have pledged not to assert any patents that are necessary to implement the specifications. During the specification process great care is taken that no submarine patents slip in.
   
3. Process - In the JCP the process is more or less in the hands of the specification leads. Having been a member of a number of JSRs I can assure you the process differs significantly. JSR 291 was run quick and efficiently, and I guess we all know what happened to JSR 277 and JSR 294, not to forget my 2 years in JSR 198, the most futile JSR of all.
   In the OSGi there is a much more standardized process that focuses on requirements first, API later. Over the past 30 years I've worked with oh so many developers developing APIs. It is a lot easier to get an agreement on requirements than on an implementation proposal. Therefore, the OSGi EGs always first work on an Request For Proposal (RFP); a document focused on requirements. Maybe those documents are not always perfect requirement documents but the process of making this requirements provides the opportunity for the EG members to create a common vocabulary. This collaborative mood helps tremendously when it is time to create the Request For Comments (RFC).
   
4. Reference Implementations (RI) - In the OSGi process a Reference Implementation is mandated before a specification can be published. For the previous releases the OSGi worked with several open source groups to provide the RI. However, the OSGi also has their own RIs when no group steps up.
   
5. Compatibility Tests (CT) - Every specification requires a CT that runs on the OSGi test harness. These CTs are free for the members and can be obtained free of cost for qualifying open source projects.
   
6. Architecture - The quality and architectural aspects of JSRs differs wildly because there is no central gating function. The running of a JSR is more less up to the specification leads and they can basically deliver what they want.
   In the OSGi Alliance all APIs have to go through the CPEG, which acts as an architecture board. Though this can be a bottleneck and a pain, it ensures consistency between specifications which is a big benefit for the users.
7. Quality Specifications - Again, in the JCP the specification is more or less what the specification lead wants to make of it. Some are excellent, other are a bit less. In contrast, all OSGi specifications are written as data sheets in the same template. Overall releases pack up a number specifications and bundle them together in a high quality book.

So what arguments could one think against the OSGi Alliance taking over the JCP role?

1. Opennes - Though the OSGi has been releasing RFCs ahead of the specifications the name lingers that the OSGi is very closed. I do think the OSGi Alliance should try to open up more but I also believe that the EG should have a period to get their act together before they have to publish. Specification writing is hard and agreeing within an EG is even harder. Anyway, so far there has been surprisingly little feedback on our released RFCs.
   
2. OSGi is Expensive - Today, the OSGi Alliance subscription fee is $25k or (€18k). They are currently trying to change our bylaws so they can actually have different tiers that will allow the subscription cost to go down for many companies. And they have invited researchers for qualifying academics. However, a bit of a reality check here. If you want to work on specifications it will cost you time and travel; both are highly expensive. If you want to do a good job, these costs dwarf the cost of the subscription fee. If the fee is the problem, should you really be wanting to work on these specifications anyway?
   The biggest advantage of the fees is that the organization is independent of the big guys and can thus be truly democratic for its members. With different tiers the big guys will pay significantly more but will require to become more equal. And was that not one of the problems with the JCP?
3. Not everyone uses the OSGi Framework - True, our specifications take the framework into account but most service specifications are written for pure POJOs. For architectural consistency it would be necessary to consider the framework in new specifications but that would not influence their usage outside a framework.
   In practice, this means ensuring the specifications are properly cohesive and uncoupled. For example, instead of putting the Factory and Provider classes inside the package, they would have to be kept in a separate packages, but that is also good modular practice in non-OSGi Java.

I am probably day dreaming to even consider for the OSGi Alliance to take over the JCP role for the Java community. But looking at the arguments it looks like Neil has a valid point ...

Peter Kriens

Masterclass Experiences

Last week Neil Bartlett and I gave a masterclass in Girona. We had a very good crowd: 10 very clever people. The first day was an introduction day but we learned the second day that we had to repeat some of the introductory material on the first masterclass day. The key reason was that even the most experienced users were not really aware how easy it is to use µservices with the bnd component annotations in bndtools.
The days were pretty intensive, going from 9 in the morning to deep in the evening. Though we stopped around 6 in the afternoon, we then tended to just move to the lobby and continue discussing and exploring. The lobby was the only place with Internet, though this sounds limiting, the effect was that we all had a good time together instead of sitting in our rooms working alone.


One of the first things we did is play with Vaadin. We used a little bundle I wrote some time ago that made it trivial to build a Web GUI with Declarative Services. We then continued with configuration. I discovered some really cool stuff just doing these exercises. Though I was the author of the Metatype specification, I never really used it since then, though I heard that the Apache Felix Webconsole supported it very well (as long as the Metatype Service is installed). A Metatype defines a type for a configuration record with sufficient information to automatically generate a decent UI for this type. It was kind of magic how a little bit of XML in the bundle suddenly allowed you to control the configuration of the component as well its number of instances. I knew it could be done, just did not realize how powerful it is.

To work on these examples we used Neil's Auction application he used for his tutorial. In this application, an Auction is (obviously) a service. Now would it not be cool to see the auctions of the others in the room? Seems like a job for Distributed OSGi! Before the masterclass Neil had investigated the existing open source implementations for the Remote Service Admin but they were either not up to the standard yet or not robust enough. So we had asked Paremus to provide us with a copy of their Remote Service Admin (RSA) implementation. They were still in active development so there was some reluctance from Paremus but they were fortunately brave enough and it paid off, RSA worked like a charm! In the end we all got each other's auctions on our screens. Distributed OSGi looks like a clear winner.

The next thing we tried was persistence. The last enterprise release provides a way to use JPA based on services. I'd never tried it so we decided to see how it works. I guess I should have prepared this part because it initially went badly. I mistakenly used the Eclipse Link bundles because they mentioned OSGi, however, it turned out that they were not at all related to the OSGi Enterprise specification. After we wasted too much time I got the brilliant idea (not really) to check how we tested the OSGi specification and then noticed that the Eclipse Link bundles we used there did not even remotely resemble what we were using. It turns out that all this work is in the Eclipse Gemini project and this is still in incubator status. Desperately after wasting so much time I used the bundles in the OSGi build. You can find now some information at the Eclipse Wiki but this desperately needs a good example. In the end we got it work thanks to Ralf Ebert who persevered.

Three attendants came from ACA-IT and used the week to work on a little Web based message aggregator based on the technologies we explored in the masterclass. They really wanted to use websockets (two way communication between browser and server) but these were only available in Jetty 7. Using parts from Felix and Equinox they actually got this to work. It was really nice to see how they leveraged the knowledge learned during the day to add this to their app during the night.

During the days we discussed an amazing amount of information. There was a lot of knowledge in the room and we could do some sparring about subjects like testing, versioning, builds, and many of the other things that occupy us as developers.

The last day each attendant had the change to submit a question to the rest of the group. This is the part I always like best because you learn about user problems. It was clear that also that day went by amazingly fast and provided a lot of food for thought. We invited all attendants to an exclusive mailing list for ''Masterclass on OSGi'' attendants. It is already working heavily.

Neil and I were very tired after this exhausting week but also very satisfied. It had been a lot of fun to do but we also learned a lot. We went out for dinner with my wife (accidentally ending up in an Irish pub with the for Neil oh so familiar English pub food) and evaluated the masterclass. As it looks now we are going to repeat it early next year on the west coast of the US. We'll inform you about the details.

Peter Kriens

Minimal OSGi Systems

Every now and then the question pops up about OSGi in really tiny environments. The press release from ProSyst last week about the smallest OSGi stack caused this question to enter my inbox: "Can OSGi be used in constrained embedded solutions?"

Though OSGi is a no-brainer, the underlying question of the use of Java turns out to be harder, even after a decade where memory prices tumbled and processor speeds exploded. In this market the Bill Of Material (BOM) still is the all overriding concern, combined with 99% experience in C(++) coding in this world. Java is usually seen as a sidekick. Nice to have but real men use C(++).

The first OSGi app I worked on was the Ericsson e-box, a home gateway with 32 Mb of RAM and 2 Mb of flash. I always wanted to get rid of the Linux on it and run Java on the bare metal so we would have a single management model. I actually wrote Java implementations of DNS, DHCP, and even wrote a Java implementation of the TCP/IP stack to be able to communicate with SLIP devices! However, others in the project were experienced Linux people and found it a lot easier to just do everything with existing software. Fighting about this architecture wasted a lot of time and in the end we ended up with an ugly hybrid that was hard to manage.

Last week, a presentation from Andre Bottaro (Orange Labs/France Telecom) and IS2T on the OSGi community event seems to indicate that things are moving again. These companies developed a minimum OSGi stack in a really small device by removing Linux and running the VM on bare metal. However, though these tiny OSGi implementations are interesting exercises I must admit that I have mixed feelings. OSGi is about downloading modules, such a model requires some headroom to have value. Why waste resources to a mechanism that can only be used for trivial downloads? Java in the phone did not become very useful until Android provided an SE like class library that was sufficiently rich and the hardware had sufficient headroom to make downloadable apps feasible.

That said, I do believe that in the end OSGi is the way to go because providing new and updated functions become more and more a necessity. And there are more activities around this. Also at the community event Tim Ellison (IBM) demonstrated Apache Harmony and how the modular approach of Harmony (it uses OSGi metadata for its modules) can be used to create really small and efficient VMs. I am going to look more in Harmony because it looks like an ideal VM to run OSGi on. I also spoke to Marcel Offermans (Luminis) who is submitting a proposal to Apache for a C(++) based runtime that is based on the principles of OSGi and will work together with OSGi through the service registry. This seems even more ambitious than the Universal OSGi idea that we played with in the OSGi Alliance a few years ago.

I do hope we do see more efforts shrinking the OSGi stack like ProSyst, Luminis, Orange Labs, IS2T and many others are doing. One day we will be at a place where OSGi is a no-brainer, in small devices, including the Java part.

Peter Kriens

JDK 7 Delayed Again

Did I get a laugh out of Mark Reinhold's announcement that Java 7 is further delayed? No, I did not; it actually made me rather sad. Java 7 contains a lot of improvements and my life would be simpler if I had those improvements available. Java is still a tremendous platform but we're losing our advantage over other platforms and the main reason is lack of a modularity.

Java is slowly being broken by the misconception that the bigger the Java platform the better it becomes. However, bigger means more internal dependencies and these dependencies tend to increase the complexity of a platform quickly. The more rope you have, the more tangled it can get. Repeatedly slipping schedules are one of the symptoms. In the nineties I've seen Ericsson waste staggering amounts of money to create a telecom application platform only to finally succumb to defeat. The simple fact is that developer needs are way too diverse to ever be captured by a single platform. Platforms that still try to satisfy these diverse needs always get torn between features and bloat. When I explained how I loved Java to my fellow Smalltalker Ralph Johnson (around '97) because it was so small, this wise man said: "Just wait." He was right. Worse, though the Java platform obtained the kitchen sink but still always requires me to include external libraries anyway.

Modularity is the only mechanism that allows us to have our cake and eat it too. If Java consisted of a core Java platform we could easily include the JSR implementations as separate modules. I never use Swing , so why does my platform have it? And maybe I need it in another version if I use it. Modularizing the JSRs would maybe complicate the life of trivial applications but for any real application handling external dependencies is already part of their complicated life. Complicated because surprisingly Java provides no support whatsoever for handling these dependencies.

Neither JSR 277, JSR 294, Jigsaw, nor Qwylt was a proper solution for handling external dependencies. Jigsaw was too simplistic for large applications and Qwylt and JSR 294 would have given us the headache of handling multiple module systems on your compiler module path. Both would have caused a packaging nightmare due to the combinatorial explosion of module system x operating system variations.

What we need is a core platform that is minimal but understands true modularity. Instead of including all these javax packages, this minimal Java should only include well defined core packages and also a mechanism to properly handle modules from (remote) repositories that make it trivial to add libraries and applications to my desktop machine and servers. Perl can do it, Ruby can do it, Python can do it, why does Java have such a hard time doing the same thing? Or live up to its promise and do it better?

Oracle should focus their Java effort in shrinking the platform and modularizing anything that is not used by most applications. Depending on the functionality of those modules, many of them can actually be compiled for 1.4 VMs (with generics), Java 5 or Java 6, making them available today and not until 2013 or even later. This decouples the life cycle of the components from the life cycle of the platform, which can never be faster than the slowest constituent component.

We do have the technology, all the parts are there. Please Oracle, this delay provides an opportunity, can we make Java agile again?

Peter Kriens

Easier Configuration Admin

We are likely to introduce a new service that makes Configuration Admin significantly easier to use. How? By using the Java type machine. Though properties are nice and flexible, they tend to cause cluttered code because of the required checks and conversions. The new model therefore defines configuration types with interfaces. For example, this is how a simple configuration type for a web service would look like:

package com.acme.webconf;
public interface WebConf {
 int port();
 String host();
}

The PID is defined by the interface name, in this example it is com.acme.webconf.WebConf. This "record" has a port (an integer) and a host name (a String). A bundle that wants to receive this information, only has to register a Configurable<WebConf> service. For example:

 @Component
public Webserver implements Configurable<WebConf> {
 public void setup(WebConf conf ) {
   web( conf.port(), conf.host() );
 }
 public void deleted(WebConf conf) {
   stop();
 }
}

No more type error prone type conversions, no more spelling errors in property names or PIDs! And you're not restricted to a single PID, you can extend the interfaces with other interfaces and each extended interface name will automatically be used as PID, merging all underlying configuration records. Annotations in this specification will also make data validation easier.

It is also possible to use factories. In that case, register a ConfigurableFactory, which looks like:

 public interface ConfigurableFactory<WebConf> {
  Configurable<WebConf> newInstance();
  void noConfigurations();
}

This specification will make Configuration Admin significantly easier to use.

Peter Kriens

P.S. Did you already register for the community event?
P.S. And did you look at the Masterclass On OSGi (with certificate) in Girona?

OSGi Community Event Sept. 29-30 in London

Just a small reminder that you still have to register for the OSGi Community Event, September 29-30 in London! We really have a very strong program this year, there are lots of very interesting presentations. From the program it is clear that OSGi is maturing in many verticals of the software industry. From the Appstore for the connected home market to the enterprise application twins Apache Aries and and Eclipse Virgo, it is clear that OSGi provides a modularity solution that transcends the silos in our industry.

OSGi provides the solid foundation that is needed when applications grow in size, as applications always do. After a certain scale, strong modularity becomes a necessity to stay on top of the complexity. The community event is an excellent opportunity to learn a software technology that will become increasingly important in the next few years.

The program at the event is interesting for many different people. For beginners because there are tutorials for building enterprise applications, handling dependencies (the hallmark of any large software system), and bndtools (an Eclipse based development tool for OSGi bundles). For experts, because some of the presentations take a deep dive in the complexity of componentizing large systems, providing insights in the problems as well as providing guidance towards solving these problems. There will also be plenty of presentations providing guidance how to modularize your existing applications. And for business people because several presentations take a good look at the business cases for OSGi. The planned sessions are:

• Rapid Bundle Development with Bndtools for Eclipse
• Predictability vs. Dynamism: managing dynamic real-time applications
• Enterprise OSGi in WebSphere and Apache Aries
• Enterprise Platform Over OSGi: Migration Diary
• OSGi and Android
• SOA Flexibility with OSGi Remote Services and the Service Component Architecture
• OSGi & Private Clouds
• Migration from Java EE Application Server to Server-side OSGi for Proc
• A crash course in OSGi application development
• Experiences with OSGi in industrial applications
• Using OSGi for the Realization of Home Automation Systems
• Automated Semantic Versioning for OSGi Bundles
• OSGi ME - An OSGi Profile for Embedded Devices
• Dynamic Swing Applications using OSGi
• OSGi and Terracotta: replication of states for clustered services.
• App Store for the Connected Home Services
• VMware and SpringSource Projects on OSGi
• Developing OSGi Enterprise Applications
• Dependencies, dependencies, dependencies!
• Modular Applications on a Data Grid - A Case Study Using OSGi and Oracle Coherence
• Distributed OSGi

And of course as the moderator, I have to invite you to a panel: “I Love OSGi. Now Let’s Change It!” that will host some of the key people in our industry.

This event is targeted at people that have invested in OSGi and want to meet their peers, software architects that need to know more about OSGi, developers that are using OSGi, and business people looking for new opportunities in the software world. So register quickly.

I am looking forward to meet you in London next month!

Peter Kriens

OSGi Masterclass Oct. 12-15

Neil Bartlett and Peter Kriens (that being me) have decided to hold a masterclass together. Neil and I have been working for some time on different tools and we felt that though there are are lots of introductory tutorials there are no places where you can learn in-depth about using (and designing with) OSGi. Together we have quite a bit of experience in the area and we can cover quite a lot of ground.

We intend to run this masterclass very hands on. With the group we will analyze use cases (your use cases are welcome), design a solution, and create prototypes. We intend to cover a lot of different areas: service based design, distributed OSGi, persistence, GUIs, etc. As tool we will be using Neil's bndtools. If you feel not completely sure about your basic OSGi knowledge, we have an introductory day to bring you up to speed.

To keep the cost down, we've organized this masterclass in a hotel near the Girona airport. Girona is very well connected to most European cities because it is a Ryanair and Easyjet hub. Also the price of the masterclass is kept low and the class is limited to 20 people. To top it off, there is also a discount when you register before September 15.

So, consider participating because I am sure about one thing: it will be an interesting masterclass!

• More Information About the Masterclass
• Register Directly
  

Scala Components vs OSGi

This week I got a question how Scala components measured up to OSGi components. Now I do not have a good understanding of Scala components and I could only find a 5 year old paper of Odersky and Zenger. From this limited understanding, Scala components seem to provide a compile time construction model. The model shields a developer of the low level details how classes interact. Such a technique can significantly increase productivity because it allows us to understand more complex systems. However, though the developer is shielded from many details, the underlying code is still the usual tangled web of classes referring directly to many other classes.

Modularity has an intriguing relation with scale. Over time we've used the same trick (modularity) to provide us with new design primitives that allows us to better understand bigger systems. We've come from digital switches, octal numbers, hex numbers, assembly instructions, macros, functions, objects, and functional objects. Each step provided us with a higher level design primitive that simplified thinking about our software problems. Each step made us significantly more productive.

However, time does not stand still and the systems we build are becoming bigger and bigger. Our generation's software problem is that today we more integrate the software from many different parties than really write code. In the eighties I've rolled my own distributed database, window system, network software, text editor etc. Today, you download big functional blobs and spent most of your time figuring out how they can be configured to work in your system. having 300 to 400 JARs on your class-path is no longer an exception and I've heard about systems with 800 JARs.

The problem with the compiler component model is that the programmer's compiler has to have full visibility to every transitive dependency. Though some people feel this is the holy grail, I fail to see how this in the long run can match the reality; systems are just getting too big. This is proven by looking closer at popular open source software. You'll see the developers struggling with creating plugin and extension architectures while heavily abusing class loaders along the way. Factories and Listener patterns are desperately applied to make the code look decoupled, but in reality only hiding the coupling from sight and not actually removing it.

I think we're at a phase in the software industry where we have to let go a bit of total control. There are just not enough programmers in the world to verify all possible combinations of 800 JAR files. We have to accept that certain dependencies cannot be verified during compile time but will have to be made during deployment time, obviously with as much verification as possible. The holy grail of software is mix and match of components. You run a program and miss a feature, well add it. You don't like a feature? Get rid of it. We no longer can have the rigid coupling caused by compile time components when a system scales to a certain level.

This is not a new idea and many engineers of my generation sigh: "Oh gosh, yet another component model. Been there, done that. Doesn't work." Strengthened by being correct many times in the past. However, I think that OSGi brings a big difference to the table that few people truly understand yet.

Our industry has reached a system scale where our previous modularity solutions are becoming part of the problem. With 800 JARs, the modules can no longer be treated as a compile time abstraction. The modules need to be reified in runtime to allow the automation of their management; 800 is just way beyond the human scale. For this reason, module-to-module dependencies are implemented in Ivy and Maven and most package managers. Though this model was a big step, it does not reduce the complexity inside the modules, it only manages that complexity in a more automated way. What we need is a solution that addresses the complexity inside our software. That complexity is largely caused by coupling between different parts of our system; reducing that coupling will simplify our systems.

Modules depending on modules is a model that increases the dependency fan-out exponentially. For example, if I use library A, and library A uses a logging library, do I then depend on the logging library? Not really, that dependency is an implementation dependency of library A, it is completely unnecessary for the API dependency I am having on library A. The dependency fan-out of module dependencies tends to be extremely large and becoming cumbersome.

The key innovation OSGi provides is its µservice architecture. A µservice is not a component model; µservices enable a true component model by reifying the coupling between components. Instead of components depending on components, components now depend on µservices. This model is based on interface based programming. Back to Scala, the service package in OSGi µservices is very much like a component in scala. The key difference is that OSGi µservices do not ignore time, and this makes all the difference in the world.

Time is an aspect that we desperately try to ignore in programming languages. We can put a program to sleep and 24 hours later continue where we left off while your program is oblivious of its long absence, well until it finds out the real world actually had changed. In nature time is crucial for almost any process but handling time is hard, just think of concurrency and date handling. Few people realize how fundamental the timing aspect is of factories, dependency injection, and listeners. One component has control and it needs to interact another component, just think how crucial timing is for these cases. Still, we tend to create solutions that mostly ignore time except when we absolutely cannot. How often can you get a factory but the factory has no way to signal it can no longer provide its functionality? The effect of ignoring time is that our code is often surprisingly brittle because it implicitly makes many assumptions that are too easily violated.

µServices do not ignore time, they embrace it. By embracing time components become robust because they cannot make assumptions about the components they interact with beyond the µservice. Though many non-OSGi users think the dynamics make OSGi applications brittle, it is my experience that µservice based designs are very robust instead. It is the lack of assumptions about the other components that makes this so.

µServices neither replace nor diminish all the previous modularity techniques, on the contrary, µservices stands firmly on their shoulders. So I think Scala and OSGi are complementary. Scala does not provide what OSGi µservices provide and OSGi does not provide what scala provides. However, combined you they stand stronger and allows us to build bigger systems with less effort.

Peter Kriens

OSGi 2010 Community Event in London: Did you submit???

The deadline for submitting a presentation to the OSGi 2010 Community is rapidly approaching. Did you already submit your presentation? Take a look at for rules and inspiration. The OSGi 2010 Community Event will be held in London, September 29-30. The deadline is July 14, so if you have anything to say about OSGi or to the community then you better submit a proposal soon ...

Peter Kriens

OSGi 2010 Community Event

I've been so busy with the work for the next specifications that I've not spent much time on the next big OSGi event: The OSGi 2010 Community Event in London, September 29-30. And then I was skyped this morning that there is only two weeks left for submitting a presentation! The deadline is July 14, so if you have anything to say about OSGi to the community then you better submit a proposal soon.

I am looking forward to this event because there is so much happening in the enterprise space, and not to forget the residential space. For the next core release we are preparing a massive number of APIs that should be (almost?) stabilized at that time. But there is also much work going on in the Residential EG and the Enterprise EG. We are working on a massive set of specifications: generics for the framework, standardized shell, byte code weaving, coordinator, thread based standard io, object conversion, object formatting, simplified and more powerful handling of configuration data, classpath scanning, parametrized services (a service factory model), blueprint update that provides configuration admin API as well as as name-spaces, generic capabilities and requirements model, nested frameworks, virtual bundles, and then some tuning of existing APIs. It is almost scary so much is in the pipeline.

So I am pretty sure there will be lots of news and exciting stuff to talk about in September, both from the Alliance and its members. However, we are also really focused on experience reports. Any technology requires a solid foundation in the community and experience reports provide feedback for the directions that the OSGi should take. So please do not hesitate to submit your experiences or (wild?) ideas. From technology to business models.

You can submit at our submission system.

Peter Kriens

Reified Types: Conversions Using Generic Types

One of the most interesting aspects of the Blueprint specification was the ReifiedType. I ran into this nifty class again today because we want create a Conversion service that is useful by the new upcoming OSGi shell service. We had decided to reuse the Blueprint conversion model, but now as a separate service, something which we probably should have done already for Blueprint.

The problem that Reified Type solved for us is how to convert an Object to a specific target type by taking any generic information into account. For example, if you convert an int[] to a Collection<Long> you want to be sure that the collection contains Long objects and not Integer objects. That is, a naive implementation would convert this to Collection<Integer>, which would miserably fail later on when someone uses the collection.

I can hear many readers thinking: "But generic information is erased, isn't it????" Yup, generics are erased, but not completely! When you have an object there is no way to know the generic parameters (the parameters between the angled brackets like T, K, V etc.). I am not sure why they decided to not provide this information with the object because it seems very doable but it clearly is not present. However, the VM maintains extensive generic information everywhere else but in the object. If you have an instance field then it can describe exactly what its generic type constraints are. For example, if you have a field numbers, declared like:

Map<String,Class<T>> numbers;

Then you can get the generic type constraints with the getGenericType method that returns a Type. Virtually all reflective methods have been duplicated to provide this Type object where they used to return a Class object.

OSGi APIs are written in a restrictive subset of Java so that they can be used in a wide variety of VMs. Though we found a solution allowing us to use generics in Java 1.4 (JSR 14), we must assume a target of Java 1.4 with the minimum execution environment for our daily work. This means there is no Type class we can rely on in our APIs.

Obviously, in enterprise scenarios the VM is Java 5 or later, and the Type class is readily available. Is there a way we can eat our cake (use the generics info in our Conversion service) and have it too (no dependency on Java 5)?

The first solution that comes to mind is to duplicate all the sub-types of the Type interface in our own name space. There are actually quite a few sub-types of the Type interface. These sub-types models (and more!) all the flexibility of the generics constraints system: type variables, arrays, wild-cards (super, extends), and parametrized types.

Hmm, not only is duplicating no fun, it also turned out that the hierarchy is not that easy to work with. For our Conversion service we only need to know the raw type of a type parameter. That is, if our target type is Collection<Long> than the we only need to know that the type parameter is Long.

After struggling with this problem we found an interesting solution: the ReifiedType class. A Reified Type collapses all the intermediate levels of wildcards, variables, and arrays and provides direct access to the most specific types that can be used. It turns out that by traversing the network of Type objects it is always possible to end in a raw class, even with variables, wildcards, and arrays.

A Reified Type is always associated with a single raw class. The raw class is the class without any generics information. It provides access to the type parameters by their position. For example, the Map<String, ? extends Number> has a raw class of Map and 2 type parameters: String and Number. For this example, the previous Refied Type has a size() of 2, and provides a ReifiedType<String> and a ReifiedType<Number> for the type parameters.

In the Blueprint specification we provide a concrete implementation for Java 1.4 VMs. In Java 1.4, there are no generics so this implementations hard codes the number of type parameters to 0 by definition. We will do the same in the Conversion service. However, users of this service will be able to pass subclasses that provide the generic information to get better conversions.

So it looks like this was a case where we could have our cake and eat it too! You can already look at Reified Type in the Blueprint specification and in the next release I hope we can have a new Conversion service based on this model.

Peter Kriens

Mea Culpa

Yesterday the OSGi Alliance introduced the new look and feel and I choose the rather despicable way of spamming many of this blog loyal readers with blogs that were never meant to be published, at least not yet. By republishing the blog to slide into its wonderful new skin I made the mistake to select all blogs and forgot to deselect some of the drafts that were in the pipeline (or forgotten).

Excuses, at least I hope you enjoy the new look & feel as well as the updated content.

Peter Kriens

To Coordinate in OSGi

Since day one of the OSGi Framework (over 12 years ago) I have been trying to get a light weight transaction model into the specifications. After several attempts that were skillfully aborted by others or way to heavy for what I had in mind I had actually given up. That is, until the last face-to-face meeting in Mountain View. David Bosschaert (Redhat and EEG co-chair) was looking for a better Configuration Admin solution than the Managed Service (Factory) services provided. One of the key requirements he had was that of a composite update. In Configuration Admin updates are done per PID. A PID is a persistence identity for a Dictionary that contains the configuration properties. David argued that in larger enterprise applications there is need to compose the configuration properties out of a number of smaller dictionaries that each represent a configuration aspect. For example, there could be a com.example.system.config PID for system configuration and a com.example.http PID for configuring an HTTP server.

An very good idea I think but he was confronted with a serious problem. Though Configuration Admin nowadays allows the use of multiple PIDs per service, it does not give any timing guarantee other then that each update will be done on another thread than the setter. The problem with the multiple configuration updates is thus that you could get parts of your configuration milliseconds apart. That is normally not good because changes in configuration are potentially causing expensive operations. After several attempts to find a good solution we realized that the transaction model could solve this problem rather nicely. If the Configuration Admin was transaction aware it could wait with updating the target services and sending out events until the commit part of the transaction.

Now there is something funny with transactions, they have a weird effect on system developers. The moment you start talking about transactions they seem them gain 10 pounds and age 10 years. Transactions are seen as very heavy weight because of the recovery requirements and setup. And acting as a resource manager is a non-trivial task with the XA API. Having lost the battle to use real transactions several times (Framework, Dmt Admin, Deployment Admin) I was not prepared to start such a battle again. That is, until it dawned on me that what I really was looking for was a coordination API, transaction are providing much more than I needed.

My side of the software fence has been relatively free of persistence problems, the whole ACID part of transactions was never my favorite part. I liked transactions because it allowed coordinated collaboration between different parties. In an OSGi system you never know how the processor flows through different services when you call another party. In this model there are many cases where you could things more efficiently, or atomically, if you only knew when the task that was being worked upon was being finished. The coordination part of the transactions was always what I liked so much because I knew there was going to be a callback at the end of the transaction.

So could the answer be a light-weight coordination API? If the Configuration Admin was updated to use this API, it could not send out notifications or update managed targets until all the changes were made, that is, at the end of the coordination. So how could this look like (notice: API is work in progress):

Coordinator coordinator = ... ;
ConfigurationAdmin admin = ... ;

void updateConfigurations(Map configs) {
Coordination c = coordinator.begin("update configurations");
try {
 for ( Map.Entry e : configs.entrySet() ) {
   Configuration c = admin.getConfiguration(e.getKey());
   c.update( e.getValue() );
 }
 if ( c.end() == OK )
   return;
 // log!
} finally {
   terminate(); // Ensure proper termination
}
}

So how does this look like for the participants? For example, how would Configuration Admin schedule its updates when it would use coordinations? Well, a participant must indicate it wants to participate in a coordination. The method to start a participation is on the Coordinator service. The code to participate is as follows for a schedule method of a Runnable that wants to delay scheduling the Runnable's until the coordination is ended:

 final List queue = new ArrayList();

void schedule( Runnable r ) {
if ( coordinator.participate( this ) ) {
 synchronized(queue) {
   queue.add(r);
 }
} else
  executor.execute(r);
}

The Coordinator will callback the participant on either the failed() method or the ended() method. The failed() method can be called concurrently with the initiating thread. The ended() method is always called on the initiating thread.

 // the coordination failed, clear the result
public void failed() {
synchronized(queue) {
  queue.clear();
}
}

// the coordination ended ok, clear the result
public void ended() {
for ( Runnable r : queue )
  executor.execute(r);
queue.clear();
}

The coordination API therefore allows two completely different implementations to synchronize their work on a common task. This API seems incredibly useful to optimize many of our existing admin APIs: from the framework itself to Remote Service Admin. I wish I had realized much earlier not to call it a transaction API ...

Peter Kriens

P.S. This Coordination API is work in progress, there is no promise this work will ever end up in an official OSGi spec.

How to use Config Admin?

Config Admin is one of the most powerful services the OSGi standardized but is often badly understood. The only reason why it seems hard is because it was designed for highly dynamic long living environments. Most applications start, read their configuration, do something, and then die because someone types control-C or the application exists the VM. In a dynamic environment your configuration can change at any time and you're expected to react to these changes. Users tend to like this model.

What we did is merge the initial "get my configuration" phase that so many people are so used to with the notification that there is a configuration change. With the intent to simplify the coding we only have one mechanism: update. The initial phase is a guarantee that the the Configuration Admin service will update you, even if there is no data provided yet. Many programmers hate this model because they do not feel in charge, they want to grab their configuration when they need and not wait until some louse Config Admin calls them. Though this is feasible, it just a lot more work. Relax, and leave the initiative to Config Admin and it all falls into its place.

The key concept of Config Admin is that the receiver of the configuration registers a Managed Service with a property called service.pid. The value of the property is some unique identification. The Config Admin will then call the service's update(Dictionary) method. If it has a configuration for that service.pid, the value will be a set of properties in the Dictionary. If there has been no configuration set, it will call will null. The key thing is to let the Config Admin control you instead of trying to be charge. Another type of Inversion of Control ...

Lets do a simple example of an echo service on an internet port:

public EchoServer implements ManagedService, BundleActivator {
EchoServerImpl server = EchoServerImpl(-1); // Dummy server

public void update(Dictionary props ) {
 int port = -1;

 if ( props != null) {
    Object o = props.get("port");
    if ( o != null )
      port = (Integer) o;
 }
 if ( server.getPort() != port ) {
   server.quit();
   server = new EchoServerImpl(port);
 }
}
}

To set Config Admin data, take a look at the Felix Webconsole, Felix FileInstall, or the Knopflerfish environment. They all support a range of (G)UIs to create configuration records.

Peter Kriens

Bundlefest in Girona!

Next week the OSGi organizes yet another bundlefest in Girona. This time we convene with the Residential Expert Group (REG). The week will start off with a REG meeting and then the remainder will be hacking with bundles for the REG release's compliance test suites and reference implementations. If you were a member, you could have participated in the fun! I am really looking forward to this week because it is a nice group of people to hang out with, the weather looks good in Spain next week, the hotel seems very nicely located, and the residential area is becoming hot again.

There is a surprising amount of activity in the residential area. All the signs are green for this area to finally happen. Many operators are now starting to develop residential gateways. Big projects are happening all over the world, which is now creating more and more interests of vendors. Where we had a hard time selling OSGi in this world a decade ago, today it is more or less a given. Ten years ago the technology was deemed unproven, today that is hard to argue. There are also no real alternatives to the comprehensive execution model that the OSGi provides.

To see how OSGi is solving real problems in gigantic applications running on enterprise servers but also able to hold its own in the embedded world is incredible. As I argued many times before, I do believe we've developed a software model (µservices!) that is surprisingly fundamental. It it is very exciting to be part of this development.

Peter Kriens

P.S. The Enterprise Specification is now available in book form, you can order it now!

Duct Tape

I discovered software when a high school friend got a programmable TI-57 calculator. This calculator made me fall in love with developing software; a love affair that has not ended yet. Falling in love made me want to read everything about her. In the pre-google era books were used for that purpose and I read all the books I could get my hands on. At that time software books were mostly about structured programming. The basic idea was that you take a function, decompose it in smaller function, and so on. The mantra for this decomposing was:

• low coupling
• high cohesion

The idea of coupling was not hard to understand but I had a bit of a problem with cohesion, it was more fuzzy. And I never liked the design magic that structured programming required. Therefore, when I discovered my mistress' objects around '83 I fell in love all over again. In the period between the calculator and the discovery of object oriented programming I had studied, started a company, and developed a number of editorial systems for newspapers. Until that time most with assembly and crafting a lot of code for networking, databases, operating system, and even a GUI (eat your heart out!). As any new generation we worked hard to ignore the lessons from our predecessors and objects seemed to be the perfect vehicle to put the old geezers in their place. Move out of the way Tom DeMarco, Edward Yourdan, and Michael Jackson, we're coming! So the cohesion and coupling mantra's went out of the window and we showed how data encapsulation with inheritance brought you all these goodies.

Most of you know the results. though objects work very well on the medium scale, once the systems grow and evolve they tend to create systems that resemble spaghetti and become hard to maintain. Something got lost along the way. Interestingly, spaghetti code was exactly the problem that drove structured programming.

Problems that we solve on one level appear almost identical on higher levels is a hallmark of fractal problems. The size of systems has increased exponentially since I started and spaghetti problems that we thought we had solved reappear in a different incarnation. So how do we address the spaghetti problem at our current scale? Could the old structured programming mantra help us when we apply it to objects? Lets take a look.

Modules were defined for functions, not for classes but when we took about a module today we talk about a set of classes with restricted accessibility. Now, classes have a tendency to act as duct tape: very useful and darned flexible. As the joke goes: if you can’t fix it with duct tape, you probably just haven’t used enough. However, classes can also be just as sticky and they can get surprisingly entangled when you're not paying attention. So even if OO modules are restricting accessibility, they've lots of classes sticking out eager to get entangled with other classes, preferably from other modules.

Clearly interfaces solve the sticky type problem by type-separating the client and the provider of an object. However, they do not help in getting in getting an instance without getting entangled with the implementation class. We have to solve that within the OO paradigm: Listeners, Factories, and Dependency Injection. However, these patterns never completely got rid of the stickiness of the implementation. Listeners require the client to know the library implementation, Factories require the factory implementation to know the implementations some way and with DI frameworks there is some all-encompassing God-XML that is sticky as hell. The big problem is that in ALL those cases the implementation class somehow leaks out of the module ready to stick. Often as a string instead of a class but the only advantage of that is cosmetically: your dependency graphs look better because the analyzers usually miss these couplings. However, the dependency still is as concrete as a class coupling and just as bad, just looks better.

So our current toolbox of patterns may hide the coupling to the implementation classes but they do not really get completely rid of it. They also have some surprisingly bad characteristics that we somehow got used to. These patterns are extremely biased to the client and forget that the module that provides the instance might have something interesting to say as well. They all force the provider to provide an object at the time they deem right without letting the provider decide if it is ready and if it really wants to provide an object. The provider has no way to signal when it is ready and maybe even offer multiple instances. Again, Factories and DI are surprisingly one sided.

Let us start with context. When you call a factory or use DI then the caller/receiver can provide parameters but the callee has nothing to say. An instance is created out of the blue from one of its classes. If there is any context, it must be stored in static fields, which is an evil software practice. A module that provides an implementation can not easily different instances based it inside knowledge. For example, maybe a provider tracks instantiated machines in the cloud and wants to offer an object per machine. Sorrt, can't do that. The provider module can only provide some manager where the manager then provides listeners, etc. etc. This lack of context makes APIs seriously more complex.

Similarly, a providing module has nothing to say about timing. The caller of the Factory or the DI engine make the decision when to instantiate the class from the module. The providing module has nothing to say about when it is actually ready to provide such an object. This makes startup ordering and dependencies really hard to manage.

We've all been working with these patterns for so long that it is very hard to see how limited they are. However, in a truly modular system the client module and providing module are peers that collaborate. Each module can play the client role and provider role in different times and neither the client role nor the provider role is passive. None of the existing patterns can handle this peer-to-peer module, all fall short in handling type coupling to the implementation class, the dynamic context, and the timing.

In a perfect world, each module should be able to offer an object to other modules. And each module should be able to react to the availability of those objects. This is the Broker pattern. If I need a Log object, I ask for a it (or get injected when it is available). With the Broker pattern, the providing module can decided when to offer, solving the timing problem. The providing module can instantiate as many objects as it likes and offers them, solving the context problem. And last but not least, it is the providing module that creates the object and thereby never exposing the implementation class.

That said, there is one thing that is still fuzzy in this model: who defines the collaboration contract? Is this the provider? Well, that makes it hard to use other providers for the same collaboration. After a lot of hard thinking it seems obvious that modules are not enough, we need to reify this contract in runtime. If we reify the contract then modules can provide this contract and use this contract without being bound to a specific implementation. Both providers and clients would be peers.

So if we talk about software modularity than in an Object Oriented world we need to augment modules with something that reifies the contract between the modules. So far we've struggled with half baked solutions like Factories and the current DI model to address the problems caused by the lack of a reified contract. These contracts are much more important for a design than module.

I strongly feel that today we're in an almost identical situation as in the eighties when objects addressed the shortcomings of structured programming. This was a hard sell because many people looked at the implementation details and not at the design primitives that OO provided: encapsulation of data, inheritance, and polymorphism. Making people see the primitive instead of the vtables and descriptors was hard work.

I believe that today we need a design primitive that allows us to reason about the collaboration of modules. A design primitive that allows us to design large scale systems and still understand the fundamental architecture of what've we created. A primitive that allows us to see a picture of a complex system and understand quickly how it can be extended. OSGi µServices are very close to that primitive I believe.

I must admit that several times in my life I was unfaithful to my mistress. When we first got married she was all Smalltalk and I loved her for it. But over time she developed a lot of C++ behavior and I not so happy about that. Fortunately, she decided to pick herself up and become so much more dynamic with Java. But if I am really honest I was eying other software the last few years, still missing some of her old dynamism. However, since I saw the potential of her µServices I was head over heals in love again.

Peter Kriens

The Catwalk

I guess there is something in the air at the moment that makes people worried OSGi is not successful quickly enough because there are not 7 million Java programmers using the OSGi API on a day to day basis. Kirk Knoernschild gave us the choice between Feast or Famine and SD Times told us OSGi is too complex for the enterprise developer. Well, feasts tend to end in hangovers and I do agree the OSGi API is not very useful for most Java web developers. Is OSGi actually a technology that is used by a (web) application programmers? Will web developers have to start using Service References and Bundle objects? I don't think so.

If you develop, for example, a social networking app then you should not be concerned about low level infra structure details and OSGi should completely stay out of your face, this is the concept of high cohesion. OSGi should never be visible on the (web) application level. However, if you write a middleware component and need to interact with the applications then you need domain objects that represent these applications. Bundles and Service References are then the perfect domain objects that allows you to interact with that app on a system level. For example, the Spring DM extender bundle leverages the OSGi API to allow a developer to write POJOs oin his bundle. Many middle-ware APIs can be simplified because the OSGi API provides detailed information about the callers, making the APIs significantly more cohesive.

OSGi itself does not simplify application development, it only enables third parties to provide frameworks that then can simplify the life of the application developers, or empower them. They function provided by OSGi is the collaborative model that makes different frameworks no islands on their own but actually allows them to work together. OSGi defines the collaboration mechanisms, not the nice to have convenience functions for web development. What OSGi allows is breaking a huge application problem in smaller collaborating parts. The cumulative complexity of a collection of small parts is less than those parts combined. However, to enable this collaborative model we must enforce a number of modularity rules. Rules that are limiting on the component level to create more flexibility on the deployment level.

Unfortunately, those rules break a lot of existing code. We often talk about modularity but in reality we tend to create highly coupled components. When these "components" are run on OSGi they crash against the module boundaries because OSGi enforces these boundaries. Many people forget that a class encoded in a string in an XML file is creating as much coupling as that class used in your code. The only advantage is that these strings do not show up in your automated dependency graph ... OSGi is just the unfortunate messenger of evil hidden coupling.

Application servers adopted OSGi because their problem domain is highly complicated and large. So large that strong modularity was their only option to keep things manageable and OSGi was perfect for this because it already contained some of their domain objects. Most Java application developers develop web apps. Web apps are a highly restricted domain that has been extensively simplified by tools and libraries. Improving on this has a very high threshold. This is the same problem as with the combustion engine and helicopter; there are better technologies in principle but the incumbents of a huge head start in optimization. Therefore we've adopted the WAR format. WAR files will make it easier to start running web applications on OSGi without having to introduce new tools for the developers: their WARs will run on OSGi unchanged. Over time they then decompose their WARs into smaller bundles.

There is one innovation in OSGi that I think is highly undervalued: the µServices. µServices are a paradigm shift as important as the move from structured programming to object oriented programming. µServices are the pinnacle of modularity. If they're so good, why does it take so much time before everybody uses them? Well, SD Times provided some insight, they said that a new technology X is irrelevant because developers have been building fantastic systems for a long time without X. It is hard to better illustrate the reasons why paradigm shifts are so hard and can take multiple decades.

As with OO, there is a chicken-egg problem. To take advantage of µServices you need components that provide and consume these µServices. Our problem so far has been that the major adopters (Eclipse/App Servers/Spring) picked OSGi for its class loaders on steroids and treated the µServices as an extra. But things are changing. Last EclipseCon it was clear that µServices are moving to the front. People that could not care less about services now publicly declared their support for them. Eclipse provides now good tooling for µServices, which will make services more attractive for many Eclipse developers. I am sure this will create the needed network effect.

Kirk notes how our industry is more fashion driven than the fashion industry and both authors complain that OSGi is not visible on the catwalk. And that is correct because OSGi is the catwalk, present in every fashion show picture and sustaining virtually any application that runs on a Java EE Application server based on OSGi, which are actually most of them.

Calling your cake and sending it too

During the last EEG meeting in Mountain View at LinkedIn in March we discussed the next phase in Distributed OSGi: asynchronous messaging. With the Remote Service Admin specification we have an elegant model for handling the distributed topology of a cluster of systems but this model is based on synchronous calls to a service, like:

Baz n = service.foo( bar )

Synchronous function calls are very simple to use because the answer is returned inline on the same thread. This model of computing allows you to store the state on the stack, which is efficient and handy. However, In a distributed environment your thread will block for billions of instructions until the return comes in from the remote systems. Threads are relatively expensive resources and it is a pity they go to waste idling. Anyway, if you have to program in a concurrent environment a lot of advantages of synchronous calling seem to disappear. For example, you must be very careful not to hold locks when you call a remote service for it is easy to create deadlocks.

The alternative is messaging. With messaging you create a message (some object) and call a send method on some distribution provider. For example, in JMS there is a send() method that can take a Message, where the message object can contain arbitrary data. The receiver of the message then can send zero or more responses back. The sender can receive this through a proprietary callback mechanism or message queue.

Programs that are based on asynchronous messaging are highly scalable, are easier to make deadlock free, and are more extendable. For example, persistent queues are transparent for the sender and receiver but can provide some very interesting reliability characteristics to the system. In the early OSGi days I wrote an OSGi test framework that used synchronous calls from the GUI to the framework. After struggling with this model for some time I gave up and went to asynchronous message and I remember it felt like a dry warm towel after a heavy water-boarding session.

A big advantage for the OSGi Alliance is that services are a very convenient way to write their specifications using Javadoc. Message based APIs are not as nearly as easy to document. Also, in many cases the synchronous way of calling methods is by far the most efficient when the method is in the same process. With distributed OSGi, we are often not aware in our code that a service is remote. For the best of both worlds we'd like to be able to do both synchronously and asynchronously. There are actually different solutions that mix the idea of a synchronous call but asynchronously processing the result value.

The simplest solution is to adapt the API to handle the asynchronous return value. Google Web Toolkit uses this model extensively for its remote calls from the web browser to the backend. The basic API is defined with an interface but in reality the caller passes a callback object in every call. The following example shows two interfaces, first the normal and second the adapted version. The caller of the second declare method passes an object that is called back when the result comes in.

interface Tax {
Return declare( Declaration decl);
}
interface ServiceAsync {
void declare( Declaration decl, AsyncCallback result );
}

An alternative is the use of the Java 5 Future interface. A Future is an object that is immediately returned as the result of a synchronous call and can be used to get the result later asynchronously. Futures also require the adaptation of the the API to reflect the asynchronous nature:

interface ServiceFuture {
 Future declare( Declaration decl);
}

Though these solutions are simple and provide type safety they are kind of ugly because it violates one of the important rules of modularity: cohesion. The interface that was very much about the domain now mixes in concerns of distribution. What does declaring taxes have to do with the callback? These two aspects are very unrelated and it is usually not a good idea to mix them in API design.

An alternative solution is provided by ECF, the Eclipse communications framework. They defined an IRemoteService that takes an IRemoteCall and an IRemoteListener parameter. The IRemoteCall object specifies the remote procedure call with parameters: a Method object, the actual parameters, and a timeout. The Remote Listener is called when the result comes in. This is an intriguing solution because it allows a call to any service, even a local one. The callee is oblivious of the whole asynchronicity, it is always called in a synchronous way. This solution is quite transparent for the callee but very intrusive for the caller because it is too awkward to use from normal code as long as Java does not provide pointers to methods. It is only useful for middle-ware that is already manipulating Method objects and parameter lists.

Could we use a synchronous type safe calling model to specify a service but use it in an asynchronous way if the callee (or an intermediate party like a distribution provider) could play along? After some toying with this idea I do think we can actually eat our cake and have it too.

It is always good practice to start with the caller because asynchronous handing of a method call is most intrusive for the caller. Assume Async is the service that can turn the synchronous world asynchronous and the player is a music player that is async aware. That is the player will finish the song when called synchronously but it will return immediately when called asynchronously. With these assumptions, the code could then look like:

Player asyncPlayer = async.create(player);
URL url = new URL("http://www.sounds.com?id=123212");
Future r = async.call( asyncPlayer.play( url ) );
// do other processing
System.out.println( r.get() );

This looks quite simple and it was actually not that hard to implement (I did a prototype during the meeting). It provides type safety (notice the generic type of the Future). So how could this work?

The heart of the system is formed by the Async service. The Async service can create a proxy to an actual service, this happens in the create method. For each call going through the proxy, the proxy creates a Rendez Vous object and places it in a Thread Local variable before it calls the actual service.

If the callee is aware of the Async service, for example a middleware distribution provider, then it gets the current RendezVous object. This RendezVous object can then be used to fill in the result when it arrives somewhere in the future.

After the asynchronous proxy has called the actual service the Rendez Vous was accepted or it was not touched. If it was not touched, the proxy has the result and fills it in. If the RendezVous object was accepted by the callee, the Rendez Vous is left alone; the callee is then responsible for filling in the result.

After the call the client calls the call method. This method takes the (null) result of the invoked method. The reason for this prototype is that it allows the returned Future to be typed correctly. Though the call method verifies it gets a null (to make sure it is used correctly) it will use the RendezVous object that must be present in the Thread Local variable. The previous sequence is depicted in the following diagram:

The proposed solution provides a type-safe and convenient way to asynchronously call service methods. It works both for services (or intermediate layers) that are aware of the asynchronicity or that are oblivious of it. For me this is a very nice example of how OSGi allows you to create adaptive code. The scenario works correct in all cases but it provides a highly optimized solution when the peers can collaborate. And best of all, it is actually quite easy to use.

Peter Kriens

P.S. These are just my ramblings, the post is just one of the many ideas discussed in the OSGi EGs, and it has no official status.

µServices

Whenever I submit something for a conference it gets easily accepted when it is about class loading modularity. Whenever the topic is services, I meet a complete lack of enthusiasm. This is in contrast with my own feeling after working with OSGi for 10 years. Though the modularity is advanced in comparison with all other class loading solutions, it pales in comparison to the innovation that we've called services.

Over time, I've become convinced that part of the problem is the name: services. The web-services guys have stolen our name; talking about services today lights up your conversation partner's neurons of: heavy, slow, XML, complicated, and other neurons you'd prefer to stay calm. Though web-services and OSGi services have the same underlying architecture for decoupling, their execution, purpose, and overhead differs day and night. A web-service communicates with a party outside your process, an OSGi service communicates always within the same process, without any overhead. Calling a method on a service is as fast as calling a method on an object, services are almost as lightweight objects. There is some overhead in signalling the life cycle of the service for the providers and the consumers but in runtime all that overhead is gone.

Though web-services have given the term service the connotation of heavy-weight, we're also to blame by not being ambitious enough. It is not until very recent that I've come to see how much we missed the part that has later been filled in by Service Binder, Declarative Services, iPOJO, Spring DM, and Blueprint. The original model of handling your service dependency manually is and was broken from the start. Sadly, I actually recall discussing moving this responsibility to the framework but it was deemed too hard and we did not have enough time. Due to the lack of built-in support for automatic service dependency handling we created the image of services being awkward constructs. Messing around service references and service trackers did not make it look lightweight at all! However, those days are gone and services are now not only lightweight with respect to performance and other overhead, today they are trivially to use, almost as easy as normal objects, albeit with a lot of built-in power that normal objects lack. With annotations, declaring a service has become trivially to use. For example:

@Component
public class ExecutorManager implements Executor {
ExecutorService  executor;
LogService log;

public void execute( final Runnable r ) {
 executor.execute( new Runnable() {
     public void run() {
         try {
              r.run();
         } catch( Throwable t ) {
             log.log(LogService.LOG_ERROR, "execution failed", t );
         }
 });
}

void deactivate() {
  executor.shutdown();
  executor.awaitTermination(10, TimeUnit.SECONDS);
}

@Reference
void setThreadPool( ThreadPool pool ) {
  executor = Executors.newCachedThreadPool(pool);
}

@Reference
void setLog( LogService log ) {
   this.log = log;
}
}

Using the bnd annotations there is almost no cruft in the code. The following bnd file is the only extra file required:

Private-Package: com.example.executor
Service-Component: *

Really! And this is not limited to bnd, iPOJO and the Apache SCR runtime annotations provide similar simplicity.

This example is very little code but surprisingly robust in many dimensions. It is perfectly thread safe, all timing issues are managed. The Executor service is not registered before the Log Service and the Thread Pool service are available. And when one of these services go away, everything is correctly handled. The example is also very open to extensions that are completely invisible from the outside. As a service I can always find out what bundle is using me and have bundle specific options, for example, certain bundles should be limited in the amount of CPU time they can take through the executor.

In the eighties I discovered object oriented programming and quickly fell in love with it. OO caused a paradigm shift; we started thinking differently about how you solved problems. Today it is incredibly hard to imagine thinking without objects because objects have become an intrinsic part of our vocabulary. However, in the eighties we explained objects with C structs that had pointers to an array of methods and then when you send a message to an object it would be dispatched to the correct class method. I recall countless discussions with people that basically didn't see the innovation because they could only see the mechanic description and not the paradigm shift; how objects really simplified problems when you treated them as primitives. I do believe services are similar in this aspect, when you have to worry about Service References and cleaning up, the chores overwhelm the gains. However, when there no more chores to worry about, services are an incredibly elegant design primitive that map very well to domain specific problems.

Now I do realize that "paradigm shift" is a loaded term. In the nineties the paradigm word was heavily abused; for a short time it became the marketing term of choice for many software products. Soon after the abuse the word was ridiculed whenever used, paradigm shifts do not come that often. I am therefore fully aware that I use big words here, but I do believe that services are a similar layer on top of objects as objects were on top of structured programming.

If you look at the recent history of software after OO became mainstream then there are a number of patterns that stand out:

• Listeners
• Factories
• Dependency Injection
  

All these patterns are trying to manage coupling. For this, they are based on the interface concept. Interfaces simplify separating implementation from specification, a concept that provides by far the best bang for the buck. If we look at type coupling in the previous three patterns we see exactly this idea: All parties are coupled to the interface and the interface is not coupled to anything. This is exactly the reason why interfaces work so well, both the provider and the client can evolve independently because they have no knowledge of each other. It really does not get much better in software to achieve simplicity than not knowing something ...

So the three aforementioned patterns use exactly the same trick, the difference between the three pattern is the dynamicity. With a listener, the control is from the library to the client. With a factory, the control is reversed, the client takes the initiative and the library is passive. Dependency injection is interesting because in this model both the client and the provider are passive, the DI framework has the initiative. Client and provider activity must be encoded in normal code, the DI framework is oblivious of this. This exactly the reason the service model took some time to integrate with Spring DM, this was the first time the providers and clients became active.

There are, however, four cases when both the client and the provider can be active or passive. What is this fourth case? This is the case where both the client and the provider are active. This is exactly the case that the OSGi service registry covers: active clients and active providers. The service registry fits perfectly in the list of patterns because it also use the interface to separate clients and providers. One could call the OSGi service registry the missing link ...

The OSGi service model does not provide an additional model, it only unifies the factory and listener pattern allowing both of them to exist simultaneously. It now becomes clear why it was such an oversight that we did not add a dependency injection facility until release 4, if we'd had that from the beginning we had covered all cases. However, with Declarative Services, the OSGi does cover all the 4 cases.

An OSGi service therefore unifies the Factory, Listener, and Dependency Injection into a single primitive idea. Because of this unification it also supports situations where both the client and the provider are active. In today's infrastructure this is no longer a luxury or nice feature, it has become a necessity. Clusters, cloud computing, and the interaction with other systems require that software does not fail when dependencies are not met all the time. All those semantics are contained in OSGi services for a very low price, both in performance, runtime costs, and conceptually.

However, the most exciting part of services is that they seem to map so well to many software domains. Maybe this excitement is partly caused by my background that is largely outside enterprise software. Most software I worked on was connected to the real world and the real world just happens to be awfully dynamic. Most of those problems can be more easily solved when services are used as a design primitive.

Trying to convince people to use services as design primitives seems to fly against the idea of abstracting oneself from the OSGi API. In my eternal quest against coupling I fully agree with this sentiment, it is exactly what I always do. However, OSGi services transcend OSGi, I am not promoting the OSGi APIs for using services, that is just the first place where this paradigm has matured and a good place to get experience. What I am promoting is the idea of µServices, the concepts of an OSGi service as a design primitive. Maybe I should start a JSR to introduce µServices to the Java Standard Edition ...

Peter Kriens