Use Case --: Delete Service

From Earth Science Information Partners (ESIP)
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Use Case <tbd>: Remove 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 ID

tbd

1.2.Use Case Name

Delete Service

2.Use Case Definition

A registered provider requests to remove a service from the EIE Extended Service Registry. The service is deleted and the event is logged.

2.1.Actors

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

2.2.Business Rules

  • 1.May be some, dependent on application of domain model.

2.3.Preconditions

  • 1.The provider has authenticated with EIE.

2.4.Normal Flow

  • 1.Provider (contact) logs on to EIE.
  • 2.EIE Authenticates user. (See Alternative Flow step 1)
  • 3.Provider (contact) navigates to manage their services.
  • 4.Provider (contact) selects the Service to be deleted, then requests to delete the service.
  • 5.EIE checks the authorization of the provider. (See Alternative Flow step 1)
  • 6.EIE removes the web service implementation from the registry.
  • 7.EIE logs the deletion (with requestor, implementation deleted, and timestamp).
  • 8.EIE sets a notification of Service Deletion to Service Provider and EIE Administrator. (See Alternate Flow 2)
  • 9.EIE triggers a DeleteService event, with appropriate metadata.

2.5.Alternative Flows

1.Provider is not authorized to delete the web service implementation.

  • a.EIE logs the security violation.
  • b.EIE presents a denied message to the provider.
  • c.Use case terminates.

2.Notification cannot be sent to new provider. (Normal Flow step 8)

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

2.6.1Normal Flow

  • 1.Service has been removed from the extended service registry.
  • 2.A log entry has been created for the deletion.
  • 3.Delete confirmation message sent to provider, EIE Administrator.
  • 4.DeleteService event is triggered.

2.6.2Alternate Flow 1

  • 1.Message is displayed, indicating a permission violation
  • 2.Service Registry has not changed.
  • 3.A log entry has been created for the security violation.

2.6.3Alternate Flow 2

  • 1.Service Registry has been changed.
  • 2.EIE Administrator detects the communication failure.
  • 3.EIE Administrator communicates directly with the Provider, informing of the Service deletion.
  • 4.EIE Administrator evaluates the communication failure.
  • 5.Use Case terminates.

2.7.Extension Points

2.8.Special Requirements

  • 1.Logging requirements - All log messages must include provider information, service implementation information, operator information, descriptive message, and a timestamp as appropriate.
  • 2.Event Management
  • 3.Guaranteed delivery of messages to providers?

2.9.Assumptions

2.10.Notes

2.11.Issues