INTER-METH -- Design Phase: How to analyze the integration of two heterogeneous platforms using INTER-METH for INTER-Health 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-Health 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 BodyCloud and UniversAAL platforms.

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: INTERM Message Translator.

Figure 3c: Instantiated INTER-IoT Patterns: INTERM Self-contained Message.

(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">My_Message_Server_Broker</Pattern_Name>
  <Identifier xml:space="preserve">02</Identifier>
  <Layer xml:space="preserve">MW2MW Layer</Layer>
  <Inspired_by xml:space="preserve">Broker Iot Patterns</Inspired_by>
  <Related_patterns xml:space="preserve">My_SelfContained_Message</Related_patterns>
  <Intent xml:space="preserve">A component that facilitates passing of messages between decoupled INTER-Health components.</Intent>
  <Problem_and_Solution xml:space="preserve">Having point-to-point communication interfaces among several interacting components, makes dynamic reconfiguration, matching of different security constraints and QoS, requirements between components difficult. The employment of a message broker, can help to overcome limitations of point-to-point connection and enforce a common messaging interface upon different middleware components. </Problem_and_Solution>
  <Applicability xml:space="preserve">Each Inter-Health component communicates directly only with the message server broker which in turn handles the communications and dispatches messages to the respective destination component.</Applicability>
  <UML_representation>
    <url xml:space="preserve">.</url>
  </UML_representation>
  <Implementation xml:space="preserve">There is a message broker service that analyzes each received messages to check is there exists a subscription for the user that sent the message. If a subscription exists, the broker obtains (from the subscription message initially received) the necessary information to send the current message. If the subscription does not exist, the message is not forwarded to the external middleware components.</Implementation>
  <Known_uses_within_the_INTER-IoT xml:space="preserve">.</Known_uses_within_the_INTER-IoT>
  <Identified_by xml:space="preserve">Pino Caliciuri and Raffaele Gravina</Identified_by>
  <Registration_Date xml:space="preserve">10-April-2018</Registration_Date>
</Design_Pattern>

INTERMW Message Translator

<Design_Pattern>
  <Pattern_Name xml:space="preserve">My_Message_Server_Broker</Pattern_Name>
  <Identifier xml:space="preserve">02</Identifier>
  <Layer xml:space="preserve">MW2MW Layer</Layer>
  <Inspired_by xml:space="preserve">Broker Iot Patterns</Inspired_by>
  <Related_patterns xml:space="preserve">My_SelfContained_Message</Related_patterns>
  <Intent xml:space="preserve">A component that facilitates passing of messages between decoupled INTER-Health components.</Intent>
  <Problem_and_Solution xml:space="preserve">Having point-to-point communication interfaces among several interacting components, makes dynamic reconfiguration, matching of different security constraints and QoS, requirements between components difficult. The employment of a message broker, can help to overcome limitations of point-to-point connection and enforce a common messaging interface upon different middleware components. </Problem_and_Solution>
  <Applicability xml:space="preserve">Each Inter-Health component communicates directly only with the message server broker which in turn handles the communications and dispatches messages to the respective destination component.</Applicability>
  <UML_representation>
    <url xml:space="preserve">.</url>
  </UML_representation>
  <Implementation xml:space="preserve">There is a message broker service that analyzes each received messages to check is there exists a subscription for the user that sent the message. If a subscription exists, the broker obtains (from the subscription message initially received) the necessary information to send the current message. If the subscription does not exist, the message is not forwarded to the external middleware components.</Implementation>
  <Known_uses_within_the_INTER-IoT xml:space="preserve">.</Known_uses_within_the_INTER-IoT>
  <Identified_by xml:space="preserve">Pino Caliciuri and Raffaele Gravina</Identified_by>
  <Registration_Date xml:space="preserve">10-April-2018</Registration_Date>
</Design_Pattern>

INTERMW Self-contained Message

<Design_Pattern>
  <Pattern_Name xml:space="preserve">My_SelfContained_Message</Pattern_Name>
  <Identifier xml:space="preserve">1</Identifier>
  <Layer xml:space="preserve">MW2MW Layer</Layer>
  <Inspired_by/>
  <Related_patterns/>
  <Intent xml:space="preserve">Each message contains all the information needed to subscribe or unsubscribe to a given topic (or conversation)</Intent>
  <Problem_and_Solution xml:space="preserve">BodyCloud and UniversAAL need to communicate. To do so, however, it is necessary to know where one platform has to send the messages to the other platform. Hence, the identified solution is the creation of a subscription mechanism to conversations.</Problem_and_Solution>
  <Applicability/>
  <UML_representation>
    <url/>
  </UML_representation>
  <Implementation xml:space="preserve">A bridge component of INTER-MW will process the messages to perform the proper action (i.e. subscription or unsubscription) . The bridges then registers a corresponding callback to the action, in case of subscription message.</Implementation>
  <Known_uses_within_the_INTER-IoT/>
  <Identified_by xml:space="preserve">Pino Caliciuri and Raffaele Gravina</Identified_by>
  <Registration_Date xml:space="preserve">05-April-2018</Registration_Date>
</Design_Pattern>