Tuesday, March 26, 2013

Wow, Day 1 of OSGi DevCon is already over. The location here in Boston this year is excellent, plenty of space and pretty good wifi, although they seem to be selling out of beers too fast at the hotel bar! If you want to keep up with the latest activity be sure to follow the OSGi Alliance Twitter feed (@osgialliance).

Day 1 was Tutorials day and Neil Bartlett and Tim Ward both had good attendance at their OSGi Tutorials. There were also two OSGi BOFs in the evening. Jamie Goodyear hosted a Karaf Users BOF and Glyn Normington and Chris Frost hosted a Virgo BOF.

But Day 1 was just the warm up.... There is a really full schedule of talks and activities planned over the next three days.

Highlights include an update on the latest OSGi specifications and a sneak peak of whats coming up in the future

OSGi Tooling discussion

Also there will be a free prize draw to win one of several OSGi Books, so plenty of swag too!

OSGi and JavaScript Workshop - Thurs March 28, 1.30pm to 3.30pm
Simon Kaegi, who is presenting at the conference on the same topic, will be hosting this workshop to look at how OSGi concepts might map to JavaScript, with the aim to gather requirements and foster discussion around producing an OSGi Alliance RFP for this. So this is your chance to get involved and input and influence in to a potential future OSGi specification.

OSGi Surgery
There is an OSGi Surgery being run where you can book a free 30 minute one on one meeting with Neil Bartlett to discuss anything OSGi.

Whether you want to review code or an issue you are having, explore how OSGi might fit in your environment, or if you are brand new to OSGi and just want to ask some newbie questions that you dont feel comfortable asking in one of the talks then this is a great opportunity. Slots are limited and you need to book in advance. Details and how to book can be found here.

Hope you have been able to join us at the conference and enjoy Day 2! If you have any questions please contact us by email.

Thursday, March 14, 2013

Earlier this week a new OSGi Early Access Draft was made available. A lot of new work is currently underway in both the Enterprise Expert Group (EEG) as well as the Core Platform Expert Group (CPEG) and in this document you can see where things currently are. Below you can find a short summary of each of the RFCs to get an idea what they are about.

RFC 182 - Defines a REST Management Interface for OSGi Frameworks. A number of remote management specifications already exist for OSGi, but especially in the context of Cloud Computing a REST-based management API is highly desirable. This is defined in RFC 182.

RFC 183 - Cloud Ecosystems. This RFC defines how a number of OSGi frameworks can work together in a Cloud Computing context, or other environment where multiple frameworks collaborate together. It describes how OSGi frameworks and their associated node-related meta-data can be discovered within the Ecosystem. It also covers how these frameworks can communicate across nodes to provide a fluid environment where a logical application is spread across multiple nodes and its components and services can easily be moved from one VM to another to deal with changes in machine load, available resources and other constraints.

RFC 184 - Blueprint 1.1. This RFC defines a collection of updates to the Blueprint specification that include the ability to switch off damping, change the behavior of the grace period and other changes.

RFC 185 - Data Transfer Objects. OSGi has always provided mechanisms for remotely managing its technology, but as the number of specs and the number of management technologies both grew maintaining coverage across all specs for all management technologies became a challenge. Data Transfer Objects provide a means for an OSGi specification to provide information suitable for a management agent in a technology-neutral style. The idea is that every OSGi spec defines its DTOs and that this can then be easily, possibly mechanically, mapped to most management technologies, so that they are kept up-to-date with a lot less effort than what was previously required. RFC 182 builds on top of these DTOs, other management specs (such as JMX) will most likely be updated in the future to take advantage of them too.

RFC 187 - Complex Repository Requirements. The Enterprise R5 specification defines the OSGi Repository spec. This was really the first Bundle Repository specification, although the Apache Felix project did have an OBR project before. The OSGi Repository is a simple yet powerful spec, which defines an API that allows one to find resources based on capabilities. RFC 187 adds a small enhancement to this specification which makes the querying mechanism even richer. It allows the combination of multiple capability namespaces into a single query so that you can express things like: I need a bundle that exports package org.foo and has license X. Or I need a bundle that provides the Declarative Services capability and has passed our company's internal QA process.

RFC 188 - Native Namespace. This specification adds a capability namespace for the generic OSGi Capabilities and Requirements model to represent the Bundle-NativeCode header. While other requirements in the Bundle Manifest, such as Import-Package or Fragment-Host can already be described using generic requirement namespaces, the Bundle-NativeCode did not have such a mapping yet. This RFC addresses this issue.

RFC 189 - HTTP Service Updates. The HTTP Service specification has been around for a long time and has seen many projects using it. However, it was long due an update to modernize it in relation to the Servlet Specification and the way people generally use OSGi Services. This RFC brings the HTTP Service spec up-to-date. It makes it possible to use Servlet Filters, adds the ability to use the Whiteboard pattern and provides additional configuration mechanisms.

RFC 191 - Weaving Hook Enhancements. This RFC enhances the Weaving Hooks allowing consumers to find out in what stage the weaving of a certain class is. In particular it helps the Subsystems specification to react appropriately to any imports that were added dynamically during the weaving phase.

RFC 193 - CDI Integration. This RFC focuses on how CDI beans can be deployed in OSGi and how these interact with the OSGi Service Registry. It brings annotation-based interaction with OSGi Services based on the popular CDI annotations. As with any OSGi component technology that uses the Service Registry, it will allow you to mix-and-match them. So a CDI bean can be injected by a service created in a Blueprint component. Similarly a simple Declarative Services client could obtain a service that was created in a CDI bean, and so on...

RFC 195 - Service Scopes. Up until now the OSGi Service Registry has supported two models. Either a registered service instance is shared across all consuming bundles or each distinct client bundle gets a separate instance. Recent work in the context of CDI and EJB integration (an OSGi/EJB RFC is being worked on but didn't make this draft) indicates that additional models are desirable. For example where a new service instance is returned every time the service is obtained, to fit stateful session models. This RFC describes additions to the OSGi Service Registry that support these models.

Wednesday, March 13, 2013

OSGi DevCon 2013, one of our main events of the year, is just 11 days away..

Will you be joining us in Boston at the Seaport Hotel & World Trade Center?

We have a jam packed schedule with a full program of OSGi Tutorials and Talks, an OSGi BOF on Tuesday evening and an OSGi and JavaScript Workshop on Thursday. There is plenty on offer whether you are an OSGi beginner or more.experienced. If you havent registered already be sure to sign up soon.

The conference program Talks are:

Modularizing Large Legacy Java Applications

Deploying Heterogeneous Artifacts to the Cloud with OSGi

Winning the WAR on complexity

Managing Installations and Provisioning of OSGi Applications

Enabling Smart Data on M2M Gateways and Aggregators

OSGi and JavaScript

RFC-193: Bringing CDI to the OSGi platform

Liberate your components with OSGi services

Modularity in the Cloud: A case study

What’s new in the Http Service Specification

DS, BP, EJB, CDI,WTF!?

Cooking up a Runtime with the new OSGi Resolver

Master Bundle Buildling

OSGi Cloud Ecosystems

Practical OSGi Subsystems

Apache Karaf in the Trenches

OSGi server runtimes – build, borrow or buy?

And the tutorials are:

Mastering OSGi with Ease

Stack Roulette - 180 Runtimes in 180 Minutes!

For anyone that hasnt been to an OSGi DevCon before then on top of all of this there will be plenty of OSGi experts and OSGi Alliance representatives in attendance who will be pleased to answer any of your questions. Its also a great opportunity to network with your peers, to learn more about how OSGi is being used, and find out about the latest and greatest advancements and future capabilities that are being planned.