Menu
OSGi talks about microservices and the press talks about microservices. However, they do not seem to be the same. What is the difference between these microservices.
531
Microservices: The individual services and functions – or building blocks – that form a larger microservices-based application. RESTful APIs: The rules, routines, commands, and protocols – or the glue – that integrates the individual microservices, so they function as a single application.
OSGI is an application architecture, while microservices is a distributed systems concept. In my experience, microservices offer a number of benefits: Individual microservices are easy to deploy, test, and maintain. Microservices are language agnostic.
While there are literally dozens of ways to implement a microservices architecture pattern, three main topologies stand out as the most common and popular: the API REST-based topology, application REST-based topology, and the centralized messaging topology.
The OSGi Service Platform provides a mechanism for developing applications by using a component model and deploying those applications into an OSGi framework. The OSGi architecture is separated into a number of layers that provide benefits to creating and managing Java™ applications.
OSGi and microservices share the same architectural style but differ in their granularity. We actually used to call OSGi services microservices until the web stole that name. We now sometimes call them nanoservices.
The principle of (micro|nano)services is to tunnel the communications between modules through a gate with a well defined API. Since an API is, or at least should be, independent of the implementations you can change one module without affecting the other modules. One of the most important benefits is that designs of even large systems can remain understandable when looking at the service diagram. In a way, a service based design captures the essence of the system, leaving the details for the modules.
With web/micro services the gate is a communication endpoint (host:port for example) and protocol (REST for example). The API is defined informally or with something like Swagger/OpenAPI or SOAP.
OSGi defines a (nano) service as an object that is made available to other modules (bundles) to use. Java is used to define the API.
Since nanoservices are OSGi most important design primitive there is a lot of support to make them easy to work with. Interestingly, since the service registry is dynamic and reflective, it is quite straightforward to map a nanoservice to a microservice and vice versa. The OSGi Alliance standardized this in their model for distributed OSGi, the "Remote Service Admin". This specification allows you to take an OSGi nanoservice and map it to REST, SOAP, or other protocols.
Therefore, choosing OSGi allows you not only to defer the decision to support microservices, it also allows you to add microservices to your system afterwards. Having a unified architectural style for the most basic functions as well as the highest level functions makes systems easier to understand as well scale.
187
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
