external relationships

[matt-beanland]

At some point we may need to support external relationships.

There are two scenarios, we are just remembering a reverse relationship, but it doesn't mean anything to us. Generally this happens when another entity is using our service, and they have some kind of OWNS relationship to us, and they want their composing service to be indicated in our reverse relationship to them.

Another one is that we manage external service or resource. We need a model of their actual, and we may have expectations for it too. It may be we want to track an assignment, which is from them to us, but we want to be able to show the forward link to the external resource.

[matt-beanland]

Two distinct scenarios

1. Reflected reverse reference

Another system owns a composing service and declares an outgoing relationship to our resource. We store a reference back to their entity (an href/external id) so the relationship is visible from our side — but we have no ownership of that external resource and it drives no behaviour on our side. Essentially a read-only pointer inward.

2. Managed external resource

We maintain a local representation of a resource or service mastered by another system — a shadow/proxy node in our graph. We may have expectations about it, track assignments from it (e.g. they assign something to us), and show forward links to it. This is more like an ExternalInstance concept: a local Ash resource with its own lifecycle that proxies a remote entity.

Key difference

Scenario 1 is passive — we record a reference we were told about. Scenario 2 is active — we create and manage a local node that stands in for something owned elsewhere. They likely need different DSL/model treatment.

Dependency on #134

Both scenarios involve relationships, but neither fits cleanly into the forward internal-only relationships do DSL being designed in #134. #134 should note this gap explicitly so the external relationship form is not shoehorned in later.