Date: Friday January 22, 2pm EST (-5 UTC)
- Dial-in Number: (712) 775-7035
- IRC:
Meeting Goals
- Develop a program for engagement with SSWAP
- Move forward on our understanding of service binding
Attendees
Agenda
- Discuss Stefano Cossu's high-level architecture diagram (ran out of time last week)
- Discuss Unknown User (acoburn)'s proof of concept for Service Discovery and Binding
- Discuss SSWAP and its potential utility to API-X.
- http://sourceforge.net/p/sswap/wiki/publications/
- 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
Their main paper:
- 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