Monday, September 22, 2014

Become an OSGi Certified Developer

Are you an OSGi Ninja and would like to show the world?

The OSGi Alliance is starting a developer certification program where you can become an OSGi Certified Developer. The first exam, OSGi Developer Certification - Foundation Level (DCFL), is held just before the OSGi Community Event in Ludwigsburg on Monday October 27th.
This exam covers the Core OSGi Framework R5 and an essential set of OSGi service specifications, including:
  • Declarative Services
  • Configuration Admin
  • Http Service
  • Log Service
Further exams, such as Advanced, Enterprise and Residential are planned.

If you're interested in taking part and getting your OSGi qualification, read more about it and sign up here:

Friday, September 19, 2014

Portable Java Contracts for javax Packages

Modularity is all about contracts; one party says what they provide, another party says what they require, and if they match, things should work just fine. So what do you do when the party providing the contract doesn't provide enough information to be certain they're providing what you want? This is the conundrum the OSGi Alliance has been grappling with when it comes to the packages defined in the JCP (javax.*).

Reliable and flexible Java contracts can only be achieved through semantic versioning of packages. The OSGi Alliance semantically versions all its packages allowing users of the OSGi specifications to reliably pick something that will work, even when it's not the version they built with. The JCP does not version the packages it defines, although it does try to preserve backwards compatibility from release to release. Versions, in the context of the JCP, are specification versions. These are not semantic, they're marketing versions, just like product versions. These specification versions are not available to the runtime and so there's no way to reason about compatibility.

A number of projects have tried to add version information for the javax packages, but with no direction from the JCP, the approaches taken have been inconsistent. Some projects use specification versions (e.g. servlet 2.5, servlet 3.0), some choose a specification version as a 'baseline' and then semantically version from there (e.g. servlet 2.5, servlet 2.6), and some have even done both, exporting the same package at multiple versions.

So, back to the question posed at the start, "what do you do when the party providing the contract doesn't provide enough information to be certain they're providing what you want?". Well, as is customary with software engineering problems of this type, the answer is, you add another layer of indirection. In this case, the indirection is achieved using the "osgi.contract" namespace defined in the OSGi Enterprise R5 specification. Instead of depending on specific package versions, a consumer depends on a specific osgi.contract capability and then the provider (or some other third-party) provides a contract definition that corresponds to the package versions that the provider exports. That's probably as clear as mud, so let's see an example.

The following is a slightly updated version of the Servlet 2.5 example taken from the Enterprise R5 specification.

Provide-Capability: osgi.contract; osgi.contract=JavaServlet; version:Version=2.5; uses:="javax.servlet,javax.servlet.http"
Import-Package: javax.servlet; version="[2.5,3)", javax.servlet.http; version="[2.5,3)"

In this example a servlet container is providing the contract called "JavaServlet" versioned at 2.5 (i.e. it implements the Servlet 2.5 specification). The contract provider also imports the container's servlet packages in a version range appropriate to the package versions the container exports. The 'uses' directive in the contract definition ensures that anyone wiring to this contract will also be wired to the same provider of the servlet packages.

On the consumer side, anyone wanting to use Servlet 2.5 via this contract would specify the following:

Require-Capability: osgi.contract; filter:="(&(osgi.contract=JavaServlet)(version>=2.5))",
Import-Package: javax.servlet, javax.servlet.http

The Require-Capability says this bundle requires the JavaServlet contract, or later (it's assuming backwards compatibility). Note, the packages it imports are unversioned. The osgi.contract requirement ensures compatibility and the unversioned imports means the consuming bundle does not depend on a particular package versioning scheme of the provider (semantic or spec version).

The OSGi Alliance has started maintaining a set of contracts for the Java EE specifications. There is also a json representation of the contracts for use by tools to help them identify when a contract is not being used and make recommendations or provide quick-fixes.

One final note, it is only a good practice to use osgi.contracts when you're not able to rely on the package versions provided. Where at all possible, it's much better to use semantic versioning on your Import- and Export-Package statements.

Thursday, September 18, 2014

Concluding the Spanish OSGi Events for September

The Barcelona JUG is hosting two more events about OSGi on September 26 and 27.

Peter Kriens will be presenting "OSGi made easy with enRoute".

The session on September 26 is a introductory presentation in the evening and the session on September 27 is a half day workshop. Both of these events are free to attend.

You can find out more details and register for these events as follows:

Friday Sept 26 - 19.00hrs     REGISTER HERE
Mobile World Centre at Plaça Catalunya
Carrer Fontanella, 2, 08002, Barcelona

Saturday Sept 27 - 10.15hrs to 14.00hrs     REGISTER HERE
Espai Jove La Fontana
Carrer Gran de Gràcia, 190, 08012 , Barcelona

Thanks to the Barcelona JUG for organising and hosting these.

Thursday, September 11, 2014

More OSGi events in Spain this month.....

So it looks like September is turning in to OSGi month in Spain....

*** Update - Live Stream for tonight available from 19.00hrs CEST on You Tube ***

Hot on the heels of the Peter Kriens presentation about enRoute to the Madrid JUG on Sept 10, there is an event from Barcelona JUG this Friday and Saturday (Sept 12 and 13) by Jean-Baptiste Onofré.

This is then followed by another event from Barcelona JUG on Friday Sept 26 and Saturday Sept 27 with Peter Kriens.  More details on Peter's sessions are to follow in a later post.

The presentation this coming Friday by Jean-Baptiste Onofré is called "What is OSGi and why and how I should consider it for my projects?" This will cover some of the OSGi specifications and introduce the Apache Karaf container.  Hopefully this session will be streamed live and further information will be updated here (see above) and posted on the OSGi Alliance twitter feed as it becomes available.

The next day (Saturday Sept 13) a workshop will be held that will show you how to create a complete enterprise level OSGi application by leveraging the different layers provided by Karaf.

Full details for these two events and how to register are as follows:

Fri Sept 12 - Presentation
Start Time: 19.00hrs CEST
Location: Plaça Catalunya, Portal de l’Àngel, 08002 Barcelona (Map)

Sat Sept 13 - Workshop
Start Time: 10.00hrs CEST
Location: Espai Jove La Fontana, Carrer Gran de Gràcia, 190, 08012 , Barcelona (Map)


Wednesday, September 10, 2014

Live Streaming of Peter Kriens presenting enRoute Today @ Madrid JUG

Peter Kriens is presenting at Madrid JUG this evening (Sept 10) about OSGi enRoute. The presentation will be in English.

Our friends at the Madrid JUG have kindly arranged to stream the session. You can also follow the event and ask questions on twitter using the hashtag #mjugOSGi.

Its taking place at 19.00hrs CEST/ 18.00hrs BST/ 13.00 EDT / 10.00hrs PDT /  02.00hrs on Sept 11 (JST) (apologies to anyone in Asia).

You will be able to watch the stream from You Tube.  If you are in Madrid its being hosted by Liferay (thanks) but there are no spaces left so you will have to watch the live stream.

Hope you can join us for the stream if you aren't one of the lucky ones attending in person.

*** Update - the video recording below of the event will be made available in due course ***


In my last whiny post I stated that we tend to solve the symptoms and not the root problem, Jaco Joubert challenged me to define what the real problem is; fair enough.

The root problem is that we write fragile software that stumbles when there are unexpected changes in the environment. The simplest solution to this problem is to lash down the environment. If the environment does not move, then our software will not fall over. This is exactly what Docker does. And if a software system consisted of a single delivery then the cheapest solution is likely the best solution. 

However. My unease is caused by two fundamental issues: 

* First, we will write the same amount of software in the next 7 years as all the software written since the big bang. 
* Second, successful software systems tend to live a long time and evolve continuously. 

In such a gyrating environment the only thing constant is change. Change that Docker will allow us to largely ignore because we create a warm nest where this bad outside world does not intrude. Sloppy programming like hard coded path names and making other assumptions about our environment will not be punished. Initially this will work perfectly ok. However, over time your modules will become more and more tied to your unique environment because we have a hard time resisting a short-cut when they see one. These short-cuts will make the modules less and less reusable, which will probably make it easier to double the lines of code in the next 7 years but efficient is different. It will also make it harder to evolve your own environment because a lot of its details will be hardcoded in all the components. Expect another variation on the spaghetti model.

The root of software bugs is almost always a violated assumption in the code, therefore, not having these assumptions is the way to go, even though this can be very hard work. Not only will this reduce bugs, it will also make code more reusable because not-knowing something also reduces constraints between modules. A great way to structure this is to do contract based programming, something which reaches its (current) perfection in the OSGi service model. 

The argument is therefore that the virtual-image model (which Docker just makes more usable) will let sloppy programming go unpunished until the big bang.

Now, the picture is not black and white; I actually feel a bit uncomfortable with such an argument in other places and I clearly see the shorter term advantages of the container model. Maybe jet fighter pilot training provides some insight. Their simulators are running significantly faster than real life. The result is that when the pilots are deployed in a real fight it actually feels a tad boring. This is why during development I want an open world and as much dynamics as possible to capture our team's false assumptions early. However, when the code actually gets deployed to Q&A I want a locked down environment that will be bitwise identical to the image that goes to production.

Ah well, that is why I love this industry, never a dull moment.

Peter Kriens

Monday, September 8, 2014

The Unbearable Uncoolness of Java

This weekend I played with Docker  to better understand this technology and this was quite fun. Interesting how we focus our energy on solving symptoms instead of addressing the root problem. But I deviate.

What actually shocked me was the current standing of Java in this world, many devops seem to hate Java with a vengenance. After trying to create a Docker image with Just Java, I can (partially) see their point. Java sticks out like a (very) sore thumb in the Linux landscape. Virtually everything can be installed with all different package managers until you hit Java, then suddenly you need a click-trough license (except for some reason when you download for the Mac, there downloading is sufficient to accept the license). But the frustration is not limited to not being able to automate an install, it is actually not that hard to bypass, just ugly. It is the whole experience. Just compare the Python, Ruby, Go, and node.js website with the java download ordeal, which even includes a nice 404 now and then. Also Eclipse, despite it new look, feels like it lost a lot of steam in the past years.

It hurts to say, but Java looks stuffy and tired ...

We have the surreal situation that Java is by far the most advanced software development environment in our universe. We have amazing tools like Eclipse, Hotspot, based on an incredibly mature environment. We have at our disposal a humongous repository with libraries. It actually has a really good module system. Java is used to build gigantic applications of sizes that most other environments can only have nightmares off. Every day Java is involved in moving around trillions of dollars. Untold number of developers use it day in day out. There is just nothing out there that can handle the size of large systems Java can.

I know, any technology that is actually solving real problems becomes complex over time and Java is no exception. I also know that sometimes you need a clean break to get rid of the scar tissue or parts that proved unnecessary but I do not see anything on the language horizon that is providing anything fundamentally better than Java 8. If Go is as successful as Java it will become as complex as Java. Most often advantages are synthetic sugar or only work for specific problems. Overall Oracle is doing a pretty decent job keeping this technology up to date. That said, they really need to rethink their position in the computing landscape, especially in the server area. However, Java surely has a very long life ahead of it. 

That said, it would be a lot more fun if Java looked more like a sexy 20 year old instead of a stuffy octogenarian. Anybody any ideas?

Peter Kriens

Blog Archive