This use case describes how actors will find Web Services that are registered in (advertised by) the EdUnify registry service.This only applies to system compatible services that have been previously deployed in a manner that is compliant with EdUnify standards. The impetus behind this use case is the need for consumers to discover published information about web services deployed by other users, so they may be researched and accessed. The monitoring tools required to provide the data for this research and the tools for accessing services are the subject of separate use cases, discovery is only about finding services that have been deployed.
The following use case could apply to just about any system at an academic institution. In order to maintain the established example, we continue the application and service example established in Use Case 1 to illustrate this use case. Any number of actors, applications, and specific web services could be substituted for this specific use case. We may decide to list more of these explicitly, if that is necessary to make this point.
High-level Story (Abstract)
A non technical user wants to discover one or more services deployed on the EdUnify network. This user may or may not be aware of what services are desired, in some cases the request could be of a specific service, in other cases the request could be to discover a collection of services that satisfy a requirement the user has. In any case, the request should return an ordered list of one or more services that satisfies the user's request. This ordered list should include all metadata published by the service, information on how to use the service, and access to data collected by the monitoring systems that will help the user make a decision about what services to access.
Detailed Story (with illustration and schematics as needed)
There are multiple web services deployed. Some of these services are Student Information Systems, but many are not. A Non Technical User wishes to find if locations which might have data about a particular student have published student information on the EdUnify network. What happens once a service is discovered is not the responsibility of the Lookup service, but the results returned to a user should either display or provide access to all static and dynamic metadata about the service including any results available from the monitoring service. Some services may require authentication before they can even be discovered, and the lookup service may be required to handle the transfer of security tokens.
When an authenticated user submits a query to the lookup service, the next steps vary depending upon the architecture EdUnify deploys. In a centralized solution, the lookup service might query a monolithic data repository of metadata provided to the system by Administrative Administrators of the various applications that are deployed to find services that meet the user's needs. In a more decentralized system, these administrators will have registered their services to one or more local federated and some mechanism will be in place to disseminate this metadata. The lookup query will enter the federated registry and interact with the mechanism that shares the published metadata to find the results that have been requested.
In either situation, the lookup service will gather the metadata of all the web services that satisfy the user query. These results will be ordered by relevance and returned to the requesting user.
The EdUnify web services lookup service must support the following high-level flow:
- User employs web form to create a query to be submitted for metadata about one or more EdUnify Web Service
- Optionally, user is challenged for authentication
- Query is submitted to EdUnify Web Services lookup service
- Results are gathered and ordered by relevance
- Results are returned to user
- static metadata for all services reported by lookup
- dynamic monitoring data for services
- a list of instructions and requirements for accessing the service