Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

The following is a listing of detailed requirements for EdUnify. These requirements are expressed as additions or modifications to the EdUnify Demonstration Registry based on the BioCatalogue available at

Security and Authenticity

  1. There should be a process for verifying service providers and registering official service provider administrators for each provider in EdUnify. These verified service providers with one or more vetted service provider administrators will appear as "verified" with both visual and data indicators in the PESC EdUnify web applications. Service providers who are not verified will appear as "unverified." (1)
  2. These service provider administrators will identify service managers for their organization who are authorized to register and manage services on behalf of the service provider.  Ideally, service provider administrators can specify service managers proactively from the EdUnify user base or approve submitters of web services as service managers for their organization at the time of web service submission (or not, the submitter may not qualify to be a service manager).  These features will facilitate collaboration and participation for new EdUnify users. (1)
  3. Unverified service providers and services will still be permitted, but the EdUnify application should offer links and buttons to encourage users to start and complete the verification process. (1)
  4. EdUnify should support both internal and web user based SAML authentication when making authorization decisions for users with privileges, including service providers and service provider administrators.  Once federated authentication is implemented, EdUnify may implement other features around service provider administration and service managers. (2) This will not interfere with non-privileged user's access.

Service Registration and Annotation

  1. A quality assessment or score of the completeness of the entry to encourage users responsible for the service to complete the entry as best they can.  We may even want to send out e-mail alerts or build a task list for users to complete entries that are not complete. (1)
  2. A currency assessment of the entry. (2 or later)
  3. Accept a WSDL upload and allow management and publication of the WSDL within EdUnify. (1)
  4. A mechanism that will allow users to specify how a service is being used.  This includes, but is not limited to, links to applications that use the service(s), how many clients use the service(s), how many invocations are made on the service and potentially who is using the service(s).  This information may be specified at multiple points throughout the life-cycle of the registry entry:
    1. When a provider or person submitting a service first registers the service
    2. When a provider and/or consumer of that service adds additional information to the service entry
  5. Category suggestions.  Provide the ability for community members to submit new potential service categories which would initiate a work flow that includes a review process resulting in either an approval or denial of the category.  If the new category is approved, it would become an official option for new and/or existing services.  These suggestions could be specified during initial registration or as the service is annotated after initial submission.

Searching the Registry

  1. Add...

Billing, Payment, and Account Management

  1. And account management...
  • No labels