Use Case --: Publish 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.

EIE Use Case: Publish Service


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

Publish Service

2.Use Case Definition

A provider publishes their service offering in the EIE Service Registry.

2.1.Actors

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

2.2.Business Rules

  • 1. Service Provider must be registered with EIE (?)

2.3.Preconditions

  • 1.The provider has authenticated with EIE.
  • 2.The provider is registered in the EIE.

2.4.Normal Flow

  • 1.Provider logs on to EIE Portal.
  • 2.Provider navigates to “Publish a new Service” activity point.
  • 3.Provider populates a form, and then submits a request to register a service.
  • 4.EIE checks the authorization of the provider (See Alternative Flow step 2)
  • 5.EIE validates the application for the service (See Alternative Flow step 1 and 3)
  • 6.EIE obtains implicit provider ID
  • 7.EIE saves the service entity information
  • 8.EIE notifies the EIE Administrator of application
  • 9.EIE returns a success message to the provider, indicating that the application was successfully received.

2.5.Alternative Flows

1.A required field is missing or invalid for application.

  • a.EIE returns a failure message to the provider with details on missing fields.
  • b.EIE logs error.
  • c.Use case terminates.

2.Provider does not have authorization.

  • a.EIE returns an authorization denied message to the provider.
  • b.EIE logs unauthorized access.
  • c.Use case terminates.

2.6.Postconditions

2.6.1Normal Flow

  • 1.A new business service entity is added to the Service Registry.
  • 2.An email has been sent to the EIE Administrator to notify the service registration.
  • 3.A success message has been sent back to the user.

2.6.2Alternate Flow 1

  • 1.A failure message has been returned to the user containing the reason of the failure.
  • 2.EIE has not stored service information.
  • 3.EIE has logged error.

2.6.3Alternate Flow 2

  • 1.A failure message has been returned to the provider containing the reason of the failure.
  • 2.EIE has not stored service information.
  • 3.EIE has logged error.

2.7.Extension Points

This Use Case precedes the Activate Service Use Case. As an Extension of Normal Flow, the Activate Service Use Case follows.

2.8.Special Requirements

  • 1.TBD requirements for specifying the contents of a service application.

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

  • 1.none, yet!

2.11.Issues

1.Analysis of Service Domain model is germane here. Issues include:

  • Reuse of interfaces
  • Web Service offerings, vice Advertisements

W/S GUIs

2.Standards: Are “active” services required to be described in WSDL? (S/wsdl)?

3.Classification of services may be specified in application. This leads us to identify categorization schemes and their governance.