Birmingham-20060705
-
Upload
miguel-vidal -
Category
Documents
-
view
151 -
download
0
Transcript of Birmingham-20060705
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