Architecture
#Architecture ORDS consists of a core that contains internal components. To this core external modules can be developed. Both the core and modules is maintained by the ORDS staff and the community while the community is encouraged to create modules and the staff of ORDS will focus on maintaining the core. ORDS has no clear limits to how many modules, and thereby functionalities that can be supported, which makes it ideal for anything from small confined, to large-scale complex telemedicine solutions.
The architecture is loosely coupled with the modules as they depended on the core instead of the other way around. Modules use of the DependencyInjectionComponent to gain instances of core components and thereby interact adapt, extend core functionalites. This principle (called dependency inversion) make sure that ORDS will continue to be extendable and adaptable to the specific telemedicine use case. The modules a developer create and the core itself is published on npm since the platform is quite popular and have many important functionalities (version control, dependency control etc.). The following illustration shows ORDS and the surrounding environment.
In this illustration two modules are given: authorisation and authentication (auth), and database connection (dbcon). These functionalities the modules give, would normally be included in a core system. This is done in modules since it allows for use of any database technology that a developer might wish for and any authentication and or authorisation technology. ORDS has two components DatabaseComponent and AuthComponent that help support these type of modules.
ORDS is illustrated in a setup in the following figure. Since the HTTP protocol on a REST API, as specified by HL7 FHIR, is used, ORDS is client-independent, where any client supporting HTTP can be used.
In the the illustration two components are used RoutingComponent and DatabaseComponent. Illustration shows a Request is send by a client and a Response is send back and ORDS communicate with a database via the DatabaseComponent. The parts of the illustration are colour coded to illustrate to what component they belong.
ORDS consist of some software components. Each of the components consists of a component named after the respective directory they are located in and their purpose. All components have their own wiki page and on that page. An illustration about the content of a component is made here:
SomeComponent is the component itself and SomeModels are models used internally in the component. These models are not to be understood as database models but rather the model of for example the content of a request to ORDS. The last part SomeMiddleware is used as described by the express framework. Middleware is basically just functions that run between the input of an interaction and output, making it possible to change the outcome of an interaction completely. SomeMiddleware holds references to middleware run by SomeComponent and can be used to add aditional middleware or delete eksisting. In each of the components wiki pages it is described what interactions that support middleware. The parameters given to each middleware is explained under the RoutingComponent.
The main class Application is exposed and is not a component. This main class is what is to be used to start ORDS via an instanciation of it. ORDS can be configured for minor adaptations of ORDS. ORDS has complete support for horizontal and vertical scaling since it uses the cluster library from Node.js in the Application class. This means that once an instance of the Application class is made, a process will be created on each cpu of the server that ORDS is implemented on and thereby scale with hardware.
If you haven’t read about the Dependency injection now do so. It will help you understand how modules can be created and class instances are managed in ORDS. Otherwise go and read about the RoutingComponent that further describes the flow from a request to ORDS to a response send back.