For Fujitsu, computational science research is one of the cornerstones of a successful IT service provider. Whether it is the development of quantum computers, new solutions for more sustainable and effective mobility, energy-saving HPC systems or the Digital Factory – alone and with international partners, Fujitsu always aims to create positive added value for society, the environment, and its customers. This is why Fujitsu regularly participates in European, more research-oriented tenders and projects with a wide range of partners.

As part of the FaaS paradigm that applies to the “PHYSICS” platform, Fujitsu has set itself the goal of contributing various optimization functions. The term optimization can be understood to cover a wide range of activities or functions: an optimized process, the provision of specific data to be able to make (optimized) decisions more quickly, the optimal use of time or the optimized packaging of content in a package. From a mathematical point of view, the latter is a real optimization problem, more precisely a problem from the field of combinatorial optimization. Combinatorial optimization problems include sequencing, assignment, grouping and selection problems. These include, for example, the traveling salesman problem, the Knapsack problem, graph similarity, portfolio optimization, (scheduling) planning, (task) assignment, software validation, AI model optimization and many others. Behind these somewhat stubborn names are everyday problems from logistics, the packaging industry, the manufacturing industry, shift planning and many others. What all these problems have in common is that there is not just one solution to them, but that there may well be many qualitatively different solutions. Furthermore, there is no known algorithm that can simply calculate these problems directly. Finding a good or the best solution in large problem spaces therefore requires an enormous amount of computing capacity and time.

As part of the “PHYSICS” project, Fujitsu has developed various optimization patterns that benefit from the performance of the quantum-inspired technology “Digital Annealer“. The Digital Annealer can solve combinatorial optimization problems particularly quickly and with particularly good results. To do this, it uses several ideas from annealing and quantum computing to solve the problems described above particularly well and quickly. But first, the problem in question is converted into a specific mathematical model, which the digital annealer can then solve. The highlight: if quantum computers are one day able to solve similarly large problems, the mathematical model already developed can simply be transferred to them and solved. The technology therefore not only provides a relevant advantage in business today, but also prepares the company in the best possible way for the age of quantum computers.

The physics project now provides two patterns for optimization problems and their solution with the help of the Digital Annealer in Node-Red. These processes can be transferred to the runtime environment with just a single click. To simplify the use of the Digital Annealer and its integration into the Node-Red ecosystem, we have implemented various backbone classes that enable the use of the Digital Annealer and the processing of optimization problems within Node-Red.

In this context, JavaScript classes were implemented that make it possible to formulate an optimization problem as a Quadratic Unconstrained Binary Optimization (QUBO) problem that can be solved on the Digital Annealer. For this purpose, various classes have been implemented that support different operating modes of the Digital Annealer. Currently, the Digital Annealer has two operating modes for solving a QUBO problem, each offering different functionalities. In addition, classes are also provided to facilitate the interpretation and presentation of the results returned by the Digital Annealer. These classes are integrated into the Node Red ecosystem and are readily available as Node Red workflow blocks. Users have the option to use both the Backbone JavaScript classes and the Node Red blocks according to their own requirements and preferences.

To demonstrate the use of the provided JavaScript classes and workflow blocks, two solution patterns are provided in Node-Red: “Two Persons Assignment” (TPA) and the “Traveling Salesman Problem” (TSP). In the classic “Two Persons Assignment Problem”, a set of items representing tasks or projects must be assigned to two persons or machines in such a way that the difference in the workload or items assigned to the two is minimized. The TSP, on the other hand, asks the following question: “What is the shortest possible route that visits each city exactly once and then returns to the starting city?”, given a list of cities and their coordinates. The TSP is an NP-hard combinatorial optimization problem that plays an important role in theoretical computer science and operations research. The enormous power of the Digital Annealer can be used by Node-Red to solve the above-mentioned problems. If you want to implement further patterns, we would also like to recommend our Digital Annealer Tutorial. However, we know that solving a specific optimization problem on quantum or quantum-inspired hardware requires a QUBO formulation, which can be a very complex task. In this regard, the Fujitsu Digital Annealer team will be happy to assist you in formulating your problem and solving it through Digital Annealer.

The post The Digital Annealer in practice: Optimizer Pattern integration. appeared first on PHYSICS.

The DFKI is currently using the PHYSICS platform to improve the reliability of a production plant prototype for selected scenarios (see Blogpost: Industrial Use Cases of FaaS: The basics you need to know).

Besides the evaluation of the technical feasibility of the PHYSICS platform, the DFKI participated in the event “Innovationstag 2022” of the “Technology Initiative SmartFactory-KL e.V” to evaluate professional opinions regarding the smart manufacturing use case.

The SmartFactory-KL has nearly 50 different industrial and research partners it its partner network where the DFKI is part of.

The possibility to present the project PHYSICS at this event which takes place once a year was very successful. Presenting the idea behind the PHYSICS platform, the status of the smart manufacturing use case and its scenarios delivered important feedback.

Looking through the glasses of other industrial users who visited the PHYSICS event-station (5 groups with each 5-10 people) many conceptual questions and suggestions arose.
Visitors and participants gave different inspirations:

• For example, the prospect of managing and deploying functions with a single mouse click was eagerly awaited. Managing complex systems with many interlocking cogs should be very easy.
• Software and hardware technologies should be used holistically. This means that digital processes such as fault tolerance using cloud technologies should be one building block of many. Therefore, a simple way to identify and keep track of where “low-tech” solutions and actions and the “high-tech” counterpart are or should be deployed would be helpful. For example, a failover scenario should also consider hard real-time processes or good software design, hardware design and operating system design.
• In addition, many participants would welcome the option of deploying functions on self-hosted or alternative cloud instances, rather than using the current cloud market leaders. Independence and individual configurability have a high priority.

The post DFKI participation in the event “Innovationstag 2022” of the “Technology Initiative SmartFactory-KL e.V” appeared first on PHYSICS.

It is commonly known that Serverless Computing has emerged as an agile environment of alternate execution while having many inherent scaling capabilities. The Function as a Service [1] approach, aims to apply the serverless scope also in the way application logic is created, embedded and executed. Currently though, the size of FaaS applications is rather small, indicating that approximately 82% of them have only up to 5 functions in the workflow [2], while at the same time native orchestration mechanisms of FaaS toolkits typically present significant limitations.

PHYSICS platform doesn’t only utilize Node-Red visual-flow tool for its orchestration needs but also OpenWhisk’s ( open-source FaaS platform ) built-in sequence operator. This gave us the trigger to investigate and measure the performance overheads that derive from each orchestration strategy of PHYSICS platform but also to calculate the percentage of useful computational time for each scenario. We created 3 different cases (modes) that apply to PHYSICS’s needs for orchestration:

Mode1: The first observed mode is the Sequence Operator for OpenWhisk runtime functions, meaning both executions and orchestrations of function-sequences we created are located on OpenWhisk exclusively.

Mode2: The second observed mode is a variation of the first, where this time function workflow is created in Node-RED and deployed within a custom Docker function image. The executions as well as the orchestration, are handled by Node-RED, while all functions execute and reside in the same container.

Mode3: The third and finally observed mode derives from the parallelization needs of PHYSICS platform. In this scenario Orchestration flow that is inside Node-RED invokes functions deployed on the OpenWhisk environment, which consequently means the flow acts as a generic orchestrator while the external containers are the main execution environment.

As for the experiment itself:

• We created the artificial delay functions a priori, already knowing their delay, which was 1000ms. Those Functions created sequences with range varying from 1-25 with a step of 5.

• We used warm containers to avoid cold start latency

• One client request was active per time

• Actions were exposed as web actions

• Each measurement was performed with 40 repetitions

The measured time was the inter-function communication delay or orchestration delay, which is the pure baseline delay from a hop of one function to the next in the sequence.

• For OW-OW we can use the average overhead time per function, given that this is independent of the number of functions used
• For NR-NR and OW-NR the initialization time significantly affects the average produced, as the number of functions grows

In order to be more precise we created a mathematical model to describe each mode, with GNU Octave’s Ordinary Least Squares function. The functions that derived from that analysis are the following:

As a next step, we created parametrized plots that arise from the previous mathematical equations, for different function sequences and inner function delays, in order to observe how the estimated total execution differs for different function numbers and delays.

The 40 functions is considerably high in cold start case, though NR-NR in warm executions is always better

• The NR-NR mode presents the greatest benefits, having under 10% from as low as 10 functions in the sequence and even for small function delays of 100 and 200 milliseconds, with a minimum of 0.29% for 100 functions in the 1000 millisecond case

By dealing with the problem of Orchestration Overheads both theoretically and practically we concluded to the following:

1. OpenWhisk’s Orchestration Time is primarily due to warm container reuse time and this delay is unavoidable since in this mode we are not able to implement both orchestration and function logic in the execution container
   
2. The proposed Node-RED orchestration aids in minimizing the needed containers which is basically the biggest part of the delay
   
3. The third mode (hybrid) is only suitable for parallelization needs
   
4. The artificial sleep functions we created, can be replaced with more complex workflows since the baseline time is around the same
   
5. Enabling easier orchestration both functionally and performance-wise can help increase the observed number of functions

All the data and links used for the experiment can be found in the following links:

• https://physics-faas.eu/
• https://hub.docker.com/r/pekoto/noderedaction
• https://flows.nodered.org/flow/f0795ad9f25ad2affcadb8deb305fdf3/in/VOf-0UrN5e2j
• https://hub.docker.com/r/pekoto/owmode3
• https://github.com/pekoto4349/measurements

For more information, please refer to the following publication:
George Kousiouris, Chris Giannakos, Konstantinos Tserpes and Teta Stamati, 2022, Measuring Baseline Overheads in Different Orchestration Mechanisms for Large FaaS Workflows. In Companion of the 2022 ACM/SPEC International Conference on Performance Engineering, April 9–13, 2022, Bejing, China, DOI: 10.1145/3491204.3527467

The post Performance overheads arising by orchestration strategies in the PHYSICS platform appeared first on PHYSICS.

Personalized healthcare requires decision support systems that can help healthcare professionals to manage large volumes of patients. Care for chronic conditions requires doing so for patients at their everyday setting, outside the clinical environment. These needs can only be addressed with AI systems, at the core of which models trained by ML can be found. Such systems are deployed to offer diverse services, such as model inference for patient outcomes’ prediction, patient clustering into phenotypes and dataset augmentation with synthetic arms.

The traditional deployments of such systems in healthcare suffer from scaling. Deployment is a lengthy procedure, certainly aided by modern CI/CD pipelines, but the resulting systems are quite static in terms of resources, while occupying them even during quiet times.

PHYSICS facilitates the design and deployment of these services. It provides a design environment to implement and deploy the services. The starting point is an AI function implemented in Python at the core, which constitutes a node in complete Node-RED flows built around it using more (Javascript) functions and PHYSICS patterns to handle input and output.

Node-RED offers developers the means to locally test the flow, using additional nodes for user input, and invocation. Local testing is handy during the implementation phase.

Still using the design environment, locally tested flows are then deployed as functions to expose the health care services. PHYSICS annotation nodes control the deployment options at the flow level.

Thus, the flows employed for defining testing and deploying healthcare services are usually split in three sections. The endpoints definition section defines two POST endpoints, the /run with the service core, and the /init for any initialization. The manual invocation section facilitates local testing by sending a request to the /run endpoint. Finally, the annotations section controls the deployment options. The sections are shown in the flow depicted below:

The healthcare services being implemented in the PHYSICS FaaS way are:

• Predictive model inference: Load feature vectors and a predictive model into an inference engine to get inference results.
• Patient phenotyping: Load feature vectors and a set of generative models (describing patient clusters) into a system that return the model best describing each vector.
• Data synthesis: Load a set of generative models and a model transition probability matrix into a system that draws vectors from the generative models, following a model activation pattern as described by the transition probability.

Currently, the first flow is implemented, tested and deployed. It is now undergoing testing to showcase the benefits of the PHYSICS approach in terms of handling rapid small requests by merging them into larger ones. The rest of the flows are under initial implementation. Stay tuned for more news on our progress!

The post FaaS-ification in Health Care appeared first on PHYSICS.

The first relevant choice made by the PHYSICS team to achieve this goal was to follow an agile development methodology, which various partners can leverage to develop, deploy and test their own components seamlessly from the edge to the cloud.

The implication of this method has been incorporated into the paradigm of DevOps[1], based on the CI/CD (Continuous Integratio­n/Continuous Delivery) pipeline concept. The use of such pipelines is particularly suitable in PHYSICS, since it has been conceived and designed in a cloud-native perspective, therefore with the leverage of container-based microservices architectures.

[1] https://www.gartner.com/en/information-technology/glossary/devops

The second major choice that has been done by the team was to found the orchestration of these containers on what is the de-facto market standard on this topic, namely Kubernetes[1].

In such technological context, a development environment based on OKD[2] has been created, where the tools for the implementation of the CI/CD have been installed within an isolated environment (namespace). The selected tools are:

• Gitlab[3], a Git repository manager that lets developer teams collaborate on PHYSICS’s source code.
• Jenkins[4], the de-facto standard open-source automation server for orchestrating CI/CD workflows.
• Harbor[5], a popular CNCF compliant Docker registry.
• OpenLDAP[6], used as the single user directory for all tools, centralising authentication and simplifying management of developer accounts.

[1] https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/

[2] https://www.okd.io/#what-is-okd

^[3] Gitlab (https://about.gitlab.com/solutions/agile-delivery/)

^[4] Jenkins (https://www.jenkins.io/doc/)

^[5] Harbor (https://goharbor.io/docs/2.3.0/install-config/)

^[6] OpenLDAP (https://www.openldap.org/doc/admin25/)

The interaction between such tools and the complete actual process and steps to be followed by a project development partner is shown the picture below:

Starting from step #1, when a developer pushes a new component code, Gogs invokes through a webhook a pipeline (also referred as job) configured inside Jenkins. The job builds the component, runs unit tests and, if everything has worked in a proper way, builds an updated Docker image that is pushed to Harbor. The following step deploys the updated component in the specific namespace: in fact, we have as many namespaces as the WPs (Work Packages number.

At the end of the process, Jenkins sends a notification to a dedicated CI/CD channel on the PHYSICS Slack[1] workspace, so that developers are informed that a new build occurred and whether it was successful or not. This is just a preview of what has been done in PHYSICS to create a unified development, test and deployment environment for the PHYSICS solution framework: further challenges and enhancements are ongoing, so stay tuned!

^[1] Slack (https://slack.com/intl/en-pt/features)

The post PHYSICS Framework Agile Deployment appeared first on PHYSICS.

In the PHYSICS platform, the main function editing environment used is Node-RED. One of the abilities of the latter is to group a number of functions into subflows that can hide the internal implementation details and appear as regular Node-RED nodes with the parameterizable interfaces. Based on this feature, we have created an extended list of pattern functionalities, providing a parametric, generic implementation that can be dragged and dropped into a developer’s flow in order to speed up development time and reduce the learning curve of FaaS. Examples of such patterns include:

• Implementation of the Fork-Join parallelization primitive, including intra and inter-container parallelization abilities

• Different means of context management, including means to maintain context in warm function executions (reuse of existing containers) or to clean up context for functional or security purposes

• Intelligent request aggregation patterns for reducing back-end stress and costs in high frequency request rates [5]

• Edge ETL Data Collection

• Function-based load generators with support for function chaining

The provided PHYSICS patterns are gradually released in a specific collection included in the Node-RED flows repository, including test flows and documentation about their usage [6].

1. A. Wahyudi, G. Kuk, and M. Janssen, “A process pattern model for tackling and improving big data quality,” Information Systems Frontiers, vol. 20, no. 3, pp. 457–469, 2018.
2. P. Jamshidi, C. Pahl, and N. C. Mendonc¸a, “Pattern-based multi-cloud architecture migration,” Software: Practice and Experience, vol. 47, no. 9, pp. 1159–1184, 2017.
3. “Microsoft cloud design patterns catalogue and documentation.” Available at: https: //docs.microsoft.com/en-us/azure/architecture/patterns/index-patterns
4. D. Taibi, N. El Ioini, C. Pahl, and J. R. S. Niederkofler, “Patterns for serverless functions (function-as-a-service): A multivocal literature review,” 2020.
5. G. Kousiouris, “A self-adaptive batch request aggregation pattern for improving resource management, response time and costs in microservice and serverless environments,” in 40th IEEE International Performance Computing and Communications Conference (IPCCC 2021), IEEE, 2021.
6. PHYSICS pattern flows for Cloud/Edge and Openwhisk, available at: https://flows.nodered.org/collection/HXSkA2JJLcGA

The post Patterns appeared first on PHYSICS.

The requirements for data collections, sharing and processing introduce important considerations on the security and privacy aspects of data owners and their control over their data. While the needs for gathering, sharing, and processing data continuously evolve and expand with new and more efficient methods, so do the needs for deploying intrinsically secure architectures and components when designing and developing data functions. Together with today’s needs for simultaneous data access, validation, authorization, and record keeping, distributed ledger technologies can provide the means for addressing all these actions and providing users with ways to communicate through secure and transparent channels.

Distributed Ledger Technology 

Distributed Ledger Technology (DLT) is a protocol that enables the secure functioning of a decentralized digital database. DLT allows for storage of all information in a secure and accurate manner using cryptographic functions. DLT can be accessed using “keys” and their corresponding cryptographic signatures. Once the information is stored, it becomes an immutable database and is governed by the rules of the network.

Once data are inserted and stored into the DLT, their state is bound, and any changes done to them are committed into its immutable storage in a secure and transparent manner. In essence, DLT provides the bedrock for implementing and deploying procedures that can fire automatically once certain conditions are met. These procedures are encapsulated in blocks of code that instruct the DLT to change the state of data that are stored inside it. These changes in turn are added into the DLT through transactions, which the network needs to approve and validate. The automated procedures are called Smart Contracts and they have great potential in revolutionizing the way governments, institutions, and corporations’ work. It can help governments with tax collection, the issuance of passports, recording land registries and licenses, and the outlay of Social Security benefits as well as voting procedures. The technology is creating unique opportunities in industries such as finance, music and entertainment, diamond and other precious assets, art, supply chains of various commodities, and more.  

Enabling DLT with Smart Contracts

Integrating Smart Contracts into the PHYSICS architecture can further expand its functionalities with dynamic data transactions and authorizations, while also leveraging the decentralized nature of Blockchain technology. The benefits of involving Smart Contracts into the PHYSICS architecture include:

• Security: Blockchain data can be signed, enabling non-repudiation, integrity on the requests send by users using wallets.

• Transparency: Blockchain uses a distributed ledger, transactions and data are recorded identically in multiple locations. 

• Instant Traceability: Blockchain creates an audit trail that documents the provenance of an asset at every step on its journey.

• Automation: Smart Contracts enable this feature as once pre-specified conditions are met, the next step of a transaction or process can be automatically triggered. 

Smart Agriculture Authorization Policies Use Case

The following diagram showcases the integration of Smart Contracts into the PHYSICS platform from the perspective of a Smart Agriculture use case. A Smart Contract for authorizing the data requests done by users is deployed where access to the field data can be regulated in a dynamic, secure and granular way by the owner of the data fields.

The post Integrating Distributed Ledger Technologies in PHYSICS appeared first on PHYSICS.

Function-as-a-service is an event-driven compute paradigm that allows to execute primarily stateless, and arbitrary code in heterogeneous cloud computing platforms[1][2][3]. PHYSICS is a research project that seeks to enhance this simple FaaS model, some of the architecture principles of the PHYSICS platform are described as follows:

• It follows the FaaS model – the basic building blocks of the PHYSICS platform are the functions.
• The way to trigger actions are by using orchestrated flows – the PHYSICS platform supports creating flows (using a GUI) in order to ease application development. These flows are orchestrated by flow orchestration tools such as NodeRED or OpenWhisk. 

It makes usage of the compute continuum – another important aspect of the PHYSICS platform is the ability to deploy functions where they can be executed most efficiently, anywhere in the compute continuum, from the data center to the edge.

So let’s look at the following simple flow:

The query data step process some complex query on a database in the data center. Based on the query result, there is a request sent in parallel to multiple edges to fetch information from the edge sensors. These results are inputs to an additional step that is also executed in the data center.

In a high-level view of the FaaS model, this looks relatively simple – a function can run everywhere, and as long as there exists an endpoint, it is possible to call each function from any location in the network. 

Based on the simple function as a service model described in the previous flow, there are novel challenges imposed by the infrastructure architectural topology of the EDGE. These challenges are:

• Keeping a streamlined workflow execution across multiple Kubernetes clusters.
  • The workflow execution must include soft-handover tasks, so forth, parts of the workflow are executed depending on the criteria defined by the workflow controller.
  • The workflow execution must ensure that the authentication, authorization, and accounting of any action is enforced across the continuum.
  • The network connectivity across the continuum must be established.
• Keeping potentially disconnected locations stable enough to run the workflows.
  • Provide mechanisms to recover from connection issues in the edge without affecting the workflow execution.
  • Provide a method to support and handle edge locations where there might be low bandwidth.

And all the above aspects should be handled transparently, without any involvement of the flow designer, since the platform decides where to deploy each function. 

These are some of the challenges that we encounter in the PHYSICS project, and we work on solving them by the platform, in a transparent manner to the flow creators. 

References:

[1]: Architectural Implications of Function-as-a-Service Computing, https://doi.org/10.1145/3352460.3358296

[2]: Cloudburst: stateful functions-as-a-service, https://doi.org/10.14778/3407790.3407836

[3]: FaaSter: Accelerated Functions-as-a-Service with Heterogeneous GPUs, https://doi.org/10.1109/HiPC53243.2021.00057

It is, per se, cost-saving as well as an accelerator of time-to-market as it supports the creation of a key differentiation factor for any kind of product.

Focusing only on EU projects, one of their main handicaps is to get out of the research bubble, identifying topics not yet addressed and real-world user needs far beyond the consortium expectations. This will help to better eliminate the boundaries between business and research activities in collaborative environments, reducing risks and better using funds while focusing on results with a wider end user scope. There are several types of innovation according to its inclusion level (intercompany, intracompany, for experts, publicly open), and the purpose of use (marketing, gathering insight, finding talent, R&D). PHYSICS follows an open innovation strategy for maximising its adoption impact, providing tailored messages and offerings according to users’ needs, and not only from the consortium perspectives. Furthermore, it is open to different external stakeholders, with or without a technical background, that can provide valuable feedback about current technical challenges and market gaps while validating the proposed project results and exploitation strategy. With the main goal of attracting and engaging external stakeholders by involving them in the project R&D processes, aiming to maximise impact and foster the adoption of results.

Stay tuned, as everything will be documented in the PHYSICS Handbook, including a replicability plan.

[1] Viima, Open Innovation, https://www.viima.com/blog/open-innovation

The post Challenges in PHYSICS Flows Deployment appeared first on PHYSICS.

FaaS is the most central technology in serverless architectures, which allows organisations to focus on code and not on infrastructure. During pandemics, data traffic increased a lot, and major cloud providers put the focus on FaaS as the next technical trend.

PHYSICS takes advantage of this situation, providing a FaaS platform to operate, orchestrate and deploy applications on different infrastructures. However, for getting a real success, it is not only a matter of developing novel technologies or covering current technical/market gaps. However, to determine PHYSICS success it is important to measure its real impact. And this can only be done engaging different stakeholders.

Open innovation is not a new concept as it has been around for more than 20 years. However, it has gained importance in the last years with the digital transformation processes and new user-centric business models. It basically consists of opening the innovation processes to any external expert or researcher who can provide valuable feedback to improve the ongoing work.

It is, per se, cost-saving as well as an accelerator of time-to-market as it supports the creation of a key differentiation factor for any kind of product.

Focusing only on EU projects, one of their main handicaps is to get out of the research bubble, identifying topics not yet addressed and real-world user needs far beyond the consortium expectations. This will help to better eliminate the boundaries between business and research activities in collaborative environments, reducing risks and better using funds while focusing on results with a wider end user scope. There are several types of innovation according to its inclusion level (intercompany, intracompany, for experts, publicly open), and the purpose of use (marketing, gathering insight, finding talent, R&D). PHYSICS follows an open innovation strategy for maximising its adoption impact, providing tailored messages and offerings according to users’ needs, and not only from the consortium perspectives. Furthermore, it is open to different external stakeholders, with or without a technical background, that can provide valuable feedback about current technical challenges and market gaps while validating the proposed project results and exploitation strategy. With the main goal of attracting and engaging external stakeholders by involving them in the project R&D processes, aiming to maximise impact and foster the adoption of results.

Stay tuned, as everything will be documented in the PHYSICS Handbook, including a replicability plan.

[1] Viima, Open Innovation, https://www.viima.com/blog/open-innovation

The post Unleashing PHYSICS potential through open innovation appeared first on PHYSICS.

In the context of PHYSICS platform graphs are divided into the following four types illustrated in Figure 2:

1. Application graph: Describes a given application that can consist of functions, flows, sub-flows, patterns and services. 
2. Resource graph: Describes a given computational resource such as public clouds and clusters that can consist of compute nodes, storage services, edge devices, etc. 
3. Global graph: Includes a given application graph with its nodes connected with the nodes of the available resource graphs that could deploy each node of the application graph. 
4. Deployment graph: Includes a given application graph with its nodes connected with the optimal nodes from the available resource graphs that will be used to deploy each node of the application graph. 

Three dedicated components have been developed to perform inference over those graphs, namely the Application and Resource Semantics and the Reasoning Framework, forming the Semantics Block of the PHYSICS (see Figure 3). 

Specifically, the Semantics Block could be perceived as an interface between the PHYSICS platform’s different layers, serving as a central repository for application and resource metadata. Hence, it interacts with various components that either provide or request data.

As far as the input data is concerned, it should be structured to data models according to the Linked Data principles before entering the Reasoning Framework. This will allow interoperability between the different components of the platform, seamless data sharing, and reasoning/inference on the data. This data could be divided into application and resource metadata. The former generated from the given application is processed by the Application Semantics component in order to be transformed according to the ontology descriptions and annotations. Accordingly, resource metadata is injected into the Resource Semantics component, which is responsible for “translating” the different resource data to the common language defined by the ontology. Thus, the Application (Resource) Semantics component creates an individual application graph (resource) for each new application (resource) registered on the platform that can be imported into the Reasoning Framework and stored to its quad-store.

On the other hand, the Reasoning Framework outputs data to other components based on their requirements. Hence, when an application needs to be deployed, its global graph (i.e., the application graph connected with the relevant resource nodes) created by the Reasoning Framework is passed to Global Continuum Patterns Placement for further optimization.

The Reasoning Framework comes with a REST API offering all the required endpoints to ease data injection and retrieval with all the other PHYSICS components.

Keep in touch with us at Twitter and LinkedIn to learn more about how PHYSICS will leverage ontology-oriented programming and semantic graphs to enhance resources performance in FaaS.

The post Modelling FaaS Graphs: The Semantic Building Blocks appeared first on PHYSICS.