birmingham-20060705

Download Birmingham-20060705

If you can't read please download the document

Upload: miguel-vidal

Post on 13-Jan-2017

151 views

Category:

Documents


0 download

TRANSCRIPT

DBE Execution Environment

Miguel Vidal

Technical Coordinator

What?

A B2B platform for all Europe wide SME's

An integrated, distributed pervasive network of local digital ecosystems for small business organisations and for local e-governance which cooperate exchanging dynamically resources, applications, services and knowledge.

It should be for Business, what the WWW was for end users

Imagine a world where computers fix their own problems before you even know something is wrong.

Imagine you can use self-managing computing systems to control an increasingly complex and expensive IT environment.

Imagine make your systems resilient, responsive, efficient, and secure without human intervention.

Imagine...

DBE: A different way to do it

How?

Without a single owner (Using a P2P platform)

Without a single point of failure (resilient by means of high redundancy)

Without System Architect, System Administrator

Self-Managed, Self-Heal, Self-optimized, Self-configured, Self-protected

With learning capabilities to substitute the human operator

Exponential Network

Scale-free Network

Airlines

What does it mean?

5.54.5, 7-7.53.4 - 4.32.6 - 2.73.0614 - 183.2

Network PL exp.

Gnutella 2 - 3

WWW 1.9 - 2.7

Internet domain 2.1 - 2.2

Internet router 2.4 - 2.5

Email 1.7 - 1.9

Movie actors 2.3

Co-authors 2.1 - 2.5

Telephone calls 2.1

Clust.coeff

0.1 - 0.30.2 - 0.3, 0.4 - 0.5

0.030.80.4 - 0.8

Some networks analysis

Condensation in evolving networks

The sustanaible growing model

Local decisions: Game Theory

Which is the self-fish strategy better for the wole system?

Wich non zero sum games?

How many players involved?

How many times the same game will be played?

What are winning the players?

Diffusion- Reaction
(Turing's Morphogenesis)

How far can arrive our messages?

Which are the minimum number of nodes to have a network?

Which are the maximum number of nodes in the network?

Which are the limits of the network?

Which organizations will stay together?

How many different players are needed?

Which patterns will emerge spontaneously?

Complexity & Stability

Which are the stable solutions?

Are such stable solutions predictible?

Under which conditions we can recover the system?

Xt+1 = Xt * (1-Xt)

Design principles

Data management beyond the centralised system approach

Loosely coupled trust and security mechanisms

Robustness vs completness

Architecture by participation

Fractal software model

The software gets better the more people use it

The network scales better the more people use it

Execution Environment (ExE)

The execution environment is made by a container (ServENT- http://swallow.sourceforge.net/) and several services:

Webapp (servlet container)

Distributed storage system (DSS)

Accounting filter and metering service.

KnowledgeBase and SemanticRegistry.

Identity.

Portal.

Habitat service and EvE filter

LANLANDBE ServENT: Service invocation

ServentDBE DesktopclientBE

serviceadapter

1-Makerequest

2-Routerequest

3-Delegateon adapter

4-CallBack-End

Acctsystem

Notify

Notify

Servent

DBE ServENT in detail

DBE ServENT in detail

ServENT - Protocol independent

There is a servent-to-servent invocation interface that can be implemented for each protocol we can handle.

Only serialization has been implemented.

ServENT - Filters

The server side allow the interception and filtering of request and responses.

Each service deployed can declare which filters use and which parameters.

Filters can be applied on specific methods

ServENT - Handlers

Services can deploy their own handlers to add http/html access.

Services with handlers offer both: HTML and DBE functionality.

There is a default handler included that allow user not to code but write velocity (http://jakarta.apache.org/velocity) pages.

ServENT - P2P Interface

There is a P2P interface implemented nowadays with FADA (http://fada.sourceforge.net/)

A new improved FADA or another P2P solution can be used.

ServENT - IP Monitorization

The ServENT auto-discovers its own IP during execution, trying to discard privates.

IP is checked periodically against another ServENT. If IP changes a message is sent to all ServENT components.

For local calls the local IP is used

Deploy a service

DAR (DBE Archive) file is unzipped in a directory

There is a ClassLoader for each service with its libraries and configuration files. Modifications in runtime are possible

Service provider knows nothing about Fada

We control the full deployment process to check results fail with control

ServiceContext (i)

Service can get the Service Context in the init method

The Servent manages different context for each service, each one with different security policies

Service params are placed in the deployment file

It must be easy for deployed services to get advantage of the Servent for getting other DBEServices

getService(String id) method allow services to get and invoke local or remote DBEServices using its interface.

Servent and SecurityServent can classify services in deployment time, allowing some of the services execute some methods and denying execution to others.

There are at least 2 kind of services: - CoreServices: Can acces to the ServentService- DBEServices: Deployed by server providers

Can service provider do what he want with the Servent?

ServiceContext (ii)

Because DBE Services are deployed by the ServENT, it is very easy for the ServENT to provide these local services.

Due to the fact that the servent controls FADA and it can provide UI, DynamicProxy and PA, it must be very easy for the ServENT to provide these services even if its deployed in another ServENT.

getService method can be very useful for Services in general but I think is essential for CoreServices.

Security policies can be necessaries, then, the Servent will only provide some specific services.

Services can call the KB service in order to search for a service and then, call the service.

Services as a resource

If services are deployed as a file, it makes sense this file can be recovered from one servent to deploy automatically in another

If we can save some state about the running service, the new service will keep its status when deployed

If temporally files don't use DSS but a tmp directory, these tmp files also can be recovered

We don't know if it's possible to save any state about execution. It's clear the new service can be deployed and restarted in other servents, what's good for statless services.

If services use DSS for temporally files, them are automatically shared (security an authentication contrl is needed)

Databases like Hypersonic can be also stored in the tmp directory.

ServENT interface

The core ServENT implementation used to deploy and undeploy services is a CoreService itself. It must provide some security restrictions to be used by other servents or services.

Servent service can be also called through an HTTP interface. Because it is a service it can provide an UI too.

Execution Environment (ExE)

ExE Webapps Application

A core DBE service uses Jetty (http://jetty.mortbay.org) as servlet container in the Execution Environment (ExE).

ExE uses this servlet container to integrate activeBPEL, Portal and OpenLaszlo.

Java Virtual Machine 1.4

RAM 64 Mb

ServENT alone 49692 kB .

With core services deployed 53824 kB.

Hard Disk 90 Mb (91915 kB)

Bandwidth 128 Kb

Requirements

e-Business by collaboration

Beginning

"An integrated, distributed pervasive network of local digital ecosystems for small business organisations and for local e-governance which cooperate exchanging dynamically resources, applications, services and knowledge.

Introduces the concept of tourism services that can be easily connected to the network and used and shared without configuration