Evaluate the use of serverless workflow in travel

[swaldron58]

Background, see document .
A major issue for travel API such as booking workflows are the inconsistencies. Within sectors like hospitality and across sectors as well. Distributors and channels often hard code the workflow for each hotel chain or airline (rail ,,,,) and in some case for hotels down to the property level (PMS). We need a way to either dynamically discover the workflow or as part the API documentation the API provider sends it.
A later effort if the approach referenced is accepted, to update the DEx tooling to allow definition of the workflow as a facet and the complier create the artifacts as needed.

[slivezey]

While I agree that the orchestration of API calls is a big problem, I am not sure this technology is mature enough to consider integrating with the OTM and DEx tooling. The first big reason for this is that it would be significant effort, very similar to when we added REST API definitions. In addition to the coding that would be required, there would also be a significant design effort to address issues like versioning which can get very complicated. Additionally, the Serverless Workflow Specification and tool suite appears to be fairly early in its development. This means we would expect a significant amount of change as the technology and standards mature over the next few years.

It is also unclear to me how much adoption this is getting across the technology industry. I have not taken the time to research possible competing standards, but we would need to do that before investing in any DEx development. I would not want to make such a big investment of time and effort just to find out that a competing standard is gaining more traction in the industry.

Rather than trying to incorporate this technology into the OTM modeling technology, I would recommend evaluating some of the SDKs and developer tools available in the Serverless Workflow GitHub organization. It might be easier just to use their tooling to develop workflow models that orchestrate the OpenAPI specs that are generated from the OTM tooling today.