Making Services Discoverable to Users

DATE and TIME: Thursday, May 26, 2011, 1:30 pm

CONVENER: Michael Geddes, Roland Hedberg

SCRIBE: Billy Cook

# of ATTENDEES: 15

MAIN ISSUES DISCUSSED

All service providers are in InCommon.  How to make the services discoverable?

Also other federations?

User Centric View vs. Technical View

Roland - mentioned wsdl, other methods that are the technical side of the service.  Need to add more information about the service. Cost, status, etc.

Roland using RDF store.  Semantic web.  Supports searching the store.  

Pilot project - Student Mobility - Students can move between universities.  Dest institution must be able to determine if they can accept the student.  Currently done with email, paper, etc.  

What are other use cases, examples?

webservices.washington.edu - registry - web services -

edunify - http://www.pesc.org/interior.php?page_id=204

Switch Federation requires all endpoints to be registered but can limit discoverability

Uportal allows searching

A registry of some kind that is searchable?

Use InCommon meta-data as a search base?  Would need extensions to support searching.

New way to distribute the metadata?  Get out of a directory?  Abililty to get one entry at at time?

Allow SP to register its services?  Push metadata to InCommon somewhere.  Filtering?

CMU - Security handled by the SP.  No need to hide services.

Categorize registrations?

Even is a SP is discovered might not be able to connect to it since IDP doesn’t trust the SP.
Update meta-data more frequently?  InCommon is once daily.

ACTIVITIES GOING FORWARD / NEXT STEPS:

  • See what Switch, others are doing to avoid duplicating effort
  • Look for standards for storing information
  • Needs to accommodate more than Shib, InCommon
  • Service catalog type approach?

-
If slides are used in the session, please ask presenters to convert their slides to PDF and email them to SteveO@internet2.edu

Thank you!

  • No labels