OSGi Community Event 2017 Presentation by Tim Ward [Paremus] REST microservices are a powerful tool for composing large-scale systems, and now, with the new features of OSGi R7, it has never been simpler to create a modular microservice. Combining the new features in Declarative Services, the JAX-RS Whiteboard, Transaction Control and PushStreams we can create a simple, transactional, persistent, streaming microservice with a minimum of code and a maximum of function. This talk will use practical code examples to show how new OSGi R7 features can save you time and effort when building microservices, letting you focus on business logic, not boilerplate. Over the last decade there has been a significant shift in the way that many computer programs are written. The focus has changed from building larger, more monolithic applications that provide a single high-level function, to composing these high-level behaviours from groups of smaller, distributed services. This is generally known as a “microservice” architecture, indicating that the services are smaller and lighter weight than typical web services. With the new features in Release 7 OSGi is a better platform for building your microservices than ever before. The Declarative Services specification is the ultimate in OSGi injection containers. It supports simple, flexible dependency injection using OSGi services; automatic lifecycle management based upon the availability of configuration and dependencies; and a concise, type-safe set of annotations to define your components. The latest round of Declarative Services updates includes new support for constructor injection, activation fields, and a host of other usability improvements designed to make your components even leaner. The standard for REST microservices in Java is known as JAX-RS. JAX-RS provides a simple annotation-based model in which POJOs can have their methods mapped to RESTful service invocations. Ideal JAX-RS resources share many features with OSGi services, in that they provide a way for machines (or processes within a machine) to interact with one another through a defined contract. This synergy between JAX-RS resources and OSGi services is the driver for the OSGi JAX-RS whiteboard service, allowing OSGi services to be transparently exposed using JAX-RS. Transaction management is a delicate balance between trying to take away error-prone boilerplate without replacing it entirely with magic. The problem with relying on magic is that the resulting system ends up being more complex to understand, not less. OSGi Transaction Control uses Java’s new functional APIs to simplify and minimise transaction management code, providing generic resource and transaction management in a concise, type-safe way. OSGi Push Streams are a powerful new take on asynchronous event processing pipelines based on the Java Stream API. ....

1. 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
tim.ward@paremus.com
OSGi R7 – microservices never looked
simpler.

2. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
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

3. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
Services, Microservices
and µServices

4. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
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

5. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
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!

6. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
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…
ProviderConsumer
MyService
foo = bar

7. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
Easy ways to Publish an
OSGi Service

8. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
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

9. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
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!

10. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
Service Whiteboards

11. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
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

12. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
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

13. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
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!

14. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
JAX-RS whiteboard example
Time for some code!

15. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
API Versions

16. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
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

17. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
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

18. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
JAX-RS contract example
Back to the IDE…

19. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
Data Access

20. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
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

21. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
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

22. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
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

23. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
Persistent REST service example
Back to the IDE…

24. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
Oh No!!

25. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
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!

26. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
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

27. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
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

28. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
Putting it all together
Back to the IDE for one last time…

29. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
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!

30. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
Questions?

31. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017
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
info@paremus.com
http://www.manning.com/
cummins

32. Copyright © 2017 Paremus Ltd.
May not be reproduced by any means without express permission. All rights reserved.
Reactive OSGi meets Reactive Java October 2017