Add new service interface to system capabilities
|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|
|Is Extended By|
|In Acceptance Scenarios||None|
|Primary Service||Capability Container & Distributed Service Infrastructure Part 1|
|UC Status||Mapped + Ready|
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.
- Actual service execution is controlled by the Integrated Observatory Operator.
System is ready to accept a new service definition.
- A new service is conceived to provide a capability in the system
- 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).
- A service may require the existence of another service in the system
- <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.
- A service interacts exclusively through the exchange (send, receive) of messages
- This may be done implicitly by selecting a Service Type, if one exists. See UC.R2.44 Define Service Type During Runtime.
- The System Process Developer implements the business logic for the service to meet the desired service functions, and satisfy the selected interaction protocols.
- The service implementation must be integration tested and versioned: unit tests, integration tests are completed.
- Dependencies on other specific service package releases and external dependencies are clearly specified.
- The service component package is placed into the software component repository.
- This can be done manually or by a release script (not as part of the running Integrated Observatory).
- This step may need Integration Engineer authorization
- A package published to the software component repository remains there for use by development, test, staging, operational and external system instances.
- The System Process Developer implements or configures an agent for the service to match the specific service functions.
- 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
- The configuration process includes associating the service to a service type.
- The System Process Developer adds the service to the list of available services in the Service Registry.
- Uses a Service Registration form or API to do this.
- 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).
- A service instance can be executed continuously (as a daemon), or scheduled for temporary execution when needed.
- One or many worker processes may be collaborating in concert to provide the service of a service (instance in terms of the service definition).
- The caller of a service does not notice these deployment details.
Service is defined and available for execution.
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.