arrowhead-logo

Orchestration

System Design Description Overview

The Orchestrator provides runtime (late) binding between Application Systems.

The primary purpose for the Orchestrator System is to provide Application Systems with orchestration information: where they need to connect to. The outcome of the “Orchestration Service” include rules that will tell the Application System what Service provider System(s) it should connect to and how (acting as a Service Consumer). Such orchestration rules include:

  • Accessibility information details of a Service provider (e.g network address and port),
  • Details of the Service instance within the provider System (e.g. base URL, IDD specification and other metadata),
  • Authorization-related information (e.g. access token and signature),
  • Additional information that is necessary for establishing connection.

This orchestration rule information can reach the given Application System (consumer) in two different ways: the System itself can request it (“pull”) or the Orchestrator itself can update the System when it is needed (“push method”). However, in both cases, there shall be an underlying, hidden process (“orchestration process”), which ensures the consistence of state between the various Core Systems.

In G4.0, only the pull method is implemented and the Orchestrator shall negotiate with the other Core Systems while trying to facilitate the new service request (or trying to push a new status). This is necessary for the following cases and requirements (basically, when ad hoc, unsupervised connections are not allowed):

  • When accountability is required for all Systems in the Local Cloud: connections cannot be established without the knowledge, approval and logged orchestration events of the Core Systems (“central governance”).
  • QoS and resource management reasons: ad hoc peer-to-peer connections cannot be allowed in certain managed networks and deployment scenarios. Every connection attempt shall be properly authorized and its QoS expectations (resource reservations) handled.
  • Inter-Cloud orchestration can only happen via negotiations between the two Core System sets. Ad hoc inter-cloud connections shall not be allowed in the Arrowhead framework.

In these cases, when the Orchestrator is the sole entry point to establishing new connections within the Local Cloud, Application Systems do not have the possibility to skip any of the control loops with all the appropriate Core Systems. When such security and safety concerns are not present, the orchestration process might be cut back or these interactions between Core Systems might be limited. Within G4.0, this is not the primary use case, but it is allowed. With the proper self-implemented (modified) and a self-compiled Orchestrator can fit the deployment best.

Therefore, the Orchestrator provides two core Services and may consume many other ones, but at least two — again, depending on its deployment. This figure depicts the mandatory and optional interfaces of this System.

In here, the provided Services are:

  • Orchestration Service
  • OrchestrationStoreManagement Service

Meanwhile the consumed Services can vary, depending on the instantiation/installation of this System. For example, the Orchestrator can utilize the services of:

  • ServiceDiscovery Service from the ServiceRegistry,
  • AuthorizationControl Service from the Authorization System,
  • TokenGeneration Service from the Authorization System,
  • GlobalServiceDiscovery from the Gatekeeper,
  • Inter-CloudNegotiations from the Gatekeeper,
  • QoSVerify from the QoS Manager,
  • QoSReserve from the QoS Manager,
  • Logging services from other supporting Systems, e.g. Historian,
  • and any other service from Core Systems that are necessary to settle during orchestration.

The Orchestrator mainly consumes services from other Core Systems in order to fulfil its primary functionality: provide connection targets for Application Systems in a secure and resource managed manner — hence build an SoS.

During this orchestration process the Orchestrator either facilitates a service request from an Application System or processes a system-of-systems (SoS) level choreography push from the Plant Description Engine (“Choreographer”). For the latter case, the Orchestrator System consumes the OrchestrationPush from affected Application Systems in order to deliver a renewed set of connection rules to them.

Within the Orchestrator, there is a database which captures design time bindings between Application Systems, the Orchestration Store. Operators of the Cloud and other System-of-Systems designer tools (“SoS Choreographers”) are allowed to modify the rules stored in the Orchestration Store, other generic Application Systems are not.

The ServiceDiscovery Service is used to publish the Orchestration Service in the Service Registry. This Service is also used to query the Service Registry and fetch (metadata) information on other Application Systems.

The Services of the Authorization System can be used to verify access control and implement other security-related administration tasks.

The Services of the Gatekeeper can be utilized when inter-Cloud collaboration, servicing is required.

The Services of the QoS management System can be used to manage device, network and service-level Quality of Service agreements and configurations.

Orchestrator can be used in two ways. The first one uses predefined rules (coming from the Orchestrator Store DB) to find the appropriate providers for the consumer. The second option is the dynamic orchestration in which case the core service searches the whole local cloud (and maybe some other clouds) to find matching providers.

Store Orchestration:

  • requester system is mandatory,
  • requested service and all the other parameters are optional,
  • if requested service is not specified, then this service returns the top priority local provider of all services contained by the orchestrator store database for the requester system. if requested service is specified, then you have to define the service definition and exactly one interface (all other service requirements are optional). In this case, it returns all accessible providers from the orchestrator store database that provides the specified service via the specified interface to the specified consumer.

Dynamic Orchestration:

  • requester system is mandatory,
  • requested service is mandatory, but just the service definition part, all other parameters of the requested service are optional,
  • all other parameters are optional

Orchestration flags:

  • matchmaking: the service automatically selects exactly one provider from the appropriate providers (if any),
  • metadataSearch: query in the Service Registry uses metadata filtering,
  • onlyPreferred: the service filters the results with the specified provider list,
  • pingProviders: the service checks whether the returning providers are online and remove the unaccessible ones from the results,
  • overrideStore: Services uses dynamic orchestration if this flag is true, otherwise it uses the orchestration store,
  • enableInterCloud: the service can search another clouds for providers if none of the local cloud providers match the requirements,
  • triggerInterCloud: the service skipped the search in the local cloud and tries to find providers in other clouds instead.

Services and Use Cases

Endpoints

Latest documentation