Soabase

Service Discovery

In SOA/distributed systems, services need to find each other. i.e. a web service might need to find a caching service, etc. DNS can be used for this but it is nowhere near flexible enough for services that are constantly changing. A Service Discovery system provides a mechanism for:

Services to register their availability
Locating a single instance of a particular service
Notifying when the instances of a service change

In Soabase, Service Discovery is transparent for the most part. Soabase applications automatically register themselves and the REST Client Enhancements use it to locate service instances. The default implementation uses Apache Curator. You only need to add configuration and the bundle.

Usage

Service Discovery is enabled via configuration. See the Service Discovery Configuration section for details. To use the default Apache Curator/ZooKeeper implementation, add a CuratorConfiguration field to your application's Configuration object. If needed, you can access the Discovery instance from SoaFeatures.

Deployment Groups

Deployment Groups support red/black style deployments. For example, you can deploy a group of servers running a new version of a service and disable the group of servers running the older version of the service. If the new version has a problem, that group can be disabled and the old version re-enabled.

See the Deployment Groups section for details.

Curator

A nice side-effect of using the standard Apache Curator integration is that you can directly access the CuratorFramework instance for any other ZooKeeper usage you might have. You can even create multiple CuratorFramework instances for different ZooKeeper clusters. Each Curator instance defined in your Configuration is set in SoaFeatures with the configured name.

Adding a Custom Implementation

To use something other than the Curator Service Discovery implementation, follow these steps:

Create implementations for DiscoveryFactory and ExtendedDiscovery
Add a directory named META-INF/services that contains two files: io.dropwizard.jackson.Discoverable and io.soabase.core.features.discovery.DiscoveryFactory.

DiscoveryFactory

Your DiscoveryFactory implementation is like other Dropwizard factories. It should be both configuration and a factory. Use ZooKeeperDiscoveryFactory.java as an example. This class must be annotated with JsonTypeName and given a unique name. You then use this name as the value for the attributes type in your configuration file. E.g.

package com.me.my;

@JsonTypeName("my-discovery")
public class MyDiscoveryFactory implements DiscoveryFactory {
    public String aConfigValue;

    public int anotherConfigValue;

        ...

    @Override
    public Discovery build(Environment environment, SoaInfo soaInfo)
    {
            ...
        return new MyDiscovery(...);
    }
}

ExtendedDiscovery

Your Discovery implementation does the actual work of Service Discovery. The details will depend on your implementation's needs. Note: your custom class should implement ExtendedDiscovery not Discovery. This allows your implementation to interact with the Administration Console.

ServiceLoader files

Like other Dropwizard plugins, your Service Discovery implementation needs Service Loader files. In the io.dropwizard.jackson.Discoverable file add a line containing: io.soabase.core.features.discovery.DiscoveryFactory. In the io.soabase.core.features.discovery.DiscoveryFactory file add a line the with fully-qualified path name of your class. E.g. com.me.my.MyDiscoveryFactory