InDiNet joint research project

Innovative services in the internet of the future

"Companies - especially small and medium-sized (SMEs) - want to participate in the Internet of Services and reposition their services profitably.

PROJECT REPORT

CONWEAVER, along with 17 research and industry partners, studied architectures and methods for prospective service platforms in the German Software-Cluster project „Innovative services for the Internet of the future”. At the 2014 software fair CeBIT in Hannover, first results were presented. CONWEAVER participated in the application scenario “Emergent Mobility”.

APPs are ten a penny, but they cannot be combined yet. Imagine your next travel planning to the beach. There are countless applications and web portals like train, car rental, car sharing, flight reservation, or hotel booking. They have more or less connections to each other. Can’t this be done more easily?

Large companies such as Google or Apple compete for the “best” marketplace for single APPs, or for the cheapest offers for cloud computing, but integrative approaches still seem to be far away. Here, the project InDiNet looked for possible solutions.

HOW COULD INTEGRATIVE SERVICE PLATFORMS LOOK LIKE?

Today, cloud computing allows the outsourcing of computations into the “cloud”, a.k.a. Infrastructure as a Service (IaaS). In 2009 the National Institute of Standards and Technology (NIST) published a path breaking definition, describing – amongst other things – three layers: infrastructures (IaaS), platforms (PaaS) and services (SaaS). InDiNet used this definition as a starting point, but with an additional layer for business processes (BPaaS). Figure 1 shows the components of the InDiNet architecture.

Figure 1: InDiNet-Architecture

APPLICATION SCENARIO: EMERGENT MOBILITY

End users do not want to be bothered with technical details. They look for simple solutions. But trying to answer the question “How do I travel from A to B“, it becomes apparent that lots of technical aspects have to be considered. Which route is preferred: the fastest, the cheapest or even the most environmentally friendly, e.g. by electric car? Does a central component handle the booking at the different travel providers? Are security aspects considered? Does the option “car” also take into account current traffic jam reports for the possible routes? From CONWEAVER’s point of view it was especially interesting to investigate which types of service descriptions are applicable for which types of service discovery in such integrative platforms.

SERVICE DESCRIPTION AND DISCOVERY

To show an end user results which have “something to do” with mobility, first and foremost a semantic annotation or description of single services is required. Because services of a platform which are concerned with other topics, such as cooking recipes and ingredients, are not interesting to him. The next requirement for a service platform is to be able to address and use these “semantically proper” services also in a “technically proper” way. Further information about the type of data on which the services operate has to be considered. For mobility services, such different types of technical information could be for instance:

Geo coordinates or
textual addresses,
start- and destination positions or
range of tankful.

UNIVERSAL SERVICE DESCRIPTION LANGUAGE (USDL)

In the project the service description language USDL was used. This language may help platform providers to continually model and connect complex and reusable base services such as billing, monitoring, or security. But the modelling is complex and less usable for the simple creation of service descriptions.

For instance, a provider of a single electric vehicle charging station does not want to create a complex technical description. And usually, he does not have to. The metadata required for emergent mobility, such as geo position, socket type, opening time, etc. are already provided by different mobility portals in a semi-structured format.

But this does not help during integration with other mobility services, as the portals themselves are closed systems, i.e. proprietary provider platforms.

DATA INTEGRATION BY CONWEAVER

Therefore, CONWEAVER investigated methods to integrate semi-structured service descriptions which can work without USDL. Using the example of emergent mobility, CONWEAVER‘s methods automatically connected the semi-structured descriptions and metadata of electronic vehicle charging stations and then centrally provided them to the InDiNet platform.

Basic data is loaded
Analyzed semantically,
Networked,
Eventually provided centrally and uniformly addressable.

Figure 2: Data integration with CONWEAVER using the example of metadata on electric charging stations

During these steps complex service description languages such as USDL are not required. Instead, depending on the type of data, analysis workflows and the network structures are defined once. Then, these structures can be reused any time and fully automatic. Thus, extensive modeling and high expenditure of time for manual annotations of services is no longer required.

CONCLUSION

Today, many cloud computing technologies are available for everyone: computation on demand, platforms, services, even business processes as services (BPaaS). But it is still difficult for end users to use the multitude of single services and platforms in a coherent, combined fashion. This is partly due to the economic benefits of closed systems for the platform providers, which is a disadvantage for platform users. On the other hand, structured service description languages are still not modelling friendly enough, which is also partly due to the variety of the services themselves which have to be modelled. Here, semantic methods could help to simplify the integration of heterogeneous service descriptions.

InDiNet -Innovative Services For the Internet of the Future