Requirements and functionalities of Computing API

The Computing Services API is being thought of as a two steps process: discovery and access.

  Discovery:  A client (that could be the computing module of one particular SRCNet node) needs to discover the different computing APIs of other nodes in order to be able to invoke them.
  To perform the discovery 3 ingredients are needed:
  * to have information on authentication and authorization: the
client needs to know if authentication is required and, if so, if it
can access  a specific resource and where (i.e. identity provider and authorization service) to obtain access credentials. [Not included in this ticket]
  * to obtain information
   ** on the computing service hardware profile (resources available, the computing architecture of the node, etc)
   ** about the signature of how to invoke this API (that could be related to ports, IPs, etc).
  * each computing node should include the capability to answer an execution planner query. For example, an interface to respond to the question "Could you execute this workflow?" by providing
  * a "yes/no" response, in a simplified case or
  * metadata of possible latency on data movement, resources required or providing platform topology information of the node, etc) so the best execution node could be invoked.
  The chosen solution has important implication: in the first case, the complexity is in charge of a service deployed server side, in the computing center, able to "understand" if a given workflow can be run.
It implies also a clear common/standardized description of the
workflow. In the second case, the complexity is client side and the client must receive a clear common/standardized description of the of the computing resource. The two situations should be explored here.

  Access: Once the information on the available Computing Services APIs is obtained, the capability to invoke a remote execution should be enabled in this step.

  Objectives of this feature:

    Presentation and discussion of the outcomes of the document produced in SP-3551 with interested parties, socializing with other relevant EPICs, Teams (in particular Magenta) and interested Stakeholders.
    Discussion a of the possible solutions and identification of the
most convenient one.
    Identification of one or two use cases with a minimal set of
functionalities for the design of a first version of the discovery and access APIs addressing :

•   the identification of a minimum set of functionalities according to the above discussion
•   the characteristics of an execution interface for discovery and access
•   the parameters/metadata for execution and discovery
•   the metadata/parameters response from the discovery and execution