Stream: implementers
Topic: source indicator for logical references
Joost Reuzel (Sep 11 2019 at 13:33):
We are looking for a way to reference resources accross services in a distributed system. The current reference element provides two mechanisms:
- a literal reference, containing (in our case) a full url to the resource, or
- a logical reference by providing an identifier by which the resource is known.
Given the varying network infrastructures in which we deploy our system, the literal references may not always be accessible (as it needs to pass through address translation frameworks, proxies, etc.) As such, we don't see those as a viable option. This leaves us with logical references, but those introduce the problem that it provides no hints where to resolve the resource. For example, several patient records may exist (at several servers, with potential conflicting information) that have the same SSN as identifier. In the reference we would like to be able to point to specific instance of those resources, but without using a literal url.
One way to resolve this is to add an extension (or preferably field) to the reference element, named source. This field (similar to the source field in the resource meta element) could provide a hint on where to resolve the identifier. How to map the source to an actual endpoint would be out of scope for its definition. In our use-case the source field would point to a service identifier, which would be resolvable through service discovery to a base-path at which the patient resource can be retrieved. The benefit of this approach is that the sender of the reference does not need to know how the resource can be reached from various networks, that is left to an external system.
Would this be something that is worthwhile adding to the standard? How are others dealing with this issue?
Any comments or suggestions are welcome...
Lloyd McKenzie (Sep 11 2019 at 14:22):
The general expectation is that only URLs are expected to be resolvable. Resolving identifiers will require a shared business context that allows determining the process for resolution. You do have the identifier.system - which corresponds to the identifier namespace. That should give you a pretty good idea of the source - particularly if you just look at the root of that system
Joost Reuzel (Sep 11 2019 at 14:44):
You are making the assumption that the authorities of identities (codified in the identifier.system) can be mapped to the services that actually hold the data. That may not always hold. For example, the example in which patient resources are identified using SSNs (or another 'global' patient id) is a case where multiple patient resources (across services) may have the same identifier. In that case I still would like to refer to a specific instance at a specific source...
Michele Mottini (Sep 11 2019 at 14:46):
Any API client will expect the resource references to resolve - so if you break that you'll break most / all clients
Lloyd McKenzie (Sep 11 2019 at 14:53):
I don't know about 'break', but you certainly won't be able to do chained queries
Joost Reuzel (Sep 11 2019 at 14:55):
Indeed most API clients expect literal urls to be resolvable. However, we are facing a complex deployment scenarios that span several clouds and on-premise applications. In this complex world, a service would not even know how to formulate a literal url that is resolvable accross all these networks, as it would not have knowledge of local proxies, etc. Given that we are forced to look for alternatives...
Grahame Grieve (Sep 11 2019 at 14:57):
sounds like fun ;-)
Joost Reuzel (Sep 11 2019 at 15:03):
We thought about the chained queries. These indeed would not work, but given the distributed nature that is ok. These aren't supported for logical references anyway.
A specific scenario would be a ServiceRequest that is send from system A to B, with a reference to a patient resource at system C. System A could put his literal url to the patient resource at system C in the request, but that url may not be resolvable by system B. Instead we are thinking of refering to the resource by its identifier, and adding as a source extension/field the name of system C. B would (based on its local service discovery) need to resolve the system C name to a locally resolvable endpoint to fetch the resource...
Grahame Grieve (Sep 11 2019 at 15:04):
One way to do this is to use redirection services....
Grahame Grieve (Sep 11 2019 at 15:07):
I don't know if Identifier.assigner helps?
Joost Reuzel (Sep 11 2019 at 15:11):
Would this not be a re-interpretation of the assigner field? Moreover, wouldn't it be cleaner to have a source/server indication external to the identifier itself?
Grahame Grieve (Sep 11 2019 at 15:14):
probably.... I wasn't sure
Joost Reuzel (Sep 11 2019 at 15:15):
Basically we are looking for a reference that allows you to say "resource of type X known under the identifier Y at system Z". X and Y have fields in the reference element (type and identifier respectively). Z is missing in our view...
Grahame Grieve (Sep 11 2019 at 15:15):
but if you know Z then you can fill out the URL
Joost Reuzel (Sep 11 2019 at 15:16):
Indeed, but we would like to have an external "context specific" mechanism to find the url related to Z, instead of making it part of the reference itself.
Last updated: Apr 12 2022 at 19:14 UTC
