Integrating SSA&I projects into the Future Internet activities Fundamental Limitations of the current Internet for the future Internet of Services Input to the Open Workshop, Brussels, 26 October 2010 From: Lyndon Nixon, STI (SOFI) Javier Vázquez-Salceda, UPC (ALIVE) Frederic Gittler, HP Labs (NEXOF-RA) Some content derived from FI-PPP white paper on FI Architecture

Transmission Critical services turn to VPNs rather than the open Internet? Services have a dependancy on the network for QoS and QoE Improved network management tools for IoS to guarantee minimum levels of QoS and QoE for critical services Fundamental limitation: service delivery today is best effort but business- and social-critical services need stronger guarantees (security, trust, reliability, fail-aware networks etc.)

Processing and handling (1) Service Economy needs value-maximisation of service QoS and support for tracking service interactions across complex workflows/BPs Should service needs like QoS, lifecycle monitoring, DRM, brokering, or billing maybe be pushed down into the Internet architecture? Fundamental limitation: dumb Internet pipes can not react to integrated context and lifecycle of service interactions (adaptability, contextual awareness, preservation of state, fallback mechanisms etc.)

Processing and handling (2a) Current Internet: interactions between distributed components are limited by technologies that are static (in structure and even on physical set-up), difficult to change and prone to failure. Development is strongly influenced by the technology platform (web, mobile net…) How it should be: development (and most of deployment) of distributed solutions should be made in a way that is independent to the physical location and underlying technology used. E.g. In the cloud, we should be able to move services from one ocation to another and theexisting compositions shoudl keep working. Fundamental limitation: current service-to-service addressing is strongly based on physical location (is part of the uri!) and technology (how shall I address a service in a mobile phone?) What is needed: a service adressing mechanism that is independent from the physical (and if possible, technology) of the services

Processing and handling (2b) Option 1: to have a Service ID that identifies it worldwide, independent from the location. Then the underlying levels are the ones responsible of routing the messages to the current location of the services as it is done in mobile phones: we don‘t need to know where the phone is, only use the full phone number with its international code to reach it). A more extreme option would be to do service addressing not by a world- wide unique id, but directly by some sort of service description. But that may not be scalable. Detachment of service addressing from the URIs is specially important if the other computational entities in the FI (things, objects, sensors, resources) are going to be described as services. This last point also brings a very important aspect: new service descriptions that can describe all the computational entities in the FI

Coordinator: Website: