Manage Learn to apply best practices and optimize your operations.

Poor componentization puts service programming at risk

Managing components is not easy. The evolution of microservices and the internet of things is not making it any easier. Here's how to properly structure your componentization architecture.

Whether it's called microservices, SOA or something else, building programs by assembling "pieces" of functionality...

improves development efficiency. It can also facilitate reliable and scalable deployment. The problem is that it can also lead to massive amounts of wasted time and increase complexity enough to put the whole notion of service programming at risk.

The advent of microservices and the internet of things (IoT) have added to an issue set that is already complex enough. To unravel it, consider component deployment in one of the three task-driven models, pick a component architecture that balances flexibility and complexity and watch for new, potentially game-changing Java developments.

The good and bad side of componentization

In a nutshell, the problem with componentization is managing components. Dependencies on external components (the "classpath problem" in Java, for example) can result in versioning problems or "avalanches" of redeployment created by a single component change. The good news is that the seemingly endless number of applications and practice drivers for componentization seem to have generated three specific models. Your architecture search should start with these.

In a nutshell, the problem with componentization is managing components.

The first model is the microservices model. With this model, components are defined as independent microservices that any application can use. They also have stateless behavior so they can be replaced and scaled as needed. Additionally, they are independent of each other and of applications that use them, so deployment/redeployment of a microservice doesn't affect applications it serves.

The second model is the IoT model, which is targeted at both the componentization of applications and at the modular behavior of middleware -- even the core OS or JVM. The goal of this model is to strip down an application to run in its least possible space.

The final model is the controlled modularity model. This model allows multi-component applications to be managed without having to redeploy everything if one component changes. It is also referred to as a "service gateway model" because it often treats components as services that can be found through some sort of gateway or registry. This model has received the most attention because of the debate on the central concept it embodies: OSGi.

Understanding OSGi

OSGi, or the Open Services Gateway Initiative, was developed for Java to support a dynamic component model. This model would allow local or remote application component dependencies to be resolved at runtime, implying that components could be loaded and changed without rebuilding an entire application. Since its introduction in 1999, OSGi has attracted many staunch supporters. Others, however, saw it as a complicated way to resolve a problem which, in many cases, didn't require resolution at all. This debate has framed an entire dialog on component management in distributed applications. It also illustrates the range of issues that already exist in component management and how even more issues are likely to evolve.

Most component-based applications are still built and deployed in a series of machine images that are built and deployed as a cooperative unit. That architecture, however, introduces a risk. Changing one set of components would break interfaces among those components and require a complete rebuilding of that application. This would even be true for something that happens regularly, like a version change in software, middleware, operating system or JVM. Java is capable of late binding components, as are most other languages used today, so a component can be added dynamically as needed. OSGi was designed to systematize this process.

OSGi consists of a series of layers. These include modules that offer features, bundles that define services and lifecycle management processes that install and sustain services. These layers combine to create a complete dynamic model, where application functions can be loaded with little need for development of that application or functions to know about how the other is working. But sustaining these layers isn't trivial, and many organizations have found that the effort isn't justified. For many, rebuilding an application occasionally is less work, though developments like JBoss-OSGi have worked to improve OSGi usability.

Market impact

As OSGi evolved, the industry has evolved alongside it in two specific areas. Java has always been a universal platform suitable for computers as well as appliances (the "embedded control" model). From its initial days, Java has also been extensively used in web applications. In fact, it's at the heart of the microservices revolution today. The first of these developments makes OSGi's role harder, and the second might displace it for many.

Device vendors want a JVM, which is a modular itself, where unneeded features could be stripped out and loaded only on demand. That would reduce resource requirements for Java on devices, especially where resource constraints could be as significant as it is for IoT. A number of enhancements to Java (scheduled for Java 9 currently) are aimed at a more modern approach to modularity and component management, notably Project Jigsaw. Spring offers control over component deployment across most kinds of devices and reduces mass redeployment of applications for single-component changes. Most feel that these changes would address most of the business requirements that OSGi addresses.

But microservices might be the biggest revolution in componentization. A microservice is a logic component deployed in RESTful form, designed to be accessed through a URL. Microservices easily address issues of component dependencies and avalanches of redeployments due to small component changes because microservices are independent as long as the API call formats are maintained. Microservices won't change the modularity of JVM or provide an efficient way of managing remote-versus-local components, but they could significantly reduce the burden of component management for distributed components.

What's the overall trend, then? Market trends indicate that a single, general approach for component management isn't going to satisfy all users' demands. We can expect to see OSGi continue to dominate where tight control over component and dependency management is essential, but not necessarily where that control isn't needed.

Java continues to be the focus for component management evolution, and it is very likely that coming versions of Java will provide stronger options, both to support OSGi and an alternative path. Fortunately, there will be good options no matter which path you take.

Next Steps

An enterprise architect's guide to microservices

How growing componentization affects API security

How to tackle the integration of REST and OSGi

This was last published in August 2016

Dig Deeper on Microservices pattern, platforms and frameworks




Join the conversation

1 comment

Send me notifications when other members comment.


Please create a username to comment.

How are you managing componentization as service programming ramps up?