Use Case --: Activate Service

From Earth Science Information Partners (ESIP)

Use Case <tbd> Activate Service



Earth Science Information Exchange

Revision History



Reason For Changes


Michael Burnett


Initial Draft


1.Use Case Identification

1.1.Use Case Number


1.2.Use Case Name

Activate Service

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)

2.2.Business Rules

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.

2.4.Normal Flow

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

2.5.Alternative Flows

1.EIE Administrator does not have authorization.

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


2.6.1Normal Flow

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

2.7.Extension Points

2.8.Special Requirements

Logging requirements

Guaranteed delivery of messages to providers?

Event management


  • 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