Service-Centrism, Neutrality, Openness, Diversity, Extendibility, Flexibility and Usability

Service-centrism, Neutrality, Openness,
Diversity, Extendibility, Flexibility and Usability
Antônio Marcos Alberti
alberti@inatel.br
antonioalberti@gmail.com
http://antonioalberti.blogspot.com/
www.inatel.br/docentes/alberti
© Antônio M. Alberti 2011
Topics
 End-to-end Principle
 Neutrality of Applications
 Exposition of Substrate Resources
 Service-centrism
 Internet of Services
 Benefits for Users
 Digital Business Ecosystems
 Some Approaches for Internet of Services
1
End-to-end Principle
 The end-to-end principle is one of the central principles of
current Internet.
 No application level functionality can be placed at the network

layer.
 IP design was kept to a minimal: “dumb network” with “smart
hosts” model.
 The model favored network applications neutrality, innovation

potential, openness, diversity, extendibility and flexibility.
 “The WWW is perhaps the most significant result of such

approach”, (Akari v2.0, 2010).
Neutrality of Applications
 This history may repeat itself!
 Nobody knows for sure what will be the most successful
applications in a few decades.
 A generic (usage independent) information network is required.
 Co-existence of evolvable, extendible, flexible

service/application frameworks over such generic information
network is desired.
2
Exposition of Substrate Resources
 Substrate resources, such as transportation, processing,
storage and others could be properly exposed to overlying
frameworks in order to allow services and applications
compose-ability and orchestration, as well as their life-cycles
management.
 Services and applications are information treatment processes,

dynamically build, from available descriptors/metadata.
 Virtualized resources could be customized to adequately

support service needs, creating resource-aware services and
applications.
 E.g. virtual service networks.
Service-centrism
 Software design is changing from component-based to service
oriented design, giving rise to what has been called service-
centrism.
 E.g. SOA (Service Oriented Architecture).
 The idea is that applications can be flexibly and dynamically

constructed by the composition of distributed software services
or utilities.
Dependability will be a Scalability and cross-domain
problem and will require App operation will be needed.
appropriate treatment.
S8 S9
S7 S6 S5
S4 S3 S2 S1
Basic building blocks become available to compose other services.

3
Service-centrism
 Service/applications life-cycling is dynamic, distributed and
cross-domain.
 It starts when a new service-based application is invoked.
 It involves the search, discovery and selection of candidate

services.
 Third party software can be used, which could not be under the
control of developers.
 In order to facilitate compose-ability, seamlessly service

describing, publishing, discovering and negotiating will be
necessary.
Service-centrism
 Like the colors of the flowers help to attract bees, the
descriptors of services will be important to facilitate the selection
of the most appropriate
services to compose
a given application.
 Examples of attributes are “capacity, throughput, QoS, latency,

protocol support, availability, security, etc., in a consistent
format. They need to express cost and availability, scalability,
and potentially elasticity and support for usage variations”,
(MANA, 2009).
 Service information could be published in divulgation services.
4
Service-centrism
 Negotiation will be necessary to establish a SLA (Service Level
Agreement) or a service binding.
 During negotiation phase, an admission control should be

performed to verify if resources are available to attach the
desired service to one more application.
 If yes, admission installation proceeds to configure the service.
 To assure that the desired quality is being achieved, service

monitoring is necessary as well as logging and exception
handling.
Service-centrism
 A lot of service management functionality is required, e.g. to
deal with failures, accountability, quality, availability, resilience,
etc.
 Autonomic service management is indicated to reduce human

intervention and OPEX.
 Changes in the application behavior can reflected in the

inclusion or elimination of participating services, as well as the
changes in SLAs.
 When the application turns off, used resources must be

released.
5
Internet of Services
 For many people, the service-centrism paradigm will be
dominant in the upper portion of a new Internet.
 According to Pasic, “Today, data and information are used

pervasively in distributed networks and applications, while
frontier between objects and users is blurring. What is really
linking all these future internet components is notion of
services.”
 One of the main justifications is that “above a certain level of

abstraction everything can be viewed as a service leading to the
concept of the Internet of Services”.
 “Internet of Services – Supporting the service economy (70% of

GDP in modern societies),” (Villasante, 2009).
Internet of Services
 Everything as a Service (XaaS), e.g. from cloud computing:
 SaaS (Software as a Service) - Delivers cloud applications a
service.
 PaaS (Platform as a Service) - Delivers a platform and/or solution
stack as a service.
 IaaS (Infrastructure as a Service) - Delivers computer
infrastructure (cloud of virtualized resources) as a service.
 DBaaS (Database as a Service) – Access to database as a
service.
 “The term Internet of Services is an umbrella term to describe

several interacting phenomena that will shape the future of how
services are provided and operated on the Internet,” (Cross-
ETP, 2009).
6
Benefits for Users
 From user’s perspective, the benefits are very promising:
 Self-servicing Capabilities – Users can configure themselves
exactly what they want.
 Improved Usability – Personalization and contextualization
(context-awareness) can be achieved in applications, varying
features according to user preferences.
 Semantic Invocation – “services can be flexibly detected and
invoked based on semantically rich inference rules relying on
properties describing context”, (Cross-ETP, 2009).
 User Designed Applications – Finally, users will be able to create
their own applications and export them to their friends. Therefore,
the diversity and quantity of applications will be tremendous.
Digital Business Ecosystems

 The dynamic service compose-ability idea could be used to
integrate business processes with applications and services,
creating the so called Digital Business Ecosystems (DBEs).
 Perhaps, such DBEs will be the new savannah, where a

diversity of services, applications, business processes,
operators, users, enterprises and other entities will live,
compete, collaborate, die and evolve together.
7
NESSI Networked European Software and Services Initiative
 “NESSI is the European Technology Platform dedicated to
Software and Services,” www.nessi-europe.com.
 According to Pasic, “European Technology Platforms (ETPs)

were proposed by the European Commission as an instrument
to address innovation challenge in a coherent way and in
domains that are strategic to Europe’s economy”.
 NESSI was launched in 2005. In 2007, NESSI decided by

specifying a platform to put into practice their visions: The Open
Service Framework (OSF).
 The first step in implementing this OSF is under the

responsibility of NEXOF-RA (NESSI Open Framework
Reference Architecture) project.

 NESSI OSF relies on the combination of SOA, virtualization and
autonomous software [X-ETP 2010]:
 to increase software modularization;
 to facilitate development by dynamic composition;
 to create a “new software industry eco-system, offering new
business concepts like SaaS”, X-ETP 2010;
 to decouple software components from the substrate resources;
 to facilitate deployment and reduce human interference;
 to expose “everything as a service” or XaaS;
 to create a highly dynamic XaaS environment;
 to deal with cross domain (seamless) services and infrastructures;
 to converge ICT and “media content services”;
 to create a “kind of network operating system” where substrate
resources are managed autonomously;
8
 to enable service self-adaptation according to context and
semantics;
 to optimally allocate required substrate resources for services and
applications;
 to enable context-aware personalized experience for users;
 to allow context-aware service invocation;
 to allow users to create their own services (self-servicing) through
new “service front-ends”;
 to allow users to export their designed services/applications;
 to standardize “service expression in cloud computing services”,
X-ETP 2010.
 to improve Trust, Security and Dependability (TSD model).
 to include services policies, rules, goals, negotiation,
accountability, monitoring, regulatory compliance, etc.

 “The Open Service Platform will incubate the creation of a new
open marketplace of services, infrastructure and content by
providing a self-organising and adaptive distributed service
environment enabling the federation of networked resources
while securing individual asset of the key players,” X-ETP 2010.
 The X-ETP vision is that the IoS will emerge in a diversity of

service layers (*aaS), contextualized, personalized, dynamically
composed, decoupled from substrate resources and
autonomously managed.
9
FISO Future Internet Service Offer
 FISO is a cluster of the European Union's Future Internet
Assembly initiative.
 Its mission is to provide adequate means to integrate, interrelate

and interwork FI overlay service/application frameworks using
service-based interfaces.
 The role of services and applications in FI is also being explored

by FISO.
FISO Future Internet Service Offer

 FISO is present at the discussions in how to develop a FI
Reference Architecture.
 Some FISO affiliated projects are:

 RESERVOIR, SLA@SOI, PERSIST, S-CUBE, MASTER,
SOA4ALL, NEXOF-RA.
 Many NESSI projects are also members of FISO cluster.
10
RESERVOIR
FISO
Resources and Services Virtualization without Barriers

 The project goal is “to develop an ICT infrastructure for reliable
and effective delivery of services as utilities,” EC 2008.
 According to project researchers, to massively scale cloud

computing resources is a challenge even for big providers.
 Thus, the project proposes to interwork clouds of partner

providers to better use available federated resources and thus
improve scalability.
 All the technologies required for collaborating clouds are in the

scope of the project.
 “Cloud Computing represents a true materialization of Service-

Oriented Computing's visionary promise”, http://www.reservoir-fp7.eu .
SLA-SOI
FISO
Service Level Agreement at Service Oriented Infrastructure

 The project goal is “to define a holistic view for the management
of SLAs and to implement an SLA management framework that
can be easily integrated into a service-oriented infrastructure
(SOI),” EC 2008.
 SLA-SOI already developed a SLA Management Framework

that:
 Receives SLA offers from costumers;
 Provides multi level (from business level to VM level) virtualized
resources admission control;
 Provides automated installation and resource reservation
according to negotiated SLA;
 Improves services predictability and dependability;
 Determines counter actions and VM restarts, when necessary;
 Provides SLA enforcement.
11
SOA4ALL
FISO
Service Oriented Architectures for All

 Envisages the incorporation of context-aware technologies,
semantic web and web 2.0 to SOA in order to create a
framework and software infrastructure for seamless and
transparent service delivery.
 The ideia is to create a scalable “service web”, where a huge

number of stakeholders can expose and consume services.
 The objective is to create a global service delivery platform that

can scale to billions of services.
 SOA provides the means to change from software to

serviceware.
SOA4ALL
FISO

 The web 2.0 facilitates use and enables prosumers paradigm.
 The semantic web enables “meaningful service discovery and

mediation”, Pedrinaci 2009.
 It includes context-awareness to better understand user needs,

to meet environment limitations and policies.
 It includes tools for services lifecycling management, user

friendly service composition, provisioning and analysis
(SOA4ALL Studio).
 Support for LPM (Lightweight Process Modeling) to enable

ease-to-use business process modeling, search for
appropriated services and automatic composition.
12
SOA4ALL
FISO
Goals
Users Services
Source: Ristol, 2009.
 The architecture also have a Distributed Service Bus (DSB) to

create semantic enabled communication among all services and
applications.
 Also, platform services provide basic service related functioning,

such as service discovery, ranking, selection, composition and
invocation.
SOA4ALL
FISO

 Simplified Architecture
SOA4ALL Studio (web-based front-end)

User friendly service composition, provisioning and analysis.
Distributed Service Bus

Semantic enabled communication.
SOA4ALL Platform Services

Service discovery, ranking, selection, composition and invocation.
Source: Pedrinaci, 2009.
13
MASTER
FISO
Managing Assurance, Security and Trust for Services

 The objective is to develop tools to monitor, enforce and audit
security, trust, privacy and dependability of services and
business processes in SOA environments.
 The main idea is to simplify compliance enforcement in such

environment.
 A conceptual model was developed, where:

 Requirements among substrate infrastructure, SOA and policy
layers were defined;
 Quantitative indicators were defined;
 A service ontology was developed to increase expressiveness.
S-Cube
FISO
Source: S-Cube Book, 2010.
 S-Cube is an European network of excellence on software

services and systems.
 It aims to identify and address research challenges behind the

Internet of Services.
 According to S-Cube, “software services (or simply services)

constitute self-contained computational elements that support
rapid and flexible composition of loosely coupled distributed
software systems”, S-Cube Book 2010.
 Several challenges related to services lifecycling were

investigated and structured in a research framework.
14
S-Cube
FISO

 According to changes in the business environment and in
context, service-based systems need to adapt themselves.
 They need to be evolvable and support services/processes

collaboration and competition.
 Dynamic service agreements as well as QoS and QoE

monitoring are a key aspects.
 Autonomic (self-*), pro-active and holistic approaches are

required in the entire service lifecycling.
 Application-awareness and context-awareness are relevant to

successfully meet customer expectations.
S-Cube
FISO
 To describe the context related to SBAs (Service-Based

Applications), it is necessary to use context modeling and
reasoning approaches.
 Service discovery, selection, negotiation, composition,

coordination, adaptation and monitoring depend on context
information.
 In general, service lifecycling depends on context and

semantics.
 Cross domain support for SLA mgt, quality, context, self-*, life-
cycling mgt, composition and coordination is required.
15
S-Cube
FISO
 Not only service composition is needed, but also service

fragmentation.
 The ideia is to enable outsourcing, load balancing, reusability,

coherence and decomposition of complex business processes.
 Service engineering and design “provides the principles,

techniques and methods that interweave and exploit the
mechanisms provided by the technology stack with the aim of
developing high-quality service-based systems.”
S-Cube
FISO
 Overview of the S-Cube research framework:
Services Technologies Layers

Service Business Process Management (BPM) Service
Adaptation Engineering
and and
Monitoring Composition and Coordination (SCC) Design
(SAM) (SED)
Service Infrastructure (SI)
Service Quality, Negotiation and Assurance (SQ)
The project dedicates a book chapter for each component and

addresses the complex interrelationships among them.
16
NEXOF-RA
FISO
NESSI Open Framework Reference Architecture

 NEXOF-RA aims to build a coherent and consistent Reference
Architecture for the NESSI Open Service Framework (OSF), EC
2008.
 The project aims to define concepts, guidelines, principles,

reference models, patterns, reference specifications and
standards for the NESSI OSF.
 Also, a proof-of-concept and a roadmap for its adoption is

planned.
 NEXOF project coordinates the contribution process of the other

5 NESSI Strategic projects: EzWeb, MASTER, RESERVOIR,
SLA@SOI and SOA4All.
NEXOF-RA
FISO

 The Motivation
 The need to facilitate integration, federation, interoperability,
extendability, interconnectivity, intercooperability and openness of
Service-Based Software Systems (SBSSs).
 Examples of SBSSs are cloud computing, internet of services, internet
of things and web 2.0/3.0.
 The need for an open, coherent, comprehensive, holistic and

consistent reference architecture for SOA-based architectures.
17
NEXOF-RA
FISO

 The Idea
 To specify a NEXOF Reference Architecture (NEXOF-RA) that can be
used to derivate NEXOF Compliant Architecture Specifications (NCASs),
describe NEXOF Compliant Architectures (NCAs), and latter to enable
implementation of NEXOF Compliant Infrastructures (NCIs) and
Compliant Platforms (NCPs).
NEXOF-RA
derived from
“Each NCP is built by

NCAS 1 NCAS 2 NCAS N
integrating a set of pluggable
platform-components, it is describes a
federated, and can co-operate NCA
with other NCPs through
that has a
platform-services that build on
a specific set of software NCI
which federates several
technologies,” D6.3 v1.0 2010.
NCP 1 NCP 2 NCP N
NEXOF-RA
FISO

 The Objectives
 To make easier the reuse of successful “service-oriented concepts
and patterns,” D6.3 v1.0 2010.
 To guide designing and implementation of compliant SOA-based
architectures.
 To specify the conceptual view of an “operating system for
services and service-oriented applications,” D6.3 v1.0 2010.
 To address availability, scalability, security, manageability,
usability, reusability, dependability, extendability and service life-
cycling of SOA-based architectures.
18
NEXOF-RA
FISO

 The Requirements
 NEXOF-RA Deliverable D10.1 provides a detailed collection of 42
requirements for service-centric architectures:
 “SLA processing (R1), Uniform service representation (R2), Service discovery mechanisms
(R3), Decentralised architecture (R4), Service description (R5), Service deployment (R6),
Service decommissioning (R7), Int. and fl. comm. standards (R8), Federated (temporal) identity
management (R9), Location based routing (R10), Services integration by semantic mash-up
(R11), Harmonization of het. inf. sources (R12), Integration with legacy applications (R14),
Adaptive deployment (R15), Workflow management and integration (R16), Aided configuration
(R17), Modelling capabilities (R18), Technical interoperability (R19), Device integration / vertical
integration (R20), Distributed workflow (R21), Stateful, device adaptive service transfer (R22),
Adaptability (R23), Rapid reconfiguration (R24), Integrity (self-diagnosing and self-healing)
(R25), Dependability for device integration (R26), Compliance to privacy, and security policies
(R27), Collaborative bus. proc. acq., mod. and eff. M. (R28), Distributed architecture (R29),
Integration of services (R30), Monitoring and reliability (R31), Orchestration (R32), Trust and
confidence (R33), Service discovery (R34), Information as a service (R35), Execution of human
based process steps (R36), Information integration (R37), Distributed transaction support (R38),
Non repudiability of data transfer (R39), Cross-certification (R40), Resilience & Continuity of
service (R41), 3D virtual env. services supp. and int. (R42).”, NEXOF-RA D10.1.
NEXOF-RA
FISO

 The Nine Concerns [D6.3 v1.0 2010]
 Services – To support services life-cycling;
 Messaging – To create “loosely-coupled” message driven service
interaction model;
 Discovery – To enable service discovery, improving reusability;
 Composition – To enable business-driven service composition;
 Analysis – To determine service fitness regarding business goals;
 Presentation – To specify high usability service front-ends;
 Management – To address monitoring, management and
governance of reference architecture entities;
 Security – To address security levels, privacy and policies;
 Resources – To manage and monitor NICs infrastructure, i.e.
substrate resources;
“From 9 concerns to 125 functionalities,” Gittler 2nd International
SOA Symposium 2009.
19
NEXOF-RA
FISO

 The Reference Architecture
 It was elaborated using a pattern-based design approach, where
each pattern limits and specifies functionalities to achieve a
certain level of quality.
 See Thomas Erl SOA Design Patterns: http://www.soapatterns.org/
 It has three elements [D6.3 v1.0 2010]:

1. Guidelines and Principles
 Principles of design used in the NEXOF-RA.
 Reference properties of components and design patterns.
 Guidelines for instantiation of architecture according to requirements.
2. The Reference Architecture Model
 Technology, solution and implementation independent conceptual view.
3. The Reference Architecture Specification
 Specifies how to achieve desired functionality by means of design
patterns, components and standards.
NEXOF-RA
FISO

 The Reference Architecture
Reference Specification Guidelines

and Principles
Patterns
Standards
Reference
Catalog
Top Level
Overall architecture. e.g. Enterprise SOA, Model
Internet of Services, Cloud and IaaS
Conceptual View:
NCA, NCI, NCP,
Context, Structure,
Abstract Design Behavior, Functionality,
Specific architecture parts. Service,
e.g. Service discovery. Software Service,
Components
UML.
Catalog
Implementation
How to implement specific architecture parts.
Source: Deliverable 6.3 v1.0, NEXOF-RA, June 2010.
20
Future Enabling Technologies
 “FET is the FP6 IST Programme nursery of novel and emerging
scientific ideas. Its mission is to promote research that is of a
long-term nature or involves particularly high risks,
compensated by the potential of a significant societal or
industrial impact.”, FET http://cordis.europa.eu/ist/fet/
 The initiative founded four integrated projects that started

activities in January 2006:
 CASCADAS
 BIONETS
 HAGGLE
 ANA
Source: http://cordis.europa.eu/ist/fet/
Component-ware for Autonomic Situation-aware Communications, and

CASCADAS
FET
Dynamically Adaptable Services
 The project developed an Autonomic Services Framework

where [Baresi et al. 2009]:
 Context-aware autonomic services can self-organize to create
self-emergent service-based applications;
 Autonomic services can self-adapt to reflect situational changes,
which ultimately allows services to self-evolve to best meet their
goals;
 Autonomic communications are used to achieve situation-
awareness;
 Autonomic services are self-similarly designed in order to use the
same structure at different scales;
 Complex applications can emerge from the self-aggregation of
simpler services;
 Applications can be federated autonomously to dynamically meet
new demands;
21
CASCADAS
FET
 Autonomic services can configure themselves according to a

functionality repository;
 Self-healing enables autonomic services to detect failures and
self-repair;
 Autonomic services are able to protect themselves from other
services anomalies and recover from them;
 Cooperative self-monitoring enables the framework to support
automatic pervasive supervision, i.e. self-management;
 Trust relationships among autonomic services can improve
security;
 The framework is based on a common abstraction called

Autonomic Communication Element (ACE).
 Each ACE has two parts: common and specific.


CASCADAS
FET

 The common part is available in all instances, while the specific
part specializes ACEs for particular purposes.
 ACEs discover each other through messages passing in a peer-

to-peer overlay network.
 “For cooperation, ACEs can “contract” each other (form a

group). This creates a direct communication channel between
partners”, Benko 2008.
 Therefore, there are two moments: service discovery and

service provisioning by means of the formation of a cluster of
ACEs.
22
CASCADAS
FET
 ACEs are formed by internal organs:

 Facilitator: It enables behavior self-adapting to autonomously react
to context changes. It creates, modifies and removes Plans. It
does reasoning and decision making.
 Executor: It executes the Plans and check if everything worked
accordingly.
 Functionality Repository: It stores the codes for functionalities
already deployed.
 Gateway: It takes care of communication with other ACEs (peer-
to-peer overlay and direct channels).
 Manager: It provides life-cycle management and inter-organ
communication.
 Supervision: It configures how supervision will take place and
triggers monitoring and healing.

CASCADAS
FET
 Two main project results are:

 ACE Autonomic Toolkit: It is a Java open source that implements
CASCADAS Autonomic Service Framework.
 Available at http://sourceforge.net/projects/acetoolkit/.
 “LICAS: Build lightweight networks of service-based components

(SOA). Autonomous behaviour with new self-organising
mechanism. Default communication is XML-RPC, but Web
Services invocation also possible. Java J2ME compatible”.
 Available at http://sourceforge.net/projects/licas/.
23
References
 European Commission, “The Future of the Internet: A
Compendium of European Projects on ICT Research Supported
by the EU 7th Framework Programme for RTD”, 2008.
 Pedrinaci, C., “Lightweight Semantic Annotations for Services

on the Web”, SSAIE 2009.
 Ristol, S., “Enabling a Web of Billions of Services”, SW 2009.
 S-Cube, “The S-Cube Book”, August 2010.
 De Panfilis, S., "FISO architecture of the Future Internet", FIA

Workshop– FISO Session May 2009.
References
 Gittler, F, "NEXOF: An Approach for Service‐based System
Architectures", 2nd International SOA Symposium, October
2009.
 Pasic, A., “Delivering Building Blocks for Internet of Services:

Trust, Security, Privacy and Dependability”, Book Chapter, New
Network Architectures, 2010.
 Benko, B. K., “Autonomic Communication Elements

and the ACE Toolkit”, ACE Toolkit tutorial, Milan, November
2008.
 Baresi, L., Di Ferdinando, A., Manzalini, A., Zambonelli, F., “The

CASCADAS Framework for Autonomic Communications”,
Autonomic Communication, Springer, Heidelberg, 2009.
24

Service-Centrism, Neutrality, Openness, Diversity, Extendibility, Flexibility and Usability

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Service-Centrism, Neutrality, Openness, Diversity, Extendibility, Flexibility and Usability

Uploaded by

Copyright:

Available Formats

Service-centrism, Neutrality, Openness,

Diversity, Extendibility, Flexibility and Usability

Antônio Marcos Alberti

© Antônio M. Alberti 2011

© Antônio M. Alberti 2011

 No application level functionality can be placed at the network

 The model favored network applications neutrality, innovation

 “The WWW is perhaps the most significant result of such

© Antônio M. Alberti 2011

 A generic (usage independent) information network is required.

 Co-existence of evolvable, extendible, flexible

© Antônio M. Alberti 2011

 Services and applications are information treatment processes,

 Virtualized resources could be customized to adequately

© Antônio M. Alberti 2011

 The idea is that applications can be flexibly and dynamically

Basic building blocks become available to compose other services.

 It starts when a new service-based application is invoked.

 It involves the search, discovery and selection of candidate

 In order to facilitate compose-ability, seamlessly service

 Examples of attributes are “capacity, throughput, QoS, latency,

 Service information could be published in divulgation services.

© Antônio M. Alberti 2011

 During negotiation phase, an admission control should be

 If yes, admission installation proceeds to configure the service.

 To assure that the desired quality is being achieved, service

© Antônio M. Alberti 2011

 Autonomic service management is indicated to reduce human

 Changes in the application behavior can reflected in the

 When the application turns off, used resources must be

© Antônio M. Alberti 2011

 According to Pasic, “Today, data and information are used

 One of the main justifications is that “above a certain level of

 “Internet of Services – Supporting the service economy (70% of

 “The term Internet of Services is an umbrella term to describe

© Antônio M. Alberti 2011

© Antônio M. Alberti 2011

Digital Business Ecosystems

 Perhaps, such DBEs will be the new savannah, where a

© Antônio M. Alberti 2011

 According to Pasic, “European Technology Platforms (ETPs)

 NESSI was launched in 2005. In 2007, NESSI decided by

 The first step in implementing this OSF is under the

NESSI Networked European Software and Services Initiative

© Antônio M. Alberti 2011

© Antônio M. Alberti 2011

NESSI Networked European Software and Services Initiative

 The X-ETP vision is that the IoS will emerge in a diversity of

© Antônio M. Alberti 2011

 Its mission is to provide adequate means to integrate, interrelate

 The role of services and applications in FI is also being explored

© Antônio M. Alberti 2011

FISO Future Internet Service Offer

 Some FISO affiliated projects are:

 Many NESSI projects are also members of FISO cluster.

© Antônio M. Alberti 2011

Resources and Services Virtualization without Barriers

 According to project researchers, to massively scale cloud

 Thus, the project proposes to interwork clouds of partner

 All the technologies required for collaborating clouds are in the

 “Cloud Computing represents a true materialization of Service-

© Antônio M. Alberti 2011

Service Level Agreement at Service Oriented Infrastructure