Use Case --: Activate Service

Use Case <tbd> Activate Service

for

EIE

Earth Science Information Exchange

Revision History

Name

Date

Reason For Changes

Version

Michael Burnett

11/28/05

Initial Draft

0.1

1.Use Case Identification

1.1.Use Case Number

tbd

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.

2.1.Actors

• 1.EIE Administrator (primary)
• 2.Service Provider (contact)

2.2.Business Rules

Service acceptance policy - tbd

2.3.Preconditions

• 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.8.Special Requirements

Logging requirements

Guaranteed delivery of messages to providers?

Event management

2.9.Assumptions

• 1.Service Registry is moderated. (i.e. – registration is two-phased, “apply & approve/activate”, with a human-in-the-loop.

2.10.Notes

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

2.11.Issues

1.tbd