Internet of Information and Services(IoIS)

Antônio Marcos Alberti, Rodrigo Carneiro Brandão, Agostinho Manuel Vaz, Bruno Magalhães Martins

Instituto Nacional de Telecomunicações - Inatel 510 João de Camargo, Santa Rita do Sapucaí, Minas Gerais, Brazil

alberti@inatel.brhttp://antonioalberti.blogspot.com

Outline

• Contextualization

• Design Principles and Choices

• Architectural Components

• Highlighting the Architecture by an Example

• Related Work

• Conclusion

Contextualization (1/2)

• Research initiatives to redesign the Internet are popping up all around the globe.

• Some initiatives focus on information exchanging, a.k.a. information- or content-centric design, e.g. content-centric networks like NetInf, CCN, PSIRP, NDN.

• Others, focus on service orchestration, a.k.a. service-centric design, e.g. everything-as-a-service or Internet of Services (IoS) approaches, like SOA4ALL, CASCADAS, S-Cube.

• And, there are those concerned with mobility and multihoming support, a.k.a. ID/Loc splitting approaches like MOFI.

Contextualization (2/2)

• Is there a the right path to follow?

• Argument: Why not to integrate them all?

• We call this approach the Internet of Information and Services (IoIS).

• The IoIS paradigm is already being employed on a broad architecture called NovaGenesis.

• This paper proposes a conceptual architecture based on this idea.

Design Principles and Choices (1/2)

• Identification of architectural residents

• Relate legible and self-certifying names

• Dynamic compose-ability and hierarchical modularity

• Resolve indirections generically and recursively

• Use publish/subscribe paradigm

• Accommodate search and discovery

• Cover social relationships among entities

Design Principles and Choices (2/2)

• Accommodate the growth on interactivity

• Design for built-in security, privacy, and trust

• Accommodate neutrality, openness, diversity, flexibility, and extendability of services and applications

Architectural Components (1/2)

• HTS (Hash Table System): A set of processes that stores name-based bindings among entities.

• GIRS (Generic Indirection Resolution System): A process used to decide the most appropriate Hash Table to store some name-based binding.

• PSS (Publish/Subscribe System): It does the rendezvous between publisher and subscriber.

• OBS (Orchestration Broker System): It helps simple services to search, discover, negotiate, and contract service partners.

Architectural Components (2/2)

• RS (Reputation System): It is responsible to determine entities reputation based on the feedbacks received from partners in established SLAs.

• DS (Domain System): It is aimed to actively represents all the systems in a domain.

• SDS (Search and Discovery System): It performs recursive subscriptions to the PSS and filters results according to semantics and context.

Highlighting the Architecture by an Example

Operating System

HTS

PSS

GIRS

Host Hardware

SDS

Operating System

HTS

OBS

RS

DS

Op. System

HTS

Service 1

Service2

Service reputation

management

Host Software

Secure pub/sub of ID-based bindings

Semantics rich search and

discovery

Broker to store ID-based

bindings.

Storage of ID-based bindings.

Active domain representation

Service instance

Service discovery and

SLA establishment.

Storage of ID-based bindings.

ID

ID

Other IDs

Information Object

Hash Table

1

2, 63, 7

4

5

8

9(1) Service 2 publishes the bindings:

< ID, Descriptor >, < ID,”Message” >, < ID,”Service” >, < ID,”Message Service” >

(2) The PSS forwards the bindings to the domain GIRS

(3) The GIRS selects the appropriate HTS, which stores

the binding.

(4) The Service 1 asks the SDS about a “Message Service”.

(5) The SDS subscribe the names “Message”, “Service”, and

“Message Service”.

(6) The PSS forwards to GIRS.

(7) The GIRS selects the appropriate HTS, which gets the

related binding.

(8) The SDS receives the bindings and filters the one related to the word

“Message”. It subscribes the Service 2 ID.

(9) The SDS answers the Service 1 with the Service 2 <ID, Descriptor> binding.

Continuing:The Service 1 publishes an SLA.

The Service 2 subscribes the SLA. The Service 2 publishes it again with its

ID, accepting the agreement.

Related Work (1/2)

• Only three closely related works have been considered:

• Expressive Internet architecture (XIA).

• Scalable and adaptive Internet solutions (SAIL), which includes network of information (NetInf).

• Component-ware for autonomic situation-aware communications, and dynamically adaptable services (CASCADAS).

Related Work (2/2)

Aspect IoIS XIA NetInf CASCADAS

Naming

Bindings among legible and self-certified

names for any entity and content.

Similar feature, but right now limited to hosts, services, and content.

Self-certified names and legible

information as metadata.

Does not provide explicit mechanisms.

TraceabilityID-based traceability

to all residents.

Transportation of correct content from

the right service, at the right host.

Supports traceability of content ownership.

Does not provide explicit mechanisms.

SecurityPub/sub. Self-certifying

IDs. Self-certifying IDs.Pub/sub. Self-certifying IDs.

Social control for self-preservation.

Search and Discovery

Based on published ontology and descriptors.

Similar feature. Published names and metadata.

Specific pub/sub protocol for service search and discovery.

Compose-ability

Distributed (per se) or centralized (via OBS)

orchestration.

Does not cover explicit service orchestration

mechanisms.

Autonomic self-management of

services is supported by 4WARD INM.

Autonomic life-cycle management of

services.

Conclusion

• Our proposal cohesively integrates information- and service-centric approaches, ID/Loc splitting, pub/sub paradigm, search and discovery, besides other ingredients, in an unique architecture.

• Compared to the related work, IoIS addresses:

• Naming and traceability issues not covered in CASCADAS.

• Dynamic ID-based orchestration and life-cycling management that is missing on XIA.

• Integrated information and services life-cycling capabilities.

감사합니다!Thank you!Obrigado!

Antônio Marcos Alberti

Instituto Nacional de Telecomunicações - Inatel 510 João de Camargo, Santa Rita do Sapucaí, Minas Gerais, Brazil

alberti@inatel.brhttp://antonioalberti.blogspot.com