What are the core principles of Orchestra?

[JoanPuig]

I think that at the core of many disagreements during the calls on the design of new features is a lack of shared vision of what Orchestra should be. Things like what use cases it is trying to satisfy, what player types are meant to use it, etc. Also we should document technical boundaries we don't want to cross, decisions made in the past that newcomers such as myself are not aware of, etc. And finally we should recognize that we are not operating in vacuum and there are other alternatives such as OpenAPI, AsyncAPI, GraphQL, TypeSpec, we should document how Orchestra is meant to be different, what benefits is it meant to provide to which type of use case.

I would like to open up this discussion to document the shared understanding, and eventually turn it into a document that sits besides the spec and helps us guide future development.

[jimnup]

And as part of this discussion - I would not see an issue with two separate levels - one a repository management layer for tool vendors or bespoke developers doing more complex repository management and the runtime orchestra specification mean to create a contract between two machine entities - the original use of Orchestra.

But agreeing on the set of use cases and the intention of Orchestra is an important step in this process as Joan states quite well.

[kleihan]

I went back to some early slide sets (starting in 2017) to find objectives and use cases (no particular order, just collecting, will be extended as I find more material):

• Support electronic interfaces that exchange messages, fields and values
• Agnostic to business area, but focus on financial services
• Support application layer, session layer, and transport
• Support FIX and non-FIX protocols, including customizations of standard protocols
• Support external and internal interfaces
• Agnostic to encoding and transport
• Mapping to major encodings developed by the FIX Trading Community (tag=value, FIXML, SBE)
• Extensibility to support arbitrary encodings
• Must not require changes to the wire format, e.g. tag=value
• Machine-readable, but also human-readable, not intended for manual editing
• Span the entire DevOps life cycle (development, testing, QA, onboarding, certification, provisioning, operations)
• Not a product, but FIX Trading Community may provide tools as free or open-source implementations
• Workflows between counterparties
• Conditional presence of elements in a message
• State machine
• Version control, audit trail of changes
• Provenance (Dublin Core Terms)
• Bilateral agreement between counterparties in terms of features used
• Support generation of configuration, code, test cases, sample messages, documentation