Difference between revisions of "Use Case --: Publish Service"
From Earth Science Information Partners (ESIP)
Line 1: | Line 1: | ||
− | Use Case | + | 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 | |
Line 19: | Line 19: | ||
==1.1.Use Case Number== | ==1.1.Use Case Number== | ||
− | + | tbd | |
==1.2.Use Case Name== | ==1.2.Use Case Name== | ||
− | + | Publish Service | |
=2.Use Case Definition= | =2.Use Case Definition= | ||
− | + | A provider publishes their service offering in the EIE Service Registry. | |
==2.1.Actors== | ==2.1.Actors== | ||
− | * | + | *1.Provider (primary) |
− | + | *2.EIE Administrator | |
− | ==2.2. | + | ==2.2.Business Rules== |
− | *1. | + | *1. Service Provider must be registered with EIE (?) |
− | |||
− | |||
− | ==2.3. | + | ==2.3.Preconditions== |
− | *1. | + | *1.The provider has authenticated with EIE. |
− | *2. | + | *2.The provider is registered in the EIE. |
==2.4.Normal Flow== | ==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== | ==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. | + | ===2.6.3Alternate Flow 2=== |
− | *1. | + | *1.A failure message has been returned to the provider containing the reason of the failure. |
− | *2. | + | *2.EIE has not stored service information. |
+ | *3.EIE has logged error. | ||
==2.7.Extension Points== | ==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. | + | ==2.8.Special Requirements== |
− | + | *1.TBD requirements for specifying the contents of a service application. | |
− | ==2.9. | + | ==2.9.Assumptions== |
− | *1. | + | *1.Service Registry is moderated. (i.e. – registration is two-phased, “apply & approve/activate”, with a human-in-the-loop. |
− | ==2.10. | + | ==2.10.Notes== |
− | *1. | + | *1.none, yet! |
− | ==2.11. | + | ==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. |
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.