Wednesday, December 3, 2014

OSGi Developer Certification Exam - San Francisco - Jan 22, 2015

We are pleased to announce the next OSGi Developer Certification - Foundation Level exam will be taking place on Thursday January 22, 2015 in San Francisco.
Picture courtesy of www.pachd.com
Picture Courtesy of
www.pachd.com 

So if you want to test and prove your OSGi proficiency and achieve an OSGi Alliance certified level of competency then be sure to sign up here.

Everyone passing the exam receives:

  • An electronic certificate (with a unique number)
  • A 'certification badge'

Plus, the OSGi Alliance maintains a register of all Certified Developers so that an individuals certification status can be verified.

The exam is open to anyone, however we recommend that you should have gained some practical experience using OSGi and have a good understanding of the OSGi R5 specification topics that are covered in the exam (full details here).

There is a special discounted price for students, and OSGi Alliance members. Please contact us by email for discount details.

More information about the exam, logistics and the benefits of achieving OSGi Developer Certification - Foundation Level can be found on the OSGi Alliance website here.

We hope you can join us.

If you have any questions please contact us by email.

Friday, October 24, 2014

Opportunity to Learn About OSGi in Romania - Nov 21

The Bucharest JUG with Luminis Technologies and Thales Romania are hosting a free one day event in Bucharest on November 21 (Registration is mandatory, see below).

The event is titled "OSGi in One Day" and it will introduce you to OSGi technology and some of the tooling available for developing with OSGi.

The expected audience is likely to include a broad range of OSGi experience, from beginners to dedicated RCP developers to core framework developers, and so the programme has been structured accordingly.  There are 3 main parts:

  • General introduction to OSGi
  • Demo of building and deploying a cloud-aware application with OSGi
  • Hands on workshop to try it out for yourself


Marcel Offermans and Paul Bakker from Luminis will be presenting and running the workshop.

Many thanks to the Bucharest JUG for their support and assistance in organising this event.


Details

Date: November 21, 2014

Start time: 9.00am for full day or 2pm for the Hands On Workshop

Location: Thales @ Sema Parc, River Palace, 319 Splaiul Independentei, Bucharest

Registration: http://www.bjug.ro/editii/osgi-one-day-2014.html

It sounds like a great opportunity to find out more about OSGi, meet new people and share OSGi experiences with your peers in Romania.

Thursday, September 25, 2014

How Should I Use Guice/Spring/Blueprint Inside My Bundle?

Someone asked me over mail:
How should I use Guice (or any other injector) inside my bundle?
The short answer is: don't.

The slightly longer answer follows hereafter.

Injectors like Spring and Guice were invented because around 2000 large monolithic applications were brought down to their knees because of their internal coupling. Even though a lot of code was written as POJOs, the instantiation and configuration of those POJOs caused massive coupling, making the app brittle and hard, sometimes even impossible, to evolve. Injectors were created to concentrate that coupling (and the related initialization ordering) in one place so the rest of the code base had significantly reduced coupling. Since coupling and complexity have an exponential relation this massively reduced complexity in the application code. A reduction in complexity that more than offset the accidental complexity of the injectors (XML!). 

However. In a proper OSGi application, the problem of a big monolithic app just does not exist! A bundle that would really need Guice or Spring is almost by definition not a proper bundle. The reason is that a proper bundle is cohesive, it only contains related parts. Because it is cohesive, most of its coupling is inside and a proper bundle only exposes a tiny part of its internals with well defined OSGi µservices, either registering them or depending on them.

The consequence of this cohesion is that the complexity landscape changes. In this landscape, the accidental cost of an injector no longer weighs up to a reduction in overal complexity as it did for monoliths. This means that good old Java with the new operator works surprisingly well, inside a cohesive bundle it lost a lot of its bad side effects. So plain old Java, as James G. intended it, is actually the best for code inside a bundle. With plain old Java, the IDE is your friend again! You can navigate and refactor at will since Eclipse is aware of your complete type tree inside a bundle, nothing is hidden behind the injector. As long as an implementation class is inside your bundle, you can use it since your IDE knows all its dependencies. That is, if you want to delete it or rename it, go ahead, since all possible dependencies are inside your bundle. Therefore, an injector just creates extra boiler plate, unnecessary barriers, and isolates the type tree while no longer providing an actual benefit.

So if you feel that you need an injector inside a bundle, you should probably redesign that bundle, it is highly likely you cram unrelated parts in it.

Now, so far this was about the bundle internals. The next story is of course the external dependencies. A proper bundle consists of a set of (DS) components. Each component is configured by DS from Configuration Admin, it has its own life cycle based on its configuration and (optionally configured) dependencies. With the annotations, the overhead of using this is quite minimal. The following is a complete component that registers one service when its two service dependencies are met.

 @Component
 public class FooComponent implements Foo {
  private Bar bar;
 
  @Activate
  void activate( Map map) { ... }

  void foo() {
   bar.bar();
  }


  @Reference
  void setLog( LogService log) { }

  @Reference
  void setBar( BarService bar) { this.bar = bar; }

 }

The magic of these components is, is that suddenly you can make any object an active component. Once it is a component, you get configuration data for free (you can even instantiate multiple in of them under Configuration Admin control), you get full dynamic dependency management, and also service registration is for free. These OSGi service components are as fundamental a shift in computing as objects were in the nineties. Ok, maybe we could reduce this tiny amount of boilerplate (and we are working on some additional simplifications) but surely not by much.

So to summarize. I think the accidental complexity of an injector inside a cohesive bundle is not balanced by reduced overall complexity. The DS spec strikes a fine balance by using injection for the external (dynamic) dependencies but assuming normal off the shelf Java for internal code. So, for a change, try unadulterated Java inside your DS components, the new operator is actually quite handy!

Peter Kriens

@pkriens

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: http://www.osgi.org/Certification/Developer

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)
Registration: http://www.meetup.com/BarcelonaJUG/events/203059432/

Sat Sept 13 - Workshop
Start Time: 10.00hrs CEST
Location: Espai Jove La Fontana, Carrer Gran de Gràcia, 190, 08012 , Barcelona (Map)
Registration: http://www.meetup.com/BarcelonaJUG/events/203060102/

Enjoy!


Blog Archive