Part I : Scalability Introduction

Part I : ScalabilityIntroduction Max Mühlhäuser

I.0 - Outline: What this chapter covers • General Introduction to Scalability • Explanation and first classification • Mathematical Scalablity • Technical and Economical Scalability • Scalability in UC (Ubiquitous Computing) • A short motivation, transition to section 3 • Approaches to Scalability for Ubiquitous Computing • Mathematical Scalability – emphasizing Distributed Systems • Technical/Economical Scalability: • Openness (includes history of open protocols, open software • Manageability • Longevity • Overview of Further Chapters • in relation to section 3 • Bibliograhical Notes

I.1.1 General Introduction: Scalability • Term became common in Computer Networks / Telecomm., Distributed Systems, and Software Engineering • Formal definition? Only possible for narrow purpose  remain informal • First approach: scalability is the ability to grow • ability of what? of a “solution to (a set of, certain) problems”:algorithm, method, system (software system, platform, …), network, … • ability implies: “… grow and remain useful” … in the performance sense • as ‘problem’ grows, resources required for ‘solution’ should not grow faster • we call this: mathematical scalability • ability also implies: “… grow and remain usable” in terms of “cost”, acceptance • acceptable effort to add / maintain / remove components • acceptable effort to migrate / re-use components & systems • acceptable usability (for humans, organization, …) as ‘problem’ grows? • we call this: technical scalability • term scalability is also used in economic / commercial world • cf. http://en.wikipedia.org/wiki/Scalability • means: a business is ready for growth (geographically, wrt. turnover …) • we call this: economical scalability • relevant below: IT related i.e. software related issues of economical scalability

I.1.2 Introduction: Mathematical Scalability More on mathematical scalability: • for sequential programs/algorithms: (1) computational complexity theory(deals with relative computational difficulty of computable functions; terms like: Big-O notation, e.g., “O(N log N)”, NP-complete, etc.) • for issues of Computer Networks / Distributed Systems: • (2) Speedup treats possible parallelization on multiple processors / nodes • Amdahl’s Law frustrating: divides program into parallelizable portion p  (0,1)andportion s that requires sequential computation, s + p = 1 (i.e.: p = 1-s ) • on N processors, p can be computed in time p/N; overall time: s + p/N • since s+p=1, yields speedup (1 vs. N processors): • basically bound by 1/s • e.g., s=4%  speedup bound to 25fold (only!!) • Gustafson’s law: “counter attack”, much more promising results, cf.http://www.scl.ameslab.gov/Publications/Gus/AmdahlsLaw/Amdahls.html • (3) CCCDS: computational & communication complexity in distributed systems (no common term!) is concerned with growing “populations” in network • assume growth of problem size (e.g., no. of users or processes joining network fabric) comes with growth of resources (e.g., users join network with “their” PC & cable) • if every node has to keep track of every other node: won’t scale! • often: tradeoff computation - #of messages – size of messages

I.1.2 Introduction: Mathematical Scalability More on mathematical scalability, contd.: CCCDS, contd.: • problem 1 -meshing: if ‘added user’ means ‘added node’ (PC), then • resources of type “CPU, memory” grow at same scale as ‘problem’ (users), but • connectivity i.e. no. of average adjacent nodes does not keep pace:new PC adds 1 link  only direct neighbor has 1 add’l connection • this issue was coined as Flatland(referring to a 19th century novella by E.A. Abbott) • a quest was made to ‘escape from Flatland’ • this lead to the Hypercube, a hierarchical multiprocessor architecture where max. distance (no. of hops) between N nodes is O(log N) – at the price of O(log N) links added for each additional node • in the Internet, hierarchies of (sub)networks and routers play a similar role • problem 2 – explosion:if ≈each node has to cope for ≈every ‘added node’, then • data structures, no./size of messages, and computation times “explode”despite the added resources (CPU, memory, links per added node) • problem is countered, e.g., by means of hierarchies (see above), KISS principle (see below), many principles & approaches of distributed algorithms (e.g., forwarding of accumulated values only) • often, measured via modified complexity theory (Big-O notation for number/size of messages, etc.)

I.1.3 Introduction: Technical Scalability Resuming technical scalability from above • different subgoals defined in literature, different overlapping terms & definitions • many concepts developed over time, which usually serve several of these different goals to a varying degree • here: attempt to summarize as three top-level goals: • openness: graceful “spatial” diversity • components of various origins (re-)usable in various systems • and: systems (re-)usable in various environments • manageability under growth • concentration: separation isolation concentration of concerns • or deconcentration: autonomy of subsystems/components • longevity: graceful reaction to “temporal” changelarge systems bring about long life (cf. Internet)  make “robust” • plasticity (ability to adapt to changing conditions, evolve) • and: durability (ability to survive failure & “attack”) both can be approached via “proven properties” or “redundancy”

I.1.4 Introduction: Economical Scalability (Resuming economical scalability from above) At first sight: not a computer science issue, but • as business grows, so does IT infrastructure • this requires mathematical and technical scalability of course • in addition: the growing IT infrastructure, in its models / capabilities…, must reflect & support the growing business • in particular, a “vast variety of variants” (as business moves to other countries / regions  cultures/languages/legislations, but also to other market segments / customer “classes” /…) • this leads to requirements almost identical to those from “technical scalability”, but at a higher (application domain / biz) layer: • openness: interact with components/systems/environments “encountered” as business moves, diverges, & scales up • manageability … in spite of the many “variants” • longevity: • plasticity: adaptation to changing legislations/demands/… • durability: 24/7 support etc.

I.1.5 Introduction: Summary Summarizing from above, we define mathematical scalability :== the ability of a solution to perform well under problem growth • solution may be a system, method, algorithm • problem growth may refer to amounts of users, nodes, data • “coping well” refers to performance Economic scalability, as treated here (i.e. the IT aspect), often builds on technical scalability  in the remainder, we define economical-technical scalability:== the ability of a solution to cope well with spread • concerns time (longevity) & space (geographic distribution, #of components) • economically, spread may be over various contexts, countries, markets • implies quest for radical reduction of human intervention

I.1 Introduction: Summary Scalability

I.2 Importance of Scalability for UC Remember from Introduction: Kevin Kelly etc. • complexity of the made approaches that of the born • networked, distributed systems pre-dominant: interconnection of smart devices: each one responsible for tiny piece of world • for mathematical scalability, this means: • CCCDS most important • for technical-economical: • all 3 aspects remain equally important • yet, known approaches are not sufficient as we enter the UC era • current research suggests that core approaches change as follows: • for openness: from standards to meta-standards & ontologies • further approach isolation aka. separation of concerns ( see aspect #2) • for manageability: from isolation to autonomy • for longevity: from perfection to abundance • read, e.g.: from verification and protection to redundancy and diversity • For explanation and details, see chapter I.2

I.2.1 Mathematical Scalability versus UC Two aspects treated above are no key issues in the UC context: • Computational Complexity (in the ‘sequential programming’ sense): • remains important, but not more dramatic in UC context then else • major growth problem in UC: growth in no. of nodes (everyday objects computerized!) • 2nd biggest growth problem: growth in no. users • 3rd biggestgrowth problem only: amount of data; why = is minly a consequence  can be mastered in highly distributed system if data are stored / computed / used “local to origin” as much as possible (often necessary anyway to face 1st problem above) • however, extended Big-O notation used to describe CCCDS issues in UC, e.g.: “message complexity” (growth of #msgs required as a function of #nodes) • Speedup: • Speedup by “parallelization of sequential problems” played only a minor role in the past for the success of distributed systems • Rather, boosting success of distributed systems was dominated by the need to retrieve / store / compute / use data ‘local to origin’ (cf. the requirement above) • Thereby, parallelization came in almost naturally; why almost? because threads / communications require ‘design for parallelism’, cf. threads for blocking-RPC  CCCDS: most important issue of mathematical scalability in UC context • concerns two key (interwoven) areas: • algorithms / methods (includes comm. protocols) • development/deployment aids (platforms, middleware, comm. paradigms/languages)

I.2.1 UC-Scalability: CCCDS 1. As to algorithms/methods, CCCDS is based on long-lived principles, such as • “Hierarchization” (cf. above) • KISS: keep it simple, stupid; one incarnation of KISS reads: • “avoid per-user state (=data) in fabrics, hold state at users nodes” • considered key to success of Internet IP protocol • IP: no “per-connection” state  grew from 4 to almost 4*109 nodes • Xmits self-contained ‘datagrams’ without prior knowledge • today: per-flow (not yet per-connection) state desired in order tosupport Voice-over-IP etc.; shows: KISS is in conflict with other goals • “Human Behavior”: learn from humans facing growth (e.g.: facing piles of work) - laziness, optimism, simplification, omission of the less important, …) • widely used in design of distributed algorithms, interconnection fabrics etc. • still important, but UC seems to need to go further, see below • Bionics/Socionics: learn from nature facing growth – most promising for UC! • is this “the next big step?” • cf. chapter 1: Kevin Kelly, “Out of Control”; principles, e.g. • give away control (cf. autonomic computing as one related research community) • provide ample redundancy (cope for errors/defects, provide local copy/cache, …) • plan the unexpected (auto-evolution, self-adaptation, …)

I.2.1 UC-Scalability: CCCDS 2. As to development/deployment aids, CCCDS is based on scaleable communication & networks • scaleable communication paradigms • Dominating in the past: “information pull” – receivers determine information flow • Two-Party Peer2Peer – the early days of Internet • scaleable? interplay of 2 communicating parties isolated as much as possible from other communications  basis: application level communication protocols (SMTP, FTP etc.) • Client-Server paradigm, based on remote procedure call • with object oriented programming, moved to “remote method call” • scaleable? hundreds/thousands of clients treated similarly, “server farms”; protocols from a) still usable • less prominent: Multimedia streams (some scalability thru multicast&abstraction), Tuple spaces, … NOTES (cf. further chapters for details): • all of the above considered insufficient for UC for scalability reasons • yet, some of it (stateful connections as in a) and b), multimedia streams) still essential as part of UC solutions! • Next wave, suitable for UC: “information push” – sender (info source) determines info flow • Publish-Subscribe (“Pub/Sub”) paradigm, based on event routing • semantics resemble multicast (server sends new data only once, has initiative) • addresses technical scalability, too!! (self-configuration: parties don’t need to know each other) • yet: scalability of internal network ‘fabric’ (event routing) still under heavy research • scaleable networking paradigms • in the past, the raw Internet i.e. IP based End2End connections were deemed the scalable solution • next wave: overlay networks: ‘the net’ evolves from an End2End bit pipe to a ubiquitous distributed system • Multiparty Peer2Peer(the “modern P2P”, P2P for short): no central components, clients=servers no bottleneck, no single point of failure, tolerates high fluctuation of nodes • Grid Computing: originates in parallel processing community (cf. “Speedup”)  not interesting for UC at first sight, BUT: in form of “business grids” or “utility computing”, Internet evolves: BitPipe  ubiquitous distributed system • plus: opportunistic networks, smart items networks: see part I of lecture/book, “connectivity”

I.2.1 UC-Scalability: CCCDS Additional comment on CCCDS & development/deployment aids: as to “Flatland” issue (see above), approaches go “back-and-forth” in history: • step 1: everything connected as needed, “switched network fabric” • step 2: as demands grow, “Flatland” is often countered via shared media • cf. Ethernet, wLAN etc.: shared media access  avoid “switches” as bottlenecks • step 3: demands grow further, media (=bandwidth) sharing becomes expensive • … and often, ultra-fast switching becomes feasible (better HW & algo’s) •  return to “exclusive” media, fast switching; was the case for e.g., Ethernet • possible future effect: Smart Antennas may cause for wLAN what Ethernet experienced 10yrs ago: the “harmless” move from shared to switched medium • new paradigms (Pub/Sub, Overlay) may be considered as development / deployment aids on higher layers; consider 3 layers top-to-bottom: • (L.3 – new paradigms) nodes act as ‘intelligent routers’ in case of P2P Overlay … and nodes act as “intelligent shared medium” in case of Pub/Sub • (L.2 - IP) all atop IP routers which follow KISS principle and resides … • (L.1 – net fabric) atop ‘switched fabric’ in case of wired network • (L.1 – net fabric) atop ‘shared medium fabric’ (today; hardly used!) for wireless nets • will these three “mega-layers” (L.1) – (L.3) merge in the future?

I.2.2 Economical-Technical Scalability vs. UC Technical Scalability (resuming from 3.1.3): • For UC, the 3 key requirements remain, however: • in the past, isolation / separation of concerns were dominating • the boosting scale & complexity require new approaches, expressed in buzzwords like • zero, e.g., zero configuration / installation / maintenance /… • self, e.g. self installation / healing / organization / tuning / monitoring / … • more below • obvious: above buzzwords i) overlap ii) cover all 3 issues, iii) don’t say much Economical Scalability (resuming from 3.1.4): • UC means ‘real time enterprise’, therefore • IT infrastructure not only supports the business, it is the business • two important examples: • interoperability with “local components” at target markets • adaptation of ‘global’ components to ‘local situation’: important since • … global components are instantiated at different parts of the world • … components move to different parts of world (e.g. with nomadic user) one sub-issue: adapt to local legal & cultural setting - called compliance Note: term “geographical scalability” is known from literature, but is not used here, since definition from literature does not fit and combines sub-issues of all 3 categories used here (math/tech/eco)

I.2.2.1 Openness: Standardization capability of system to assimilate components Interoperability of Components capability of systems to assimilate to environments capability of components to assimilate to systems Component System System Environment Environment Environment remember: “Openness - Standards  Meta-Standards & Ontologies”; next 4 slides: standardization; here: preamble • openness: 3 key types of entities must interoperate: components, systems, environments • all 3 entities (usually): offer operations, exchange data (messages)  standardize data&operations • interoperation concerns: • syntax i.e. structure of data, operations • dynamics (sequencing) of data, operations: dynamics are an important part of the • … semantics of data, operations: what is their effect? • important: (de facto and real) standards can either • standardize the syntax/dynamics/semantics themselves or • means (lges., calculi, …) for defining these (the ‘meta level’) • this is a way smarter & more flexible approach if these means are used at runtime for dynamically introducing components to one another; but then, components (/systems/environments) have to dynamically interpret! (hardly realized today)

II.2.2.1 Openness – Standardization: Protocols Openness – standardization approach 1: Communication Protocols • (note: openness was goal #1 in Internet & ISO protocol standards) • components = ‘protocol entities’; interoperate via messages only mainly standardized the syntax … semantics, but also the meta-level (cf. brackets) • syntax: standardized via message headers – define bit/byte sequences (SDL) • dynamics: standardized sequencing rules; brought about standardized means: • rule based (Estelle ) / automata based (SDL) lges, but not used at component runtime • further semantics: important parts missing i.e. not formally definied • “meaning” of data (e.g.: “call request packet”) usually only verbally described • standards define interoperation of pairs of entities, not of may pairs • systems = protocol layers; standardized: interface between layers • interface: service provided thru interoperation of a pair of entities • standardized syntax: operations called ‘primitives’ (requests, replies) exchanged between a protocol entity and its users (higher layers) / underlying system (lower layers) – includes operations and data; beware: operations in both directions (user  provider) • dynamics&semantics: same as for components (‘concurrent automata’ needed!) • environments: embedding of protocol entities & layers in operating system etc. • usually, at most defined via operations ‘to be provided by environment’  handcrafted • in context of UC: for openness (in economical and technical sense) … • protocol standards still useful (cf. service discovery, Web Services) • however: • process to slow / heavy / inflexible (meta level not available at runtime!) • semantics not fully defined

I.2.2.1 Openness – Standardization: Components Openness in distrib. SW engineering (as opposed to protocols above): • “opennness thru standardization” refers to industry standards only • platforms: OSF DCE  Corba  .NET & JEE  Web standards • via interface definition languages (IDLs) related to platforms above • basis: up-to-date concepts for components (see below) and communication (RPC, Distributed Objects, …) • lately, UML as a design standard; UML dialects according to MDA (model driven architectures): programming happens in UML dialect • above-mentioned industry standards are for means to declare syntax/dynamics/semantics, i.e. meta level; • BUT: • mainly applied at design/implementation time, not flexibly at runtime • by standardizing the meta level, openness can only be (fully) reached if semantics are covered (i.e. “will res=sqrt(real v) really compute the square root of v?”) • not solved (in practice) today - will ontologies help??? see below

I.2.2.1 Openness – Standardization: Components Radically short 4-step history of “component based programming” since ~1970: • ADTs - abstract data types: • state (= data) hidden inside ADT, accessible via operations only; advantages • no undesired state manipulation (why?: controlled via operations), • implementation details hidden, can be changed (e.g., bug fix) independently; later: concurrent added • ADTs are types  first important approach to re-use (first step towards openness) • Objects: “from ADTs to classes”  superclass/subclass hierarchy • basis for concepts like inheritance, late binding, polymorphism: flexible combination/reuse • still: class tree must be known in advance, new component must “accept” existing tree (limitation reduced via reflection/evolution) • Components: intended as step beyond objects/classes, term not precisely defined • emphasize flexible combination: predefined interfaces (class concept relaxed), event/listener models: only events (≈messages) predefinied • Services (in the service-oriented-architecture – SOA – and WebService sense): • basically, service = self-contained distributed ADT, provides&uses operations (service calls) • services viewed as components for ‘programming in the large’, steps 1-3 for …in-the-small • steps 2+3 (inheritance, interfaces, event/listener, …) often not fully included  • services “glued together” via description of workflows, called business processes;more advanced: flexible service orchestration (aka … composition)

I.2.2.1 Openness – Standardization: Services A deliberately negative assessment of Web services & SoA • component interoperation • WebServices are industry standard, SOA is industry ‘recipe’ for definition of syntax • operations&data (op’ name & parameters – academic term: operation signature) defined in service interface • same as in ADTs, objects, components: nothing really new!! • SOA services are required to be “stateless” (from outside) • thus, standardizing on dynamics irrelevant! (accordingly, SOA-’contracts’ are notmuch more than signature) • SOA is a recipe  ‘buy your ingredients where you want’ (.Net, Java, WebServices…) • negatively speaking, SOA is ‘30 years of component-based programming explained to managers’ • … and de facto standard for definition of dynamics  semantics?? • irrelevant ‘by definition’ in SOA  • in WebServices, approached via Web Service Choreography Interface WSCI: for def. of sequencing rules • (above-described UML/MDA approach [@design time] supports at least dynamics) • component-system interaction?? concentrate on WebServices here • Web Services distinguish business processes (≈ workflows)  Services • subject: Web Service orchestration (as opposed to … choreography above) • limted layering/structuring for “hierarchies of services” (a BP may be exposed as a Web Service) • Key standards: Business Process Execution Language BPEL, Web Service Definition Language WSDL • Many additional / accompanying (in part, / competing – within W3C) standards • dynamic use/consideration of dynamics-rules (WSCI) in stateful business processes still left to developers, no ‘run time intelligence’ yet • thus, with respect to the dynamics, services are about as sophisticated as protocols • further semantics of services are usually known to a community, but • are usually not globally accessible • are not accessible (in machine-readable form) to other services – hope for ontologies?? see below

I.2.2.1 Openness – Isolation (note: overlap with issues of manageability) in SW Engineering there is a 30 years tradition of supporting openness thru isolation aka. ‘separation of concerns’ (in component context): most important contributions: • concepts for software components as such: see above • components are major approach to isolation/separation today • key goal: limit the effects of changes • aspect-oriented programming: • idea: isolate/separate functional aspects (security, reliability…) from core software • patterns (for design, programming …): • isolate/separate sketches of solutions to recurring problems • by nature (?), can be only partly formalized • isolation / separation of concerns is helpful for openness (a single place for dealing with assimilation), manageability, and longevity • However, in UC context … • even isolation is not sufficient: if, for every required assimilation, a change has to take place at just one place only, even this becomes too much as the rate of assimilations / changes grows

I.2.2.1 Openness: what’s next? Ontologies • infer from above: for UC, standardization must emphasize meta-level: • standardize means for dynamically exchanging syntax … dynamics … semantics of entities • WebServices may become standardization meta-level for syntax, maybe dynamics, but not (alone) for overall semantics • Ontologies hold promises here! A quick ontology 101: • purpose 1: organize terms/relations (i.e. syntax) in a certain domain (aka taxonomies) • purpose 2: define semantics by describing activities (operations) & their effects • ultimately, from domain knowledge to world knowledge? • attempted 10 years ago (CYC project), deemed failure • meanwhile, lots of advancements!! • got co-assistance from “folksonomies” like Wikipedia: free, verbal descriptions of “world knowledge” • research on ontology (oversimplied): 2x2 camps • hand-crafted vs. “automatically built” ontologies • detailed domain knowledge (limited scope) vs. world knowledge (limited depth? computation?) • OWL (along with RDF for syntax), promoted by W3C, de facto standards for semantics (i.e. meta-level)? • several variants because there is a tradeoff today: • powerful language  computational complex … to infeasible today (see OWL Full) • restricted language  restricted use for above purposes • OWL lite & OWL DL are based on description logic, OWL Full is not computational complete • Particularly important for economical scalability! (vast diversity of application domains, issues, etc. must be semantically described!) • ‘competing’ approaches for definition of “formal semantics” (cf. operational / denotational semantics) currently not progressing much • A possible future scenario: WebServices and Ontological Languages evolve into Meta-Standards for the runtime exchange and processing of descriptions for syntax & semantics of components, in systems  environments

I.2.2.1 Overlay Networks, Pub/Sub, and Openness Remember: overlay networks (P2P in particular) and Pub/Sub Connectivity considered viable approaches to mathematical connectivity i.e. CCCDS Hovewer, what about openness: wrt. P2P – would mean: platform exists where developers can build P2P nodes of their own & integrate them it into existing P2P fabric • no wide spread, close-to-standard such approach exists • even JXTA is a platform for developing individual but “closed” P2P networks, not components to participate in “open” P2P fabric wrt. Pub/Sub – would mean: platform for developing one’s own event publisher / subscriber & integrate it into existing Pub/Sub fabric • this is, in principle, possible and meaningful • however, there is no standardization, there are no wide-spread “open Pub/Sub systems”; in some industry segments (e.g., stock trading, finance), standards for limited use exist or emerge

I.2.2.2 Manageability (remember: “Manageability – from Isolation toAutonomy”) Up to recently, Manageability (under growth) was addressed with isolation / separation of concerns, too; therefore, see also slides above • separation of concerns in manageability led to, e.g., configuration files (more advanced: selfcontained configuration agents): single points of change handling • again, does not scale to UC if manual changes, even at single points, are required • scream for “zero installation, zero configuration” • cf. buzzword plug’n’play for single computers • solution? autonomy • either fully autonomous points-of-change-management - or (deemed more promising: ) • components autonomously handling change ‘themselves’ (single point of change not needed) Is service discovery the holy grail to autonomy for manageability? • goal of service discovery: services encounter, find, & use each other autonomously • without need for configuration/installation • obviously, this approach serves openness, too • many approaches, discussed in respective book chapter • residual problems: • many languages  i.e. no common meta-level standard yet • worse: as a to-be-discovered service ‘explains itself to the world’, …: • … this is only possible in known terms, … which means: • known service discovery works only if discovering-party already ‘expects’ to discover certain kinds of discovered-parties (laptop ‘expects’ to find printers, monitors, … in new surrounding) • approaches don’t supports discovery of something up to then “unknown” (imagine UC examples like: vending machine, air condition, …) • will ontologies help here?

I.2.2.3 Longevity (remember: “Manageability – from Perfection toAbundance”) • Consider: • Manageabilty: ability to cope with desired changes:improvement (e.g., ‘new version’) & enlargement • Longevity: ability to cope with undesired changes:failure & destruction (cf. IT security) • Longevity was addressed with ‘perfection’ in the past: • against failure, tried to develop ‘100% correct’ code • against destruction, tried to develop ‘100% secure’ entities • But: • imperfect humans search perfect solutions? • as complexity grows (towards that of nature)? • Therefore: look at nature • combination of perfection (e.g., ‘survival of the fittest’ in evolution) plus • abundance (attack & destruction are foreseen, extinction/replacement too) • basis autonomy: individuals replaceable, restricted effect on system

I.2.2.3 Longevity: Autonomy & Abundance • Autonomy emphasized in Self-X research community • considers “Self-X properties” • examples: self-configuration self-installation, self-maintenance, self-healing self-organization, self-tuning, self-monitoring • many of them also known as auto-X • research particularly pushed by IBM • beware: many different approaches subsumed under the new term Self-X, many discussed here and in following chapters • service discovery can be considered most well-understood self-X approach • basically: Self-X ≈≈ Scalability • autonomy&perfection not promising for UC without abundance • Therefore, need to look at nature i.e. bio-analog (‘bionic’) approaches • On the other hand: • don’t expect to map principles of nature to UC easily: • won’t accept failure of essential (/vital!) support function for humans • won’t easily map zillions-of-years evolution to sub-year timeframes (even on fast computers) • won’t easily solve century-old quest for tradeoff planning-chaos in nature • therefore, need to look at societies, too, i.e. socionic aproaches: • trade off autonomy & control (individual freedom vs. laws & law enforcement) • able to trade off autonomy

I.4 Overview of Further Chapters At the same time: Summary of I.2 general taxonomy of scalability goals wide-spread approaches novel approaches appropriate for UC related book chapters (grey: not in part I) Socionics & Bionics (Chapter 3) Event-Based & Publish/Subscr. Communication (Chapter 11) Peer-to-Peer Networks (Chapter 12) Ontologies & Ubiquitous Components (Chapter 6) SOA & Service Ecosystems (Chapter 7) Service Discovery (Chapter 8) plus: sub-issues of further chapters

Bibliography • tbd

Part I : Scalability Introduction