INTER-METH -- Design Phase: How to analyze the integration of two heterogeneous platforms using INTER-METH for INTER-LogP Pilot

(Getting Ready) Integration scenario description

The integration scenario to be addressed in this recipe is shown in the following figure in which two different IoT platforms needs to be integrated in the INTER-LogP Pilot (see Deliverable D6.3). In particular, the design phase involves the integration requirements reported in the INTER-GOM model. The integrator/s has to instantiate a set of INTER-IoT DESIGN PATTERNS (see Deliverable D5.1) related to the integration of the following two platforms that are deployed in the Port of Valencia (Spain): Port Platform and Noatum SEAMS2 Platform.

Figure 1. Overall integration scenario.

Recipe ingredients

Documentation: INTER-METH methodology available here
SW: INTER-CASE tool (downloadable here)
INTER-GOM model, generated as output of INTER-IoT-based Analysis Phase

Prerequisites

Apache Tomcat
MySQL DBMS
Bootstrap library
Xonomy library
Itextpdf library
log4j library

OR

Simply use our web-app instantiation of the INTER-CASE Tool available here

(How to Do it) Execution of the Design Workflow through INTER-CASE

Here we describe how to execute the design workflow through INTER-CASE:

The Integrator user first logs into the web-based INTER-CASE (see the official user guide here and starts a new Integration Project. A summary page, Project Status (see Figure below), shows an overview of the integration procedure. In this case, we just focus on the Design phase.

Figure 2: Project Status window.

As first step the Integrator has to identify the necessary pre-instantiated design patterns, among the available ones that are filtered automatically by the INTER-CASE tool according to the input from the Analysis Phase.

Figure 3a: Instantiated INTER-IoT Patterns: INTERM Message Broker.

Figure 3b: Instantiated INTER-IoT Patterns: INTERIOT Gateway Event Subscription.

Figure 3c: Instantiated INTER-IoT Patterns: API Facade.

Figure 3d: Instantiated INTER-IoT Patterns: AS2AS Discovery of IoT. Services

Figure 3e: Instantiated INTER-IoT Patterns: Alignment based Translation Pattern.

(How it Works) Inspection of the XML INTER-CASE files

Here we describe how to inspect the XML files representing the > instantiated patterns created into the previous step using the > INTER-CASE tool:

The files can be extracted and easily saved to your local machine directly from the tool.

INTERMW Message Broker

<Design_Pattern>
  <Pattern_Name xml:space="preserve">INTER-MW Message Broker</Pattern_Name>
  <Identifier xml:space="preserve">05</Identifier>
  <Layer xml:space="preserve">MW2MW Layer</Layer>
  <Inspired_by xml:space="preserve">1) “Message Broker” Enterprise Integration Patterns: Message Routing (Section: “Enterprise Integration Patterns”)         2) “Broker” IoT Patterns: Design Patterns for Interaction (Section: “IoT Patterns”)</Inspired_by>
  <Related_patterns xml:space="preserve">INTER-MW Self-contained Message</Related_patterns>
  <Intent xml:space="preserve">A component that facilitates passing of messages between decoupled INTER-MW components</Intent>
  <Problem_and_Solution xml:space="preserve">There are several IoT platforms publishing data in real time. In order to access these data it is needed a common broker</Problem_and_Solution>
  <Applicability xml:space="preserve">Port authority subscribing to all the terminals data</Applicability>
  <UML_representation>
    <url xml:space="preserve">image.png</url>
  </UML_representation>
  <Implementation xml:space="preserve">The UML diagram depicts the message flow through the broker. Each message, which the publisher        sends to the broker, is composed of a label and payload. Message payload contains the content of        the message, while the label is used for message routing within the broker. When the message        arrives into the broker, it is sorted in Exchange into applicable queue(s), based on its label.        INTER-MW label contains the topic that this message has to be routed to (for example, the topic that        distinguishes messages that come from IoT artifact to the other one), and each topic has a queue        associated with it. Message is then passed on to the consumer through the queues, associated with        this topic.</Implementation>
  <Known_uses_within_the_INTER-IoT xml:space="preserve">All IoT platforms in INTER-LogP pilot are integrated with INTER-MW, and can publish and subscribe in the INTER-MW broker </Known_uses_within_the_INTER-IoT>
  <Identified_by xml:space="preserve">Valenciaport Foundation</Identified_by>
  <Registration_Date xml:space="preserve">20/6/2018</Registration_Date>
</Design_Pattern>

INTERIOT Gateway Event Subscription

<Design_Pattern>
  <Pattern_Name xml:space="preserve">INTER-IoT Gateway Event Subscription (Publish/Subscribe)</Pattern_Name>
  <Identifier xml:space="preserve">03</Identifier>
  <Layer xml:space="preserve">D2D Layer</Layer>
  <Inspired_by xml:space="preserve">1) “Publish/Subscribe” IoT Patterns: Design Patterns for Interaction (Section: “IoT Patterns”)            2) “Publish-Subscribe Channel” Enterprise Integration Patterns: Messaging Channels (Section: “Enterprise Integration Patterns”)            3) “Facilitator” Agent Design Patterns: by Kendall (Section: “Agent Design Patterns”)            4) “Proxy” Agent Design Patterns: by Kendall (Section: “Agent Design Patterns”)</Inspired_by>
  <Related_patterns xml:space="preserve">D2D REST Request/Response</Related_patterns>
  <Intent xml:space="preserve">INTER-IoT proposes as a potential solution, a D2D gateway that allows any type of data forwarding. It will make the device layer flexible by decoupling the gateway on two independent parts: a physical part that only handles network access and communication other gateway operations and services</Intent>
  <Problem_and_Solution xml:space="preserve">In the port there are several wireless sensors deployed that need to send their data. It is needed to gather the data and send it to the proper platform</Problem_and_Solution>
  <Applicability xml:space="preserve">The lamp posts in the coverage area of each gateway gather all the lighting data and send it to the port IoT platform</Applicability>
  <UML_representation>
    <url xml:space="preserve">image.png</url>
  </UML_representation>
  <Implementation xml:space="preserve">In this case, the Gateway is the subscriber of a publisher (Device X) and in the subscription request        message an endpoint is defined (Device Y). Also the INTER-IoT gateway is subscribed to        publications of Device X, and in the subscription request message the other endpoint is defined        (Device X). Protocol conversion is performed if required to establish this communication. When the        publisher has new events (asynchronous) it will push the event data (publication) to the defined        endpoint. This example illustrates a D2D communication through the INTER-IoT gateway, that acts as        an intermediary element enabling this interaction</Implementation>
  <Known_uses_within_the_INTER-IoT xml:space="preserve"/>
  <Identified_by xml:space="preserve">Valenciaport Foundation</Identified_by>
  <Registration_Date xml:space="preserve">20/6/18</Registration_Date>
</Design_Pattern>

API Façade

<Design_Pattern>
  <Pattern_Name xml:space="preserve">API façade</Pattern_Name>
  <Identifier xml:space="preserve">19</Identifier>
  <Layer xml:space="preserve">INTER-FW</Layer>
  <Inspired_by xml:space="preserve">"Web API Design: Crafting Interfaces that Developers Love" [59]</Inspired_by>
  <Related_patterns xml:space="preserve">Other patterns, related with the describing pattern</Related_patterns>
  <Intent xml:space="preserve">Create a single unique API for IoT artifacts interoperability</Intent>
  <Problem_and_Solution xml:space="preserve">Each port company has it's own API for accesing its data. A common API would be useful for developers and integrators to access data from different sources</Problem_and_Solution>
  <Applicability xml:space="preserve">The INTER-FW API is used to access data from different IoT platforms</Applicability>
  <UML_representation>
    <url xml:space="preserve">image.png</url>
  </UML_representation>
  <Implementation xml:space="preserve">1. Design the ideal API – design the URLs, request parameters and responses, payloads,        headers, query parameters, and so on. The API design should be self-consistent.        2. Implement the design with data stubs. This allows application developers to use your API and        give you feedback even before your API is connected to internal systems.        3. Mediate or integrate between the façade and the systems.</Implementation>
  <Known_uses_within_the_INTER-IoT xml:space="preserve">The API façade can turn complex for the user depending on the number of subsystems that is        composed by. In the case of INTER-IoT, the heterogeneity of these systems and the depth in the        individual APIs can increase the overall learning curve</Known_uses_within_the_INTER-IoT>
  <Identified_by xml:space="preserve">Valenciaport Foundation</Identified_by>
  <Registration_Date xml:space="preserve">20/6/18</Registration_Date>
</Design_Pattern>

AS2AS Discovery of IoT Services

<Design_Pattern>
  <Pattern_Name xml:space="preserve">AS2AS Discovery of IoT Services</Pattern_Name>
  <Identifier xml:space="preserve">10</Identifier>
  <Layer xml:space="preserve">AS2AS Layer</Layer>
  <Inspired_by xml:space="preserve">1) “Discovery” IoT Patterns: Design Patterns for Interaction (Section: “IoT Patterns”)        2) “Enterprise inventory”: SOA Patterns (Section “SOA Patterns”)</Inspired_by>
  <Related_patterns xml:space="preserve">Other patterns, related with the describing pattern</Related_patterns>
  <Intent xml:space="preserve">This design pattern allows to register and claim the specific services, used by the platforms (within the INTER-IoT environment).</Intent>
  <Problem_and_Solution xml:space="preserve">The port authority provide a seet of services that can be used by all the companies in the port sector</Problem_and_Solution>
  <Applicability xml:space="preserve">Port authority publish the available services to be used by port companies</Applicability>
  <UML_representation>
    <url xml:space="preserve">image.png</url>
  </UML_representation>
  <Implementation xml:space="preserve">The UML diagram depicts two aspects, relevant for this pattern. First is a service registration process,        in order to provide the service as a public. Second main functionality is discovery action, i.e. claiming        the necessary service(s) by INTER-IoT artifact</Implementation>
  <Known_uses_within_the_INTER-IoT xml:space="preserve">AS2AS discovery module</Known_uses_within_the_INTER-IoT>
  <Identified_by xml:space="preserve">Valenciaport Foundation</Identified_by>
  <Registration_Date xml:space="preserve">20/6/18</Registration_Date>
</Design_Pattern>

Alignment based Translation Pattern

<Design_Pattern>
  <Pattern_Name xml:space="preserve">Alignment-based Translation Pattern</Pattern_Name>
  <Identifier xml:space="preserve">13</Identifier>
  <Layer xml:space="preserve">DS2DS Layer</Layer>
  <Inspired_by xml:space="preserve">1) “Message Translator” Enterprise Integration Patterns: Message Transformation (Section: “Enterprise Integration Patterns”)        2) “Data Model Transformation” SOA Patterns (Section: “SOA Patterns”)         3) “Metadata centralization” SOA Patterns (Section: “SOA Patterns”)        4) “Market Maker” Agent Design Patterns (Section: “Agent Design Patterns”)</Inspired_by>
  <Related_patterns xml:space="preserve">Other patterns, related with the describing pattern</Related_patterns>
  <Intent xml:space="preserve">Semantic translation of RDF messages exchanged between two IoT artifacts, based on an        alignments (set of correspondences) defined between artifacts’ ontologies</Intent>
  <Problem_and_Solution xml:space="preserve">Each of the companies in the port sector was its own data model. So if you want to exchande data with other companies, a tool is needed</Problem_and_Solution>
  <Applicability xml:space="preserve">All the data is sent through the IPSM to translate between ontologies</Applicability>
  <UML_representation>
    <url xml:space="preserve">image.png</url>
  </UML_representation>
  <Implementation xml:space="preserve">The UML diagram depicts a process of alignment-based translation between two IoT artifacts.        Translator is an external component that applies alignment i.e. performs translation. It consumes        incoming messages, applies an alignment (correspondence after correspondence), and publishes        translated message</Implementation>
  <Known_uses_within_the_INTER-IoT xml:space="preserve">IPSM component of INTER-IoT uses this pattern to execute translation between source IoT artifact        and INTER-MW (source ontology is translated to central ontology), and INTER-MW and target IoT        artifact (central ontology is translated to target ontology)</Known_uses_within_the_INTER-IoT>
  <Identified_by xml:space="preserve">Valenciaport Foundation</Identified_by>
  <Registration_Date xml:space="preserve">20/6/18</Registration_Date>
</Design_Pattern>