La reformulación de las categorías del daño a la persona

Originally, the term “orchestration” refers to a design pattern that is dedicated to the effective maintenance and execution of business process logic [26]. Peltz [130], [131] describes

service orchestrationas a centralised executable business process that can interact with web services at the message level. Barker and van Hemert [102] provide a similar definition of service orchestration. However, existing definitions are inaccurate and do not capture the true meaning of service orchestration. Therefore, this thesis provides its own definition of service orchestration as follows:

“Service orchestration is an approach for the enactment, and management of a service-oriented workflow that involves the coordination of control, and data messages across distributed web services based on a precise high-level specifi- cation of service interactions.”

Service orchestration is typically carried out using a workflow management system. Existing workflow management systems provide their own development environments, and tools for managing the execution of the workflow [121]. The architectural design of these management systems affects the manner in which services are orchestrated. The remainder of this section provides a description of service orchestration system architectures which include centralised and decentralised service orchestration system architectures.

2.4.1

Centralised Service Orchestration System Architectures

Centralised service orchestration refers to an approach for the execution and management of a workflow using a centralised system architecture [132]. There are two kinds of centralised service orchestration system architectures which include:

1. Completely centralised service orchestration system architectures.

2.4 Service Orchestration 51

The remainder of this section describes these architectures, their components and the interactions between them, and highlights the advantages and disadvantages of each archi- tecture.

Completely Centralised Service Orchestration System Architecture

This approach relies on a single compute server (e.g. workflow engine) which is responsible

for coordinating control and data flows amongst the services. This engine providescomplete

controlover the workflow, supports process automation, and encapsulates the overall work- flow logic [26]. This is useful because all the information about the workflow, its tasks and relevant data are persistent and resident at the server that hosts the engine. The engine provides capabilities to interpret a given workflow specification, invoke a set of services, collect the invocation results, and forward these results to other services as necessary. Us- ing a centralised engine, however, is not considered a scalable approach as discussed in Section 1.1. This is because all data and control messages are routed through a single point of coordination which risks in causing the engine to become a performance bottleneck. The advantages and disadvantages of this architecture are identified as follows:

• Advantages: This architecture permits the workflow logic, and all system status in- formation to be maintained at a single location which is useful for monitoring the progress of the workflow execution.

• Disadvantages: This architecture makes it difficult to change the workflow struc- ture, and employ performance optimisation techniques. The centralised engine also presents a single point of failure (e.g. potential performance bottleneck) in the work- flow.

Hierarchical Service Orchestration System Architecture

Centralised orchestration can be partial when it is based on a system architecture that em- ploys centralised control, and distributed data transport mechanisms to execute a workflow.

52 Literature Review

the overall workflow. Each workerexecutes part of the workflow on behalf of the engine

by invoking a particular group of services, and collecting the invocation results. Typically, the engine initiates the execution of the workers and receives notification messages from the workers regarding the execution progress of the workflow. For example, a worker can transmit a notification message to the centralised engine which indicates that the worker has completed the execution of a particular set of workflow tasks. Based on the contents of these notification messages, the centralised workflow engine may choose to change the behaviour of the workers. For example, the engine may instruct the workers to forward the results of the executed workflow tasks to particular locations, or execute a new set of workflow tasks based on these results. Multiple workers can collaborate with each other by transferring data directly to locations where they are required, or exchanging references to the data that permit workers to obtain the data from particular network locations when necessary. How- ever, the failure of the central engine will result in entire system failure. The advantages and disadvantages of this architecture are identified as follows:

• Advantages: This architecture permits system status information to be obtained from low-level workers, and maintained at a centralised location (e.g. workflow engine). The centralised engine is only responsible for controlling the behaviour of the workers instead of executing the overall workflow logic. This reduces the amount of data to be passed through the engine. Low-level workers have some degree of autonomy, and can collaborate with each other directly.

• Disadvantages: Control messages between the engine and the low-level workers (e.g. inter-level communication) may increase and influence the performance of the work- ers. Low-level workers have limited capabilities to execute the workflow tasks. It is also difficult to employ optimisation techniques to adapt to changes in the execution environment. The centralised engine presents a single point of failure (e.g. the failure of the engine can interrupt the execution of the workers and halt the overall workflow execution).

2.4 Service Orchestration 53

2.4.2

Decentralised Service Orchestration System Architecture

Decentralised orchestration system architectures consist of multiple engines that may col- laborate with each other without the need for a centralised coordination entity. Each engine plays an equal role in the workflow by executing part of it, and may transfer data directly to remote engines that require the data to execute other workflow parts. Unlike centralised and hierarchical service orchestration system architectures, there is no single entity that con- trols the workflow execution. Decentralised orchestration architectures must guarantee that a sufficient number engines provide the required capabilities that can be provided by a cen- tralised engine. Typically, decentralised orchestration typically employs self-management techniques that determine how to establish communication between engines, and how com- munication messages are routed across them. However, decentralised orchestration presents a set of research challenges which were described earlier in Section 1.2.2. The advantages and disadvantages of this architecture are identified as follows:

• Advantages: There is no single point of coordination that may become a performance bottleneck in this architecture as it relies on multiple collaborative engines. Each en- gine controls its own behaviour (e.g. local autonomy). Each engine is also identical in design and implementation (e.g provides the same capabilities). This architecture supports optimisation techniques for adapting to changes in the execution environ- ment.

• Disadvantages: In this architecture, it is typically difficult to change the workflow structure as its logic is distributed across different engines. There is no standard pro- tocol that describes the manner in which engines collaborate with each other. The engines may operate in an execution environment that may be unstable, and may be running on unreliable hosting machines. It is difficult to implement failure handling mechanisms due to lack of a centralised coordinator, and it is also difficult to distin- guish between different types of failures (e.g. engine failure, broken communication link between two engines) during the workflow execution.

54 Literature Review