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 31 Current »

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 https://demo.edunify.pesc.org.

SOA Governance

  1. Add ability for organizations to use EdUnify (SaaS) to register private services that are only viewable to verified members or affiliates of that organization (2 or later, analysis will be done prior to beta launch).
    1. Single product instance.
    2. Could make certain "pieces" of the service publicly viewable.
    3. Could choose when to make an individual service public (to the world) or to targeted users and/or communities.
    4. Searches would search all registered items (public and private) and indicate that "private" items were found.  Users would have an opportunity to request access or more information about the "private" items that were found.
    5. Community/affiliation targeted service registration.  Providers/registers can indicate which EdUnify "communities" or affiliated users are allowed to see specific services.  e.g., all clients affiliated with a vendor can see any service submitted by that vendor.  Could be targeted to a broad based community and/or an individual user.

Authentication and Authorization 

  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." (2)
  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. (2)
  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. (2)
  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. There will be a definition of the various attributes a user must possess to qualify for specific roles as defined by the Business group (2).

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.  If this is implemented, it will likely require a "submission and approval" process that confirms the provider of the WSDL is a known entity.  Ideally, providers will host the WSDL themselves and provide public access to the artifact so that would eliminate the need to have any approval process.  (need more analysis, for now, the WSDL must be public)
  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 (1)
    2. When a provider and/or consumer of that service adds additional information to the service entry (1)
  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 (1).
  6. Add WEB SERVICE definition version attribute to core service metadata (1).
  7. Make Usage Conditions required and add more to description asking for "how can I use this service."  Add pick lists for common usage requirements (similar to categories) (1).
  8. Make Cost required (1).
  9. Add ability to apply filters to existing search results (2).
  10. Allow people to save searches between sessions (2).
  11. Add ability to register web sites (no login required) and web applications (login required) (1-2).

Searching the Registry

  1. The EdUnify Demonstration Registry leverages the the BioCatalgue experiences 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 (2).

Accounting

  1. SAML will be used to provide authentication tokens to the EdUnify web application. (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 web application as described. These assertions also provide the tools for a detailed accounting mechanism (2).
  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 web application will be positioned to support changes in the business model as they happen, increasing the flexibility of the portal and its value (2).
  • No labels