-
Notifications
You must be signed in to change notification settings - Fork 18
Conventions
This page lists all conventions behind Ratel implementation. If you want to find out how things work in detail, you should probably read this page first.
Ratel implements a discovery-by-contract principle which means that the only supported way for referring to a service is its contract. We consciously don't support selectors, discovery-by-name convention, etc. In java world contract is a Plain Old Java Interface. Period.
When service-providing bean is registered in the service registry, its first implemented interface is used only. When a bean implements more than one interface, you can configure the contract of a service in a way described in exporting services.
At the moment Ratel does not support api versioning.
When service is registered, its absolute address is build according to this scheme http://<value of property jboss.bind.address>:<value of property jboss.bind.port>/<dispatcher servlet's context path>/ratelServices/ This is specific solution, that assumes that both jboss.bind.address and jboss.bind.port are set. If this is not set, you can configure the address of a service, as described here
By default Ratel uses efficient binary Hessian as a transport protocol, but when you use Ratel, you have no direct dependency to Hessian, so the transport may change in the future and it will require no change in your application