...
What is the input to Parser ?
- Usually a CSAR Archive File
...
- Observation : The tool should be able to resolve the whole import tree i.e. resolve all dependencies.
What is the expected output / response of this "Parser As A Service" function ?
- For the consumer of the "Parser As Service" function, the first response is a simple - Yes (Valid Call) or No (In-Valid Call)
- If the response is "Yes" move to next step in "Parser As A Service" Call, if Not, Send back an exception / error code
- If answer is No, list down all possible exceptions (error codes) that can be sent back to the requestor with some additional text for the receiver to take corrective action and re-trigger the "Parser As A Service" call
- As Part of R2 PoC, trial / design activity, define all exceptions from all parsers and standardize on the API specifications for call, exceptions, request - response etc...
- If the response of the "Parser As A Service" function is Yes Valid Request, the next stage is an Output TOSCA Object Model, (there is a need to standardize both inputs and output representations here) Observation : If the transactions / interactions are REST representable, and are stateless, that means that every transaction should have every possible information on there, which may not be practical (how to overcome that)
Requirements Gap / Observations from UUI javatoscachecker implementation in R1
Most TOSCA users separate schema (type definitions) and templates. For one schema the users have a large(r) set of templates to validate. The users do not want to submit the schema every time (or re-assemmble a csar every time) so
we had to provide a stateful api.
Solution in the checker:
- The user creates an application 'space' to which the server associates all type definitions. Because of the imports structure the API allows a client to submit 'named' documents (the processor's output will become part of the state and the
document can be referenced) and 'anonymous' documents (the output is reported back to the client but does not become part of the state)
- Extensions: some clients have extensions to the standard which require a new grammar and optionally additional coherence checks. The service needs to account for all this variations. This is also true for different versions of the spec.
- The output of this service will be (in most cases) processed by some piece of software. While the REST API might not changed the set of errors and backwards compatibilty of the response representation are an issue as the underlying
processing evolves.
Action Points for Next Call : On 22nd January 2018
- Atul to consolidate requirements, suggest a tentative plan of action for R2 and R3 on "Parser As A Service" Project
- Create a Proposed Architecture Deck for Modelling Sub-Committee Presentation on 23rd January 2018
- Secure an Agreement for Proposed Plan
- Agree / Propose Set of Details Architecture / Design Artefacts Required for R2 & R3
- Agree with TSC / Line Up Calls with various PTLs on "Parser As A Service" concept and agree a buy in for implementation