OSGi R7 - Microservices never looked simpler

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

OSGi R7 – microservices never looked simpler. October 2017

Tim Ward [email protected]

OSGi R7 – microservices never looked simpler.


Reactive OSGi meets Reactive Java October 2017

Who is Tim Ward?

Chief Technology Officer at Paremus

9 years developing OSGi specifications

Co-chair of the OSGi IoT Expert Group

Interested in Asynchronous Distributed Systems

Author of Manning’s Enterprise OSGi in Action http://www.manning.com/cummins

@TimothyWard

http://www.manning.com/cummins



Services, Microservices and µServices



What do we mean by “service”?

Simply put, a service is software that does something! Retrieving/updating stored data Transforming data from one form to another Providing access to real time sensors/actuators

10-15 years ago these services were Web Services Web Services tended to be large and coarse grained Usually HTTP front ends bolted on to an existing system

Microservices were an evolution of (or reaction to) Web Services Smaller, fine-grained services with a dedicated process Applications built from many Microservices



What do we mean by “service”? (2)

In OSGi Services have existed for even longer A way to maintain loose coupling between modules A dynamic representation of a changing physical environment

OSGi services are ultra-lightweight microservices Just a call from one object to another OSGi services are usually in-process

OSGi Services are an excellent way to build microservices It’s turtles all the way down!



The Basics of an OSGi Service

An OSGi service is a Java Object It’s registered in the OSGi Service Registry The registration includes the Service’s API

OSGi services also have properties These provide additional information They can help clients when multiple services exist They can also communicate other information…

ProviderConsumerMyService

foo = bar



Easy ways to Publish an OSGi Service



Declarative Services

Declarative Services is an OSGi Compendium Specification A container for registering and consuming OSGi Services Automatic dependency and lifecycle management Annotation driven metadata

Providing a Service:

Referencing a Service:

@Component public class MyServiceImpl implements MyService { … }

@Reference private MyService myService



Declarative Services (New for R7)

Constructor Injection! Previously only fields or bind methods were supported

Activation Fields! Inject configuration and/or other types without an activate method

Component Property Types Custom annotations that can define service properties You’ll be seeing more of these later!



Service Whiteboards



What is a whiteboard?

OSGi services usually communicate between bundles Sometimes they are also used to register extensions A whiteboard service is designed to be “extended” in some way Service properties are used to identify and configure the services

There are several Whiteboard compendium specifications The Http Service Whiteboard exposes Servlet services New in Release 7 - the JAX-RS Service Whiteboard

The R7 updates include Component Property annotations



The Http Whiteboard

The Http Whiteboard is a simple way to provide Servlets Service properties for things you would normally find in web.xml

Write a normal Servlet Make it a service Add the osgi.http.whiteboard.servlet.pattern property

In R7 this property is much easier to define @HttpWhiteboardServletPattern(“/foo”)

You can also use the whiteboard for static resources



The JAX-RS Whiteboard (new in R7)

JAX-RS was created to simplify writing RESTful services The whiteboard uses OSGi services to add JAX-RS resources It is dynamic, resources can be added and removed at runtime

Write a normal JAX-RS resource Make it a service Add the osgi.jaxrs.resource property

With DS and component property types this is really simple!



JAX-RS whiteboard example

Time for some code!



API Versions



Managing your API versions

Yes, this is a boring topic, so I’ll keep it short!

API versions are really important They are a statement about backward (and future) compatibility

Always version your API properly Baselining tools (such as the ones in bnd) can help you do this

Some public APIs are really badly versioned Google use a single incrementing version number for Guava Java EE specification versions jump around randomly



Coping with badly versioned APIs

We can’t stop Java Specs from using bad versions I tried *really* hard!

We can work around the problem by defining “contracts” A contract is an OSGi capability representing an API version

Clients require the contract at a particular version Clients import the API packages *without* versions

Bnd can detect contracts on your build path and use them



JAX-RS contract example

Back to the IDE…



Data Access



CRUD services

Many RESTful services use CRUD operations Create, Read, Update, Delete

This typically requires a persistent back end SQL / NoSQL / whatever

JDBC and JPA specifications already exist for OSGi R7 adds automatic lifecycle and transaction management

This is defined by the Transaction Control specification



Transaction Control

Transaction Control manages resources using scopes Scopes can also be transactional, guaranteeing atomicity

Managed resources are bound to the scope They are therefore automatically cleaned up and disposed

Managed resources are created using a ResourceProvider Resource Providers also offer pooling and other features

Standard resource providers exist for JDBC and JPA



Wiring it all together

It’s not good practice to do persistence in the REST service What if you want to change persistence store? What if you want to access the data in another way?

OSGi services are perfect for reusable modules! Microservices all the way down remember!

Declarative Services is even better for consuming services Just annotate your fields and away you go You can also have activation/deactivation callbacks



Persistent REST service example

Back to the IDE…



Oh No!!



So why didn’t it work this time?

Our REST Service @Provides(APPLICATION_JSON) JSON support is not built into the JAX-RS spec

We need to tell the whiteboard our requirement!

There is a standard annotation we can use @JaxrsExtensionSelect(“(media.type=JSON)")

But we can do even more by building our own annotations!



Writing a custom annotation

Writing a Component Property Annotation is easy Using Target “TYPE” and “CLASS” retention is sufficient Then annotate your annotation with @ComponentPropertyType

For single element annotations (using value()) UnCamelCase the annotation name and add dots (e.g. un.camel.case) The value is either the default, or whatever the user supplied

For other annotation types Take the property name and replace ‘_’ with ‘.’ The value is either the default, or whatever the user supplied



But wait, there’s more!

You have seen me resolving my OSGi runtime This uses bundle metadata to build my whole demo

A whiteboard property is a runtime requirement We need to tell the resolver about the resolve time requirement

There are @Requirement and @Capability annotations These are meta-annotations that add to the bundle manifest We can add these to our component property annotations too



Putting it all together

Back to the IDE for one last time…



Some more advanced things to think about

The JAX-RS whiteboard can host Application services Scoping and targeting features for multi-tenant servers

More advanced Transaction Control behaviours Controlling rollback, nested transactions, XA recovery…

OSGi PushStreams for asynchronous and reactive data These fit really well with Server Sent Events in JAX-RS

Dynamic Services, Remote Services, Asynchronous Services There’s a whole ecosystem of cool stuff to play with!



Questions?



For more about OSGi... Specifications at http://www.osgi.org

Enterprise OSGi in Action

For more about the R7 specs and APIs https://www.osgi.org/developer/specifications/

http://oss.sonatype.org/content/groups/osgi/

For more about Aries JAX-RS Whiteboard https://github.com/apache/aries-jax-rs-whiteboard

http://repository.apache.org/content/repositories/snapshots

Thanks!

http://www.paremus.com [email protected]


http://www.osgi.org

http://oss.sonatype.org/content/groups/osgi/

https://github.com/apache/aries-jax-rs-whiteboard

https://repository.apache.org/content/repositories/snapshots

http://www.paremus.com

mailto:[email protected]



