Process View. Another useful view to describe the architecture is a process view, which describes the communication between the various components within the platform. In this view the actual implementation of the platform is described and the two main types of communication within the platform are highlighted: synchronous communication through REST and asynchronous communication through Messaging. The MSA design that we have chosen uses (as outlined above) two components that deal with communication within the platform: the orchestrator for synchronous communication and the message broker for asynchronous communication. The choice of a hybrid solution, in which both types of communication coexist, satisfies all the needs and requirements identified so far. Let's now analyze the benefits of this choice, describing in detail the two types of communication and how processes communicate with each other within the architecture: Synchronous Communication - Orchestration Orchestration is the traditional way of handling interactions between different services in Service- Oriented Architecture (SOA). With orchestration, there is typically one component that acts as the “orchestrator” of the overall service interactions. This typically follows a request/response type pattern. In the CPN platform the orchestrator will be implemented as a microservice that will be responsible for managing the API Orchestration, decoupling this functionality from the API Gateway. API orchestration services are a special type of light services that take an API call, split it in into multiple API calls, aggregate the result of each of these calls and return back the aggregation as the result of the original request. API orchestration allows to simplify the client API, improves performance and security. There are different ways to implement an orchestrator, e.g. Netflix Conductor13 use task and workflow definitions to manage the orchestration. 13 xxxxx://xxxxxx.xxx/netflix-techblog/netflix-conductor-a-microservices-orchestrator-2e8d4771bf40 Figure 10: Synchronous Communication - Orchestration Asynchronous Communication - Messaging While some of the microservices are conceived to be consumed in synchronous use cases, e.g., deliver data to final consumers, real-time recommendations and so on, some others are essentially thought to be processing components that will operate in background executing tasks such as gathering information, semantically enriching the existing data, building Machine Learning mod...
Process View. A remote use case is started as a training use-case, or typically when an operator identifies a machine breakdown (see Figure 5-12). When this happens, the operator can use smart glasses (or other mobile devices) and can start the Oculavis SHARE app. On the other side, the supplier helpdesk will help to analyse and solve the failure. Results and documents will be stored in a case that serves like a ticketing system. After the end of the call, the relevant maintenance knowledge can be shared with participants of the case.
Process View. The ESB mediates messages through provision of communication endpoints, routes information and supports multiple transport protocols and transformation abilities. In Figure 8, the activity diagram of the message handling process is presented. In the initial step, the message is received and is directed to the message router. A routing service will forward to the right output destination of the message, whilst a translation processor will undertake the task of converting among the different data models and data formats supported by the sender/receiver of the message, and in many occasions to standardized data formats. Figure 8 Message flow activity diagram (a) and process diagram (b) sd Orchestration Flow ESB SCADA DAP EF PFS CEF GOS m S o Moreover, the ESB has the role of the orchestrator of business processes, handling the routing of a message through a set of services to produce the desired result. Orchestrating of such operations means that when a client of a service (e.g. the operator of an application or an internal time-trigger of an application) triggers the business process, the ESB is responsible for delivering the end-result. The ESB must invoke the right services and provide the result to the original requestor. Figure 9 presents the sequence diagram of the main flow of an application orchestration process. Grid data request() Grid Configuration, PED Status() Weather forecast requ est() ption and Generation dat a) data(energy)) on data (voltage)) Weather forecast() SM data request(Weather f orecast) SM Measurements () Forecast Request(Weather forecast, Gri d configuration, Consu Consumption & Generation Forecast() Power Flow Simulation Request(G rid configuration, Con sumption and Generation Power flow simulati ons() [If application is CEPA]:Forecast Reques t(Power flow simulatio ns, grid configuration, con sumption and generati Criti cal events() Optimal chedule Request(Gen eration and Demand Forec ast, PED Status, Grid C nfiguration) Grid schedule() Grid schedule() Figure 9 Sequence diagram of orchestration Business Process Business Process View Trigger Event Invoke Service Result Received «flow» «flow» Filter Message Invoke business Incoming Message service Result Received «flow» «flow» Request Service1 Request Service2 Service Requests Service Request Result Request ServiceN MOM Service Requestor In Figure 10, an execution flow of the BPE is instantiated (using BPMN notation), depicting how the external requestor triggers a process, how the ...
