Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

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


Authentication and



  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 Security Assertion Markup Language (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.
  5. Should we define what privileged and non-privileged user's are allowed to do here?
  6. Should we define what attributes are required for different levels of authorization here? Or perhaps simply state that we intend to do so later?

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. The EdUnify Demonstration Registry leverages the experiences the BioCatalgue experience in creating and searching a registry of web services. However, it is unlikely that all search scenarios can be predicted. Therefore the EdUnify registry will include a issue tracking mechanism that will collect requests for specialized features that may be specific to the target audience.


  1. SAML will be used to provide authentication tokens to the EdUnify portal. (see Security and Authenticity above). The assertions provided by SAML carry rich details about the users. These assertions will be used for Authentication to various portions of the portal as described. These assertions also provide the tools for a detailed accounting mechanism.
  2. EdUnify will build or install a mechanism for storing parsed SAML, and account for usage based upon predetermined attributes. These accounting files will be leveraged to support the business use cases as they are published. In this manner, the portal will be positioned to support changes in the business model as they happen, increasing the flexibility of the portal and its value.