client a

bart.disi.unige.it
  • No tags were found...

client a

High-order distributed autonomic componentsa.k.a.Behavioural SkeletonsMarco AldinucciComputer Science Dept., University of TorinoComputer Science Dept., University of PisaTorino, January 2009


Outline❖ Briefly introducing my background ...❖ Short research retrospective: a roadmap✴ high-level parallel programming & skeletons✴ static optimization✴ dynamic optimization and autonomic computing๏via components and skeletons❖ Sketching possible evolutions within ( ? ) EOS 3✴ short-term✴ medium-term✴ long-term2


Multi-corePisa Lab BackgroundMPPBeowulfGridPervasiveClouds❖ High-level, structured approach to programming✴ Static: Exploit language semantics for domain specific needs?๏topology, memory access pattern, geographic distance, data-flow, QoS,sizing, self-management, ...✴ Dynamic: Exploit a layered run-time support๏๏exploiting well defined semantics of adaptable code (reconf protocols)supporting lightweight or heavyweight virtualization of resources(execution flow, memory, hw-level virtual machines ..)3


High-level parallel programming❖ // is difficult✴ low productivity, hard to debug, hard to optimize, hard to maintain andport even to slightly different platforms๏synchronizations, deadlocks, livelocks, bottlenecks, lot of NP-hard problems(mapping, scheduling, ...)✴ usually approached at a very low level๏ MPI, sockets, threads+locks ...❖ Our approach: raise the level of abstraction✴ “goto considered harmful” approach✴ transfer many of the mentioned problems from the programmer to thedevelopment and run-time tools4


Algorithmic skeletons❖ abstract common parallelism exploitation patterns✴ parametric schema of interaction among parallel entities๏๏control/stream (pipeline, farm, tree, graph...) data parallel (map, reduce, scan....)more abstract than design patterns (that exist only in the OO world)❖ programmers just fulfill the skeleton with sequential code✴ synchronization, sharing, mapping, scheduling are managed by thecompiler and runtime support๏skeletons are designed to avoid bottlenecks and memory hot spots✴ sizing, porting and performance portability are in charge of the compilerS1 S2 ... SnS...S11 S12 S1nS21 S22 ... S2nW1S1S2EW2...C.........WnS11S12S215S22Sk1 Sk2 ... Skn


gather(map(f,scatter(A)))6


gather(map(f,scatter(A)))6


gather(map(f,scatter(A)))6


gather(map(f,scatter(A)))6


the C+MPI code (low-level)#include #include "mpi.h"#define MAXPROC 8 /* Max number of procsses */#define NAMELEN 80 /* Max length of machine name */#define LENGTH 24 /* Lengt of send buffer is divisible by 2, 4, 6 and 8*/main(int argc, char* argv[]) {int i, j, np, me;const int nametag = 42; /* Tag value for sending name */const int datatag = 43; /* Tag value for sending data */const int root = 0; /* Root process in scatter */MPI_Status status; /* Status object for receive */char myname[NAMELEN]; /* Local host name string */char hostname[MAXPROC][NAMELEN]; /* Received host names */int x[LENGTH]; /* Send buffer */int y[LENGTH]; /* Receive buffer */MPI_Init(&argc, &argv); /* Initialize MPI */MPI_Comm_size(MPI_COMM_WORLD, &np); /* Get nr of processes */MPI_Comm_rank(MPI_COMM_WORLD, &me); /* Get own identifier */gethostname(&myname, NAMELEN); /* Get host name */if (me == 0) { /* Process 0 does this */printf("Process %d on host %s has elements", me, myname);for (i=0; i


Why components❖ use - provide ports❖ lifeycle control❖ unit of deployment❖ legacy code❖ GCM (CoreGRID) - fractal (INRIA - F telecom)8


Why Autonomic Computing❖ Performance✴ the app should sustain x transactions per second✴ the app should complete each transaction in t seconds❖ Security✴ the link between P1 and P2 should be secured with k-strongencryption✴ the DB service is exposed by platform P3❖ Fault-tolerance✴ the parallel server should survive to the failure of y platforms... then consider that x, t, P1, P2, P3, k, y can dynamically changeas may dynamically change the performance and the state of therunning environment9


Why skeletons❖ Management is difficult✴ application change along time (ADL not enough)๏how “describe” functional, non-functional features?✴ the low-level programming of component and its management is simplytoo complex❖ Component reuse is already a problem✴ specialising component yet more with management strategy would justworsen the problem✴ especially if the component should be reverse engineered to be used(its behaviour may change along the run)❖ Industrial mainstream: Google’s MapReduce, Intel TBB, ...10


Skeletal frameworks in Pisa❖ P3L (1995 with HP)✴targeting MPP, few skeletons implemented❖ SkIE (1997- within Alenia spazio)✴✴targeting homogenous clusters, support streaminglibrary, support for C, C++, Java, Fortran as host languages❖ ASSIST (2001-2005 within grid.it)✴✴targeting grids, skeletons + generic skeletons (parmods);compile onto C++ templates + sockets + threadsstreaming, shared memory, components, services, dynamic adaptation❖ Lithium, muskel (2000, 2003)✴ macro data-flow, implements Normal Form optimization (Aldinucci ‘99)✴Java, support for adaptivity and centralized management for QoS❖ Grid Component Model (2006 - today within CoreGRID NoE)✴✴components, services, fully autonomic with distributed managementstandard ETSI11


Skeletal frameworks in Pisa❖ P3L (1995 with HP)✴targeting MPP, few skeletons implemented❖ SkIE (1997- within Alenia spazio)✴✴targeting homogenous clusters, support streaminglibrary, support for C, C++, Java, Fortran as host languages❖ ASSIST (2001-2005 within grid.it)✴✴targeting grids, skeletons + generic skeletons (parmods);compile onto C++ templates + sockets + threadsstreaming, shared memory, components, services, dynamic adaptation❖ Lithium, muskel (2000, 2003)✴ macro data-flow, implements Normal Form optimization (Aldinucci ‘99)✴Java, support for adaptivity and centralized management for QoS❖ Grid Component Model (2006 - today within CoreGRID NoE)✴✴components, services, fully autonomic with distributed managementstandard ETSI11optimization increasingly dynamic


Fully static source-to-source optM e t a 12


Behavioural Skeletons idea❖ Represent an evolution of the algorithmic skeleton conceptfor component management✴ abstract parametric paradigms of component assembly✴ specialised to solve one or more management goals๏self-configuration/optimization/healing/protection.✴ carry a semi-formal/formal description and an implementation๏they are component factories, actually❖ Are higher-order components❖ Are not exclusive✴ can be composed with non-skeletal assemblies via standardcomponents connectors๏overcome a classic limitation of skeletal systems13


ABCFunctional replication (GCM implementation)SWWWC1.Choose a schemae.g. functional replicationABC API is chosen accordinglyABC = Autonomic Behaviour Controller (implements mechanisms)AM = Autonomic Manager (implements policies)B/LC = Binding + Lifecycle Controller14


ABCFunctional replication (GCM implementation)SWWWC1.Choose a schemae.g. functional replicationABC API is chosen accordingly2.Choose an inner componentcompliant to BeSke constraintsABC = Autonomic Behaviour Controller (implements mechanisms)AM = Autonomic Manager (implements policies)B/LC = Binding + Lifecycle Controller14


ABCFunctional replication (GCM implementation)SWWWC1.Choose a schemae.g. functional replicationABC API is chosen accordingly2.Choose an inner componentcompliant to BeSke constraints3.Choose behaviour of portse.g. unicast/from_any, scatter/gatherABC = Autonomic Behaviour Controller (implements mechanisms)AM = Autonomic Manager (implements policies)B/LC = Binding + Lifecycle Controller14


ABCFunctional replication (GCM implementation)SWWWC1.Choose a schemae.g. functional replicationABC API is chosen accordingly2.Choose an inner componentcompliant to BeSke constraints3.Choose behaviour of portse.g. unicast/from_any, scatter/gather4.Run your applicationthen trigger adaptationsABC = Autonomic Behaviour Controller (implements mechanisms)AM = Autonomic Manager (implements policies)B/LC = Binding + Lifecycle Controller14


ABCFunctional replication (GCM implementation)B/LCSWWWWC1.Choose a schemae.g. functional replicationABC API is chosen accordingly2.Choose an inner componentcompliant to BeSke constraints3.Choose behaviour of portse.g. unicast/from_any, scatter/gatherW4.Run your applicationthen trigger adaptationsABC = Autonomic Behaviour Controller (implements mechanisms)AM = Autonomic Manager (implements policies)B/LC = Binding + Lifecycle Controller14


ABCFunctional replication (GCM implementation)B/LCSWWWWWAMABC = Autonomic Behaviour Controller (implements mechanisms)AM = Autonomic Manager (implements policies)B/LC = Binding + Lifecycle ControllerC141.Choose a schemae.g. functional replicationABC API is chosen accordingly2.Choose an inner componentcompliant to BeSke constraints3.Choose behaviour of portse.g. unicast/from_any, scatter/gather4.Run your applicationthen trigger adaptations5.Automatise the processwith a Manager


A motivating exampleIBM fingerprint recognition app(mockup, GridComp)datasetCompon L aclient a on L aW 1on L 1W 2 on L 2AM on L 3client bon L bclient n on L ntransientStorageCompDPfingerprint DBRPC or dataflow bindings management bindings data sharing port bindings15


A motivating exampleIBM fingerprint recognition app(mockup, GridComp)datasetCompon L aclient a on L aW 1on L 1W 2 on L 2AM on L 3client bon L bclient n on L ntransientStorageCompDP5) repeat 2-3-4 ... 2-3-4 ...4) clients get the answer OR(W1,W2,...)fingerprint DB3) each worker matches the fingerprintagainst its DB partition2) clients broadcast requests to all workers1) references to DB slices are scatteredRPC or dataflow bindings management bindings data sharing port bindings15


A motivating exampleIBM fingerprint recognition appdatasetCompon L aclient a on L aW 1on L 1W 2 on L 2AM on L 3client bon L bclient n on L n(mockup, GridComp)transientStorageCompfingerprint DBDP7) AM reacts (e.g. increasing // degree):copying W1;bindings (external, AM, StorageComp)should be preserved;DB partitions (Wx state) should beredistributed via StorageComp6) AM may sense a changed answer time(e.g. increased), due to a datasetsize/kind and/or platform status change5) repeat 2-3-4 ... 2-3-4 ...4) clients get the answer OR(W1,W2,...)3) each worker matches the fingerprintagainst its DB partition2) clients broadcast requests to all workers1) references to DB slices are scatteredRPC or dataflow bindings management bindings data sharing port bindings15


A motivating exampleIBM fingerprint recognition app(mockup, GridComp)W 1 on L 1 AM on L 3datasetCompon L aW 2 on L 2 client a on L aclient b on L bclient n on LtransientnStorageCompfingerprint DBW 3 on L 3DP7) AM reacts (e.g. increasing // degree):copying W1;bindings (external, AM, StorageComp)should be preserved;DB partitions (Wx state) should beredistributed via StorageComp6) AM may sense a changed answer time(e.g. increased), due to a datasetsize/kind and/or platform status change5) repeat 2-3-4 ... 2-3-4 ...4) clients get the answer OR(W1,W2,...)3) each worker matches the fingerprintagainst its DB partition2) clients broadcast requests to all workers1) references to DB slices are scatteredRPC or dataflow bindings management bindings data sharing port bindings15


Some adaptation operationsMigrationReplicationKillgostartsharecopykillkeep the external state (if any)start from a fresh external statecomponent replica share external statewith source componentcomponent replica is created with a freshexternal statekill the component(detach bindings, garbage collect, ...)16


Adaptation ops as SHR axiomss, s’ = external states; g, g’ = managers; l, l’ = locationsmove componentf from l to l’(keep state)ggo〈g•′ ,l ′ 〉l•f• s➟g ′ •l • • l ′g • f • se.g. g=g’move componentf from l to l’(fresh state)g• startσ〈g ′ ,l ′ ,s ′ 〉l• g ′ •• sf➟ l • • l ′ σ g • f • s s ′•e.g. g=g’, s ≠ s’replicate component(keep state,change location)g•l•rep〈g ′ ,l 〉 ′ f • s➟g ′ •g•l• l ′ • ff• se.g. g=g’replicate component(fresh state,change location)g•l•repσ〈s ′ ,l 〉 ′ f • s➟gf•l • • l ′ • s ′f • se.g. s ≠ s’kill componentg•kill〈〉l•f• s➟g•l•• s17


SHR Inference rules...in one slideParallelΛΓ ⊢ G 1 −→ Φ ⊢ G2 Γ ′ ⊢ G ′ Λ ′1 −→ Φ ′ ⊢ G ′ 2(Γ ∪ Φ) ∩ (Γ ′ ∪ Φ ′ )=∅Γ, Γ ′ ⊢ G 1 |G ′ 1Λ∪Λ ′−−−→ Φ, Φ ′ ⊢ G 2 |G ′ 2The system can dowhatever disjointsubsystems doRestrictΓ,x⊢ G 1Λ−→ Γ,x⊢ G2 Λ(x) =ɛ ∨ Λ(x) =τΓ ⊢ νx G 1Λ\{x}−−−−→ Γ ⊢ νx G 2The system can do anytransition not requiringany synchronisations onrestricted nodeMergeΓ, x, y ⊢ G 1Λ−→ Φ ⊢ G2Γ[x/y] ⊢ G 1 [x/y] Λ,{x,τ,}−−−−−→ Φ[x/y] ⊢ νU G 2 [x/y]ρx and y can be fusedprovided that theyperform compatiblesynchronisation actions


ExampleAMstartσ〈g,l 1 ,s 1 〉• l •l 1g•startσ〈g ′ ,l ′ ,s ′ 〉 f • s σ➟AM • l •l 1g •f • s σ s 1•σAM asks component f to change location and attach to a newexternal state (application of start rule)Observe that hyperedges can be used to represent very differentconcepts/attributes (e.g. location, store, manager hooks)19


Driving adaptations❖ Managers drive the adaptation process✴ choose among all possible adaptations✴ in a distributed way❖ Implementing concepts in GCM✴ when-event-if-cond-then-act list of rules✴ where act either an adaptation or a message to a set of companionmanagers✴ as JBoss Drools๏first order logic• maybe not fuzzy enough 20


A simple contractrule "CheckInterArrivalRate"salience 5when$arrivalBean : ArrivalRateBean( value < ManagersConstants.LOW_PERF_LEVEL)then$arrivalBean.setData(ManagersConstants.notEnoughTasks_VIOL);$arrivalBean.fireOperation(ManagerOperation.RAISE_VIOLATION);System.out.println( "InterArrivalTime not enough - Raising a violation");endrule "CheckRateLow"when$departureBean : DepartureRateBean( value < ManagersConstants.LOW_PERF_LEVEL )$parDegree: NumWorkerBean(value ManagersConstants.HIGH_PERF_LEVEL )$parDegree: NumWorkerBean(value > ManagersConstants.MIN_NUM_WORKERS)then$departureBean.fireOperation(ManagerOperation.KILL);$departureBean.fireOperation(ManagerOperation.BALANCE_LOAD); System.out.println( "Rate "+$departureBean.getValue()+" (Removing 1 workers)");end21


Orchestration of managers (overlay)M(C1)C2M(C3)M(C5')C6' C7' C8'C5'C4Qos contractCx = Component x(from users)Cx', Cx'' = Instances of CxM(Cx) = Manager of CxC1C2C3C4StructuralrelationshipsManagementoverlay networkFunctionalnetworkM(C5'')C6'' C7'' C8''C5''C3C1C5'C6' C7' C8'C5''C6'' C7'' C8''22


Mandelbrot example (two-levels)! get_service_time" change // degreeappmanager" new contract (e.g. Ts


Advance 1/3: autonomic components❖ Evolutionary - short term❖ Not fully happy about our GCM components✴ do not properly distinguish stateful and stateless entities๏this is quite important to define correct adaptations✴ do not properly support alternative interfaces๏slow/fast versions, component wrapping✴ fat implementation (on top of Proactive 4.x)❖ Are treats a candidate to re-design a similar framework?✴ how they deal with concurrency and parallelism ?๏ serialization, flow of control, synchronization, ...✴ not enough expert yet ...25


Advance 2/3: compiling adaptations❖ Evolutionary - medium term - key advance for many-coresourcedesigner specify adaptationoperation semantics at thehighest possible levelbinaryoperations are reallyadaptation protocolslifecycle, resource recruiting,creation, binding, ... )Ce.g.JITadapta26adaptbD D Dadaptc1 2 3 D 4CC[ adapta] C[ adaptb]1 CC[ adaptc]3CCCe.g.e.g.e.g.JITJITJITC 2we need it for dynamically introducing newcontracts or adaptationsC 4


Advance 2/3: compiling adaptations❖ Evolutionary - medium term - key advance for many-coresourcedesigner specify adaptationoperation semantics at thehighest possible levelbinaryoperations are reallyadaptation protocolslifecycle, resource recruiting,creation, binding, ... )Ce.g.JITadaptaadaptbD 4D D Dadaptc1 2 3C 1opt_adapt = C[ adapta ; adaptb ; ] adaptcCJITe.g.JITC 426


Advance 2/3: compiling adaptations❖ exploit both static and dynamic techniques✴ e.g. represent adaptations as graph transformations๏๏in such a way only correct configuration can be generated (e.g. as types)QoS constraints with free variables✴ bound free variables with values๏๏free variables can be bound at compile, launch time with constant or nonconstant valuesmanage adaptation accordingly❖ uniformly define static and dynamic adaptations✴ apply them the earlier is possible๏compile/deploy/launch/run-time❖ here proper language abstractions become crucial27


Advance 3/3: Concurrency & QoS❖ More-than-evolutionary - long term❖ Questions:✴ how functional and non-functional aspect are represented at the highlevellanguage level in a decoupled but interacting way?✴ are QoS contract compositional? Can they be locally managed? How acontract is projected in subcontracts? Is the union of the projection“correct” and “complete”?✴ have we have an algorithm to determine worst-medium case? Do wehave an algorithm to a global contract through local steps?❖ What kind of constructs and/or abstraction can be efficientlystatically-or-dinamically optimized?✴ think again to goto ...28


Recap: Participation in ProjectsOngoing❖❖❖❖IN.SY.EME (MIUR-IT FIRB) Integrated System for Emergency - Jul. 2007, 36 mFRIMP (Cassa di Risparmio di Pisa) Software for Network Processors Feb. 2007, 24 mGridComp (EU-STREP, 6th FP) Grid Component Model - June 2006, 30 mSFIDA (MIUR FAR-ICT): Innovative platform supporting collaborative-business for Small-Medium Enterprises - Sept. 2007, 24 mCompleted❖ BEinGRID (EU-IP, 6th FP) The Grid infrastructure for the Retail Management Experiment - Jun. 2006, 18 m❖ Organisations for Next Generation Grids - Jun. 2006, 24 m❖ CoreGrid (EU-Network of Excellence, 6th FP): Foundations, Software Infrastructures and Applications for large scaledistributed, Grid and Peer-to-Peer Technologies - 2004, 48 m❖ XtreemOS (EU-IP, 6th FP): Building and Promoting a Linux-based Operating System to Support Virtual❖ VirtuaLinux (Eurotech SpA) Robust Virtual Clustering - Nov. 2006, 6 m❖ Galieo Pisa-ParisVII/INRIA (Exchange Programme) 2004 - 2006❖ MOPROSCO Pisa-ParisVII/INRIA (Exchange Programme) 2005 - 2007❖ Grid.it (MIUR FIRB) 2003 - 2006❖ GridCoord (EU-Special Action, 6th FP) 2004 - 2006❖ Vigoni Pisa-Berlino/Muenster (Exchange Programme) 2003 - 2005❖ SAIB (Ricerca Industriale MIUR) 2002 - 2004❖ Law 449/97 year 2000 (strategic projects MIUR-CNR) 2002 - 2004❖ Law 449/97 year 1999 (strategic projects MIUR-CNR) 2002 - 2004❖ ASI-PQE2000 (MIUR) 2001- 2002❖ Agenzia2000 (MIUR) 2000-2002❖ Vigoni Pisa-Passau (Exchange Programme) 1998 - 2000❖ MOSAICO (MIUR 40%) 1998 - 2000❖ PQE2000 (CNR, ENA, INFN, Alenia Spazio) 1997 - 200029


❖ M. Aldinucci, S. Campa, M. Danelutto, P. Dazzi, P. Kilpatrick, D. Laforenza, and N. Tonellotto. Behavioural skeletons for component autonomicmanagement on grids. In CoreGRID Workshop on Grid Programming Model, Heraklion, Crete, Greece, June 2007.❖ M. Aldinucci, S. Campa, M. Danelutto, M. Vanneschi, P. Dazzi, D. Laforenza, N. Tonellotto, and P. Kilpatrick. Behavioural skeletons in GCM:autonomic management of grid components. In D. E. Baz, J. Bourgeois, and F. Spies, editors, Proc. of Intl. Euromicro PDP 2008: pages 54–63,Toulouse, France, Feb. 2008. IEEE.❖ M. Aldinucci and M. Danelutto. Skeleton based parallel programming: functional and parallel semantic in a single shot. Computer Languages,Systems and Structures, 33(3-4):179–192, Oct. 2007.❖ M. Aldinucci, M. Danelutto, and P. Dazzi. Muskel: an expandable skeleton environment. Scalable Computing: Practice and Experience, 8(4):325–341, Dec. 2007.❖ M. Aldinucci, M. Danelutto, and P. Kilpatrick. Adding metadata to orc to support reasoning about grid programming. In T. Priol andM. Vanneschi, editors, Towards Next Generation Grids (Proc. of the CoreGRID Symposium 2007), CoreGRID, pages 205–214, Rennes,France, Sept. 2007. Springer.❖ M. Aldinucci, M. Danelutto, and P. Kilpatrick. A framework for prototyping and reasoning about grid systems. In Parallel Computing:Architectures, Algorithms and Applications (Proc. of PARCO 2007, Jülich, Germany), volume 38 of NIC, pages 235–242, Germany, Dec. 2007.❖ M. Aldinucci, M. Danelutto, and P. Kilpatrick. Management in distributed systems: a semi-formal approach. In A.-M. Kermarrec, L. Bougé, andT. Priol, editors, Proc. Euro-Par 2007 Parallel Processing, volume 4641 of LNCS, pages 651–661, Rennes, France, Aug. 2007. Springer.❖ M. Aldinucci, M. Danelutto, P. Kilpatrick, and P. Dazzi. From Orc models to distributed grid Java code. In S. Gorlatch, P. Fragopoulou, and T. Priol,editors, Grid Computing: Achievements and Prospects, CoreGRID, pages 13–24. Springer, 2008.❖ M. Aldinucci, M. Danelutto, P. Kilpatrick, and P. Dazzi. From Orc models to distributed grid Java code. In S. Gorlatch, P. Fragopoulou, and T. Priol,editors, Proc. of the Integrated Research in Grid Computing Workshop, CoreGRID, pages 2–13, Hersonissos, Crete, Greece, Apr. 2008.❖ M. Aldinucci, S. Campa, M. Danelutto, P. Dazzi, P. Kilpatrick, D. Laforenza, and N. Tonellotto. Behavioural skeletons for component autonomicmanagement on grids. In Making Grids Work, CoreGRID, chapter Component Programming Models, pages 3–16. Springer, Aug. 2008.❖ M. Aldinucci and M. Danelutto. Securing skeletal systems with limited performance penalty: the Muskel experience. Journal of SystemsArchitecture, 54(9):868–876, Sept. 2008.❖ M. Aldinucci, M. Danelutto, H. L. Bouziane, and C. Pérez. Towards software component assembly language enhanced with workflows andskeletons. In Proc. of the ACM SIGPLAN Component-Based High Performance Computing, pages 1–11, New York, NY, USA, Oct. 2008. ACM.❖ M. Aldinucci, M. Danelutto, G. Zoppi, and P. Kilpatrick. Advances in autonomic components & services. In T. Priol and M. Vanneschi, editors,From Grids To Service and Pervasive Computing, CoreGRID, pages 3–18, Las Palmas, Spain, Aug. 2008. Springer.❖ M. Aldinucci and E. Tuosto. Towards a formal semantics for autonomic components. In T. Priol and M. Vanneschi, editors, From Grids ToService and Pervasive Computing (Proc. of the CoreGRID Symposium 2008), CoreGRID, pages 31–45, Las Palmas, Spain, Aug. 2008. Springer.❖ M. Aldinucci, M. Danelutto, and P. Kilpatrick. Autonomic management of non-functional concerns in distributed and parallel applicationprogramming. In Proc. of Intl. Parallel & Distributed Processing Symposium (IPDPS), Rome, Italy, May 2009. IEEE. To appear.❖ M. Aldinucci, M. Danelutto, and P. Kilpatrick. Co-design of distributed systems using skeletons and autonomic management abstractions. InWorkshops of Euro-Par 2008, volume 5415 of LNCS, 2009. To appear.❖ M. Aldinucci, M. Danelutto, and P. Kilpatrick. Towards hierarchical management of autonomic components: a case study. In Proc. of Intl.Euromicro PDP 2009: Parallel Distributed and network-based Processing, Weimar, Germany, Feb. 2009. IEEE. To appear.30

More magazines by this user
Similar magazines