Date: Friday January 22, 2pm EST (-5 UTC)

Meeting Goals

  1. Develop a program for engagement with SSWAP
  2. Move forward on our understanding of service binding

Attendees

Agenda

  1. Discuss Stefano Cossu's  high-level architecture diagram (ran out of time last week)
  2. Discuss Unknown User (acoburn)'s proof of concept for Service Discovery and Binding
  3. Discuss SSWAP and its potential utility to API-X.
    1. http://sourceforge.net/p/sswap/wiki/publications/
      1. iPlant (the ecosystem? that SSWAP was designed to operate in) architecture http://sourceforge.net/p/sswap/wiki/publications/attachment/iPlant%20Semantic%20Architecture%20and%20Design.pdf

      2. Their main paper: 

        Gessler DDG, Schiltz GS, May GD, Avraham S, Town CD, Grant D, Nelson RT 2009. SSWAP: A Simple Semantic Web Architecture and Protocol for semantic web services. BMC Bioinformatics, 10:309 doi:10.1186/1471-2105-10-309.

  4. PoC implementation

Notes

  • High-level diagram: Simple diagram, intended to advertise API-X work to Fedora and non-Fedora communities
    • Lots of discussion in various communities (e.g. hydra).  Many use cases overlap
    • Triple store is in the diagram because many extensions will likely use on
    • Do all have to go through API-X?  Thinking about scaling issues
      • Graph indicates how it works, does not imply it's mandatory always, just in cases where API-X is use
      • Suggestion: put "API-X client" in the box, rather than just "client"
    • Question regarding Arrows between extensions:  is it the intent to communicate thait it is a recommended pattern that extensions invoke another?  To what extent is it mediated by API-X?
      • Wanted to demonstrate a pipeline, in reality API-X mediated the pipes.  Maybe make the arrows a different colour.
      •  It's a common pattern that if extensions need to communicate with one another, they'd be a sort of client too.
      • Extensions should not directly be passing information to one another.  They ideally should be a set of functions or configuration, these are parsed by API-X core.  The API-X core is the one that routes.
      • Will communication bounce back between extensions and API-X core?  there may be scalability issues.
    • Observation: There are no arrows between low-level storage and triple store.
      • Right, this is discouraged.  Recommended means of populating storage is async/event driven.
      • In either case, though, there are no arrows currently on the diagram which indicate how triple store is populated
    • Maybe distinguish between Fedora and the APIs?  Square boxes make them all look the same
      • re-affirm that we've decided that all interaction with Fedora is through it's REST api.
      • Boxes were "something with logic in it"
      • Should emphasize that API-X is a body of software
      • Swim-lane diagrams can make it clear what's an API
      • Diagram of what's inside API-X core would be useful at some point as well.
    • Action item:  Stefano Cossu to revise graph
      • Offer from A. Soroka to assist with swim-lane diagrams to clarify interactions
        • This will aid debate/discussion
  • Open repositories:  Aaron Birkland preparing an API-X submission
  • Service Discovery and Binding (SD&B)
    • Overview
      • Make sure clients of API-X can understand which services are running. 
      • Should be a way of registering change so clients know what is available or not.
      • Knowing if a service can be applied to repository objects of a type
      • Two possible client modes:  Directly with the client (client polls registry and  invokes service), or mediated (proxy, client uses public URI, request is routed behind the scenes by API-X using information from SD&B registry)
      • Binding of services: how would service interact with API-X:  they register themselves (types they operate on)
      • Should be distributed (across multiple machines)
    • Ruth:  To ensure that crawlers can understand these services and know how to invoke.  Should be understandable and machine actionable.
      • Is the API of the SD&B, or the APIs they are describing?  Both?  Probably both
      • To what extent does API-X need to know how to invoke a service, or reason about descriptions?
    • Selecting services by nominal type vs description
      • If you want to factor behaviour, it becomes difficult
      • Types for objects in Fedora 3 were quite specific/narrow, rich description would be to avoid that scenario
      • Where do you want to do your inferencing: Pre-calculated, in API-X, or make the client do it?
      • Give discovery service a notion of an ontology (e.g. as SSWAP).  Do it in a way so that you don't have to.
      • Less naming things, more "what they do"
      • Dan:  What I saw in SSWAP is a framework for doing a model for lower-level information for service binding.
        • If we start with a bean registry, then we have no growth
      • Ruth: Similar questions in ESip being asked right now as well, but fedora doesn't really have a presence there at the moment.
    • API-X Service discovery & Binding may be an opportunity to correct what Fedora3 dissemination got wrong
      • Aaron B: No high-level requirements explicitly suggest description-based binding.  Maybe describe the problem and pass by Stakeholders?
        • May lead to additional high-level requirement, don't want to miss opportunity
        • Action item:  A. Soroka to add use cases where this is necessary
        • Action item: Ruth Duerr has a use case requiring description-based biding, will add it as wel

 

Some interesting post-meeting discussion also followed on IRC (see conversation after 15:12) : http://irclogs.fcrepo.org/2016-01-22.html

 

 

Next call

Friday, Feb 5

 

 

 

 

 

  • No labels

2 Comments

  1. Stefano Cossu

    Updated architecture graph:

  2. Stefano Cossu

    These are all very interesting topics, but I would like to make some time to go further with the implementation plan for the proofs of concept as we discussed in previous meetings.

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.