move some shared definitions into a common package that both INTERSECT-SDK and INTERSECT core services can use #39
Description
Both the INTERSECT-SDK and INTERSECT core services (iHub, campaign orchestrator, most likely NOT the registry service) share some common definitions between them:
- the structure of message headers: userspace, event, lifecycle
- most of the logic for the control plane protocol clients can be shared. iHub works a bit differently from the campaign orchestrator and scientific microservices, as it generally subscribes to ALL lifecycle messages but does not otherwise send or receive userspace or event messages
- potentially, most of the logic for the data plane. General outlook here is for microservices to send raw object storage URIs; these pass through backends until potentially being observed by either the iHub browser or a dedicated INTERSECT-SDK client. This must be looked at further.
Logic which will NOT be shared will include, but not be limited to:
- Client or Service classes. Microservice authors should be expected to utilize the
IntersectClientandIntersectServiceclasses provided by the SDK, core services should generally create their own clients/services to handle their own special logic. - Capabilities, the concept as understood by the SDK should only be implemented by microservices. Core services do not have dynamic, discoverable capabilities.
- The SDK will have logic for interacting with the registry service, this does not need to be seen by core services.
It makes sense to move this shared logic into a shared library, to avoid duplication across core services.