CODVerif: A Continuous Verification of Service-Oriented Architecture Data

Introduction

Service-oriented architecture applications (SOAs) define a set of services from a service provider. Service consumers could invoke these services by providing the right inputs to obtain the expected outputs. For many applications, the input/output data does not need to be defined rigorously (e.g., class attributes representing informal descriptions). However, for many other applications, it is necessary to define SOA input/output data very rigorously (e.g., an attribute that aims to capture a URL (Uniform Resource Location) needs to be well-defined), otherwise, problems would appear at run-time when the data will be used. The rigor comes from the specificity of the application that the SOA supports. This application happens for certain cyber-physical systems (CPSs) applications where the input should uphold a standardized specification strictly, and users cannot deviate from the constraints defined by that standard when defining inputs for SOA services. A typical example is the STK SOA data definition standard (Osorio et al., 2006) and its application to CPSs (https://bit.ly/3NyToG0) can check STK SOA data coherency). Nevertheless, the drawbacks of the a-posteriori verification approach are two-fold:

• •

  Users will figure out the errors when the data definition phase is almost done (van der Aalst & Pesic, 2006). This means that users could affect the delivery of their data because they would repeat defining data to resolve the problems raised.

• •

  Users would face many errors in many objects in the data store. These problems often need to be addressed sequentially and manually.

With the CODVerif approach, each time users populate a piece of data, one or many Monitoring Data Insertion processes or Workflows (MDIWs) are launched. An MDIW checks whether the piece of information populated is coherent, following the rules imposed by the standard or even by naming conventions if they would be applicable. If the MDIW detects that a certain object has not been well-populated in the data store, it will raise the warnings or create actions that will remain pending until the problems raised are resolved. The advantage of this approach is that users can continuously address the problems related to data coherency. Furthermore, users will not let the problems accumulate until the end of the data definition phase.