Yes, service orchestrating can be somewhat overwhelming, luckily Pivotal has reorganized this which is where Eureka, Cloud Config Server and Hystrix can help out.
Claude Moore wrote:I'm afraid that orchestrating all modules as microservice already at time zero would be an unuseful approach (at least for mine scenario)
I'm unsure as to why you would limit AMQP to the same JVM, as I don't think that you do not need to.
Claude Moore wrote:I think I'll use an AMQP-based RPC schema between modules (when modules won't be co-located in the same JVM, of course)
Implementing REST endpoints can be useful if you are going with different client implementations including but not limited to Android and IOS devices.
Claude Moore wrote:I can't see the point to use REST API
Are sure you can control the network and hardware? If you are pushing your project to a cloud provider then implementing a lightweight communication protocol may be a requirement.
Claude Moore wrote:I think that they will be deployed in the same LAN (with very low latency), so using a lightweight communication protocol won't be a key requirement.
Tim Holloway wrote:
The one thing that did stick out is your confusion about auto-wiring local and remote interfaces. Spring is based on a bean factory and wires bean instances. You cannot manufacture and instantiate an interface, only a bean that implements that interface. Likewise you cannot inject an interface. An interface is an abstraction and Spring deals in concretes.
Tim Holloway wrote:Yes, if you introduce a custom bean factory into your mix you can make it decide whether to return a remote interface object or a local object, sure. No problem.
I claim this furniture in the name of The Ottoman Empire! You can keep this tiny ad:
Two software engineers solve most of the world's problems in one K&R sized bookhttps://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton