*Register a new service interface with the running system*
|Actors||Service Deployer (Integrated Observatory Operator), Service Consumer (Application Developer)|
|Uses||UC.R2.31 Define New Service Interface|
|Is Used By|
|Is Extended By|
|In Acceptance Scenarios||None|
|Technical Notes||This use case advances the infrastructure for the use case in R1 for operational use; the R1 use case accomplished similar basic capabilities via manual configuration during integration time.|
|Primary Service||Elastic Computing Services|
|UC Status||Mapped + Ready|
This information summarizes the Use Case functionality.
Register a new service interface with the running system. This use case is used to deploy new versions of existing services (in parallel to the current version, for a certain amount of time) and to add new services with new business logic to the running system.
- The system is operational (i.e., this is not an integration time activity as in R1)
- The Operator has permissions to add or modify a service type in the running system
- A service type defines the public service access interface (operations, messages and guarantees). A different version of a "service" with a changed interface is a different type
- A service instance is an operational instance of a service type with a publicly registered name.
An Application Developer has implemented a service process, unit tested it, and integration tested it (see UC.R2.31 Define New Service Interface), and the system is running.
- The Service Deployer defines a new service type
- Through an operator console would be ideal
- The Service Deployer executes a command and specifies service type description information.
- The Service Deployer defines the service interface, consisting of operations, message types and behavior guarantees for the operations. The interface can be inferred by introspecting an existing service component package.
- A new version of the same service type is a new service type, but metadata may be added without changing the service type.
- The Service Deployer publishes the service type
- The service type is registered with the Directory Service under a public entry (path and name)
- Test instances of the system may reference a production service directory
- A service type, like any resource, is given a unique service type identifier on creation. The identifier in this case is associated with that type of service, not with a specific executing instance of it.
- A service type is deployment/location-independent and programming language independent.
- <2> The Service Deployer associates an implementation with the service type
- Through an operator console
- The Service Deployer executes a command and specifies the identifier of the service type and locator of the service component within the software component repository
- Multiple implementations of the same service type may exist (e.g. Python, Java, Debug-on, debug-off)
- The Service Deployer associates further metadata with the service implementation
- The Service Deployer changes metadata for an existing service type
- Metadata attributes can be changed
- This list of associated service implementations can be changed
- The service interface definition cannot be changed, once published
- A Service Consumer can discover service type by their attributes and the service type identifier.
- Discovery occurs through querying the Directory Service.
The system is operational, with the new service type and its interface registered in the resource registry and queryable through the directory service.
These comments provide additional context (usually quite technical) for editors of the use case.
- Operational separation of service types from implementations is a combined CEI-COI concern. Thus multiple implementations of a service depends on both subsystems.
- In order to make a service run-time definable, the COI container has to support dynamically loading service definitions (services are defined in the YAML in R2).