Home » Software Development » Two Types of Deployment for Subsystems

About Bozhidar Bozhanov

Bozhidar Bozhanov
Senior Java developer, one of the top stackoverflow users, fluent with Java and Java technology stacks - Spring, JPA, JavaEE, as well as Android, Scala and any framework you throw at him. creator of Computoser - an algorithmic music composer. Worked on telecom projects, e-government and large-scale online recruitment and navigation platforms.

Two Types of Deployment for Subsystems

During development you sometimes have a part of the system that is rarely changed, requires a lot of resources, has a lot of prerequisites to run, and/or takes a lot of time to deploy. What do you normally do? Extract that part into a separate application and run it on one or several servers, having developers connect to these services. Examples may be: search engine interface, CPU-intensive operations, 3rd party systems, etc. In a way, you make your system modular.

However, there’s a drawback to this modularity – it adds complexity and points of failure. What if the communication between the module breaks, how do you trace and debug issues (they might be caused by either of the two (or more) systems), how do you keep multiple versions of the applications’ public interfaces in sync (and do you need multiple versions to co-exist?), how is deployment of two applications handled at one atomic step, and more.

Many times you don’t need to introduce that complexity, but you still need the flexibility during development.

An option I sometimes use is to have the subsystem both as embedded and as a standalone module. To do that, you make a thin layer (calling it a layer from architectural perspective; in terms of code it is going to consist of 2 classes and an interface) which handles two types of deployment. There is one interface that defines the operations, performed by the module, and two implementations – one is RESTful, calling RESTful services of a separately deployed application, one is simply wrapping the class that performs the actual operation (or even is the class itself) and is present on the classpath of the application.

An example. You have an ExtractionService which has to perform some text analysis and concept extraction on an input. This requires a lot of CPU and memory, and so it is not feasible for each developer to run it locally. You make

  • ExtractionService interface, defining the extraction operations
  • RestfulExtractionService which is configured with an endpoint URL and invokes restful services that wrap the actual extraction implementation
  • ClasspathExtractionService which is either the actual extraction implementation, or a simple wrapper of it.

How do you organize that in terms of projects and their dependencies? You have a separate jar-packaged project with the extraction implementation, you have a war-packaged project (that depends on the jar), which wraps the implementation in a RESTful API and you have your main application, which also depends on the jar.

How do you switch the implementations, depending on whether you are in development or in production mode? It depends on the framework you use. With spring you can simply have @Resource("${service.implementation}") ExtractionService service, where service.implementation is externally configured.

Why do you need that, doesn’t it add overhead, and why don’t I just keep the modularity in production? You will be able to build and deploy one monolithic application (with only classpath dependencies) to production without worrying about the problems mentioned in the 2nd paragraph. You are keeping your architecture simple, and that’s always a good thing. At the same time you are getting a lot of flexibility during development, by not having to redeploy heavy parts of the system. And all of that is achieved with just a few classes and one configuration switch. It is not always applicable, of course, but do consider it as an option if you are faced with a similar scenario.

Reference: Two Types of Deployment for Subsystems from our JCG partner Bozhidar Bozhanov at the Bozho’s tech blog blog.
(0 rating, 0 votes)
You need to be a registered member to rate this.
Start the discussion Views Tweet it!
Do you want to know how to develop your skillset to become a Java Rockstar?
Subscribe to our newsletter to start Rocking right now!
To get you started we give you our best selling eBooks for FREE!
1. JPA Mini Book
2. JVM Troubleshooting Guide
3. JUnit Tutorial for Unit Testing
4. Java Annotations Tutorial
5. Java Interview Questions
6. Spring Interview Questions
7. Android UI Design
and many more ....
I agree to the Terms and Privacy Policy

Leave a Reply


This site uses Akismet to reduce spam. Learn how your comment data is processed.

Notify of