fixtradingcommunity / fix-orchestra-api Goto Github PK

So far, no security model has been implemented for Orchestra API. Aside from user authentication, it would be useful to implement an authorization model. Desirable features:

• Users with read-only access allowed to query but not perform creation (POST) or update (PUT) operations versus users with full access.
• Users with access to specific Orchestra repositories only.

So far, the REST API covers message structures and workflow. It may also be useful to wrap a REST API around the Orchestra Interfaces schema. Included features of that schema are:

• Service offerings (application layer)
• Protocol stack (presentation, session, transport)
• Session definitions: identifiers, transport settings such as host:port

With appropriate security, this would allow users to query interfaces in a standard and use the information to configure their system.

Currently the server holds Orchestra repositories in memory as XML DOM. It would be advantageous for the server to persist Orchestra files in a directory and read it Orchestra files and load them into memory on demand.

It would be desirable for the server to assign unique IDs to new elements to relieve users of the burden of avoiding ID collisions. For example, when a new field is added, the server could assign it the next free tag number in a series. Also, it could assign a unique object ID to new elements as a UUID or URI (under a given base path).

The REST API currently has a data structure for element pedigree that is consistent with the Orchestra XML Schema. However, does not yet have operations to maintain pedigree based element creation, deletion, or update. It would be desirable for the server to maintain pedigree as changes are made through the API.

The initial implementation of the Swagger specification of Orchestra API is being created manually by translating the data structures in the Orchestra XML Schema. If changes are made to Orchestra in the future, the XML, REST API and other representations could get out of sync, however. It would good to generate the Swagger API spec and others from a common model, probably UML.