TOSCA Architecture - I | Application structure & Audit log events

Welcome to "TOSCA Architecture - I | Application structure & Audit log events". We want to build an application that will allow us to generate YAML (TOSCA) script from a network diagram & vice-versa. The design for the app has been provided for reference this is a work in progress & designs can be updated in the future.

Background Overview

The application will consist of an HTML5 Canvas element on which network diagrams can be drawn. A network has a number of different elements called Nodes. A node can have different capabilities and requirements based on which linking of different nodes can be done. If the requirements of one node match the capabilities of the other node then only the nodes can be linked.

Nodes, Capabilities & Requirements:

Refer to this workflow https://marvelapp.com/bbb68a4/screen/57316810 that allows a user to define requirements & capabilities of a node.

TOSCA

Topology and Orchestration Specification for Cloud Applications (TOSCA), is an OASIS standard language to describe a topology of cloud-based web services, their components, relationships, and the processes that manage them. The TOSCA standard includes specifications to describe processes that create or modify web services.

Summary of key TOSCA concepts

The TOSCA metamodel uses the concept of service templates to describe cloud workloads as a topology template, which is a graph of node templates modeling the components a workload is made up of and as relationship templates modeling the relations between those components. TOSCA further provides a type system of node types to describe the possible building blocks for constructing a service template, as well as relationship type to describe possible kinds of relations. Both node and relationship types may define lifecycle operations to implement the behavior an orchestration engine can invoke when instantiating a service template. For example, a node type for some software product might provide a 'create' operation to handle the creation of an instance of a component at runtime, or a 'start' or 'stop' operation to handle a start or stop event triggered by an orchestration engine. Those lifecycle operations are backed by implementation artifacts such as scripts or Chef recipes that implement the actual behavior. An orchestration engine processing a TOSCA service template uses the mentioned lifecycle operations to instantiate single components at runtime, and it uses the relationship between components to derive the order of component instantiation. For example, during the instantiation of a two-tier application that includes a web application that depends on a database, an orchestration engine would first invoke the 'create' operation on the database component to install and configure the database, and it would then invoke the 'create' operation of the web application to install and configure the application (which includes configuration of the database connection). The TOSCA simple profile assumes a number of base types (node types and relationship types) to be supported by each compliant environment such as a 'Compute' node type, a 'Network' node type or a generic 'Database' node type. Furthermore, it is envisioned that a large number of additional types for use in service templates will be defined by a community over time. Therefore, template authors in many cases will not have to define types themselves but can simply start writing service templates that use existing In addition, the simple profile will provide means for easily customizing and extending existing types, for example by providing a customized 'create' script for some software.

Refer to this document to learn more: http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.1/os/TOSCA-Simple-Profile-YAML-v1.1-os.pdf

Browser support

Chrome, Firefox & MS edge are the browsers in scope.

Architectural Requirements

As seen in the above HLD the block marked in blue is in the scope of this architectural challenge. The application is going to be a desktop-only application. Here we need to know the architectural details of all the points included in these:

Application layers: Specify the shared communications protocols and interface methods to be used by the application in a communications network.

The Product structure: Define the basic structure of a ReactJS project. The organization of folders, components, assets, containers, basic libraries to be used in this application like Redux for state management, the structure of README.md file. Performance consideration to be made to keep the application fast. Along with the architectural documentation, if you want you can submit a mock reactJS submission to show the mock directory structure/tree.

Deployment: The ReactJS application should be on hosted on an Oracle Weblogic 12c server in local environment & also in the cloud. We are running a learning challenge that you may refer to this here: https://www.topcoder.com/challenges/30091679/?type=develop&noncache=true . Provide us all the details we need to consider to build the ReactJS application & host it in an Weblogic 12c environment. Details about hosting the application on heroku and/or AWS should also be included in the doc.

Unit Testing: The application to be united tested. Following are the tools/framework to be considered for unit testing.
Jest & Enzyme: To test all JavaScript code including React applications. (Jest is a testing framework, while enzyme is a utility to easily mount React components).
Istanbul: To do coverage test & generate coverage report. It's integrated into Jest https://istanbul.js.org/integrations/ . (Istanbul is a coverage tool used by Jest).
JUnit: for testing any Java code.

We are expecting documentation about testing ReactJS & Java code. You can include other tools/frameworks that can be used for testing the ReactJS & Java code.

CI/CD pipelines: The application code will be stored in GitLab repo. & developers are going to push & pull the codes in this repo. Whenever code in the repo gets updated the CI/CD pipelines should automatically push the updated code to the cloud (sever where the app. Is hosted, Heroku/AWS). Provide us the details about setting up CI/CD pipelines in these cases.

Tools and Softwares: What are the tools & software we need to build this application. Provide the details of IDEs to be used, design-related software, software to be used by front-end developers to transform the design into working UI application, software/tools required to document & view the APIs, tools required to test the application, etc.

Audit log Events

For every user action done by the user, logs should be created & should to be saved in browser local storage for now. Later we are going to use APIs to store these into a DB. These logos are then going to be consumed by Elasticsearch engine & Kibana will be used to visualize your Elasticsearch data and navigate the Elastic Stack. Provide an overview of creating logs from the user actions. What consideration we need to make so this doesn't affect the performance of the application & it should run fast.