Difference between revisions of "Use Case --: Publish Service"

From Earth Science Information Partners (ESIP)
 
 
Line 1: Line 1:
Use Case EIE24: Track Usage
+
EIE Use Case: Publish Service
  
for
 
  
ESIP Earth Information Exchange
+
Earth Science Information Exchange
 +
Revision History
  
 
+
Name
Version 1.0 draft
+
Date
 
+
Reason For Changes
Prepared by Karl Benedict
+
Version
 
+
Michael Burnett
Earth Data Analysis Center, University of New Mexico
+
11/28/05
 
+
Initial Draft
12/8/2005
+
0.1
  
  
Line 19: Line 19:
 
==1.1.Use Case Number==
 
==1.1.Use Case Number==
  
EIE24
+
tbd
  
 
==1.2.Use Case Name==
 
==1.2.Use Case Name==
  
Track EIE portal usage by registered users,  unregistered anonymous guest users, and automated interfaces.
+
Publish Service
  
 
=2.Use Case Definition=
 
=2.Use Case Definition=
  
Through this use case portal usage will be monitored, with the resulting information feeding into analysis tools that summarize portal usage along dimensions of interest (see notes). Reports based upon usage tracking will summarize results for multiple time intervals.
+
A provider publishes their service offering in the EIE Service Registry.
  
 
==2.1.Actors==
 
==2.1.Actors==
  
*Operator - Establishes, maintains, and accesses usage reports.
+
*1.Provider (primary)
*Provider (?) - usage statistics should probably be made available to data and service providers for the products that they have contributed to the system.
+
*2.EIE Administrator
  
==2.2.Preconditions==
+
==2.2.Business Rules==
  
*1.Required metrics have been defined
+
*1. Service Provider must be registered with EIE (?)
*2.Required information has been collected for registered users
 
*3.Automatic acquisition of basic request parameters has been enabled (i.e. host, object or service request, date, time, data transferred, status of request)
 
  
==2.3.Postconditions==
+
==2.3.Preconditions==
  
*1.Record(s) has been added to the usage tracking database reflecting required services
+
*1.The provider has authenticated with EIE.
*2.Regularly scheduled reporting processes have been defined for the collected data
+
*2.The provider is registered in the EIE.
  
 
==2.4.Normal Flow==
 
==2.4.Normal Flow==
  
*EIE24.0.1) The user selects a page, data or service resource from the portal interface
+
*1.Provider logs on to EIE Portal.
*EIE24.0.2) The system captures information about the request, minimally including: timestamp, identifier for the requested resource, ID of the requester (if registered)
+
*2.Provider navigates to “Publish a new Service” activity point.
*EIE24.0.3) Write the request information into the usage tracking database/log
+
*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==
 
==2.5.Alternative Flows==
  
===Unregistered User===
+
===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.
  
*EIE24.1.1) Present with opportunity to join
+
===2.Provider does not have authorization.===
*EIE24.1.2) User joins
 
*EIE24.1.3) Proceed with request fulfillment
 
  
===Unregistered User - declines invitation to join===
+
*a.EIE returns an authorization denied message to the provider.
 +
*b.EIE logs unauthorized access.
 +
*c.Use case terminates.
  
*EIE24.2.1) Present with opportunity to join
+
==2.6.Postconditions==
*EIE24.2.2) User declines invitation to join (suppress invitations for remainder of session)
 
*EIE24.2.3) Proceed with request fulfillment
 
  
===Routine generation of updated reports===
+
==2.6.1Normal Flow==
  
*EIE24.3.1) Execute regularly database/log analysis routines to generate reports for recent time periods
+
*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.
  
===Data Provider/Operator accesses use tracking reports===
+
===2.6.2Alternate Flow 1===
  
*EIE24.4.1) Data or service provider accesses reporting interface
+
*1.A failure message has been returned to the user containing the reason of the failure.
*EIE24.4.2) Specified report is requested
+
*2.EIE has not stored service information.
*EIE24.4.3) Specified report is delivered to the requesting provider or operator.
+
*3.EIE has logged error.
  
==2.6.Exceptions==
+
===2.6.3Alternate Flow 2===
  
*1.Insufficient information provided to capture request. Log in separate error log
+
*1.A failure message has been returned to the provider containing the reason of the failure.
*2.Inaccurate information provided. Log in separate error log.
+
*2.EIE has not stored service information.
 +
*3.EIE has logged error.
  
 
==2.7.Extension Points==
 
==2.7.Extension Points==
  
*1.EIE01: User management (user)
+
This Use Case precedes the Activate Service Use Case.  As an Extension of Normal Flow, the Activate Service Use Case follows.
  
==2.8.Priority==
+
==2.8.Special Requirements==
  
Normal
+
*1.TBD requirements for specifying the contents of a service application.
  
==2.9.Frequency of Use==
+
==2.9.Assumptions==
  
*1.Invoked once per request to the portal, potentially multiple requests per second at peak demand times.
+
*1.Service Registry is moderated.  (i.e. – registration is two-phased, “apply & approve/activate”, with a human-in-the-loop.  
  
==2.10.Business Rules==
+
==2.10.Notes==
  
*1.Differential access to resources by members/non-members?
+
*1.none, yet!
  
==2.11.Special Requirements==
+
==2.11.Issues==
  
Regularly scheduled report generation capabilities should be enabled for efficient processing of captured log/database
+
1.Analysis of Service Domain model is germane here.  Issues include:
  
==2.12.Assumptions==
+
*Reuse of interfaces
 +
*Web Service offerings, vice Advertisements
  
Automated request information capture is available within the used portal technologies.
+
W/S GUIs
  
==2.13.Notes and Issues==
+
2.Standards: Are “active” services required to be described in WSDL? (S/wsdl)?
  
Need to identify portal metrics for which data need to be collected by the portal. These metrics may be driven by a combination of external requirements (e.g. OMB reporting) and internal requirements (e.g. performance, participation, utilization).
+
3.Classification of services may be specified in application. This leads us to identify categorization schemes and their governance.

Latest revision as of 12:04, January 31, 2006

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.