Skip to end of metadata
Go to start of metadata

Overview of "Define New Service Interface" Use Case

Add new service interface to system capabilities


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

Metadata

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

Actors System Process Developer, Integrated Observatory Operator
References UC.R1.11 Define New Service, UC.R2.44 Define Service Type During Runtime
Uses UC.R2.30 Define Interaction
Is Used By UC.R2.44 Define Service Type During Runtime
Extends  
Is Extended By  
In Acceptance Scenarios None
Technical Notes  
Lead Team COI
Primary Service Capability Container & Distributed Service Infrastructure Part 1
Version 2.2
UC Priority 5
UC Status Mapped + Ready
UX Exposure PGM

Summary

This information summarizes the Use Case functionality.

Perform the steps necessary to achieve the life cycle of a service, from conception to execution. The interaction pattern protocol for the service must be defined, business logic implemented, an agent implemented/configured, and the service deployed and made operational.

Assumptions

  • Actual service execution is controlled by the Integrated Observatory Operator.

Initial State

System is ready to accept a new service definition.

Scenario for "Define New Service Interface" Use Case

  1. A new service is conceived to provide a capability in the system
    1. This can be a transformation from one information representation to another, or providing access to the capabilities of an (external) resource, or providing a basic system capability (such as a data store service).
    2. A service may require the existence of another service in the system
  2. <3> An interaction pattern protocol is selected or defined for the input and output interfaces of the service, according to the service's functional capabilities.
    1. A service interacts exclusively through the exchange (send, receive) of messages
    2. This may be done implicitly by selecting a Service Type, if one exists. See UC.R2.44 Define Service Type During Runtime.
  3. The System Process Developer implements the business logic for the service to meet the desired service functions, and satisfy the selected interaction protocols.
    1. The service implementation must be integration tested and versioned: unit tests, integration tests are completed.
    2. Dependencies on other specific service package releases and external dependencies are clearly specified.
  4. The service component package is placed into the software component repository.
    1. This can be done manually or by a release script (not as part of the running Integrated Observatory).
    2. This step may need Integration Engineer authorization
    3. A package published to the software component repository remains there for use by development, test, staging, operational and external system instances.
  5. The System Process Developer implements or configures an agent for the service to match the specific service functions.
    1. A service is a resource and has a service (resource) agent. The service agent is responsible for the starting and stopping the service, monitoring its correct operation, and advertising its capabilities
    2. The configuration process includes associating the service to a service type.
  6. The System Process Developer adds the service to the list of available services in the Service Registry.
    1. Uses a Service Registration form or API to do this.
  7. To deploy or execute the service on a specific execution node within a Capability Container, the Integrated Observatory Operator adds the service to the process list for a specific supervisor process (see UC.R2.45 Instantiate Service Anywhere During Runtime).
    1. A service instance can be executed continuously (as a daemon), or scheduled for temporary execution when needed.
    2. One or many worker processes may be collaborating in concert to provide the service of a service (instance in terms of the service definition).
    3. The caller of a service does not notice these deployment details.

Final State

Service is defined and available for execution.

Comments

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

A better name is Define New Service, but we'll leave it at this late stage.

All service resources should appear in the list of resources monitored in UC.R2.40 Monitor ION Resources.

Need to address the deployment of service to multiple sites/capability containers.

In order to satisfy more of the DOORS requirements, this use case could be enhanced to include access to resource-data connectors for service access to resources and backward compatibility.

(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

Labels

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.