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!


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 ***

Challenged

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

Friday, August 29, 2014

Is Docker Eating Java's Lunch?

The reason I've put up with Java's deficiencies so long (ok, now with Lambda's it is finally starting to become a real language) is that I truly believe in the 'Write once, run anywhere' mantra. I've never understood why you want to write software that is not reusable and thus portable. Java achieved its portability by creating an abstract API for the interaction with the host Operating System (OS). I am duly impressed with Sun's engineers of how close they got to this goal, the Java VM is amazing piece of technology.

However, in practice, writing portable software still required effort from the developer. Despite the abstractions (alas, if only they had stayed close to POSIX), there are many subtle, and some not so subtle differences, that must be handled by the developer. Just like the differences in the configuration of an OS or the way its file system is used (i.e. hard coded path names).

The dreaded 'But it works for me!' frustration drove the idea of virtualization, where the software runs on a standard (Linux) OS that is virtualized on each developer's machine, which is then bitwise identical in test & production. The cost of this model was that it required schlepping around large images of many Gigabytes whenever the tiniest detail changed. Docker is, however, removing this disadvantage by making it very efficient to create, manage, and deploy these custom images.

So it looks like that the majority of Java applications in the future will run on Linux even if they run on MacOS or Windows, voiding the unique selling point of Java: portability. From now on, Java will be on par with every other language in the world regarding portability.

So what is left?

Java's greatest asset is that it allows you develop very large applications with sizable teams and stay sane. Though its type safety and long name feel cumbersome for small applications it becomes a necessity when the code base grows, which it inevitably will for any successful product. Type safety gives you confidence that all the different parts are actually compatible; the long names prevent conflicts. Even more important, it gives you navigability in the IDE, crucial when you maintain a large code base. This is of course exactly the area where OSGi provides it benefits: extending the type system with private Java namespaces, a time dimension (semantic versioning), dependency model, and into the runtime. There is no competitor on the horizon here.

So though Java/OSGi seems still have some unique selling points, it is the programmer in me that is a bit sad because the Docker revolution is another win for the sloppy programmer. There is something fundamentally wrong in our software industry if our software is so brittle and fragile that we can only make it run in a rigidly defined bitwise identical world, it points at a fundamental failure in the way we develop software. Sadly, we have so far been unable to learn from nature. In nature, systems survive and evolve because they are dynamic, adaptable, and resilient, often even anti-fragile. The Docker revolution will actually make our systems even sloppier since now many bad practices will go unpunished and this will have a price tag. These now unpunished bad practices will make maintenance and evolution of the code base much harder, aggravating the situation down the line.

Then again, who cares what happens in the next quarter? This Docker development model will likely lower the use of the  excuse: 'But it works for me!' in this quarter.

Peter Kriens

Follow me on Twitter @pkriens

Monday, July 14, 2014

The Big Ball of Mud

I am a tad frustrated about the whole µService discussion. How carefully designed concepts and terminology gets trampled over by a crowd that doesn't bother to look around in their rush to next year's fashion. When Neil Bartlett posted a link to an interesting blog that discusses exactly this subject I was therefore pleasantly surprised. It is about how our industry tends to swing from hype to hype and does not even try to learn any lessons from the down-swing. That is, if those lessons requires more than a minimal attention span. Ok, Simon Brown  does not appear to be an OSGi aficionado but he hits the nail on the head that your monolithic big ball of mud is not going to be a tender agile application overnight by adopting micro-web-services. Or, how a new fashion is always more attractive than the grunt work of making the existing stuff right. Hey, maybe they did find the silver bullet this time! #not

We actually know quite well, and for a long time, how to build large complex systems: contract based component designs scale very well. It just so happens that in practice the siren song of short cuts are much more attractive than doing it right ... that is, in the short run. We show beautiful layered architectures that are in reality camouflage nets over the actual big ball of muds. Read Simon's blog and weep.

Now, although I agree with the view in this blog, I think he misses the key reason why we always end up with that big ball of mud. Unfortunately, experience shows that this is not an easy story that fits the 140 character attention span, the cause of the big ball of mud does require some work to understand. Please shut off twitter and bear with me.

In the seventies, structured programming was the then current best practice. The mantra's in those times were 'Low Coupling' and 'High Cohesion'. Then, in the early eighties, we got Objects! New! Improved! No need to bother about these old geezers with their coupling and cohesion muck anymore. (I never really got that cohesion stuff anyway.) Progress, New! We were young and innocent until time taught us that the old geezers had probably learned a lessons or two that we had missed. Embarrassingly, the anticipated reuse we had promised to our managers were much harder to achieve than we had thought in our youthful exuberance. What killed us most were the transitive dependencies that are implicit in the object programming models. It is wonderful to reuse another object, but the damned thing should then not do the same thing and depend on others, ad nauseum. Instead of picking and choosing reusable objects, systems quickly became big balls of mud, or more appropriately, a different form of spaghetti coding. We had carefully avoided the GOTO statement but the result was painfully similar, just on another level.

In the nineties I had learned my lessons about coupling, cohesion, and objects. So when I met Java in 1996 I  immediately realized what interfaces were doing, they were addressing the transitive dependency problem that had caused me so much pain! With an interface you could program against a contract, not against an implementation! This did wonders for the transitive dependency problem since you were now bound to an interface. Interfaces were much less coupled by design than implementation classes. I obviously wasn't alone and interfaces became highly popular in Java and are pervasive today because they do provide freedoms that transitive dependencies kill.

Alas, we then witnessed a demonstration of how little intra-generational learning is going on. Two things went haywire. First, interfaces raised this pesky problem of 'How on earth do we get the instance in runtime?` Factories were kind of awkward so we found the greatest ostrich solution of all software times: 'We hide it in a XML!'. Obviously, the fact your coupling Java analysis tools did not see these hidden dependency anymore did not mean they stopped hurting you over time. An implementation class reference is a transitive dependency as much as any "new" expression is in your compiled code. Worse, a class referenced in text bypasses all those type safe-guards in Java you just spent all that money on.

The other, and surprisingly even worse, mistake was that we happily copied the transitive implementation dependencies model that failed so spectacularly with objects into our modules. And surprise, we got the same ball of mud, just now on a tad larger scale. Don't get me wrong, it is not maven that downloads the Internet, it is people that download the internet. People are addicted to solutions that look easy. That is, until that proverbial stuff hits the fan but then the original designers have then usually moved on.

Hard coding a dependency on another module will inevitably create more and bigger balls of mud, we learned this with structured programming, with object oriented programming, and now we are learning it with modular programming. The structural problem is identical in all these cases, so why should the result differ? (Though I find that a surprisingly large group of people disconnect now, 'What on earth has an interface to do with modules? This guy is an idiot ...'. Then again, their attention span probably already had made me loose them to that interesting tweet that just came in.)

Obviously, when we started designing OSGi in 1998 we did not have the clear view of today. However, the crew that did the early design had a lot of experience and provided a very elegant, µService based, model.  It solved the 'how on earth do I get my instance of that interface' problem in a non-ostrich way, it also innovatively used Java packages as the dependency model.  The Java package plays the same role for a module as the interface does for a class.

If you find this hard to swallow then you're not alone (which does not make you right btw, just more common). At JavaOne, I actually once overheard a discussion between three (at that time) Sun/Oracle high level executives;  they were making fun of package dependencies, radiating an amazing ignorance of the underlying issues. Even with very bright people, some that I admire a lot, I've seen that it takes effort to accept this structural analogy between classes and modules. However, even at the JCP, the Java package is already playing a large organizing role in most, if not all, specifications. It acts as the mediator between the provider (e.g. Jersey) of the specification (JAX-RS in javax.ws.rs. packages) and the consumer of that specification.

The key consequence of the OSGi model is that the µservice is not an implementation (a module) as many people tend to talk about it, it is a contract. Modules can provide implementations for these service contracts and they can consume objects that implement these service contracts. The modularity model is thus not: module A depends on module B. No, module A depends on service S and module B and module C can provide such a service. It is this crucial indirection that I think Simon misses in his blog that is the only known answer against drowning in the big ball of mud over time. We figured this out with Java interfaces, we now only need to understand how we can eradicate the same transitive pest with modules as well.

Yes, I know the model is not as simplistic as the module A depends on module B model that we know so well; it adds an additional indirection that is not free. The difference is that you pay that cost up-front while the long term cost of module dependencies is much, much higher but drawn out over time.  Though we like to postpone costs, we actually did learn a lot of lessons over time that made us take some up-front cost, Java as a type safe language is the prime example. So I am utterly convinced that model we learned in OSGi will prevail over time. Just hope that I do not have live through another hype that presents (parts of) these ideas as if they are something new.

Peter Kriens

@pkriens











Monday, June 23, 2014

Software mixed with marketing: micro-services

A few months ago I was on the phone when the speaker on the other side mentioned micro-services. Many moons ago I'd written a blog about OSGi's µservices because people were getting confused with the term service. Though this name was unique enough in 1998, the advent of Service Oriented Architectures (SOA) had imprinted people to think about heavy weight, costly, and complex things requiring stacks and other things a developer wants to avoid. That is, everything OSGi is not. I even used the Mu symbol (µ) because it was also the symbol for friction, of which µservices have so little. I therefore kind of naturally assumed the guy was talking about our wonderful in-VM µservice oriented architecture (µsoa). Actually, I smugly told him that I coined the term, trying to impress him. This however turned the discussion from straightforward discussion about technologies into a rather confusing one, that is, until I realized that they had stolen our name again!

Looking at the discussions it seems that micro-services talk like a web-service, they walk like a web-service (that is, they don't walk, they are actually kind of static), and they quack like a web-service.  Ergo?

They could not even call it tiny-service, puny-service, or small-service (getting the alliteration for free). Oh no, they had to jump the 6 magnitudes with micro! The worst thing is that it is a terrible misnomer to call a web-service a micro-service. I get the service part, a service is clear a point to access some functionality according to a contract; all service models share this core idea. However, a REST-service and a WS-* service use the Web/REST prefix to identify the communication stack. Since the OSGi µservices have zero overhead because they are actually local calls it makes sense to call them µservices. However, this new 'micro-service' is still a web-service or a REST-service, inheriting the often sizable communications stack and overhead associated with remote procedure calls. These new incarnation of web-services are only supposed to be conceptually small.

Which is of course is quite silly, since size is not the primary factor for module decomposition (of which service design is an instance). The things that mostly counts in good design is cohesion. Cohesion measures the conceptual closeness of the service's methods in relation to the overall system, a cohesive services has a well defined single responsibility. When I read about the micro-web-services I think they actually just mean cohesive web-services.

So can someone please ask them to call their bright idea cohesive web-services? Then we all know what they are talking about, we keep the vocabulary consistent, and we can keep using the term µservices because in OSGi they actually are!

Peter Kriens

@pkriens




Thursday, June 12, 2014

OSGi BOF Tonight @ OSGi DevCon 2014

OSGi DevCon 2014 is well underway and Tonight we have an OSGi BOF.

Its at 19.30hrs in Comedians Room in the South Tower at the New York Marriott at the Brooklyn Bridge.

Its your chance to come and meet with your peers, network and ask any questions.  There will be a number of the OSGi Alliance Board Members at the BOF including Dan Bandera, the President.

David Bosschaert will kick us off with a quick demo creating a project through Bndtools and then showing how to work with this project both inside Bndtools as well as from the command line with Maven.

Peter Kriens will also be around and keen to talk with anyone about OSGi enRoute or answer any questions.

In the true spirit of a BOF there will be plenty of opportunity for everyone to take part asking and answering questions, sharing and gathering insights and experience.

We hope you can join us at 19.30hrs this evening.

Mike

PS Don't forget its tutorial day tomorrow at OSGi DevCon - sign up to be sure of your seat.


Wednesday, June 11, 2014

Draft OSGi Enterprise R6 specification available

The OSGi Enterprise Expert Group has released a draft of the upcoming OSGi Enterprise R6 specification. You can find the following updates in the download package:

  • The new Asynchronous Services specification has been added which allows clients to invoke OSGi services in an asynchronous way.
  • A Promises API specification has been added. Promises are a very popular programming model in the Javascript world, where they make it easy to work with operations that execute in an asynchronous way. OSGi Promises follow a similar pattern. They are used by the Asynchronous Services specification, but can also be used independently.
  • A new specification on Framework management via REST has been added. This facilitates remote framework management in cloud and other contexts where REST is the protocol of choice.
  • A number of updates are made to the Remote Service Admin specification. RSA now supports remote endpoint modification notifications through new modification events. This means that if you update the service properties on a remoted services, this will no longer appear to clients as if the service was removed and then re-added. With the new modified event a previously remoted service will remain, and is updated in place.
  • Subsystems have been updated to version 1.1, a number of changes have been made to this specification including the ability to provide the Deployment Manifest separate to the subsystem archive.
  • The Repository spec has been updated to version 1.1, allowing more complex queries to be passed to the Repository.
  • A new HTTP Whiteboard specification is being worked on. This specification brings Servlet support up to Servlet 3.x and adds whiteboard-based Servlet and Filter registration.
  • Declarative Services is receiving an update which adds a new and really convenient way to work with Configuration, support for Prototype Service Factory (which is introduced in Core R6) and an introspective API.
  • The MetaType service is being extended with annotations.

You can download the draft specification from the OSGi website on this location. Note that the zip file contains the draft spec, as well as three RFCs for which no spec chapter is ready yet, these will also be included in the final specification.

Also released this week, the Core Platform R6 final specification. Get it here.

OSGi EEG co-chairs,
David Bosschaert
Tim Diekmann

Thursday, May 29, 2014

Only 2 weeks to go to the Big Apple...

June 11 to 13, New York at the New York Marriott at the Brooklyn Bridge.




We are on the final countdown to OSGi DevCon 2014 in New York.  There are just 2 weeks to go, so if you have not registered yet be sure to REGISTER NOW.

You can still save $200 by booking before June 9 and for groups of 3 or more there is a group booking discount.


We have an excellent schedule for the event this year and don't forget all attendees also get full access to the QCon New York conference as well as OSGi DevCon. 

Thanks to the OSGi DevCon sponsors Adobe and Cloudyle for supporting this event.

In total you have access to 4 keynotes and over 100 speakers, along with 2 dedicated OSGi Tutorials and an OSGi BOF. In addition there are deep technical case studies from organisations including NASA, Netflix, Twitter, Facebook, Amazon, and others.

With a 1:5 speaker to attendee ratio, over 500 of your peers in attendance, and numerous breaks and parties, the combined OSGi DevCon and QCon event offers fantastic opportunities for peer sharing and networking.

You can full details about OSGi DevCon on the conference home page including how to register, the conference location, how to book accommodation and the schedule.

We look forward to seeing you in the Big Apple on June 11.

If you have any questions you can contact the Program Committee by email.


Monday, May 12, 2014

Register For OSGi DevCon By May 25 For A Chance To Win.....

The countdown is on with just 1 month to go before OSGi DevCon 2014 in New York (11 to 13 June).

The Schedule is announced, the hotel is booking up, NOW is the time TO REGISTER if you haven't done so already.

There are some key money saving deadlines ending on Friday this week

  • Registration savings: You can save $300 if you book before May 17, that's this Friday. 
  • Hotel savings: The discounted hotel conference rate is only guaranteed for reservations made by this Friday too. 

Of course don't forget if there are 3 or more of you registering at the same time you can contact the QCon Registration Team for a group discount.

And now for the chance to WIN.....

Our friends at Manning Publications Co. have kindly donated some of their excellent OSGi Books that you have a chance of winning just by registering by May 25.  Don't worry if you have registered already you will also be entered in to the draw.

All you need to ensure is that when you make your reservation you select OSGi as the option in the last question (Are you primarily registering for:) and you will automatically be entered in the draw!

There is 1 copy of each of the following books and we will draw three names from the hat.


Good luck and get your registration sorted this week to benefit from the savings and be in with the chance of winning one of these books.

OSGi DevCon 2014 Program Committee



Friday, April 11, 2014

OSGi DevCon 2014 Schedule Announced

We are pleased to announce that the OSGi DevCon 2014 Schedule is now available.

Register before April 19 to save $400 per ticket. Yes thats just 8 days away!  Don't forget there is a group discount available if there are 3 or more of you registering at the same time.


As you will see there is plenty to keep you busy for the 3 day conference (June 11 to 13) in New York.

There are:
  • 23 Talks
  • 2 Tutorials
  • 4 keynotes
  • An Open Space session
  • A BOF

In addition attendees to OSGi DevCon 2014 also have full access to the QCon New York schedule which offers 5 tracks each day.

Plus there are plenty of social activities on offer to:
  • Exhibitor Reception
  • Conference Party
  • IBM Reception
  • QCon Reception
Your conference pass also includes breakfast (8am to 9am) and lunch each day.

Thanks to everyone who made a submission to the CFP. We really appreciate the time and effort that goes in to these.  The quantity and quality of the submissions was extremely good which gave the Selection Committee a tough time in coming up with the Schedule.

Thanks must also go to the Selection Committee for their assistance and time to produce the excellent Schedule for OSGi DevCon this year.

We hope yo can join us in New York in June.  As ever if you have any questions you can contact the Program Committee by email.

Click here for the OSGi DevCon 2014 Schedule

Tuesday, March 11, 2014

OSGi DevCon 2014 Update - Save $500 booking before March 15



The Call For Papers is now closed and the Selection Committee are hard at work picking the program.

Thanks to everybody who made a submission. We look set to have a fantastic program and we are expecting to announce this in early April.


You can get the best prices for attending by booking early.  Bookings made before March 15 save $500 per person so don’t delay and secure your place today. Registration is easy and is provided using the QCon registration system.

If there are 3 or more of you planning to attend you also qualify for a Group Booking discount.  Please contact the QCon conference team to obtain a group discount code.

Attendees to OSGi DevCon also get full access to all of the QCon program and are invited to all of the planned QCon conference social activities. Full details about OSGi DevCon 2014 location, hotel and registration are available on the OSGi DevCon 2014 website.

QUESTIONS?
If you have any questions about OSGi DevCon 2014 please contact the OSGi DevCon Program Committee by email at osgidevcon@osgi.org.


QCon New York is busy confirming speakers for its program.  Software Engineers, Technical Leads, and Data Scientists from LinkedIn, Netflix, Foursquare, Google, Mount Sinai, Gilt and others will describe how they're dealing with some of the greatest challenges in the arenas of Big Data, DevOps, Cloud Computing, Architecture, and Software Delivery.

The following sessions for QCon New York 2014 have just been confirmed:



There are 15 track themes for the 2014 QCon conference, see the full list of QCon tracks.

Hope to see you in New York at OSGi DevCon 2014 in June.

The OSGi DevCon 2014 Program Committee

Monday, February 24, 2014

Don't Delay - OSGi DevCon 2014 CFP Deadline Feb 28, 2014

The Call For Presentations (CFP) for OSGi DevCon 2014 deadline is this coming Friday, February 28.

With the deadline rapidly approaching please make sure you get your submissions in as soon as you can so you don't miss the cut off date.

The conference is being held in New York for the first time, co-located with QCon New York. We know there are lots of you out there in New York and the surrounding areas using OSGi so we hope you take the opportunity to submit a talk or at least join us for the conference while we are on your doorstep.

We are looking for submissions from anyone who has something to share about OSGi, large or small, new or old.  This can include use cases, case studies and your real world experiences from using OSGi. Tools and frameworks that improve the developer and user experience are also popular topics.  Examples and users of OSGi in the Cloud or in the IoT and M2M areas are of particular interest.

Submissions are invited in the following formats:

  • Presentations (50 mins)
  • Panel Sessions (50 mins)
  • Tutorials (180 mins)
  • BOFs

Further details about how to make a submission and access to the submission system are provided on the conference home page.

Submissions that are accepted will not only give you the opportunity to share your experiences and knowledge, but also provide the speaker with one (1) 100% discount for a 3 day pass to OSGi DevCon 2014 (June 11 to 13 in New York) - a value of up to $2,295!  This pass will give you access to the OSGi Tutorials on Day One (June 11) and the presentations, panel sessions, BOF's and other activities at OSGi DevCon on Days Two and Three (June 12 & 13).

Through our co-location with QCon New York attendees to OSGi DevCon are also entitled to full access to the QCon sessions and social activities that are taking place between June 11 to 13.

Save More By Booking Early

And for those of you who don't fancy presenting you can save more off the ticket price by booking early. The registration is open now and the next price increase is on March 15.  Full details on prices and how to register can be found here.

The Selection Committee are eagerly awaiting  your submissions so that we can start the review process in March and we expect to be able to confirm the schedule of selected talks in early April.

If you have any questions feel free to post a comment or email the OSGi DevCon 2014 Program Committee.

[Picture courtesy of PublicDomainPictures.net]

Monday, February 3, 2014

enRoute: Time

This is the first installment in the enRoute project's principles as I announced last week. In the principles section I am trying to lay down first principles. This first section is about what I believe to be the root of much of software's complexity: time. The purpose of sharing this text is to get feedback so we can come to a common set of principles that are shared by many people. I am doing this in installments since I am told that my blogs are already to long. The whole text can be found at github, where you can also report any ideas, issues, and proposals.

Enjoy.

Peter Kriens @pkriens

Time
Trying to explain our industry to lay people is hard. It is hard because what we software developers are doing has remarkably little to do with the concrete world; cyberspace is truly a different area. We use words like build, object, and framework that are defined in a concrete world but have much more ephemeral semantics in our virtual world. You build a house from concrete, stones, and wood, a far cry from flipping bits on a hard disk in what we call the build process. Objects are, yeah, what are objects actually? And where a real framework is touchable, our frameworks are intangible. No wonder that many our partners are at large when we try to describe what it is that we do. We tend to utterly confuse them with these inadequate metaphors.

Out of this all, the hardest aspect to explain aspect of our work is the volatility. The baker bakes bread, and the bricklayer builds buildings. They deliver a concrete result to their customers and the next day they bake or build something brand new, unrelated to yesterday's work. Software engineers 'build' their 'software' several times a day, but they seem to deliver largely the same thing over and over to their customers. We seem to be working on something that is continuously evolving but is still called the same. The closest metaphor is maybe a city. A city is a continuously evolving entity that never stands still, still we continue to give the same name. Julius Ceasar would not recognize Rome today, it is still the same city that he once knew.

It is interesting to see how we lack proper terminology in our industry. In maven we talk about an artifact but it is not clear if refers to the bits on disk (the JAR file), or the project that builds it, or something maybe even something else? In this document we use program for the what is the combination of groupId and artifactId in maven and revision when a specific version is added. The term project defines the concept of a set of programs that can be used to build a revision.

The difficulty of describing these core development processes clarifies why explaining to uninitiated what you do day in and out is hard. The core of our business is a long lasting process of reshuffling bits so that when they are combined with computers and users we achieve the results we promised. We call this process 'maintenance' but it has very little to do with the maintenance in the real world. In the real world, products deteriorate. A car needs an oil change or certain parts are designed to wear out over time and need to be replaced before they pass a breaking point, causing great damage. Bizarrely, in software we theoretically do not have wear and tear since a bit is a bit and they do not chance happenstance. A revision is immutable for all time. What we call 'maintenance' is actually a different process. In this process we:
  • Fix bugs.
  • Add features.
Though bugs can just be stupidities, quite often they are caused by the coder's assumptions of the environment. And when this environment changes, the assumptions are no longer met and the code fails. This is also called bitrot. It is the weird effect that over time programs that are not maintained will start to fail.

It should therefore be clear that a large part of our work is addressing the effects time. The context changes, which requires us to change the software, which changes the context for others. When we develop software we should be aware at any time that we are not really building anything but that we are in a continuous re-shaping process. It is crucial to be aware that any real world system lives in an ever evolving context where our own changes contribute to this changing context.
There are many practices in our industry that would be perfectly ok when change was no continuous, but that have unexpected consequences in world that never stops changing.

A surprising example is aggregating, putting parts together in a greater whole. For example, you repackage a number of JARs in a single JAR. Every time you aggregate a set of parts, you create an additional responsibility because the underlying artifacts, the dependencies, will each change over time at their own rate. Each of these changes will add maintenance costs to rebuild the aggregate. Also, you will have to make the aggregation evolve at the rate of its fastest evolving part or the clients of the fastest moving part will be upset. Therefore, by aggregating you increase the entropy of the build.
Last but not least, you now also constrain the revisions of the constituents as they are in the aggregate. Clients, that need a different set of the constituents are out of luck.

To problems around aggregation are illustrated by the concept of profiles. A profile is a set of API revisions put together so that end users can have a single JAR to compile against. In the Java world there are a number of J2ME profiles, and of course Java SE and Java EE can also be seen as profiles when squinting the eyes a bit. Developers in general love them because it seems to simplify their lives considerably. That is, until they find out there is a newer version of a profile's constituent that they absolutely need or when it is time to add new parts and they find that the process of maintaining the profile is highly politicized since there are now many different interests to take into account. In the 90's Ericsson and HP had TMOS, a Telecom Management Operating System, that imploded because they found it impossible to release a revision that satisfied the needs of all their users.

Though an aggregate or repackaging can have benefits, see [Modularity], the drawbacks of increasing the rate of evolution and the additional constraints between the parts do have a cost that is caused to this continuous changing world. These costs are often ignored because they are in the future when the first decision is taken, however, they should be taken more into account. We should reflect on our way of working not with an eye towards processes in the real world, but be acutely aware of the effect of a continuous changing world.

With respect to time, we should then take the following principles into account:
  • Versioning – Ensure that independent parts are versioned so that we (and the computer know) of what revision we are talking about.
  • Prepare for change – Ensure that the code base is always optimal for additional changes since they will happen.
  • Minimize the cost of change – Since things will change ensure that when change happens the impact, and thus the cost, is minimal.

Thursday, January 30, 2014

enRoute Principles

I am currently writing the principles of the enRoute project, which will be a precursor to the architecture. This will all become a chapter in the enRoute book. Since we will run the enRoute project in the open I will therefore use this blog to publish sections from this document in the coming weeks. I actively seek feedback, you can comment in github issues and do not hesitate to propose your own subjects or chapters.

Now principles of software is a huge territory. Despite feeling that I have some credentials after writing software for 40 years it still feels a bit presumptuous to make an attempt to define these principles. However, looking around me I see a lot of cases where working from shared principles could make a huge difference.

In software a situation is rarely black and white. In almost all cases there are many forces at play, sometimes directly opposite each other, that make some solutions more desirable than others. So in the upcoming blogs the principles of different aspects of software development are discussed. Not with the intent to provide black  and white rules but only with the hope that the forces for that aspect are understood and recognized.

So despite feeling a bit nervous I am going to try to put these principles down hoping that I get a lot of feedback so together we can come to a common understanding (if only to understand the different trade offs that come into play). So watch this space (or unsubscribe now).

Peter Kriens
@pkriens

Monday, January 13, 2014

OSGi DevCon 2014 - The Big Apple

We are pleased to announce OSGi DevCon 2014 will be taking place in New York June 11 to 13, 2014 so be sure to save the dates. Full details are available on the conference website.

OSGi DevCon 2014 will be co-located with QCon New York and is being held at the New York Marriott at the Brooklyn Bridge (Map).

This is an exciting new venue for OSGi DevCon and is the first time we will visit the Big Apple.

The co-location with QCon means that delegates to OSGi DevCon will also have the opportunity to take part in QCon New York conference sessions and join their social events - the Welcome Party, Exhibitors Reception and the Meet and Greet Reception.

We're excited to bring OSGi DevCon to New York, which also gives us a chance to share the OSGi content, including OSGi tutorials and case studies, with the QCon New York attendees.

Call For Presentations

The OSGi DevCon 2014 Call For Presentations is NOW OPEN. The deadline for submissions is 28 Feb 2014 so don't delay and get your submissions in to us as soon as you can.

We are looking for submissions in the form of presentations, panel sessions, tutorials and BOFs and expect to provide content for those new to or just starting out with OSGi along with plenty of interesting material for the more experienced.

Particular topics of interest for submissions include:
  • Case studies of OSGi in use in embedded, enterprise or desktop
  • Tools and frameworks that improve the OSGi experience
  • OSGi in the Cloud and its use in IoT and M2M are also encouraged
Full details on how to make a submission are provided on the conference web site.

Registration

Registration for the Conference is also open and we encourage you to book early as the rates for attending increase each month in the run up to the event.  The first early bird rate ends this Friday (18 Jan). You can find pricing and details of how to register online.

Conference Hotel

A discounted delegate rate to stay at the New York Marriott at the Brooklyn Bridge where the conference is located is available on a first-come-first-served basis. Details on pricing and how to book can be found here.

About QCon

QCon was launched in 2007 by InfoQ and has hosted over 12,000 attendees at their worldwide series of conference held in London, New York, San Francisco, Tokyo, Beijing, Chengdu, Shaghai and Sao Paulo.  Further background information on QCon is available from http://www.qconferences.com.

Questions

If you have any questions about OSGi DevCon 2014 please contact the OSGi DevCon 2014 Program Committee by email.

We hope to see you in New York in June.