Overall Design

We first model the activities carried out by the users of the tool. Users (i.e. the three stakeholders) can carry out two different types of activity in order to meet their requirements: i) assessing the

interoperability of a composition of an application/service using a pattern of FI-WARE enablers, ii) assessing the interoperability of a single enabler. The business and operational logic captured in these models can then be used to inform the further specifications e.g. the sequence models describing the operation within the component architecture.

Analysing interoperability of Future Internet services and applications using FI-WARE patterns

Figure 82: Analysing interoperability of an Enabler

Analysing interoperability of an Enabler

Figure 83: Analysing interoperability of an Enabler

3.5.6.2 Component Diagram

The Interoperability Tool follows a classic front-end, back-end architectural design. The client portion operates to collect user input regarding interoperability testing and produces the corresponding output.

In order to provide a single point of access to the XIFI tools, the XIFI portal provides a common user interface (entry point and look and feel); hence, the Interoperability Tool integrates within the overall XIFI architectural design.

The back-end architecture consists of the service elements that perform interoperability testing, and store data related to pattern-based interoperability testing. These services are designed such that the architecture can be deployed and distributed across multiple hosts for scalability and reliability reasons. The deployment of a single instances of the tool may lead to: performance bottlenecks (i.e.

multiple pattern executions waiting to be scheduled), system outages and data inconsistency.

Figure 84: The FMC compositional structure.

The FMC compositional structure figure highlights the relationships between the individual

components in the Interoperability Tool. A short functional description of each of these components is provided in the following table.

Architecture

Element Description

GUI

Interoperability Tools

Graphical user interface for the user to perform interoperability tests. This runs within a web browser, and is integrated as part of the XIFI portal web interface.

Interoperability Tools Interface

Front-end component representing the services provided by the Interoperability tool back-end implementation. Offers a single instance for the front-end to interact with i.e. it offers similar benefits to the façade pattern.

Interoperability Service

The Interoperability functions implemented as a REST service that can be interacted with using HTTP. Allows interoperability testing to be treated as a service, supporting both programmatic and interactive tools.

Pattern data service

Provides operations to list current patterns, details about the patterns, and the input form data about the patterns. Also queries the resource catalogue module in order to extract information about generic and specific enablers and specific instances of these.

Patterns &

Interoperability Rules

Data element describing a composition pattern and the interoperability rules that must be asserted for a valid execution of the pattern (used in the description of the pattern provided to the user).

Resource Catalogue Module

Component of the XIFI portal. This tool invokes the REST interface of the catalogue in order to retrieve data about enablers such that this information can be added to the description of composition patterns.

Pattern Execution Engine

Execute an instance of a pattern of enablers; monitoring the execution to observe interoperability issues. Generates an interoperability report. Individual instances of patterns are implemented as separate components e.g. an authentication pattern.

This performs the correct invocation of enablers (using correct protocols etc.)-it is the job of the execution to provide the correct input to this component and observe its outputs. Hence, new patterns can be plugged in as individual pattern

implementations.

Specification comparison service

Executes interface matcher components that are plugged in (e.g. WADL or WSDL). These simply examine differences in methods, syntax and data and produce a report to be returned by the comparison service.

Table 37- Interoperability tool - List of components

3.5.6.3 Sequence Diagrams

As defined in the activity diagrams, there are two significant behaviours carried out using the tool. We use sequence diagrams to now illustrate how the elements of the component architecture interact with one another to realise these behaviour. First we show the sequence diagram for selecting a pattern, inputting data to the pattern, executing the pattern and then producing the interoperability report that describes its behaviour. Secondly, the comparison of two interface specifications to check the compatibility of an enabler with a FI-WARE specification.

Pattern Execution Sequence

Figure 85: Pattern Execution Sequence

The user first selects the option of browse through the available patterns i.e. they wish to be shown a list of current patterns that can be experimented with:

The GUI calls an operation on the interoperability tools service interface to list the currently available patterns. These are stored in the Pattern Data Store Component and hence the service interface queries this directly.

The user selects to view one or more of these patterns using the GUI. The view pattern request sent to the service interface builds an initial document template of the pattern which is filled with further information about each of the enablers. This information (e.g. list of instances of an enabler type) is not stored in the pattern database, rather within the XIFI resources catalogue-hence the pattern data service builds a richer data structure via communication with the XIFI catalogue.

The user selects a pattern, inputs their data (URLs chosen from the XIFI instances and their own deployments) and then tells the tool to execute the pattern. The service interface interacts directly with the pattern execution engine (whose role is to co-ordinate an individual pattern implementation) to first initialise a pattern with the required input data and then execute it.

The execution trace is collected to build the interoperability report which is returned as a result of the operation and then displayed via the GUI.

Interface Comparison Sequence

Figure 86: Interface Comparison Sequence

The User first enters two pieces of information using the GUI: i) the interface description to check against (developed by the user), ii) the FI_WARE specification it should be compatible with (discovered in the FI-WARE or XIFI catalogue). These inputs are both URLs to machine processable descriptions (WADL, WSDL, etc).

The GUI calls a check compatible operation on the Interoperability Service.

The service interacts with the Specification comparison service to perform matching and comparison tests on the two interfaces.

If the interface is of type WADL it invokes the WADL-flavoured service, if WSDL the WSDL-flavour. This sequence pattern is hence extensible to future machine processable formats (e.g. USDL) without making any changes to the tool implementation.

Once the specific component performs matching, the results are collated by the Specification Comparison service and the compatibility report is generated and returned the GUI for display.

3.5.6.4 Graphical User Interface (GUIs)

Given the previously identified requirements we now design the interface of the tool (i.e. specifically how it will be used). The aim is for the tool to be general purpose i.e. it isn’t designed for one stakeholder in particular; rather it is general purpose but will satisfy all of the use case diagrams specified in the previous section. The following are a sequence of screen mock-ups that illustrate how the tool will behave.

1) Start & Authentication

Any user who with access right to use the XIFI federation tools can use the Interoperability Tools;

there are no requirement to restrict certain types of behaviour to different user roles. Hence, the Interoperability Tool uses the general XIFI marketplace login for access control. Once logged in the user is presented with the XIFI marketplace; the available tools are presented in the form of a tool bar at the top of the screen. In order to use the interoperability tool the user selects the Interoperability hyperlink from the bar.

2) The Interoperability Tools Home Screen

When the Interoperability link is selected from the XIFI marketplace the user is presented with the initial home screen of the Interoperability Tool. This provides a wiki documentation of how to use each of the three tools. These three tools are available as tab links on the home page in order to allow easy navigation between information and the different tools. The user can then select either of the three tabs to start using a particular tool.

Figure 87: GUIs - Interoperability Tools Home screen.

3) Pattern-based Interoperability Testing

If the user selects the Pattern-based Interoperability Tests tab they are presented with the screen in following screen. Here they can select from a list of implemented patterns (available from the tool) presented as a drop down list. Once a pattern is selected from the list the tool transitions to the next screen. This presents a visual representation of the pattern i.e. detailed information about how enablers integrate (with each other and/or external SEs).

This behaviour satisfies the use cases:

Search enabler pattern (FI application developer) Select software pattern (FI application developer) Select GE patterns (Enabler developer)

Figure 88: GUIs - Pattern-based Interoperability Testing

The following screen is also an input screen for the Interoperability tests. Within the pattern are text boxes where URLs of the enablers (the components leveraged in the sequence) must be entered. Once entered the pattern has now been concretized for specific deployments. Clicking test interoperability button will execute the pattern, monitor the behaviour and then output a report of the interoperability problems. This output report is presented via a text box in the GUI and is shown in the next screen.

Figure 89: GUIs - Output report

This behaviour satisfies the use cases:

Integrate application with pattern (FI application developer) Execute software pattern (FI application developer)

Monitor application execution (FI application developer) Read Interoperability report (FI application developer)

Check behaviour interoperability (Enabler developer) – however using multiple patterns (see Enabler compatibility tests which presents a list of patterns per enabler)

Check behaviour interoperability (Infrastructure owner)

Figure 90: GUIs - Check behaviour interoperability 4) Interface Compatibility Testing

If the user selects the Interface Compliance Tests tab they are presented with the following screen.

e.g. in WSDL or WADL. The second is the URL of new interface to check compatibility – this must be in the same format i.e. WSDL or WADL. When the user clicks compare a list of the differences between interfaces is presented in the comparison report. This behaviour satisfies the use cases:

Execute Interface comparison test (FI application developer) Check interface compatibility (infrastructure owner)

Figure 91: GUIs - Interface Compatibility Testing

5) Enabler Interoperability Checking

If the user selects the Enabler Compatibility Tests tab then they are presented with the following screen. The key behaviour here is basically an aggregation of the pattern tests. For a given enabler, multiple pattern tests can be executed automatically to indicate the interoperability of a newly developed enabler. The list of enablers (having a test suite) is presented in a drop down box to be selected. The user also enters the URL of the new enabler to test and then they click the “compatible“

button. Multiple tests are executed and monitored and the results are reported in the compatibility report box.

This satisfies the use case:

Check behaviour interoperability (Enabler developer)

Figure 92: GUIs - Check behaviour interoperability

3.5.7 Interfaces exposed (REST)

This section describes the external services interface provided by the Interoperability Tool service.

This minimal interface provides operations to use the interoperability operations programmatically and/or update the state of the resource patterns.

Resource Summary

Figure 93: API REST

Authentication

Each HTTP request against this API requires the inclusion of specific authentication credentials.

Faults

Error code Description 200 OK

201 Created 304 Not Modified 400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found

500 Internal Server Error

API Operations

The operations are detailed in the Appendix D.

3.6 Security and Privacy Dashboard