The vlingo/directory component supports service registration and discovery. When a new Bounded Context, implemented as a microservice, is started, it registers itself with the vlingo/directory.
As a result, other Bounded Contexts will discover the services that they must collaborate with. This happens when the vlingo/directory broadcasts the registration details, including hosts and ports, around the enterprise. This is a cluster-capable component, which means it is meant to be run within the vlingo/cluster for reactive high availability.
More to come...
The best place to see the implementation of the vlingo/directory service is in its main processing component
io.vlingo.directory.model.DirectoryServiceActor. The directory information is both maintained here and broadcast from this point. For this discussion see the following packages:
This is where vlingo/cluster and UDP multicasting meet. See the vlingo/wire component for its
MulticastPublisherReader, which is alluded to in this discussion and used by the
DirectoryService protocol includes
assignLeadership(), which is how a given vlingo/directory cluster node knows that it is in the lead and is the active UDP multicaster/publisher. Any other cluster nodes are standby in case the leader node is lost for any reason.
DirectoryClient, which is any service that wants to register and/or discover via the vlingo/directory, sends and receives availability information in the form of
ServiceRegistrationInfo by supporting the
io.vlingo.directory.model.DirectoryApplication, which is a
ClusterApplication via the
ClusterApplicationAdapter, informs its own
DirectoryServiceActor to go into either active or passive mode. Active mode is described above. Passive mode is any cluster node member that is not the leader. These (most typically 2 of 3 nodes in the cluster) simply collect publishable data that the leader receives. The leader tells them this via the cluster
AttributesProtocol attributesClient. This means that the leader uses the cluster-wide attribute publishing facility to share registration information with all passive nodes. If the leader is lost, then a passive node will be elected as the leader, and already has most or all of the current registration information. Any lag in current registration information will soon be cleared up when directory clients begin live (pulse-based) updating to the new directory leader.