# Service Interface Translation. An Interoperability Approach
## 5 Discussion  
Experimental results demonstrate that the presented approach is capable of solving interoperability issues at the service interface level. The autonomous generation of new interface instances was performed successfully in the presented scenario.  
Despite that the interface translation allows two systems with several interoperability mismatches (protocol, encoding, semantics, payload structure, and datatype) to successfully interchange data, there are also limitations and challenges that need to be overcome. One of the major challenges associated with this approach is the variations in the application interfaces (syntax, data formats, and semantics). The translation of data models and semantics presents an important barrier that needs to be addressed. The approach has been tested for a limited set of payloads. Future experiments need to cover a wider range of data models and consider the introduction of machine learning algorithms and semantic annotations, e.g., reinforcement learning.  
Security implications need to be further analyzed. The current implementation of the consumer interface generator system is secured via the HTTPS protocol. The system includes two working modes, _secure_ and _insecure_. If the system is started in secure mode, X.509 identity Arrowhead compliant certificates are used for authentication and authorization. The system is considered a trusted peer in the Arrowhead local cloud and follows the security policies stated in the framework [32]. The insecure mode is exclusively used for development.  
The translation also implies a time delay. One hundred milliseconds are necessary to consume the service against 40 ms for the direct consumption of the service, a little more than double. We consider that the proposed approach can be used in systems that do not need request-response times of less than 100 ms, regardless of the delay introduced by the  
Figure 8: Comparison between the time required to consume the service in the proposed scenario (\(T_{S}\)), which includes the use of interface (\(T_{I}\)), and the time required to consume the service making a direct request (\(T_{D}R\)) using a CoAP interface without any interoperability mismatch.  
interface instance. Regarding the generation process, it increases the orchestration times by approximately 50 ms. The increase in time is assumable since the orchestration process takes place only once when the consumer system requests the provider endpoint. Once the communication is established, the consumer system uses the same provider endpoint each time that wants to consume the service.  
An important clarification is that the service consumption times cannot be compared directly since the consumer does not count with the appropriate interface. Both systems cannot communicate without providing a new interface. The use of interface translation at runtime solves the interoperability misalignment. These problems would require stopping the operation and spending time and resources in the implementation of the code. Usually, the implementation of an interface by hand implies several minutes to hours. The use of the consumer interface generator reduces that time to hundreds of milliseconds and at runtime. Consequently, the generator may potentially decrease the engineering costs associated with interoperability.  
Moreover, future work will involve the improvement of the proposed approach, including the design of a wider and robust injection strategy, and the testing of the prototype in industrial scenarios.  
This approach can mean a major improvement in comparison with other solutions, such as semantic platforms, WoT, and middleware. These approaches do not try to find a generic solution to the problem, but provide a specific solution that is only useful for a limited period of time and for certain technology.