One of the microservices I was describing in my post Content Delivery Microservices is the Discovery Service. This post describes what the service does and provide a step-by-step installation guide.
The Discovery service is a new addition to the set of functionality in Tridion. It is a REST service that provides information about the capabilities of a given content delivery environment. A capability represents a Content Delivery module that is exposed itself as a REST service (i.e. the other CD Microservices of SDL Web 8). The Discovery service knows about each capability in a given environment and exposes this information in its methods.
For example, if a content delivery environment has capabilities Deployer and Dynamic Content, the Discovery service will provide the calling client the information about their endpoints, such that other systems discover what capabilities are available in a given environment, and what are their endpoints, so that they can communicate with these modules. We will see in a subsequent post, how this works in more detail using the New Way of Publishing and the Topology Manager.
The Discovery service is a new addition to the set of functionality in Tridion. It is a REST service that provides information about the capabilities of a given content delivery environment. A capability represents a Content Delivery module that is exposed itself as a REST service (i.e. the other CD Microservices of SDL Web 8). The Discovery service knows about each capability in a given environment and exposes this information in its methods.
For example, if a content delivery environment has capabilities Deployer and Dynamic Content, the Discovery service will provide the calling client the information about their endpoints, such that other systems discover what capabilities are available in a given environment, and what are their endpoints, so that they can communicate with these modules. We will see in a subsequent post, how this works in more detail using the New Way of Publishing and the Topology Manager.
 |
| Top level XML response of Discovery service |
The Environment metadata provides the actual access to the individual capabilities:
The Discovery service is a server role, running either as a standalone or Windows service Spring Boot package. By default, it contains an embedded Apache Tomcat instance, which makes it very easy to install and get running.
Discovery service uses a Content Delivery database to persist the information about each configured capability in its environment. Therefore, we need to configure node Storage in cd_storage_conf.xml, as well as the individual installed capabilities. These capabilities are in the form of URL endpoints, which define each capability as REST service, a client id and possibly an OAuth secret.
In order to install it as Windows service, the user should execute the .\installService.ps1 PowerShell script:
Also it is possible to run Discovery service in secured mode, using the OAuth protocol. In order to configure it, modify file cd_ambient_conf.xml.
It is possible to run it also as HTTPS, however, due to additional hassle with certificates, SDL recommends to use a reverse Proxy, instead in front of it and to secure the connection at the proxy level.
Lastly, we can start the SDL Delivery Discovery Services Windows Service.
Once all configurations are done and the Discovery service is up and running, we need to store the information about each capability in this environment into the Discovery Content Delivery database. In order to do so, we use a utility JAR, named discovery-registration.jar, using the following command line (I ran it from the /config folder of the Discovery Service installation):
java -jar discovery-registration.jar
This utility reads the capability configurations defined earlier in cd_storage_conf.xml and performs an HTTP POST to the Discovery service, which will then store them in the Content Delivery database. The fact that it is possible to send these configurations over the wire and instruct the Discovery service to persist them in its database, represents a nice step towards modular/self-configuring services and it opens up the scenarios where this can be used in the future.
For the inner geek, this is a little snapshot of how the configurations look like when stored in the Discovery database:
 |
| Details of the available capabilities |
The Discovery service is a server role, running either as a standalone or Windows service Spring Boot package. By default, it contains an embedded Apache Tomcat instance, which makes it very easy to install and get running.
Discovery service uses a Content Delivery database to persist the information about each configured capability in its environment. Therefore, we need to configure node Storage in cd_storage_conf.xml, as well as the individual installed capabilities. These capabilities are in the form of URL endpoints, which define each capability as REST service, a client id and possibly an OAuth secret.
In order to install it as Windows service, the user should execute the .\installService.ps1 PowerShell script:
 |
| PowerShell installation script |
Also it is possible to run Discovery service in secured mode, using the OAuth protocol. In order to configure it, modify file cd_ambient_conf.xml.
 |
| OAuth configuration section cd_ambient_conf.xml |
It is possible to run it also as HTTPS, however, due to additional hassle with certificates, SDL recommends to use a reverse Proxy, instead in front of it and to secure the connection at the proxy level.
Lastly, we can start the SDL Delivery Discovery Services Windows Service.
 |
| Discovery Service running as Windows Service |
Once all configurations are done and the Discovery service is up and running, we need to store the information about each capability in this environment into the Discovery Content Delivery database. In order to do so, we use a utility JAR, named discovery-registration.jar, using the following command line (I ran it from the /config folder of the Discovery Service installation):
java -jar discovery-registration.jar
This utility reads the capability configurations defined earlier in cd_storage_conf.xml and performs an HTTP POST to the Discovery service, which will then store them in the Content Delivery database. The fact that it is possible to send these configurations over the wire and instruct the Discovery service to persist them in its database, represents a nice step towards modular/self-configuring services and it opens up the scenarios where this can be used in the future.
 |
| Execution of the discovery-registration.jar |
For the inner geek, this is a little snapshot of how the configurations look like when stored in the Discovery database:
 |
| Capabilities persisted in Discovery Service database |
Comments