One of the major challenges one faces while developing any typical enterprise application is in enforcing the design constraints which increase the modularity and reusability aspects of the system. This is a major headache when you have a team which is distributed across different geographical locations and also involves multiple IT service providers.
If you do a review of major applications in a typical large enterprise, there is a good percentage of the functionality across those applications which are almost similar. But those common functionalities will most likely spread all over the code-base of an application and will also be tightly coupled which makes it impossible to reuse and at the same time, makes it difficult to maintain.
Most of the traditional design & code reviews fail to address this issue because of multiple reasons. Is this an issue of how the systems are "designed and built" which failed to enforce modularity and reusability or rather is it the failure of programming models which failed to address this?
Let’s look at another different issue. In an enterprise application/product, there will be multiple functionalities which depends upon one another. During the course of development life cycle, one team may require some new enhancements to existing functionality but at the same time, there will be another team who may not be in a position to take the change but would like to stick to old functionality itself till they migrate. So this means we need to support multiple version of same functionalities running at the same time on the same JVM. So there is a real need for versioning support.
When one hears about the above set of issues, the most immediate response may be an enterprise-wide SOA based solution using full fledged SOA stack (ESB, BPEL and BAM etc) which is the current trend. Obviously there is a great value addition in enterprise wide adoption but only if adopted in a proper way. At the same time, there are certain types of enterprise grade applications & products ,for example development of different variants of a services procurement system for different industry segments, whose requirements could be satisfied using SOA based approach which is more at a micro level.
Micro Services Based Application Development using OSGi & Spring DM
Let’s look at Micro Services based application and its characteristics. Micro Service provides business/technical functionality exposed in terms of a well defined interface but its intent of usage is limited to a particular application or rather limited to a JVM instance. In true SOA style, micro service provider publishes its service interface through a registry and the consumer invokes the service by doing a look-up in the registry. But at the same time, the consumer could convey its intent or rather its dependency on particular services to micro services framework so that framework will do a lookup in the registry on behalf of the consumer and do a dependency injection into the consumer.
Even though its intent of usage is limited to a particular application, micro service based system facilitates the reuse. For this to happen, services should be developed in a way to provide the ability to manage its dependencies. This is extremely important because in majority of the cases, challenge is to avoid unintended web of dependencies. So it’s better to make explicit declaration of its dependencies on other micro services through meta data files. This will help in quickly creating a dependency graph of the micro services within an application during every stage of the development which in turn will help in taking corrective action on unintended dependency at earlier stage itself. The packaging also affects the ability to pull out micro services for example in terms of jar and make it reusable in another application just like a third party libraries like log4j/xerces etc. Micro Services based framework also provide the ability to host multiple versions of same micro service within an application runtime.
Combination of OSGi and Spring Dynamic Modules provides an excellent platform for building micro services based applications. Let us look at the features of OSGi and Spring DM and how it supports the development of micro services based application.
OSGi Features : One of the primary design task in any application development is to logically divide whole system into highly cohesive modules. Each functionality can be built as separate independent modules. In OSGi, it is supported in term of bundles which is nothing but modules. The bundles in OSGi are like physically independent jar files which can be deployed in OSGi runtime environment. In that runtime environment, these bundles act as a perfect black box. No reflection techniques or class-loader poking will provide any access to other classes in the bundle. In order to expose package/service, those bundles should explicitly declare those packages/interface, with optional version number and user defined properties, in manifest file. Basically only those packages/services will be visible outside the bundle. When a bundle import packages/services of other bundles, they should explicitly declare that by providing package name/interface with optional version number plus other filtering criterion. This will provide the ability to control the visibility and explicitly control the code boundaries and dependencies.
At the same time, it is possible to change the behavior of a module and deploy a new version along with older version. OSGi allows different version of same module to coexist within the same instance of JVM so that other bundles can consume any version of the service just by providing the package name/interface along with version information. It brings in versioning support which was lacking in java for long time.(Currently JSR 277 tries to address the versioning aspect).
It provides service registry support so that bundles could expose the services through the service registry and other bundles consume those services by doing look up in service registry. This provides the support for service oriented interaction pattern within an application. It also manages the life cycle of bundles and also take care of scenarios like availability/non-availability of service. It brings in better operational control in terms of the ability to install/start/stop/update/uninstall the bundle at runtime and also the ability to monitor the status information on service wiring/service state through its console/JMX support.
Spring Dynamic Modules: It brings together the strengths of Spring Framework and OSGi which helps in building modular, reusable micro services based systems in simpler and faster way. For example, it takes care of registering micro services with service registry with version info plus optional properties and also takes care of injecting service dependencies into service consumers by doing lookup in the registry.
This article briefly tries to look into the micro services based application development approach and also provides a high level view of OSGi plus Spring DM support for the same. This approach brings in a model which could address the modularity and reusability aspects in a better way. This approach does not offer a solution which fits all scenarios but definitely addresses the requirements of certain types of enterprise application/product development initiatives.
Spring Dynamic Modules : http://static.springframework.org/osgi/docs/1.1.2/reference/html
Apache Felix : http://felix.apache.org/site/documentation.html