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

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.

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?