-
Notifications
You must be signed in to change notification settings - Fork 18
SOA principles
The philosophy of Ratel is to project universal SOA and microservices architecture best practices to specific java requirements, so you as a developer don't need to worry about inconvenient universal abstractions. Ratel is build around the following principles:
This principle says that Services within the same service inventory are in compliance with the same contract design standards.
In java world there is no simpler way of expressing a service contract than a Plain Old Java Interface. Therefore
Ratel treats java Interface as the only valid way of expressing a service contract
Service contracts only contain essential information and information about services is limited to what is published in service contracts.
We want all non-functional aspects, that are not specific to bare business logic to be explicitly hiden the business contract only. Therefore
Ratel does not require to pollute the business interface or explicitly use any API to benefit from its mechanisms. Business interface is the only valid abstraction of a service
Services are supplemented with communicative metadata by which they can be effectively discovered and interpreted.
Ratel uses the Registry server to ensure that all metadata is implicitly exchanged between services, clients as well as tracing and monitoring applications. The only information that must be shared between them is the address of the registry server
Further reading: Service discoverability
Ratel implements a discoverability by contract principle, which means that you only need to know the contract (the interface) of a service to be able to use it.
Service client does need to know or care about location of the service.
In Ratel, when you want to use a service, you only need to know its contract.