Ubiquitous Computing

Max Mühlhäuser, Iryna Gurevych (Editors)

Part I : ScalabilityIntroduction

Max Mühlhäuser

UbiquitousComputing

I.0 - Outline: What this chapter covers

1. General Introduction to Scalability– Explanation and first classification– Mathematical Scalablity– Technical and Economical Scalability

2. Scalability in UC (Ubiquitous Computing)– A short motivation, transition to section 3

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

4. Overview of Further Chapters– in relation to section 3

5. Bibliograhical Notes

UbiquitousComputing

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

UbiquitousComputing

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

Ns

sNp

s

ps

11

UbiquitousComputing

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

UbiquitousComputing 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:

1. openness: graceful “spatial” diversitya. components of various origins (re-)usable in various systemsb. and: systems (re-)usable in various environments

2. manageability under growtha. concentration: separation isolation concentration of concernsb. or deconcentration: autonomy of subsystems/components

3. longevity: graceful reaction to “temporal” changelarge systems bring about long life (cf. Internet) make “robust”a. plasticity (ability to adapt to changing conditions, evolve)b. and: durability (ability to survive failure & “attack”)both can be approached via “proven properties” or “redundancy”

UbiquitousComputing

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.

UbiquitousComputing I.1.5 Introduction: Summary

Summarizing from above, we definemathematical 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 defineeconomical-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

UbiquitousComputing I.1 Introduction: Summary

TechnicalScalability

(IT Aspects of)EconomicalScalability

Openness

Manageability(under growth)

economical-technicalscalability

Longevity

MathematicalScalability

CCCDS

Speedup(not in scope)

ComputationalComplexity

(not in scope)

Scalability

UbiquitousComputing

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:1. for openness: from standards to meta-standards & ontologies

» further approach isolation aka. separation of concerns ( see aspect #2)2. for manageability: from isolation to autonomy3. 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

UbiquitousComputing

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 biggest growth 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:

1. algorithms / methods (includes comm. protocols)2. development/deployment aids (platforms, middleware, comm. paradigms/languages)

UbiquitousComputing 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 to

support 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, …)

UbiquitousComputing 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

a) 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.)b) 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

c) 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”

UbiquitousComputing 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?

UbiquitousComputing 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

muchEconomical 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:1. interoperability with “local components” at target markets2. 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)

UbiquitousComputing I.2.2.1 Openness: Standardization

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)

Environment

System System

Environment

Component

Interoperabilityof Components

capability of system toassimilate components

capability of components to assimilate to systems capability of systems to assimilate to environments

Environment

UbiquitousComputing

II.2.2.1 Openness – Standardization: Protocols

Openness – standardization approach 1: Communication Protocols- (note: openness was goal #1 in Internet & ISO protocol standards)1. 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

2. 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!)3. 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:

a) process to slow / heavy / inflexible (meta level not available at runtime!)b) semantics not fully defined

UbiquitousComputing

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

UbiquitousComputing

I.2.2.1 Openness – Standardization: Components

Radically short 4-step history of “component based programming” since ~1970:

1. 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)

2. 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)

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

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

UbiquitousComputing

I.2.2.1 Openness – Standardization: Services

A deliberately negative assessment of Web services & SoA 1. 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 not much 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)

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

UbiquitousComputing 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

UbiquitousComputing

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

UbiquitousComputing

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

UbiquitousComputing I.2.2.2 Manageability

(remember: “Manageability – from Isolation to Autonomy”)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?

UbiquitousComputing I.2.2.3 Longevity

(remember: “Manageability – from Perfection to Abundance”)• 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

UbiquitousComputing

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

UbiquitousComputing I.4 Overview of Further Chapters

At the same time:Summary of I.2 scalability

mathematicalscalability

technical-economicalscalability

CCCDS

Manageability LongevityOpenness

Isolation PerfectionStandards

scaleablealgorithms

scaleablecommunication:

scaleablenetworks

e.g.: KISS, hierarchization,human behavior

Info. Pull: Client-Server+

IP based End2End

bionics / socionics

Info. Push:Publish/

Subscribe

Overlay Net’s:P2P, Grids, …

Meta-LevelStandards &Ontologies

Autonomy Abundance

Socionics & Bionics

(Chapter 3)

Event-Based &Publish/Subscr.Communication

(Chapter 11)

Ontologies &Ubiquitous

Components(Chapter 6)

SOA & Service Ecosystems (Chapter 7)

ServiceDiscovery

(Chapter 8)

Peer-to-PeerNetworks

(Chapter 12)

plus: sub-issuesof furtherchapters

generaltaxonomyof scalabilitygoals

wide-spreadapproaches

novel approachesappropriate for UC

relatedbook chapters(grey: not in part I)

UbiquitousComputing Bibliography

• tbd