130 likes | 209 Vues
Towards an Architecture for Extreme P2P Applications Nadia Shalaby John Zinky 19 th Conference on Parallel and Distributed Computing Systems Cambridge, MA November 21, 2007. What is the Problem?. App 1. App 2. App 3. App n. …. P2P applications. P2P overlay API. P2PO 2 substrate.
E N D
Towards an Architecture forExtreme P2P ApplicationsNadia Shalaby John Zinky 19th Conference on Parallel and Distributed Computing Systems Cambridge, MANovember 21, 2007 PDCS '07
What is the Problem? App1 App2 App3 Appn … P2P applications P2P overlay API P2PO2 substrate P2PO1 substrate P2POk substrate … P2P overlay substrates DB language: SQL client/server API job queues RPC HTTP service abstractions resource abstraction API process socket files Message services Grid services Database services resource abstractions operating system network stack file system resource API wire/fiber/ radio cyber resources CPU Disk • Scope of P2P paradigm expanded beyond research arena • Ubiquitous in commercial, industrial and military applications • Optimized P2P solutions available for single resource dominant applications: e.g. file distribution, grid computing, Pub/Sub message passing • Large scale, reliable, complex, real-time applications need custom development • High-risk, time consuming, expensive • How do we fill this gap? • Formulate properties of these apps • Propose general architecture • Propose implementation platform • Ensure backward compatibility PDCS '07
Outline • What is the Problem? • Taxonomy • Examples • Architecture • Cougaar’s Two-Tier Architecture • Architectural Mapping • Integration with Legacy Systems • Case Studies of Extreme Applications • Conclusion PDCS '07
Taxonomy • System Resource Constraints • (exhibited during runtime) • Distributedness of cyber resources: centralized vs. LAN vs. WAN • Data plane speed: batch vs. online vs. superhuman realtime • Survivability (reliability & performance): non-crucial vs. exigent • Security adversary level: trust all vs. compartmentalized trust vs. malicious vs. insider threat • Scalability (nodes): 10s vs. 100s vs. 1000s vs. >10,000 • Application Functional Requirements • (addressed at programming/development phase) • Communication: client/server vs. P2P • Development cycle: waterfall vs. adaptive • Process during operational lifespan: fixed vs. evolving • Human participation level: none vs. sensor vs. model vs. cognitive • Cross-cyber resource usage CPU vs. network vs. storage vs. all Application Business System • Business Environment • (real-world constraints) • Market share: large vs. medium vs. small • Integration environment: standalone vs. stovepipe vs. new functionality w/ legacy system integration PDCS '07
Examples of Extreme Applications • System Resource Constraints • (exhibited during runtime) • Distributedness of cyber resources: centralized vs. LAN vs. WAN • Data plane speed: batch vs. online vs. superhuman realtime • Survivability (reliability & performance): non-crucial vs. exigent • Security adversary level: trust all vs. compartmentalized trust vs. malicious vs. insider threat • Scalability (nodes): 10s vs. 100s vs. 1000s vs. >10,000 • Application Functional Requirements • (addressed at programming/development phase) • Communication: client/server vs. P2P • Development cycle: waterfall vs. adaptive • Process during operational lifespan: fixed vs. evolving • Human participation level: none vs. sensor vs. model vs. cognitive • Cross-cyber resource usage CPU vs. network vs. storage vs. all • Examples of Extreme Applications • Information Assurance • UAV surveillance on mobile sensor platforms • Field modifiable systems preventing evolving malicious attacks • Proactive content distribution • Management of evolving data proc. Centers • ISP network management and optimization • Voice, video over Disruption Tolerant Networks • Business Environment • (real-world constraints) • Market share: large vs. medium vs. small • Integration environment: standalone vs. stovepipe vs. new functionality w/ legacy system integration PDCS '07
Degrees of Extremeness Distributed P2P S3 Extreme Message based Grid based DB based PDCS '07
Outline • What is the Problem? • Taxonomy • Examples • Architecture • Cougaar’s Two-Tier Architecture • Architectural Mapping • Integration with Legacy Systems • Case Studies of Extreme Applications • Conclusion PDCS '07
Architecture of Extreme Applications App App App Sensor Agents Sensor Agents Protocol Protocol Real-time Optimizer Agents Cognitive Learner Agents Situation Predictor Agents Stack Stack Data Plane Executor CPU wire/fiber/ radio Disk hours to secs control plane data plane Cognitive Control Loop Model-Based Control Loop Sensor-Based Control Loop app. status coordination app. trends coordination app. pattern coordination state machine situation policy inference rules resource pattern coordination resource trends coordination resource status coordination days to hours hours to minutes secs to msecs PDCS '07
Cougaar’s Two-Tier Architecture Behavior Behavior domain specific BB BB Agent Agent coordinator coordinator sensor sensor activator activator system specific service service service service service component component component component component library library Environment Agents • Agent/Env. API • sensor • activator • coordinator • active API • at every node • Environment • Distributed • Event driven • Components • Services • Service oriented API • Imported libraries • Local • Data driven • Distributed BB • Behavior (plugin) • State (BB) • Pub/Sub BB API PDCS '07
Outline • What is the Problem? • Taxonomy • Examples • Architecture • Cougaar’s Two-Tier Architecture • Architectural Mapping • Integration with Legacy Systems • Case Studies of Extreme Applications • Conclusion PDCS '07
Architectural Mapping Mapping Dimensions Separation of data and control planes Computational model Decoupling of system and application Hierarchical control plan Evolving degree of operational human involvement • Extreme App. Architecture • Data plane • Computational model: • Functional modules (ovals) • Functional heterogeneity • Inter-module coordination • Control plane of the application • Hierarchy of functionality • Sensor-, model-, cognitive-based • Cougaar • Import from native infrastructure • Computational model: • Agents • Behaviors • Agent coordinations • Cougaar Environment (systemic QoS) • Agent societies • Transitioning of control loops human to automation architectural mapping PDCS '07
Integration with Legacy Systems enterprise service bus OWL knowledge base JESS C o u g a a r runtime C o u g a a r runtime runtime C o u g a a r SQL DB services MPI Library Corba/RMI web services processes/threads TCP/UDP network stack files wire/fiber/ radio wire/fiber/ radio wire/fiber/ radio disk disk disk CPU CPU CPU embedded control word processing semantic tagging scheduling Applicationn Applicationn banking/airlines ftp, telnet, ssh … web Services Applicationn Applicationk embedded devices scientific comp. … … … grid-based systems message-based systems DB-based systems Main Cougaar architectural feature: imported libraries and component wrappers PDCS '07
Conclusion • Taxonomy for P2P Application space • Identify classes with progressively stringent constraints • Novel architecture for Extreme Applications • Leverages the extreme development process, gradual phasing out of human involvement during system operation • Two-Tier Cougaar architecture • Serves as a middleware platform, natural fit for Extreme applications, backward compatible for legacy components PDCS '07