Use Case --: Activate Service
Use Case <tbd> Activate Service
Earth Science Information Exchange
Reason For Changes
- 1 1.Use Case Identification
- 2 2.Use Case Definition
- 2.1 2.1.Actors
- 2.2 2.2.Business Rules
- 2.3 2.3.Preconditions
- 2.4 2.4.Normal Flow
- 2.5 2.5.Alternative Flows
- 2.6 2.6.Postconditions
- 2.7 2.6.1Normal Flow
- 2.8 2.7.Extension Points
- 2.9 2.8.Special Requirements
- 2.10 2.9.Assumptions
- 2.11 2.10.Notes
- 2.12 2.11.Issues
1.Use Case Identification
1.1.Use Case Number
1.2.Use Case Name
2.Use Case Definition
Once a Service Application is approved, make it visible and active in the Service Registry.
- 1.EIE Administrator (primary)
- 2.Service Provider (contact)
Service acceptance policy - tbd
- 1.Service Provider has submitted Service Application (Use Case: Publish Service).
- 2.EIE Administrator is logged on to the EIE management system, and has been authenticated.
- 3.EIE Administrator has approved the new Service application, based on policy.
- 1.EIE Administrator is notified of new Service Application.
- 2.EIE Administrator, using Administrative Tool (better name here!), displays Service Application.
- 3.EIE Administrator evaluates information on application and investigates the content, if appropriate.
- 4.Based on policy constraints, decides to approve Service application (See Alternative Flow step 2)
- 5.EIE Administrator approves the service application.
- 6.EIE checks authorization of the ECHO Administrator.
- 7.EIE extracts and validates activation fields from application.
- 8.EIE activates the Service within the Service Registry.
- 9.Notification of service Activation is sent to the service registering provider via e-mail, and EIE Administrator communicating the fact that the service has been activated by the system.
- 10.EIE triggers a NewService event, with appropriate metadata.
- a.EIE logs the security violation.
- b.EIE returns a denied message to the user.
- c.Use case terminates.
2.Service application denied - submitted application does not meet policy constraints. (Normal Flow step 4)
- a.EIE Administrator rejects the application. Provides a reason for rejection to EIE.
- b.EIE logs the rejection event.
- c.EIE returns a rejection message (email?) to provider with reason of rejection. Copy of message is retained within EIE (email to EIE Administrator?)
- d.Use case terminates
3.Notification cannot be sent to new approved provider. (Normal Flow step 9)
- a.EIE sends an e-mail message to the EIE administrator notifying problem with provider e-mail
- b.Use case terminates.
- c.EIE Administrator notifies provider directly. Investigates communication failure.
- 1.EIE issues event for NewService.
- 2.New Service activation is logged.
- 3.The new service is added into the Service registry.
- 4.Notification is sent to provider, with copy logged within EIE.
2.6.2Alternate Flow 1
- 1.Message is displayed, indicating a permission violation
- 2.EIE has logged the security violation.
- 3.Use case terminates.
2.6.3Alternate Flow 2
- 1.A rejection message has been returned to the provider (contact) containing the reason of the failure.
- 2.EIE has logged the rejection.
- 3.Use case terminates.
2.6.4Alternate Flow 3
- 1.A communication failure event has been created.
- 2.EIE Administrator detects the communication failure.
- 3.EIE Administrator communicates directly with Provider, informing of Service approval.
- 4.EIE Administrator evaluates the communication failure.
- 5.Use case terminates.
Guaranteed delivery of messages to providers?
- 1.Service Registry is moderated. (i.e. – registration is two-phased, “apply & approve/activate”, with a human-in-the-loop.
Policy decisions must be made. This implies governance issues (who decides the policies and how they are updated/managed.) The policies must be documented and baselined in a form that EIE Administrators can use effectively.
Alternative guaranteed delivery mechanisms may replace email