What is the Specific difference between Java Modules (In Java 9), OSGi bundles and Microservices? and What specific purpose is served by each of them?

Question

I have gone through all three technology and I think more or less all three technologies are nothing but different approaches to tackle a same or common problem Say for e.g.

Common Problem: Suppose there is a very big enterprise application and over the period of time this application grows more larger and more complex by adding new features, updating the existing one, bug fixing etc (in monolithic architecture style) consequences of it are difficult to maintain the code, if any thing break can break the entire application, changes made to the application requires rebuild and retest and redeploy entire application (redeploy .Ear, .War etc) its a time consuming process and application down time was high.

Common Solution: Break the big enterprise application in to "small chunks" and these "small chunks" are called with different names In Java 9 : it is called as "Module" or JMPS (Java Module Platform System) In OSGi : it is called as "Bundle" In Microservice based architecture : it is called as microservices or just service

Make these small chunks to perform single function, make them work independently, deploy independently, start and stop independently, and then provide dependencies between these small chunks so that they can Communicate with other small chunks and make the entire application work seamlessly. If any of the small chunk fails should not have major impact on entire application that particular function only get affected but entire application keeps running Easy to maintain the small size chunks (known as Module, Bundle , Microservice) Faster development, and easy to deploy and ship it.

Apart from this if any one who knows all 3 technologies very well and can provide specific difference and specific purpose for each of them then it would be great.

Regards, Gokul

Answer 1

There are already a number of answers on Stackoverflow pointing out the different technologies. However, I do not think there is a clear comparison. I've been in the OSGi from the beginning as well as has been quite present in the JPMS development since 2004.

Sadly, JPMS is a surprisingly bad impression of a module system. It walks like a module system, it talks like a module system but it definitely isn't since it lacks the intrinsic properties of modules: information hiding. It does an admirable job of giving the impression but just try to use the same class name in two unrelated modules. For example, you need to have 2 versions of the same class. This violates the primary purpose of modularity that you can do whatever you want in the private area of a module; it should not affect the whole.

This may sound as a far fetched complaint but it is actually a very common use case in OSGi. Instead of depending on an external module, you package the module internally to simplify the overall operations. In JPMS, you will have to complicate your build and shade. And then still someone might conflict with your private namespace.

For me, this would be sufficient to disqualify JPMS. You also ask about microservices. Microservices are however not modules. They are, however, imho an absolutely necessary aspect of modular thinking. A crucial aspect of module systems are dependencies. The popular build system maven uses a module to module dependency model that is very simple and very powerful but for larger systems it will create a very hard to control transitive dependency model that tends to have a massive fan-out. Maybe it is people that download the internet for a simple hello world but the module-to-module dependencies do make it absolutely too easy to create a mess for large complex applications.

Microservices change the module-to-module dependencies to module-to-services dependencies. The fantastic success of microservices is largely because it allows modules to evolve independently by providing the same API to their microservices while the module evolves. This breaks the transitive dependencies and significantly simplifies the overall complexity of a system. Although JPMS has the Service Loader model, this is such a poor mans implementation of microservices that it hardly deserves to be mentioned. It is static and completely ignored in the dependency model.

So far, I left microservices relative vague; basically they are a conduit between modules. However, in the big world out there microservices are generally understood to be something like REST services. However, their architectural advantages (breaking the transitive dependency model) are not depending on their communication technology. The benefits are caused by having a clear endpoint to communicate with that has a cohesive API.

OSGi coined the term µservices since the early 2000's. The core programming model in OSGi is to create modules that register services and get services. A good OSGi system only communicates over these services. Since an OSGi service is a plain old Java object, the (minimal) overhead is limited to setup.

Since we designed OSGi to be reflective from day one, it is possible to map an applicable OSGi service to a communication endpoint, e.g. a REST service or MQTT topic. This mapping can be done without any knowledge in the actual services. This is all standardized in Remote OSGi services. The dynamic nature of OSGi provided and excellent foundation since it provides the substrate to handle the fallacies of distributed computing.

One of the primary software laws is cohesion; in OSGi you can keep your modules, packages, classes, and methods maximally cohesive.

To provide the cherry on the cake, OSGi integrated the µservices in their native dependency model. An OSGi application consists of hundreds of modules that interact with each other over hundreds of services. Modules only depend on well defined services. Services can be provided by different modules, which could get messy quickly. Fortunately, the OSGi therefore provides a resolver to select an assembly of modules where all the module requirements (which includes the services) are met.

To conclude. Neither JPMS nor microservices are proper module systems. Only with OSGi do you get a real module system that has private and integrates natively with microservices.

See also Difference between OSGi services and REST microservices

Answer 2

"Sadly, JPMS is a surprisingly bad impression of a module system". (Very much true) "For me, this would be sufficient to disqualify JPMS". (I agree) In short JPMS should be restricted for internal use of "JRE Restructuring Or Reorganizing" so that it can be used in small size devices.So let's assume that JPMS is ruled out for time being.

Now I tried to find out some specific difference between OSGi and Microservices Let's Look at OSGi first

1] OSGi bundle export and import packages and register themself 2] OSGi bundle communicates with each other by importing and exporting required packages 3] and Yes OSGi Bundle can be install/deploy/start/stop individually 4] Ideally each OSGi bundle supposed to perform a single function. 5] But All this OSGi bundle exercise happens with application (No communication between bundles in two different application deployed on two different environments) and the OSG bundle communicate to other bundles directly 6] OSGi bundles are not heterogeneously distributed (e.g. developing 4 bundles using different programming languages like Java, C++, Python, .Net and make them work together I am not sure whether it is possible or not with OSGi bundles) 7] Well managed dependencies among OSGi bundles (As you mentioned it is "A crucial aspect of module systems are dependencies".)

On the other hand microservices

1] Microservices are small autonomous services. 2] The basic concept which I understand is that each microservice performs a single function. 3] Microservices communicate with each other using RESTful calls 4] Microservices can be heterogeneously distributed (meaning if there are 4 microservices then first is developed in "Java" second is developed "C++", third is developed in "Python" and forth is developed in ".Net" and all four can communicate seamlessly via RESTful calls) 5] As Microservice are loosely coupled hence less dependent on other microservice but still dependent up to certain extent here also well managed dependencies and communication among microservices. As you perfectly mentioned that 6] Microservices change the module-to-module dependencies to module-to-services dependencies. The fantastic success of microservices is largely because it allows modules to evolve independently

Communication between multiple OSGi bundles and Communication between multiple microservices
OSGi is not variant of SOA and OSGi bundles do not communicate with bundle in other application using RESTful API calls or by any other means(Pl. correct me if I am incorrect) Whereas microservices is a variant of SOA and can communicate with other heterogeneously distributed microservices using RESTful API calls

Load Balancing and scalability If there are heavy load of request for one particular microservice then multiple instance of the same microservice can
be created to balance the load (I am not sure whether this is possible with multiple instance of the same OSGi bundles)

Security (Secure communication among heap of microservices) Communication between multiple microservices can made more secure using OAuth (I am not sure whether this is possible with OSGi bundles)

So to summarize OSGi architectural style is bit different than microservice architectural style in above means and at first glance it appears to me that microservice based architecture is having slightly upper hand than OSGi style.

It could be a is kind of chaotic situation if we try to use both technologies together for developing large scale enterprise application (Pl. correct me if in case I have added any incorrect thing in this entire post) Thanks and Regards, Gokul