Transcript Document
Digital Business Ecosystem Miguel Vidal [email protected] http://www.techideas.es Many different DBE project views ...and your view 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 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, Selfoptimized, Self-configured, Selfprotected Why? • Beause no one is willing to deploy the infrastructure • Because no other technology scales lineally • Because there is no single point of failure DBE Architecture Legacy System Client Servent Servent DBE Network Servent 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 DBE ServENT Network Legacy System Client Servent Servent DBE Network Servent Agrifood Overlay Network Legacy System Client Servent Servent Agrifood Network Servent Turistic Overlay Network Legacy System Client Servent Servent Turistic Network Servent User Overlay Network Legacy System Client Servent Servent User Network Servent Networks What does it mean? Airlines Exponential Network Scale-free Network 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 Execution of Services Legacy System Client Servent Servent DBE Network Servent 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 Interceptors Legacy System Client Servent Servent DBE Network Servent Execution Environment (ExE) • The execution environment is made by a container (ServENThttp://swallow.sourceforge.net/) and several services: – – – – – – Webapp (servlet container) Distributed storage system (DSS) Accounting filter and metering service. KnowledgeBase and SemanticRegistry. Identity Portal 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. 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. 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. 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 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. DBE Studio DBE ServENT Links •DBE EC portal (http://www.digital-ecosystems.org ) •Conference DE-2007( http://www.de-2007.eu/speakers.html ) •DBE Community (http://www.digital-ecosystem.org ) •DBE Studio (http://dbestudio.sourceforge.net ) •DBE ServENT(http://swallow.sourceforge.net ) •Examples (http://www.ita.es/dbe/?ID=176 ) •Tourism Example (http://www.europaactiveclub.eu/home/index) 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.