internet of information and services (iois)
DESCRIPTION
Research initiatives to redesign the Internet are popping up all around the globe. Some claim that the Internet must be redesigned from the information point of view. This approach goes under the banner of information-centrism. In the other hand, other initiatives claim that the design must be centered on the services, i.e. the service-centrism or the Internet of services. And there are also those focusing on decoupling host identifiers from locators to improve mobility support. Which is the right path to follow? We contend that none of them alone, but instead, to integrate synergistically them all. We call this approach the Internet of information and services.TRANSCRIPT
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
[email protected]://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
[email protected]://antonioalberti.blogspot.com