We recognized several key issues in the current Airavata API design.
- Issues for Gateway Developers
- Too many functions confuses the gateway developer.
- Gateway developers are exposed to unwanted and potentially unsecure
functions.
- Issues for Airavata Developers
- Name "API" is wrong in this context
- Less freedom in naming and introducing functions/parameters/models
supporting gateway developer context and terminology.
- Currently the airavata client, the API interfaces and the the
implementation of the API is merged in a single deployment. This doesn't
represent the accurate way to expose or use an API.
Following is the simple design we thought so far to solve the issues,
1. Define an integration layer which exposes the useful functionalities
of the components present in Airavata. (This may be just a logical
integration layer to bring everything to a common layer which every
component is aware of)
2. Use related functions in the integration layer to design and
implement a "Simple" Airavata API for gateway developers.
3. Use related functions in the integration layer to design and
implement an "Advance" Airavata API for gateway developers.
4. Use related functions in the integration layer to design and
implement a Server Controller Interface (where functions will have a
workflow context) for internal Airavata developers.
We are still in the process of figuring out if this is the best approach or
not.
Any thoughts are welcome.
Thank you,
Saminda
