Add service module workflow, ran in the previous step, created a
service descriptor in the repository’s
The steps below flesh out the service’s descriptor with it’s input and output topics.
Crucially, this will define the filter service’s input topic using the
handle-occurrence-service’s output topic descriptor.
This is one of the two key features of this tutorial. The other being system testing multiple services.
Define the topic resources
The aggregate template provided a shell service descriptor in the repository named
Add the following to the class to declare the service’s input and output topics:
Importantly, note how this descriptor’s
HandleUsageStream topic descriptor, (step #1 in the code above),
is created by calling
toInput() on the
TweetHandleUsageStream output topic descriptor.
Compare this to the explicit declaration of the
TweetHandleUsagePresidentsStream output topic, (step #2 in the code above),
which declares a new, previously unseen, topic
toInput() method, called in step #1, returns an unowned input topic descriptor, with the correct name and types.
Whereas, the output topic descriptor, created in step #2, is an owned topic descriptor, owned
by this new filter service.
ProTip: The concept of topic ownership defines which service / aggregate, and hence team within an organisation, is responsible for the topic, its configuration, and the data it contains.
In this case, by declaring the filter services input by calling
toInput() on the occurrence service’s output topic,
we’re declaring the filter service as a downstream consumer of the occurrence service.
Conversely, though less common, service’s can define owned input topics. In such a situation, upstream services
can declare that they produce to the topic by calling
toOuput() on the input topic descriptor when
declaring their own output topic descriptor.
The eagle-eyed of you may also have noticed that the service’s output topic, (step #2 in the code above), declares the topic’s key and value types by referencing the input topic’s key and value types. This is just a convenient & type-safe way of ensuring the key and value types of these two topics align, given that the output topic is simply a filtered view of the input topic.