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:

  1. identifying the need and specifying the problem;
  2. design the proposed solution;
  3. evaluate the proposed solution; and
  4. 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:

  1. reports correspond to documents describing existing tools, repos, approaches, etc.;
  2. datasets correspond to collections of data points that will be stored in a repo;
  3. schemas correspond to documents describing the format of data stored in repos, or exchanged between components;
  4. tool corresponds to existing implementations that solve a practical problem;
  5. approach corresponds to novel research approaches (method, algorithm, etc.) for problem solving. They are expected to be linked to a publication;
  6. 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;
  7. 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.

Figure 1: SmartCLIDE research problems identification

Upon problem identification, the project team proceeded to the assignment of responsibilities for answering each problem (see Table 1).

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 deployedTechnological 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)
Table 1: Micro-planning per task and relevant problems

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

Leave a Reply

Your email address will not be published. Required fields are marked *

Recent Tweets
Share via
Copy link
Powered by Social Snap