About: Cloud-based integration is a research topic. Over the lifetime, 22 publications have been published within this topic receiving 38 citations. The topic is also known as: integration platform as a service & iPaaS.
TL;DR: Obelisk, a scalable and multi‐tenant cloud‐based IoT integration platform used in the EU H2020 PortForward project is presented, and the scalability of the platform is evaluated by means of an air quality monitoring use‐case deployed in the city of Antwerp.
Abstract: Internet of Things (IoT) technologies, when adequately integrated, cater for logistics optimisation and operations' environmental impact monitoring, both key aspects for today's EU ports management. This article presents Obelisk, a scalable and multi-tenant cloud-based IoT integration platform used in the EU H2020 PortForward project. The landscape of IoT protocols being particularly fragmented, the first role of Obelisk is to provide uniform access to data originating from a myriad of devices and protocols. Interoperability is achieved through adapters that provide flexibility and evolvability in protocol and format mapping. Additionally, due to ports operating in a hub model with various interacting actors, a second role of Obelisk is to secure access to data. This is achieved through encryption and isolation for data transport and processing, respectively, while user access control is ensured through authentication and authorisation standards. Finally, as ports IoTisation will further evolve, a third need for Obelisk is to scale with the data volumes it must ingest and process. Platform scalability is achieved by means of a reactive micro-services based design. Those three essential characteristics are detailed in this article with a specific focus on how to achieve IoT data platform scalability. By means of an air quality monitoring use-case deployed in the city of Antwerp, the scalability of the platform is evaluated. The evaluation shows that the proposed reactive micro-service based design allows for horizontal scaling of the platform as well as for logarithmic time complexity of its service time.
TL;DR: The concept includes a definition of an interface suitable for engineering tools to connect to the repository, based on which an AML-based importer and exporter was developed for RobotStudio and a strategy to specify what kind of data should be stored in and exchanged via the AML.
Abstract: This paper describes a concept for the cloud-based integration and exchange of robot data between engineering tools. We validate the concept at the example of AML.hub by logi.cals, a repository basing on the vendor-neutral data format AutomationML (AML), and ABB RobotStudio. The concept includes a definition of an interface suitable for engineering tools to connect to the repository, based on which an AML-based importer and exporter was developed for RobotStudio. We developed a strategy to specify what kind of data should be stored in and exchanged via the AML.hub. Overall, we validated the concept by means of a prototypical implementation.
TL;DR: The most common integration types identified in this study are on-premises implementations, hybrid, and cloud-based integration platforms as mentioned in this paper, and the study found how software companies choose between these integration types.
Abstract: Choosing between different integration implementations is an important but surprisingly understudied part of software projects. However, the world is digitalizing rapidly, and the number of different systems that require integration is increasing. In this situation the importance of scalable cloud-based integration platforms, iPaaS and iSaaS platforms, has grown. These digital platforms and their APIs have made the integration of different systems significantly faster and easier than before, when integrations were handled on the premises and custom-built from scratch. This study goes through, via thematical analysis, the interview data collected from the representatives ( $\mathrm{n}=20$ ) of the Finnish software companies that have experience with integration projects. The most common integration types identified in this study are on-premises implementations, hybrid, and cloud-based integration platforms. The study found how software companies choose between these integration types. By using the cultural lag theory framework, the study can explain that the adoption of new cloud-based integration platforms is in a maladjusted situation. Furthermore, the study shows that choice between on-premises and cloud-based integration solutions is not always clear as there is frequently a lack of a broader strategy behind integration decisions.
TL;DR: In this paper, the authors describe systems and methods for providing stage file objects in a visual design tool for integration development, where the integration can be developed on a cloud based integration service that can receive, via a visual development tool interface, selection of a stage file object for insertion into an integration flow.
Abstract: Described herein are systems and methods for providing stage file objects in a visual design tool for integration development. The integration can be developed on a cloud based integration service that can receive, via a visual development tool interface, selection of a stage file object for insertion into an integration flow. The cloud based integration service can also receive a selection of a type value for the stage file object. The scope for the stage file object can be determined, and the stage file object can be displayed in the integration flow based on the type value and the scope.
TL;DR: In this paper, the authors present a technique for debugging and introspecting an integration deployed in a distributed computing environment, where the orchestrating system sends instructions to the public interfaces of the computing systems to cause the performable operations and their associated inverse operations, if any, to be performed in parallel with one another.
Abstract: Certain example embodiments relate to techniques for debugging and/or introspecting an integration deployed in a distributed computing environment. The integration includes operations performable responsive to receipt of instructions from an orchestrating system by public interfaces of computing systems in the distributed computing environment. The orchestrating system is remote from the computing systems. An inverse operation for at least some of the performable operations in the integration is identified. The inverse operations also are performable responsive to receipt of instructions from the orchestrating system by the public interfaces of the computing systems of the distributed computing environment. Each inverse operation reveals, upon its performance, an effect of one or more associated performable operations. The orchestrating system sends instructions to the public interfaces of the computing systems to cause the performable operations and their associated inverse operations, if any, to be performed in parallel with one another, in the debugging and/or introspection.