Introduction and Goals

In the Proof-of-Concept, the research and developments of the various subprojects flow together in a uniform, integrated software system. With the help of the Proof-of-Concept, typical scenarios of an On-The-Fly market can be played through. The goals of the Proof-of-Concept are:

Demonstration of the general feasibility of On-The-Fly Computing
Imparting the concepts of On-The-Fly Computing to both a specialist audience and lay people
Clarification of the relationships between the subprojects
Testing new approaches and reviewing hypotheses

OTF Machine Learning Scenario

The Proof-of-Concept is designed domain agnostic, such that it can be adopted for any kind of OTF problems. For illustration purposes, the Proof-of-Concepts focuses on an application scenario to configure tailor-made Machine Learning Services on the fly. The main problem addressed is the automatic creation of a learning process that generates a predictive model (e.g., a classifier) on the basis of given training data. Such a learning process consists of different algorithms or software components that have to be appropriately parameterized and combined with each other. The result of a corresponding selection and configuration process is a Machine Learning Pipeline. This OTF Machine Learning Scenario has the characteristics of an OTF problem:

end-users do not need to know the underlying software architecture and manual steps in this process,
the user is provided with an executable service in the form of a Machine Learning pipeline,
this service is optimized for the individual requirements (i.e. training data) and
the provision of the service takes place within a short time.

Architecture

Numerous concepts and methods of OTF computing, which have been developed in the respective subprojects, have already been integrated in the proof of concept.

Subproject	Contribution
A1	Self-stabilizing publish-subscribe system for market and OTF provider
A3, A4	Concepts for the reputation system for the rating of service compositions
B1	Chatbot for a user-friendly requirements specifications and a matcher for matching non-functional requirements
B2	Configurator for service composition using heuristic search
B3	Verification of functional properties within operation sequences
B4	Certification and validation of functional properties of basic services
C1	Authentication of ratings, authorization for buying service compositions and their access control
C2, C4	Deployment of basic services in Compute Centers and the execution of service compositions in heterogeneous computing environments
C5	Conformance checking of the Proof-of-Concept architecture with the On-the-Fly architecture framework

Features

Market Roles

The Proof-of-Concepts has several user interface views for the individual OTF market roles, i.e., Service Requesters, OTF Providers, Service Providers, Compute Centers, and a Market Provider.

Service Requester

The process of the Service Requester consists of four phases: requirements specification, configuration, buying & using, rating.

Requirement Specification

The process starts with creating a new request. Service Requesters conduct a dialog with a chatbot, where they describe the functional and non-functional requirements of their tailor-made service composition. The chatbot extracts a machine-readable request specification from requester’s answers and sends them to the Market Provider. The Market Provider broadcasts the Service Requests to all OTF Providers via a self-stabilizing Publish-Subscribe system. The OTF Providers respond with a confidence score that estimates how well they can solve the problem. Based on this confidence score and the overall reputation of the OTF Providers, the Service Requester chooses one OTF Provider from whom he wants to receive offers.

Configuration

The configuration process starts and the Service Requester can inspect the progress of the request. The OTF Provider uses templates for Machine Learning Pipelines and fills the placeholder of the templates with basic services by using a heuristic search. The configuration search space is visualized as a graph. Every node represents a concrete Machine Learning Pipeline.

Buying and Using

After the configuration process is done, the OTF Provider offers the Machine Learning Pipelines to the Service Requester. The offers differ in their non-functional properties and the Service Request chooses the offer that best fits his needs and buys the service composition. The composition is automatically deployed in the Computer Center, where it is ready to be used. An access control prevents that unauthorized third-parties can use the service composition.

Rating

Finally, Service Requesters can rate their service composition and share their experience with other Service Requesters.

Market Provider

The Market Provider can visualize the self-stabilizing OTF Provider network and can monitor the processes that are ongoing in the market.

OTF Provider

The Market Provider can visualize the self-stabilizing OTF Provider network and can monitor the processes that are ongoing in the market.

Service Provider

Service Providers publish libraries to the OTF market. A library consists of several basic services. A basic service is a piece of code that can be executed stand-alone by itself without relying in any other services. Basic services can be arranged in service compositions. In the example scenario, we are using the Machine Learning libraries Weka, scikit learn, Tensorflow and two image processing libraries.

Compute Centers

Screenshots

Organization, DevOps, and Technologies

The development process of the proof-of-concept is controlled by a chief architect and a committee. A six-person development team is responsible for putting the core components of the subprojects into the proof-of-concept's microservice architecture and developing any other components that are not sub-project-related, such as a unified user interface.

In addition, the DevOps development process includes Continuous Integration and Continuous Delivery: GitLab is used to manage the program code of the components. The Jenkins build server monitors program code changes, compiles the program code with Gradle, analyzes the program code for errors with SonarQube, automatically runs JUnit tests, automatically creates Docker containers, and distributes them into a Kubernetes cluster where the components are ultimately executed. All processes can be monitored with ElasticSearch and Kibana.

Team

Supervisor

Gregor Engels

Architect

Dr. Christian Soltenborn

Advisors

Jan Bobolz (C1), Thorsten Götte (A3), David Niehues (C1), Marcel Wever (B2)

Developers

Oliver Butterwegge, Jan-Niclas Nutt, Saman Soltani

Credits

Logo design by freepik.com

Contact

Dr. Christian Soltenborn

Sonderforschungsbereich 901

Projektleitung "Proof of Concept"

Mehr zur Person

Further information:

Projects Project Area A Project Area B Project Area C Project Area T Tools and Demonstration Systems Tools from the 1st Funding Period Tools from the 2nd Funding Period Tools from the 3rd Funding Period