We are doing an architectural refactoring to convert a monolithic J2EE EJB application to Spring services. In order to do that I'm creating services by breaking the application against the joints of its domain. Currently, I have three of them and each calls another service via Rest.
Our domain contains User, Customer, Alarm, Notification, Market and other modules. So, for example a user send a request from a GUI to a service which does its logic and then calls another service:
UserService ---REST--> CustomerService ---REST--> AlarmService
Does our approach that creating services that calls each other with REST make sense in context of transitioning from EJB to microservices as a step?
Our current infrastructure which consists of some Wildfly EJB containers running on multiple VM's doesn't handle more concurrent connections. We wanted that if we could separate them as services, for example in the busy times with a help of some kind of orchestration maybe we can increase the number of VMs and deploy different services to different VMs and ultimately maybe later, since we have separated them, we can transform to microservices easier than before. In this way we thought that maybe we can trade network latency for more concurrent users gain.
In this project our ultimate purpose is transforming the application to microservices, but since cloud infrastructure isn't clear and probably won't be possible, we decided to make it this way and thought that since services will be using Rest, it will be easy to make the transform to microservices when the infrastructure supplied in future.
I'm asking this, because in this current form I have some problems like passing common request parameters across REST calls but a few people on the web talk about this. So I thought that maybe we are on the wrong path since it's not popular among people that services calling each other with REST calls. Also, for example every service need to use a few common CustomerService methods. So I thought that maybe we can put CustomerServiceImpl bean in a common module also so that services can Autowire it for these common methods but at the same time can send Rest requests for other methods. My collegue says that it's not suitable for microservices architecture.