racker/java-service-registry-client — pull request #20 by gdusbabek (2013-03-06 20:26:26+00:00)
Title: WIP: Netflix Curator integration

## Netflix curator integration

First, go read about [how Curator does service registration](https://github.com/Netflix/curator/wiki/Service-Discovery). You will noticed that there are some mismatches between how both registries work:
* Curator registration interfaces are tightly coupled to Zookeeper. Witness how `start()` and `stop()` methods have leaked into several interfaces. For the most part, those translate to no-ops in the RSR integration.
* RSR requires that a session be established before a service can be registered. There is no concept of a session in Curator. Whether it gets used or not, we end up creating a session in `RSRServiceDiscoveryImpl.start()`. For cases where you are only interested in querying services, it is not necessary to call `start()`
* The Curator interfaces are strongly typed. You are encouraged to create types for your services. Following this practice would make it difficult to look up different kinds of services using the same `ServiceDiscovery` implementation. I suspect that in practice most users will have a single service type and just facet on the service name. (Keep in mind that in Curator lore, all services of one type have the same name, but different instance ids.)
* Curator stores serialized service objects instead of metadata and tags as done in RSR. We get around this a bit by requiring that each service type implement two static `convert` methods. It's not a rigidly enforced interace, but you will be prevented from instantiating a `ServiceDiscovery` object unless your class is has the proper static methods. Fields that you wish to appear as metadata need to be annotated with the `@Meta` annotation. The key difference here is that the RSR Curator integration leaves marshaling in the hands of the user instead of relying on a JSON serializer (because we have no storage).
* Frameworks like this tend to encourage polling (in order to observe service events). RSR was designed from perspective of reads happening infrequently (they are subject to a lot of server-side work).
* RSR event polling does not support an operation that returns all events since $TIME.

Some notes about this implementation:
* I have not tested `RSRServiceCacheImpl`
* I still don't know the best way to test this without a way of mocking RSR.
* Performance could be improved with a lower-level cache (we frequently have to look up __ALL__ services and filter on client-side).

[Here is an example of using these bindings.](https://gist.github.com/gdusbabek/afa06aaa0fcdbc7f13f1) The code is compatible with using the default Curator library with the exception of the calls into `RSRServiceDiscoveryBuilder.builder()` which would need to be replaced with calls into `ServiceDiscoveryBuilder.builder()`