modularity and smart cities - the fundamental role played by osgi

Copyright 2005 - 2017 Paremus Ltd.May not be reproduced by any means without express permission. All rights reserved.February 2017 www.paremus.com

Beyond Market HypeRealising the true potential of IoT.

Dr Richard Nicholson: Paremus CEO & OSGi Alliance Board

http://www.paremus.com

Copyright 2005 - 2017 Paremus Ltd.May not be reproduced by any means without express permission. All rights reserved.February 2017 2

Longevity?


London - 190AD


London - 2017AD


Beijing - 150BC


Beijing - 2017


Both Successful Cities Both have Adapted, Grown & Evolved


Why? How?

A City will continue to prosper as long as the cost of adapting to new circumstances does not exceed the new economic benefits.

Buildings can be repaired & incrementally replaced. However the plots of land remain the same.

Roads, Water and Sewerage & Energy systems all evolve in response to the Cities requirements. However their routes tend to remain the same.

Cities have Structural Modularity


The Importance of Being Modular

Copyright 2005 - 2017 Paremus Ltd.May not be reproduced by any means without express permission. All rights reserved.February 2017

What is a Module?

10

A module is a unit of encapsulation that communicates with other modules through agreed contracts

Encapsulation is the hiding of internal implementation details such that entities outside the encapsulated unit are not aware and cannot become aware of those details.

A contract is the definition of all supported modes of interaction and communication between cooperating modules, including the responsibilities and expectations of each actor.


Modularity underpins both Agility, Maintainability and so enables Longevity!

11

As long as the design rules are obeyed:

Modularity makes complexity manageable; Modularity enables parallel work; and Modularity is tolerant of uncertainty.

Here tolerant of uncertainty means that particular elements of a modular design:

may be changed after the fact and in unforeseen ways


Where is Modularity used?

12

Modularity is in use everywhere

Biological Systems - human body, organs, tissue, cells. Manufacturing Construction - Walls, Houses, Furniture Toys - LEGO, IKEA, bricks, Construction Kits (Meccano). Vehicles - car / bike production lines are based on assembling modules.


Smart Cities - 2017 to 2025 and Beyond!

Tomorrows successful Smart Cities will have large, sophisticated software nervous systems which will be embedded and an integral part of each City.

Each Smart City nervous system must have have similar Longevity and Sustainability characteristics as the physical structures they control and represent.

The software nervous system for each Smart City must also be modular.


But we have a problem?


http://www.darpa.mil/

Modern-day software systems, even those that presumably function correctly, have a useful and effective shelf life orders of magnitude less than other engineering artifacts.

While an application's lifetime typically cannot be predicted with any degree of accuracy, it is likely to be strongly inversely correlated with the rate and magnitude of change of the ecosystem in which it executes.

DARPA BRASS initiative April 2015

A Longevity / Adaptability problem


http://www.trustmarque.com/wp-content/uploads/2015/10/Trustmarque_IT_Complexity_Report_2015.pdf

We also have a Complexity problem

http://www.trustmarque.com/wp-content/uploads/2015/10/Trustmarque_IT_Complexity_Report_2015.pdfhttp://www.trustmarque.com/wp-content/uploads/2015/10/Trustmarque_IT_Complexity_Report_2015.pdf


Complexity drives up OPEX

Operational ComplexityIncreases OPEX


Cost == Effort required to Manage Dependencies as they Change Over Time.

No Change No Cost. But things ALWAYS change!

18

How does Complexity increase OPEX?


Complexity also increases Failure

Operational Complexity Increases the Likelihood and Duration of Service Failures

Berkleys ROC initiative.


Digital infrastructure exceeding limits of human control, industry experts warn

Guardian 23rd August 2013 http://www.theguardian.com/technology/2013/aug/23/nasdaq-crash-data"These outages are absolutely going to continue," said Neil MacDonald, a fellow at

technology research firm Gartner. "There has been an explosion in data across all types of enterprises. The complexity of the systems created to support big data is beyond the understanding of a single person and they also fail in ways that are beyond the comprehension of a single person."

"The outage at Amazon last year was traced back to some of the processes and technologies they had put in place to make it more resilient," said MacDonald. "It is almost like an auto-immune disease, where the systems they created to make it more resilient actually spread the failure more rapidly."

"We don't yet have a design for society that can run this technology well. We haven't figured out what the right human roles should be."

20

The Amazon S3 Outage Is What Happens When One Site Hosts Too Much of the Internet https://www.wired.com/2017/02/happens-one-site-hosts-entire-internet/

http://www.theguardian.com/technology/2013/aug/23/nasdaq-crash-datahttps://www.wired.com/2017/02/happens-one-site-hosts-entire-internet/https://www.wired.com/2017/02/happens-one-site-hosts-entire-internet/


Service Outage == Failure to correctly manage dependencies as they change over time - i.e.

Operational Error

Change may be intentional or due to component failure.

21

How does Complexity increase Failure?


So we need effective Software Modularity to achieve Adaption,

Evolution & Longevity.


But if we make Software Modular - dont we make it

more Complex?


A smart Phone

Simple to Configure / Operate (mostly)

Phone Internals

Moderately Complex

(but modular)

Is a modern Smart Phone simple or complex?

Processor Internals

Extremely Complex

(but modular)


All sophisticated artefacts are comprised of structural hierarchies.

When correctly implemented Modularity shields each layer of the structural hierarchy from the implementation

details of the lower layers!


So what is the problem with software?

Lets look at current IT Fashions e.g. Docker / Microservices


A `Silicon Valley` Cloud Native / Docker centric ecosystem (2017)

Comple

xity is

Expose

d to t

he

Custom

er!


Docker / LXC etc - Nothing Magical - just Linux Containers!

The deployment artefact - the Docker Image - is Opaque. Which libraries are actually included in the image & why?

Docker Images are referred to by `Name`.

Docker Images do not specify what they

Require from their environments, nor what their Capabilities are.

Weak Modularity & Dependencies Ignored


1. http://www.boycottdocker.org

2. docker in production a history of failure (http://bit.ly/2m3SowL)

Ad so Docker and related orchestration solutions fail to address Operational complexity

http://www.boycottdocker.orghttp://bit.ly/2m3SowL


Microservices Problems

These problems also leak through into the resultant runtime Microservices layer. Service Orchestration is complex as Service dependencies are not defined. Configuration, deployment, monitoring, alarm & log collection also need to be

explicitly managed as Infrastructure Service dependencies are not defined.

In addition NOT EVERY APPLICATION FITS the Microservices model: HTML / REST based Microservices are too heavy weight for many uses

(Performance, network latency). Impedance mismatch between the actual function / services and their

exposed REST-full representation. Inappropriate use of REST/HTML leads to in-efficient resource hungry

applications and code complexity.


MicroServices: No dependency management


Is this really the best we can do?

+


What about Java?


Java is almost Modular

Java was developed with a basic module system: Methods encapsulate local variables; contract is input parameters and return

value. Classes encapsulate fields and methods; contract is public methods. Packages encapsulate classes; contract is public classes and interfaces.

But not quite . Methods, Classes, Packages are not deployable entities. JARs are deployable but they are not modules because they offer no

encapsulation. Therefore Java lacks a concept of deployable modules.


Java - is missing layers of Modularity

Packages Classes

Unit of Deployment Unit of State

Unit of Composition

Unit of Inter Process Re-Use

Unit of Intra Process Re-Use

WS-* / RESTWorkflow etc

Business Service Application Structure Code Structure

?


Introducing OSGi


OSGi - Modularity for Java

JARs are perfectly good units of deployment. We Simply add the missing information to the JAR manifest!

A meaningful name A Version Explicit, versioned Requirements upon the external environment. Explicit, versioned Capabilities provided to the external environment.

After which we have created an OSGi bundle.

Now all that is needed is a runtime - an OSGi framework - that can use this addition Metadata.


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"

Client A: I love my cat Cathy, but not rich! Require-Capability: pet.grooming;filter:="(&(type=cat)(rate=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)

NB - these are LDAP expressions - not tied to a specific programming language (no dependency on Java).

A simple Requirements & Capabilities Example


microServices OSGi Services OSGi Bundles Packages Classes


Unit of Composition





39

OSGi - True Java Modularity


The Result?

Bundles in an OSGi framework can be individual stopped / restarted.

Bundles can be updated at runtime Composite runtime environments can be automatically

assembled from sets of bundles. OSGi provides a powerful Services architecture - REST, Async /

Sync RPC, Push Streams, Events.

As OSGi based software runtime assemblies are Composite, Adaptive and Evolvable - OSGi directly addresses the Longevity challenge posed by DARPA!


Introducing the OSGi Alliance


OSGi: The Open Industry Standard for Java Modularity since 1998!


All Markets: M2M, Smart Home, Telematics, Assisted Living, Healthcare, Automotive, Media, Control Systems, Energy Management, Smart Meters, Telecommunications, Robotics, ML / AI & Big Data platforms.

And the enabler for important Telco, Smart City & Industry 4.0 standards: Telco: OpenDaylight, ONOS, OneM2M

Smart Home: openHAB

OSGi Extensive Adoption since 1998


OSGi Ecosystem Examples


OSGi is the open industry standard for building modular Java software

However just like any other tool - OSGis effectiveness is a function of the Craftsman using it. To encourage and ensure best practices, and increased understanding, the OSGi Alliance has introduced the OSGi Developer Certification program.

see https://www.osgi.org/osgi-certification/developer-certification/

https://www.osgi.org/osgi-certification/developer-certification/


Introducing Paremus


UK Company founded 2001. Service Fabric product research & development started 2008 International reputation with customers (OSGi Training, Consulting, Service Fabric

product) in many verticals

Paremus Overview

47

Internet of Things / Smart City / Industry 4.0

In 2008, Paremus realised that Operational Complexity, Longevity & OPEX would cripple future large scale IT deployments. The Paremus Service Fabric directly addresses these fundamental issues.

On Premise - Autonomic Business


Paremus at the Heart of the OSGi Alliance

Paremus OSGi Alliance activities:

Board Members since 2009 President (2011 / 2013 - Dr. R Nicholson) Treasurer (2014 / 2017 - Dr. R. Nicholson) Strategy (2012 / 2017 - Dr. R. Nicholson) IoT Expert Group Co-Chair (2016/17 - T Ward) VP Marketing (2015 / 2017 - M Francis)

Paremus Contributions to recent OSGi Specifications include: Asynchronous Services Promises (Reactive OSGi strategy) Push Streams (Reactive OSGi strategy) Transaction Control (JEE / Database) Remote Service Admin Cluster Information Service


Paremus: World Leading OSGi skills

Neil Bartlett (Paremus VP Engineering / founder and project lead for Bndtools). OSGi Alliance Leadership award 2016.

Neil is recognised throughout the industry as an OSGi expert andevangelist. Over the last decade Neil has provided consulting and trainingfor numerous organisations in many different countries. Neil is currently writing his second book "Effective OSGi which will show developers how to quickly accelerate their productivity with OSGi using the latest techniques and tools.

Tim Ward (Paremus CTO / IoT EG Chair for the OSGi Alliance).

Tim is internationally recognised for his OSGi expertise, regularly speaking and giving tutorials at conferences around the world on topics such as OSGi, the Java Persistence API, Apache Aries, and Websphere Application Server. Tim also helped create the OSGi Alliance Developer the Certification program.Tim is also co-author of one of the more recent OSGi Books from Manning Publications called Enterprise OSGi in Action.

http://bndtools.org

49

http://www.manning.com/cummins/


Dependencies, Dependencies, Dependencies

51

1.Dependencies MUST NOT be masked or hidden. Dependencies at each structural / logical layer must be explicitly managed.

2.Artefacts must be self-describing.3.One MUST NOT assume that

dependencies are static. Dependencies are dynamic and this dynamism MUST be managed.

4.To minimise Operational Complexity, runtime dependencies must be automatically managed by the runtime platform.


The Paremus Service Fabric

A modern Java / OSGi based distributed Platform Isolates your applications from Cloud Providers Infrastructure (e.g. AWS, Google, etc). Enables the rapid creation of on-premise Cloud, MicroCloud or Ad-Hoc Cloud runtime

environments on either physical or virtual resources. Operationally Extremely Simple: To Create, Install, Manage, Scale and Maintain:

including infrastructure Services: e.g. ZooKeeper. Secure by Default: Both Resource Membership and the distributed communications

between participating members.


The Paremus Service Fabric

Big Data

Machine Learning IoT/Fog

Application / Architecture Agnostic: Big Data, lightweight IoT, traditional Enterprise, Java and non-Java applications may all be hosted upon and managed by the Fabric. These applications may be REST, Reactive Async RPC, Stream or Actor based.

Lightweight & Resource Agnostic: A Fabric may be hosted on a single Raspberry Pi. A 10 Fibre Service Fabric can be run in a single 4GB VM.

Autonomic Capabilities - Adaptive to Environment Changes / Robust against Failures. The Fabric decouples and protects from planned infrastructure changes, unplanned resource failures.

Based on open Industry Standards - OSGi with support via Docker, non-OSGi and non-Java artifacts.


A Service Fabric is comprised of one or more Fibres (OSGi frameworks). Each Service Fabric is created from a dedicated Fabric Profile.

Fibres may be rapidly created from groups of physical machines, virtual machines and / or Linux containers.One or more systems (i.e. composite applications) may be imported to - and deployed in - the same fabric

Hence a Service Fabric may be:

Dedicated to a single Application: i.e. a shrink wrapped distributed solution / Cloud Appliance

Shared by a group of functionally related Applications. Dedicated to a business unit / or a functional unit of an

Organisation (e.g. dedicated Dev, UAT & Production Fabrics).

Provide a shared Platform for Services offered internally or externally by the organisation (i.e. PaaS).

Runtime Modularity

Copyright 2005 - 2017 Paremus Ltd.May not be reproduced by any means without express permission. All rights reserved.Februaryr 2017 55

Self-Describing, Self-Managing Modular Applications

A system may be deployed to a Fabric as quickly and easily as installing an application on a Smartphone or Tablet.

A `system` is a composite application.

A `system` is the unit of Ownership, unit of Release, unit of Operational Management.


A system is composed of one of more system.parts. A system.part is a functional unit (e.g. a Microservice) and the unit of Scale Out. System.part instances are deployed to fibres - by default instances will not be

colocated to the same fibre. A system.part may be composed of one or more system.part.elements A system.part.element may represent an OSGi assembly or a Container Image.

System Structural Hierarchy

microServices uServices OSGi Bundles Packages Classes


system

system.part

system.part.element


Unit of Composition



07/01/2015 00:17Hogosha

Page 1 of 2https://178.62.36.81:9106/paremus/entire/index.html#/fabric/Hogosal-demo/resolution/com.paremus.demo.fractal.http/fibre/fabric-2.1

fractal-demo :: com.paremus.demo.fractal.http@ fabric-2.1

com

.par

emus

.dem

o.fra

ctal

.http

v1.

0.0

org.

eclip

se.e

quin

ox.h

ttp.s

ervle

t v1.

1.30

0.v2

0120

522-

1841

org.

eclip

se.e

quino

x.http

.jetty

v3.0

.0.v2

0120

522-

1841

org.a

pach

e.arie

s.jnd

i v1.0

.0

osgi.ac

tive.bu

ndle v

0.0.0

osgi.res

olved.bu

ndle v0.

0.0

org.apache.felix.f

ramework v4.2.1

jackson-core v2.0.0

jackson-databind v2.0.0com.paremus.demo.fractal.api v1.0.0

javax.activation v1.1.0.v201108011116

javax.annotation-api v1.2.0

javax.inject v1.0.0

org.bndtools.rt.rest v2.2.0.201312311620

javax.xml v1.3.4.v201005080400

com.parem

us.service.async v1.0.0

osgi.cmpn v4.2.0.200908310645

org.eclipse.jetty.http v8.1.8.v20121106org

.ecl

ipse

.jetty

.io v

8.1.

8.v2

0121

106

org.

eclip

se.je

tty.u

til v

8.1.

8.v2

0121

106

slf4j

.api

v1.

7.4

ch.q

os.lo

gbac

k.clas

sic v1

.0.0

org.ec

lipse

.jetty

.serve

r v8.1

.8.v2

0121

106

org.ec

lipse.je

tty.co

ntinu

ation

v8.1.

8.v20

1211

06

org.ec

lipse.je

tty.ser

vlet v8

.1.8.v2

012110

6

org.eclips

e.jetty.se

curity v8

.1.8.v201

21106

org.apache.f

elix.configad

min v1.6.0

org.apache.aries.proxy v1.0.

0

org.apache.aries.util v1.0.0

org.objectweb.asm.all v4.0.0

component v1.8.2

http v1.1.3prim

ordial.part v0.0.0

jndi.provider v1.0.0

org.apache.aries.jndi v1.0.0Type Name/Filter Resolved by

javax.naming org.apache.felix.framework 4.2.1

javax.naming.directory org.apache.felix.framework 4.2.1

javax.naming.ldap org.apache.felix.framework 4.2.1

javax.naming.spi org.apache.felix.framework 4.2.1

jndi.provider jndi.provider 1.0.0

org.apache.aries.jndi org.apache.aries.jndi 1.0.0 slf4j.api 1.7.4

org.apache.aries.jndi.urls org.apache.aries.jndi 1.0.0

org.apache.aries.proxy org.apache.aries.proxy 1.0.0 slf4j.api 1.7.4

Alarms


And the Fabric supports Polyglot Microservices & Docker Containers!

57

microServices uServices OSGi Bundles Packages Classes


Unit of Composition





?Packager allows generic software artefacts to be treated as OSGi bundles: e.g. RabbitMQ, a Database, Java Script or C / C++ code. 1. OSGi Requirement / Capabilities metadata is used.2. The OSGi bundle life-cycle is used. 3. OSGi configuration mechanisms are used.4. And so distributed dependency / orchestration

services are provided via the Service Fabric.

However, rather than the OSGi framework, the software artefact is hosted in its own local Linux Container (e.g. Docker), or as a native OS process.

RabbitMQKafka

ZooKeeper

PostgreSQL PythonSpark

Cassandra

JavaScript/

nodeJS

C/C++

Go


Demo


Fabric & IoT


Smart Cities - 2017 to 2025 and Beyond!

OSGi is the Open Industry Standard for software modularity upon which the tomorrows modular software nervous systems can be built and evolved.


The Paremus Service Fabric is an Example of such a runtime - Smart City OS - Industry 4.0 OS - Smart Agriculture OS!

Secured / hardened / lightweight / high performance JVM

secured / hardened / lightweight OSGi framework

Operational Simplicity: Installation, Operational management and maintenance.

Fabrics Autonomic and Self-Repair capabilities.

Security throughout the runtime stack.

Lightest weight resource footprint.High performance Paremus

implementation of OSGi specifications.

A supported modular cloud runtime for Smart City, Industry 4.0 and Smart Agriculture

OSGi

frameworks

Java

JVM


The Catalyst for local IoT based Economies

Local Service Fabrics can be simply and rapidly created and adapted in response to changing Business or Environmental conditions.

Each Fabric can be optimised for the requirements e.g. Smart City, Industry 4.0, Smart Agriculture requirements.

Service Fabrics may be deployed: Locally on-premise or in remote public Cloud To physical or virtual machines. Managed by local Operational staff.


Placing Data Processing & Intelligence where it is needed

Data is processed `in-the-context` of the local environment that generates the data.

Analytics / AI are deployed to optimal processing locations and are aware of the local context.

Local services are optimised for low latency and / or high throughput - i.e. SCADA.

Then refined / augmented / anonymised information may be, optionally, sent to third parties.


Security and Governance

Each Fabric is secure by default: Resources can be allowed or refused

to participate in the Fabric. Communication between

participating members is secure.Each Fabric is self-configuring. No

reliance on external DNS services. Governance is explicit. At all times the

pedigree of all software components is known.

Rapid re-start, re-configure and patch / adaption behaviours mean that un-foreseen breaches can be rapidly closed and countered


An Adaptive / Sustainable EcosystemSmart Cities, Industry 4.0, Smart Agriculture and Public Clouds all are all peers (leveraging Gossip protocols) in an Evolvable Federated Smart Ecosystem

factory I local real-time

fabric

factory II local real-time

fabric

manufacturer off-site

non-realtime analytics fabric

Copyright 2005 - 2017 Paremus Ltd.May not be reproduced by any means without express permission. All rights reserved.February 2017 www.paremus.com

www.paremus.com @Paremus [email protected]

Thank You

http://www.paremus.com

67

OSGi

OSGiTMOSGi2013

OSGi

OSGi OSGi http://china.osgiusers.org

OSGi