Thursday, February 4, 2016

Building the IoT with OSGi - Jaxenter

There is a great article published earlier this week in Jaxenter talking about the important role that OSGi has to play in IoT.  The article is by Tim Verbelen from iMinds. Tim is an invited contributor at the OSGi Alliance.

Tim discusses how the OSGi service model offers an elegant and easy way to deal with the challenges presented by the sheer volume of different devices, APIs and protocols, and the different lifecycle requirements that they all have.

The big improvements in OSGi tooling from Bndtools and OSGi enRoute are also covered.  If you haven't checked these out for yourself then they are definitely worth a look.

The article goes on to look at a Smart Home Dashboard case study that Tim has been working on with his colleagues at iMinds.

And to emphasise the concluding point - you can get involved with the OSGi IoT Expert Group to help define and deliver the specifications to further improve the IoT experience and ensure that the interfaces to all of these devices are interoperable.

Tuesday, January 26, 2016

2016 Dates - OSGi Developer Certification Professional Exams

The OSGi Alliance Developer Certification team are pleased to announce he first four dates for the OSGi Developer Certification - Professional exam in 2016.

We will be considering further dates and locations throughout the year depending upon demand. So if you are interested and these dates or locations don't work for you please let the Developer Certification team know your suggestions for other dates and locations.

The first exam for 2016 is being held in London, UK on Friday 11 March between 9.30am and 1.00pm.

A full list of the locations and dates that have been announced so far are as follows:

Date & Time Location
Fri 11 Mar, 2016. 9.30pm to 1.00pm London, UK BOOK NOW
Fri 15 Apr, 2016. 9.30pm to 1.00pm New York, NY, USA BOOK NOW
Mon 31 Oct, 2016. 1.30pm to 5.00pm Ludwigsburg, Germany BOOK NOW
Fri 25 Nov, 2016. 9.30pm to 1.00pm São Paulo, Brazil BOOK NOW

We have maintained the 2015 price for the exam at $500 per person, and the discounted student price of $200 (which requires proof if student status).

The exam is 3.5 hours in duration and consists of three sections:
  • Section 1 – written questions and answers, consisting of both multiple choice and open questions.
  • Section 2 – a practical assignment with working deliverables developed and submitted for assessment.
  • Section 3 – a practical troubleshooting assignment. Here OSGi bundles are provided and answers should be written on the exam paper.
Details of the exam topics that may be covered along with answers to other FAQ can be found on the OSGi Alliance Developer Certification webpage.

If you have any questions please contact the Developer Certification team at the OSGi Alliance by email.

Monday, January 25, 2016

OSGi IoT Developer Hack Challenge with Bosch

OSGi Alliance Strategic Member, Bosch, is organising a Hack Challenge for developers that will include the opportunity to experiment with OSGi technology to implement industrial IoT solutions for the Bosch Power Tool range of products.

The Hack Challenge is free to attend and participate and it will take place at the Bosch ConnectedExperience event which is being held at Café Moskau, in Berlin between March 8 to 9, 2016.

To participate developers should register online.

Developers who attend the Connected Power Tools Hack Challenge will get the opportunity to work with the most advanced Power Tools from Bosch Rexroth as well as additional equipment to solve real world problems. These challenges include locating tools, supporting the worker in using these advanced tools, and building new sales and maintenance services for the users. The Bosch IoT Suite, which includes the ProSyst mBS OSGi Framework, can be used to build new and disruptive IoT applications in this area.

For further information please see the Hack Challenge website or contact Kai Hackbath from ProSyst (Bosch).


Good luck!

Saturday, December 12, 2015

IoT & Standards

About 8 years ago Apple steamrolled the mobile telephony industry with the first iPhone. They drastically disrupted the symbiosis of operators and device manufacturers. Nokia and Motorola did not survive this mayhem and knowing the operators of 15 years ago they are still have not recovered.
After visiting the ETSI OneM2M workshop in Nice for three days I am wondering if history will repeat itself? It feels like the telecom industry never analyzed why Apple ate their lunch and thought about how to defend itself against the next attack. In the workshop the work is about standardizing protocols, abstract reference semantic reference models, and maybe some open source influence. The underlying rationale is the somewhat tired lesson that collaborating on protocols will enable interoperability, which will increase the pie many times. True, but how do we prevent that an Apple will come again and steal the pie under our nose?

Apple succeeded so easily because it hit the soft underbelly of the mobile telekom industry: software. Software was proprietary in the telekom industry, protocols were paramount. Only after NTT Docomo succeeded on generating revenues on applications did the industry enable a severely crippled software model on the phones. I did participate in an attempt of Motorola, Nokia, IBM and others to set a better software standard based on OSGi just before the iPhone hit. I can ensure you that we didn't stand a chance because the focus was on irrelevant aspects like managing the device, constraining the application developer, and lowering the cost. Instead the focus should have been on what independent developers could do with a programmable device.

The rest was history.

The iPhone enabled Facebook, WhatsApp, Google Maps, and all of the other millions of applications because anybody could write cool applications for it which is the truest source of innovation.

The telekom industry is now sitting on the fence of  a huge new market: The Internet of Things. The industry is eminently suited to provide the connectivity and having first row access to the humongous pie of IoT services. Instead of learning the lessons of the mobile telephone industry it feels like history will repeat itself.

It is the software, stupid!

Peter Kriens

Thursday, December 3, 2015

Functional Modularity - Building Better APIs for the OSGi Ecosystem

Introduction


One of the new RFCs (RFC 216) being discussed in the Enterprise Expert Group is called PushStreams and is all about stream processing. I’m leading the RFC and whilst a final specification is still a way off, the open processes at the OSGi Alliance mean that people (including me) have already been talking publicly about this RFC.

My talk about PushStreams at the OSGi Community Event was well attended, and feedback on it led me to write a blog post about why we need PushStreams. Since then there have been even more questions, including a few about the design of the API and the theory behind it. I thought therefore I should talk a little about the reasoning behind the APIs from some OSGi specifications that I've worked on in the last few years.

Functional Programming at the OSGi Alliance


The OSGi framework is a module system for Java, and Java is inherently Object Oriented in its approach. Given that this is the case why is OSGi starting to define APIs with a more functional usage pattern? In fact OSGi is far from alone here, Open Source Projects, and even Java itself, are building more functional concepts into the libraries that we all use.

The reasons for this change are varied, but in general functional concepts are introduced to solve problems in a simpler way than is possible using Object Oriented programming techniques. OO programming provides a lot of benefits, but as systems become more distributed, more highly parallel, and more asynchronous they become much harder to manage and to reason about.

OSGi as a technology is used across a huge range of sectors, and across many layers of the technology stack. OSGi is used in embedded software, such as car entertainment systems and home gateways; it is used in desktop applications, such as Eclipse RCP apps; and it is used in server runtimes, such as Java EE application servers and distributed cloud runtimes.

In order to support such a large ecosystem it is vital that OSGi continues to evolve to better match the areas it is used. To better support distributed server platforms the OSGi compendium release 6 included Promises and the Async Service. The addition of PushStreams will help to support new use cases from IoT, where event filtering, forwarding, and aggregation are vital parts of allowing systems to work in the real world.

For those of you already familiar with functional programming, you will notice that the PushEventSource and PushEventConsumer are an example of an Enumerator and an Iteratee. Once a basic implementation is available I’ll put together some examples showing just how much they can simplify processing a stream of events.

Tuesday, December 1, 2015

Using Requirements and Capabilities

by Ray Augé, Senior Software Architect, Liferay  


I really love how everyone at Liferay is taking to the OSGi development model. It makes me proud to see how much work has been done in this regard.
There's one very cool area I think is worth expanding on.

Requirements and Capabilities


What is it? Some history.


The Requirements and Capabilities model is a surprisingly powerful concept born from the 17 years of experience the OSGi Alliance has in designing modular software: defining strong contracts. In OSGi contracts are described with meta-data and enforcement by a strict runtime.

The process involved in defining these contracts led to a frequently repeating pattern. First a contract was defined using special manifest headers and their specific semantics. An example of this is the Import-Package header which is used to specify what java packages should be made available so that your code can execute. This was followed by the need to implement the specific logic to enforce the definition. The result of this work manifested itself (excuse the pun) by what we recognize as OSGi Bundle manifest headers and the OSGi frameworks that enforce the semantics of those headers.

Around 2005 some very smart people in the OSGi community and OSGi Alliance recognized a pattern and developed it into a constraint model called Requirements and Capabilities.

How does it work?


A contract is defined starting with a unique namespace. Within this namespace semantics are defined for a set of attributes and directives. The entire definition forms a type of language from which can be created instances of Capabilities and Requirements.

Let's take an example.

Suppose I want to describe a service (which begins by defining a contract) where people can take their pets to be groomed. There are many types of pets, and many grooming agencies who can only groom certain kinds of pets because of the special skills, equipment or facilities required for each type. It can be a challenge to find an appropriate agency to groom your pet.

Let's imagine that every agency declared their capabilities using a single name-space called pet.grooming having 4 attributes:
  • type: a list of strings naming the type of pets groomed by the agency
  • length: a positive integer specifying the maximum size of the pet which the agency can groom
  • soap: a string naming the type of soap used by the agency
  • rate: a positive integer specifying the rate per hour charged by the agency

Here we have three example agencies using this contract in the syntax found within an OSGi Bundle manifest:

Agency A: Haute Pet Coiffure
Provide-Capability: pet.grooming;type:List="dog,cat";length:Long=800;soap="organic";rate:Long="50"
Agency B: Great Big Pets
Provide-Capability: pet.grooming;type:List="cat,horse";length:Long=3000;soap="commercial";rate:Long="20"
Agency C: Joe's Pets
Provide-Capability: pet.grooming;type:List="dog,cat";length:Long=1500;soap="regular";rate:Long="15"
Clients could then declare their Requirements using the pet.grooming name-space and a special LDAP filter.

Let's take a look at 5 clients:

Client A: I love my cat Cathy, but not rich!
Require-Capability: pet.grooming;filter:="(&(type=cat)(rate<=20))"
Which agencies do you think satisfy this requirement? (hint: B & C)

Client B: Huge Dog Doug
Require-Capability: pet.grooming;filter:="(&(type=dog)(length>=1000))"
Which agencies do you think satisfy this requirement? (hint: C)

Client C: Horse Haurice
Require-Capability: pet.grooming;filter:="(type=horse)"
Which agencies do you think satisfy this requirement? (hint: B)

Client D: Stylish Stan
Require-Capability: pet.grooming;filter:="(&(type=dog)(soap=organic))"
Which agencies do you think satisfy this requirement? (hint: A)

Client E: Cat lady Clara
Require-Capability: pet.grooming;filter:="(type=cat)"
Which agencies do you think satisfy this requirement? (hint: A & B & C)

Client F: Hiccup
Require-Capability: pet.grooming;filter:="(type=dragon)"
Which agencies do you think satisfy this requirement? (hint: Oh my!!!)

Observation: What happens for client F? This is a case where requirements cannot be satisfied. What does this mean? This might translate directly into the resource containing this requirement not resolving. In other words, it might be completely blocked from doing whatever it was it intended to do. This is a remarkable characteristic. That we could know in a safe and reproducible way that a resource cannot be satisfied could prevent any number of catastrophic situations we would hard pressed recovering from at runtime.

Once again, note the name-space and the filter used to query or match the attributes of the available Capabilities.

This language, which first materialized as OSGi RFC 112, is very powerful and can model a wide range of contracts. It's power was demonstrated by the fact that all bundle headers from prior OSGi specifications could be modeled by it. It also became possible to implement an engine which could calculate a set of resources given an initial set of requirements. This engine is known as the resolver and all OSGi frameworks beginning at release R4.3 have such a resolver at their heart. Since then it's possible by specifying new name-spaces to model new contracts specific to your own needs. These new contracts play at par with any of the OSGi defined name-spaces.

In Liferay we have used this language to generalize contracts for JSP Tag Libraries to enable modularity around their use, for Service Builder extender support, so that the correct version of service builder framework is available to support your SB modules. We have also used it to create a prototype of RFP 171 - Web Resources to enable modular UI development.

One of great benefits of having such succinct way of defining a contract is that much of the information can be auto generated through introspection which makes it both easy to implement and use. The majority of cases require little to no effort from the developers who are requiring capabilities, and greatly reduces the effort for developers who are providing them.

Recently the bnd project was enhanced with a set of annotations to easily produce arbitrary Requirements and Capabilities automatically. These annotations can be seen in use in the OSGi enRoute project.

As a follow up to the bnd POC an RFP was submitted to and accepted by the OSGi Alliance under RFP 167 - Manifest Annotations to specify a standard set of annotations for simplifying and enhancing manifest management programmatically, including Requirements and Capabilities.

There is a lot of exciting work going on in this area and many opportunities to get involved, the simplest of which is giving feedback on or testing current work.

How could you use the Requirements and Capabilities model in your project?

Monday, November 23, 2015

OSGi and IoT: The emergence of a continuously growing platform


An article was published by JAXenter back in August 2015 entitled "OSGi and IoT: The emergence of a continuously growing platform".

The original article was in German however we are pleased to say that JAXenter have agreed for us to provide an English translation.  This can be downloaded in pdf format from http://bit.ly/1IbsDOF.

Happy reading.

Mike

Blog Archive