In the first post on this series about the Holographic Principle I presented an example of a Cat Service. In that example, a service provider is available for other services to store pictures of cats. This example comes out of a common situation in applications, but there are other typical examples of services which do not involve persistence, and which may be holographic as well.
No Persistent Holographic Services
Let’s imagine a geolocation service, which returns the country a device is located given its public IP, or a currency exchange rate service, which returns the current exchange rate between two given currencies.
Both services, as well as plenty of other similar services, have in common that they do not provide a persistence feature to their clients. In other words, unless the Cat Service, transactions are utterly ephemeral. Therefore there is no need for the service provider to return any trans-uuid to the consumer, since there is no future transaction related to any particular resource which requires identification.
However, by definition Holography happens on contact surfaces, and those surfaces must be uniquely identified because they relate services one to one. This is what allows the service provider (and the consumer as well) to hide its internals, and at the same time it settles a commercial infrastructure.
To operate, this commercial infrastructure makes use of the transaction uuids, because they not only identify the resources shared between the services involved in the transaction, but, and most importantly, they uniquely identify the service consumers and the contract they signed with the service provider as well.
In other words, urls like these:
- GET https://currency-exchange-rates.service/eur/usd/{trans-uuid-A}
- GET https://currency-exchange-rates.service/eur/usd/{trans-uuid-B}
may pinpoint to exactly the same endpoint in the Currency Exchange Rates service, but they are unique because bring information which is only shared between this service and the contractor A.
A final note: the urls above are examples which show the service endpoint in plain. In real cases, they should likely take the form of dynamic links, like those provided by Google’s Firebase, Branch, etc, shorten links, as provided by Bit.ly, or similar.
Photograph credit: https://pixabay.com/users/free-photos-242387/
how possible 