Skip to end of metadata
Go to start of metadata

Overview of "Define Service Type During Runtime" Use Case

*Register a new service interface with the running system*

Tip: Key Points
UC Priority= 4 or 5: Critical, is in R2
Only boldface steps are required
<#> before a step —> lower priority
(optional) —> run-time option

Related Jira Issues:   [Open|,+status+DESC]   •   [All|,+priority+DESC,+status+DESC]


Refer to the Product Description and Product Description Release 2 pages for metadata definitions.

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.
Lead Team CEI
Primary Service Elastic Computing Services
Version 1.9.1
UC Priority 3
UC Status Mapped + Ready
UX Exposure ONC


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.

Initial State

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.

Scenario for "Define Service Type During Runtime" Use Case

  1. The Service Deployer defines a new service type
    1. Through an operator console would be ideal
    2. The Service Deployer executes a command and specifies service type description information.
    3. 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.
    4. A new version of the same service type is a new service type, but metadata may be added without changing the service type.
  2. The Service Deployer publishes the service type
    1. The service type is registered with the Directory Service under a public entry (path and name)
    2. Test instances of the system may reference a production service directory
    3. 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.
    4. A service type is deployment/location-independent and programming language independent.
  3. <2> The Service Deployer associates an implementation with the service type
    1. Through an operator console
    2. 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
      1. Multiple implementations of the same service type may exist (e.g. Python, Java, Debug-on, debug-off)
    3. The Service Deployer associates further metadata with the service implementation
  4. The Service Deployer changes metadata for an existing service type
    1. Metadata attributes can be changed
    2. This list of associated service implementations can be changed
    3. The service interface definition cannot be changed, once published
  5. A Service Consumer can discover service type by their attributes and the service type identifier.
    1. Discovery occurs through querying the Directory Service.

Final State

The system is operational, with the new service type and its interface registered in the resource registry and queryable through the directory service.

Use Case Diagrams

Architecture Diagram


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).

(click on # to go to R2 use case)
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
61     27B


r2-usecase r2-usecase Delete
usecase usecase Delete
productdescription productdescription Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.