Should a software Service be completely standalone or can/should it be part of a larger component?

Question

Hi all,

I am in the process of refactoring 4 disparate software components that pretty much do the same thing into a single service (not a web service - necessarily or even likely). 3 are written in C++ while the last and most important is written in Java. The rest of the system is written in Java and therefore I will not be refactoring the C++ code and using JNI especially as the components currently written in C++ are scheduled to be replaced with Java components in a foreseeable future.

The component which is currently implemented in Java is actually a subcomponent of a larger component. Therefore when the larger/wrapping component wishes to use the subcomponent (being refactored into a service) it simply calls intra-process Java methods. If I refactor that subcomponent into a separate service the original wrapping component will lose the benefit it currently has of in process method invocation.

Should I then add a thread to the original/wrapping component to act as the service gateway or should I completely refactor out the code into a standalone service.

I hope that I have been sufficiently clear...

Answer 1

In general, there need not be a single instance of "service" and instances need not be invoked remotely. A strategy of co-deployment for performance or availability reasons is quite reasonable. You have a lot of gains simply by having a single implementation of the logic.

However if you already have a service infrastructure in place, where the service providers are perhaps managed in a particular way, it it probably desirable to be consistent.

So you need to understand the impact of separation, are those benefits of in-process invocation significant in this case? You also need to consider whether expsoing teh in-process service as a remotely callable service for other clients will adversely affect the performance of the existing system.

My gut feel: pull the code into a component capable of both local and remote invocation (in my world that could be done with a simple Stateless Session EJB) and deploy it twice. Once co-located with the original system. Once as a service. Sacrifice absolute consistency for minimal perturbation.