Skip to end of metadata
Go to start of metadata

Overview of "Instantiate Service Anywhere During Runtime" Use Case

*Deploy an instance of a service and allocate where need is greatest during system operations*

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   •   All


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

Actors Service Deployer (Integrated Observatory Operator), Service Consumer (Application Developer)
References UC.R1.15 Put Services Anywhere
Uses UC.R2.31 Define New Service Interface
UC.R2.44 Define Service Type During Runtime
Is Used By  
Extends UC.R1.17 Replicate Service
Is Extended By  
In Acceptance Scenarios None
Technical Notes  
Lead Team CEI
Primary Service Elastic Computing Services
Version 1.7.1
UC Priority 5
UC Status Mapped + Ready
UX Exposure ONC


This information summarizes the Use Case functionality.

Deploy a service instance, given a service type definition and associated service implementation. The service instance is to be started up to a particular operating environment, for example in a given physical region or computational environment. The service instance should be automatically configured for compatibility with the designated environment. Once running, the service instance is discoverable by its attributes, and can also be found by the appropriate service type identifier. The operator may change deployment policy during runtime of the system.


  • The system is operational (i.e. this is not an integration time activity as in R1).
  • There exist multiple distinct running service instances.
  • The operator has permissions to modify the running services and deploy new ones.
  • A service instance can have many worker processes (managed by the HA service agent), in the same or different deployment locations.
  • Policy is defined mostly on the service instance (HA service agent) level.

Initial State

The Service Deployer has defined a service type and associated it with one or more matching service instances for the type.

Scenario for "Instantiate Service Anywhere During Runtime" Use Case

  1. The Service Deployer finds a defined service type for a given task
    1. This is done via UI, by querying the Directory Service, or by accessing the Resource Registry directly
    2. Selection is done at the discretion of the Service Deployer, such as Python implementation only
    3. There may be a default implementation of the service type
    4. The Service Deployer keeps service type identifier and service implementation identifier
  2. The Service Deployer defines a new service instance
    1. Through an operator console, ideally
    2. The Service Deployer provides service type identifier and service implementation identifier (optional if a default exists)
    3. The Service Deployer provides service process configuration information
      1. Configuration is applicable to all or some processes for one service instance, on initial creation or subsequent service process spawns.
    4. The service process definition includes default values, or even fields in the place of values, where the service process needs configuration variables (e.g., IP address) filled out before it runs, as defined by the service deployer
    5. (optional) The Service Deployer defines access policy
    6. A service instance, like any resource, is given a unique service instance identifier on creation. The service instance is associated with a service type and one service implementation in the Resource Registry.
  3. <3> The Service Deployer defines the location and deployment policy for the service processes of one service instance
    1. There are multiple processes for the service. The number of processes and deployment arrangement (which site, execution engine, etc) is determined by policy.
    2. This is performed through an operator console, ideally.
    3. This step can be done for a new or a running service instance.
    4. The Service Deployer provides a given set of characteristics for deployment, performance, scope, configuration.
      1. The service instance defines the need for one or multiple service processes as part of its creation, as well as during steady state operation and in the presence of process failures.
      2. If multiple processes are providing a service instance, this is hidden from the view of the requester of a service instance (worker queue load balancing)
      3. Service processes for one service instance can be deployed in different locations (i.e. available capability containers)
      4. The Service Deployer can specify a previously provisioned Execution Engine where a service process should be instantiated.
      5. The Service Deployer may instead specify a deployment policy, such that a minimum number of service processes are created to guarantee high availability, with the service processes spread across multiple execution environments. For elastic scaling scenarios, a minimum and maximum bound of service processes may be specified, as well as a monitoring function leading to provisioning/termination of service processes and their distribution to existing capability containers.
    5. The Service Deployer finalizes the service deployment configuration.
    6. System reaction: Service processes are "spawned" on Capability Containers by a responsible service agent.
      1. The service agent spawns new service processes as configured on existing capability container instances; the spawned process may be on another capability container instance (i.e., another execution node) than the agent process.
      2. The agent identifies a process definition (service package with specific version) when spawning a process. This package can be loaded from a software component repository service onto the specific capability container and instantiated.
      3. The service supervisor (agent) may have policy to dynamically grow and shrink the number of service processes providing the service, for instance to react elastically to demand (see Scaling the Processing).
  4. The Service Deployer publishes the new service instance
    1. Through an operator console
    2. The service instance is registered with the Directory Service.
    3. The Service Deployer assigns a defined name to the service instance
  5. A Service Consumer discovers service instances by their attributes, and can also find them by the service type identifier.
    1. Discovery occurs through querying the Directory Service
      1. Via API or UI
  6. <3> (optional) The Service Deployer can restart a service instance
    1. This means bringing down all existing service processes for the instance and restarting them according to defined deployment configuration
  7. (optional) The Service Deployer deactivates a service instance
    1. This means bringing down all existing service processes for the instance
    2. Service Consumers will receive an error when invoking the service
  8. <3> (optional) The Service Deployer removes (decommissions) a service instance
    1. This means making a service instance unavailable for future execution.

Final State

The system has modified the service directory and the operational service instances and processes to reflect the operator changes, and the effective "launch plan" of the system reflects the operator changes.

Use Case Images

Architecture Diagram


These comments provide additional context (usually quite technical) for editors of the use case.

If two different services get instantiated on the same operational unit there may be conflicts (e.g., one of them assumes that a different version of Java is the default than the other and the contextualization overrides that default). Those are subtle differences, difficult to manage on a higher level as conflicts, but will make things not work.

(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
openissue openissue Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.