This article describes novel approaches for service discovery, and classification. This approach is detailed in the deliverable D2.1 “SmartCLIDE Innovative Approaches and Features on Services Discovery, Creation, Composition and Deployment“[1] which is currently under review.
We will share the deliverable once the document is validated by our reviewers. In meantime, we can already present the approach adopted by the project team to define and organize the project tasks.
The approach used by the SmartCLIDE team is the engineering cycles, as described in the design science framework [2]. According to Wieringa, every engineering problem can be treated as a 4-step process:
- identifying the need and specifying the problem;
- design the proposed solution;
- evaluate the proposed solution; and
- apply the solution.
The deliverable D2.1 aims at the first 3 steps of the approach in the sense that the application of the solution falls into “Assessment of SmartCLIDE at pilot users”. In this article, we focus on the 1st step identification of problems; whereas the 2nd (proposal) and the 3rd (evaluation) steps will be presented in the final deliverable D2.1.
The identification of the targeted problems stemmed from the project proposal and the associated requirements. Each problem has been decomposed into simpler tasks that need to be fulfilled to solve the problems. The tasks are decomposed into two main categories:
- technological tasks aim to solve problems by reusing or adapting existing solutions. The advancement that technological tasks is the introduced level of automation, as well as the composition of existing solutions into processes.
- research tasks aim to solve problems that cannot be treated with existing solutions; thus, urge for novel algorithms, prototypes, and tools.
The outcomes of these tasks are organized into seven types:
- reports correspond to documents describing existing tools, repos, approaches, etc.;
- datasets correspond to collections of data points that will be stored in a repo;
- schemas correspond to documents describing the format of data stored in repos, or exchanged between components;
- tool corresponds to existing implementations that solve a practical problem;
- approach corresponds to novel research approaches (method, algorithm, etc.) for problem solving. They are expected to be linked to a publication;
- draft prototype corresponds to the proof-of concept implementation of novel approaches. This version of the implementation is used only for research purposes. We expect a low level of automation and no integration at this stage;
- final prototype corresponds to the functionally final version of the research prototype. This version will be fully automated, no integration.
Figure 1 maps the problems identified and the associated requirements to a list of tasks, so as to guide the organization of the D2.1 deliverable and the research activities.
Upon problem identification, the project team proceeded to the assignment of responsibilities for answering each problem (see Table 1).
| Problem | Solution |
|---|---|
| How can services be identified? | Research approach on getting services from classic registries Research approach on getting services from web pages Research approach on getting services from code repositories |
| How can services be classified? | Research approach on available datasets Research approach on classification model implementation |
| How can services be registered? | Research approach on registry service query Research approach for interfacing service registry |
| How can services be created? | Technological Approach on the Integration of Version Control in SmartCLIDE Technological Approach for service creation in SmartCLIDE |
| How can services be specified? | Technological Approach on Functional Service Specification Technological Approach on the Specification of Service Runtime Monitoring & Verification |
| How can code be generated? | Research Approach on Source Code Generation Research Approach on Autocomplete Suggestions |
| Can patterns lead to code templates? | Research Approach on Design Patterns Default Implementations Research Approach on Architectural Patterns Default Implementations Research Approach on Security Patterns Implementations |
| How can services be composed into workflows? | Technological Approach on Service Composition Representation Using BPML Technological Approach on Service Composition (either Discovered or Created) Technological Approach for Mapping Services to Containers |
| How can service composition be assisted by AI? | Research Approach on Autocomplete Suggestions on Service Composition Research Approach on Workflow Context Identification |
| How can services and workflows be tested? | Technological Approach for Coverage of Created Services Technological Approach for Unit and Acceptance Testing Research Approach for Automated Test Case Generation (Virtual User for Testing) |
| How can security, maintainability, and reusability be assessed? | Research Approach for Security Assessment at Service Level Research Approach for Security Assessment at Workflow Level Research Approach for Maintainability Assessment at Service Level Research Approach for Maintainability Assessment at Workflow Level Research Approach for Reusability Assessment at Service Level Research Approach for Reusability Assessment at Workflow Level |
| How can services and workflows be deployed | Technological Approach on Deployment and Orchestration Tools Technological Approach on Management Tools Research Approach on Continuous Delivery |
| How can conformance to requirements be assessed? | Research Approach on Cost Analysis Research Approach on Scalability Assessment |
| How can services and workflows be monitored? | Technological Approach on Runtime Monitoring and Verification of Services Research Approach on Defining Sensors/Metrics for Security Monitoring Technological Approach on System Monitoring (Performance and QoS) |
The deliverable D2.1 details each problem and how it is planned to be solved.
[1] The link to the deliverable D2.1 will be available as soon it will be accepted by the project reviewers
[2] R. J. Wieringa, “Design science methodology for information systems and software engineering”, Springer, 2014.
Photo by Patrick Perkins on Unsplash
No responses yet