View source for Use Case 10: Service Discovery


Use Case EIE10: Service Discovery

for

ESIP Earth Information Exchange



Version 1.0 draft

Prepared by Karl Benedict

Earth Data Analysis Center, University of New Mexico

December 13, 2005

Revision History



=1.Use Case Identification=

==1.1.Use Case Number==

EIE10

==1.2.Use Case Name==

Discover available data or expert services registered into the portal. 

=2.Use Case Definition=

The availability of data and expert services to portal users is a key requirement for the portal. This use case describes the process for user discovery of services based upon search criteria that include: dataset, parameter, date and time coverage of the service, spatial domain for the service, and keyword classification.

==2.1.Actors==

*User
*Provider (as an extension of EIE07)

==2.2.Preconditions==

*1.Services have been registered into the portal
*2.The service registry includes sufficient information to support searches by: dataset, parameter, date and time coverage of the service, spatial domain for the service, and keyword classification.

==2.3.Postconditions==

*1.The user has been provided a listing of services that meet the specified criteria
*2.The provided listing includes interface elements that facilitate use of the service: i.e. Add service to a visualization system, review detailed service registry information, retrieve service access URI, contact service provider.

==2.4.Normal Flow==

*EIE10.0.1) User enters the portal
*EIE10.0.2) (optional) User logs into the portal
*EIE10.0.3) User selects the service search link in the initial portal page
*EIE10.0.4) User is presented with a basic search interface (i.e. Google-like) which may be used to perform a non-specific search (i.e. Across service registry fields). A link to an 'advanced' search form is also provided.
*EIE10.0.5) The user completes the basic search form and submits it to perform the search  against the registry(ies) (see note)
*EIE10.0.6) A listing of services that meet the search criteria is provided to the user for further action: visualization, provider query/contact, access/use instructions. manage service (if authenticated and authorized)

==2.5.Alternative Flows==

*EIE10.1.1) User enters the portal
*EIE10.1.2) (optional) User logs into the portal
*EIE10.1.3) User selects the service search link in the initial portal page
*EIE10.1.4) User is presented with a basic search interface (i.e. Google-like) which may be used to perform a non-specific search (i.e. Across service registry fields). A link to an 'advanced' search form is also provided.
*EIE10.1.5) The user selects the link to the advanced search form.
*EIE10.1.6) The user completes the advanced search form (providing dataset, parameter, date and time coverage of the service, spatial domain for the service, and keyword classification search criteria as appropriate). 
*EIE10.1.7) The advanced search form is submitted, and search is performed against the registry(ies). 
*EIE10.1.8) A listing of services that meet the search criteria is provided to the user for further action: visualization, provider query/contact, access/use instructions, manage service (if authenticated and authorized).

==2.6.Exceptions==

Invalid search parameters are provided. The error is logged and an error message is returned to the user.

If performing a distributed search, some registries do not respond in a timely manner. Present available search results to the user, noting absence of materials from unavailable registries. Log the error.

No services are found that match the provided search criteria. Report to user the failure to discover any services that match the specified criteria, and offer guidance to perform a new search that is more likely to return useful results.

==2.7.Extension Points==

*EIE25 – Access visualization tool
*EIE07 – Manage Services

==2.8.Priority==

High

==2.9.Frequency of Use==

Invoked at least once per session, often more frequently

==2.10.Business Rules==

None

==2.11.Special Requirements==

Service registry must contain necessary information to be able to discover services based upon criteria deemed important in discovering those services. 

==2.12.Assumptions==

It is assumed that there is a high-performance index of service metadata available to support both the basic and advanced search capabilities, either as part of a centralized search or as part of a distributed search capability. 

==2.13.Notes and Issues==

The use of a single service registry (analogous to GOS II's harvesting model for metadata) or distributed registries (analogous to the FGDC Clearinghouse Node model) needs to be determined. 

This use case seems to be a logical entry point for basic service management.