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
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.
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.
The Market Provider can visualize the self-stabilizing OTF Provider network and can monitor the processes that are ongoing in the market.
The Market Provider can visualize the self-stabilizing OTF Provider network and can monitor the processes that are ongoing in the market.
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.
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.
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
