1. Digital Business Ecosystem
Miguel Vidal

2. Many different DBE project views ...and your view

3. The DBE Architecture
The DBE network consists of all the running instances of the DBE Execution Environment
In each instance there can be service adapters deployed
The Service Adapters can be found by other servent instances by the means of the DBE nervous system

4. 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

5. Why? Beause no one is willing to deploy the infrastructure
Because no other technology scales lineally
Because there is no single point of failure

6. DBE Architecture Legacy System Client Servent Servent DBE Network

7. The DBE Nervous System
The service adapters deployed in a servent are advertised in a peer-to-peer network
This p2p network keeps the information for a relatively low amount of time
Servent instances tell periodically the p2p network not to delete the data
Should the service instance crash, the stale data doesn't remain in the p2p network

8. DBE ServENT Network Legacy System Client Servent Servent DBE Network

9. Agrifood Overlay Network
Client
Legacy System
Servent
Servent
Agrifood Network
Servent

10. Turistic Overlay Network
Client
Legacy System
Servent
Servent
Turistic Network
Servent

11. User Overlay Network Legacy System Client Servent Servent User Network

12. DBE Nervous System search
Service Instance
Service Instance
Service Instance

13. Networks

14. What does it mean? Airlines
Exponential Network
Scale-free Network

15. Execution of services
A client performs calls against a servent instance
The servent isolates the client from remote calls over the internet. Ideally, the client is in the same LAN as the servent
The servent routes the request to the servent instance that contains the service adapter the client wants to run

16. Execution of Services Legacy System Client Servent Servent DBE Network

17. Interceptors
Each service call performed by a client that is received by a servent can be intercepted by a filter
Each service call made on a service adapter on behalf of a remote servent can be also intercepted by a filter
This is the way in which the Accounting system meters the data used to invoke services

18. Interceptors
Client
Legacy System
Servent
Servent
DBE Network
Servent

19. Execution Environment (ExE)
The execution environment is made by a container (ServENT- and several services:
Webapp (servlet container)
Distributed storage system (DSS)
Accounting filter and metering service.
KnowledgeBase and SemanticRegistry.
Identity
Portal

20. DBE ServENT in detail

21. DBE ServENT in detail

22. 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.

23. 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

24. 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 ( pages.

25. ServENT - P2P Interface
There is a P2P interface implemented nowadays with FADA (
A new improved FADA or another P2P solution can be used.

26. 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

27. 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 Security
Servent 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?

28. 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.

29. 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.

30. 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.

31. Execution Environment (ExE)

32. ExE – Webapps Application
A core DBE service uses Jetty ( as servlet container in the Execution Environment (ExE).
ExE uses this servlet container to integrate activeBPEL, Portal and OpenLaszlo.

33. DBE Studio

34. DBE ServENT

35. Links DBE EC portal (http://www.digital-ecosystems.org )
Conference DE-2007( )
DBE Community (
DBE Studio (
DBE ServENT(
Examples (
Tourism Example (
Advertencia: las opiniones y puntos de vista expresados en este documento son aquellos de algunos miembros de la comunidad de los ‘Ecosistemas Digitales’, y no reflejan necesariamente el punto de vista oficial de la Comisión Europea sobre el tema. Bajo ninguna circunstancia las opiniones aquí expuestas deben de ser tomadas como el punto de vista oficial de la Comisión Europea.