Institute for Software ResearchUniversity of California, Irvine

www.isr.uci.edu/tech-reports.html

Christoph Dorn University of California, Irvinecdorn@uci.edu, c.dorn@infosys.tuwien.ac.at

Richard N. TaylorUniversity of California, Irvinetaylor@ics.uci.edu

Mapping Software Architecture Styles and Collaboration Patterns for

Engineering Adaptive Mixed Systems

June 2011 ISR Technical Report # UCI-ISR-11-4

Institute for Software Research ICS2 221

University of California, IrvineIrvine, CA 92697-3455

www.isr.uci.edu

Mapping Software Architecture Styles and Collaboration Patterns forEngineering Adaptive Mixed Systems

Christoph DornInstitute for Software ResearchUniversity of California, Irvine

cdorn@uci.edu

Richard N. TaylorInstitute for Software ResearchUniversity of California, Irvine

taylor@uci.edu

Abstract

Software architecture styles determine to large de-gree a system’s ability to adapt during runtime. Sim-ilarly collaboration patterns describe the flexibilitywith which humans can join or leave a team andwhat constraints apply. With the rise of large-scalemixed systems, the boundary between humans andsoftware becomes increasingly blurry. Thus, in thispaper, we propose to map architectural styles to col-laboration patterns. We raise awareness on how adap-tation strategies in software systems might facilitate themanagement of Internet-scale collaborations and viceversa. Ultimately, understanding the mutual propertiesand interdependencies is fundamental for a holisticapproach to run-time adaptation of mixed systems.

1. Introduction

Over the past twenty years we have observed atrend towards ”social software” leaving the realm ofgroup support systems for small or medium sizedteams and entering the dimension of internet-scalecollaborations. We find collective intelligence and userparticipation among the main characteristics of theWeb 2.0 [1]. Especially noteworthy is the increasinglyblurry boundary between humans and software. Hu-mans have become both provider and consumer ofcontent and computation. Humans are no longer justthe ”users” of a system but an integral part. Theirinteractions with other humans and software elementshas a significant impact on the runtime management ofsoftware components. In mixed systems humans andsoftware components are equal, first-class entities.

At the same time, systems have become too complexand large-scale to be managed by human administra-tors alone and mechanisms for self-adaptive systemshave been proposed [2]. In mixed systems any adapta-tion mechanism now also needs to consider the human

Technical Report UCI-ISR-11-4, June 2011

collaboration structure. As repeatedly pointed out [3],[4], architecture-based approaches to self-managementaddress adaptation on the right level of abstraction andgenerality, rather than focusing on language-level ornetwork-level adaptation. On the architectural level,adaptation actions generally describe the replacementof components and the reconfiguration of connectors.To this end, the underlying architectural style deter-mines to a large extent the effort required to implementruntime changes [5].

We argue that the same holds true for the human col-laboration structure. Collaboration patterns at design-time define what aspects change, how long adaptationtakes, what the sideeffects on the collaboration statusare, and what adaptation restrictions exist. Patterns atruntime enable abstraction from detailed interactionsand shared artifacts to reason about the structure ofthe collaboration. This motivates the main contributionof this paper: mapping architectural styles to collabo-ration patterns. Note especially that we do not claima perfect mapping between architectural styles andcollaboration patterns, as human entities exhibit a farhigher degree of autonomy and dynamicity than anypure software system.

The insights gained from this mapping are bidi-rectional. On the one hand, experience from buildinglarge-scale software systems can be applied to hithertounseen internet-scale collaborations. In return, adapta-tion strategies in collaborative settings potentially openup new perspectives on self-adaptation in systems ofmassively autonomous entities.

The remainder of this paper is structured as follos.In Section 2, we discuss software runtime adaptationaspects as first introduced in [5] and how these applyin a collaborative context. These aspects then serve tocharacterize the mapping of architectural styles to col-laboration patterns in Section 3. We apply the runtimeaspects in Section 4 to analyze existing mixed systemswith respect to collaboration adaptation capabilities.We discuss insights on adaptation of mixed systemsand the interplay between software architectural styles

and collaboration patterns in Section 5 before con-cluding this paper with an outlook on future work inSection 6.

2. Runtime Adaptation Aspects

In our attempt to combine software architecture andhuman collaboration structures, it seems natural tobuild upon the software runtime adaptation aspectsdefined in the BASE framework [5], [6] — behavior,asynchrony, state, and execution context. We revisitthe initial BASE aspects for sake of completeness,and then map the BASE aspects to the correspondingproperties of collaboration patterns.

Behavior highlights the scope of supported change.This aspect concerns the means for changing a sys-tem’s behavior and the respective level of abstraction(e.g., reconfiguration at code level or at componentlevel), and whether adaptation is limited to compo-sition of existing behaviors or new behaviors can beintroduced. This also includes specification of behaviorthat must remain unmodified.

Asynchrony addresses the implications that comewith the lag between initiating a system’s adaptationand its completion. Large-scale distributed systemstake potentially longer to update than compact, centralsystems and might never reach a completely updatedstatus. Relevant issues also include maintenance ofsystem constraints during adaptation and continuoussystem availability.

State refers to potential adaptation ”side effects”that have an impact on the system’s state. Changing adata type definition might require updating all currentinstances to the new definition. Replacement of a com-ponent potentially involves extracting that component’sstate for initializing the new component with that databefore the system can resume.

Execution Context raises awareness of constraintsthat determine whether or not adaptation can com-mence. For example, a component currently havingcontrol cannot be modified directly. When adaptationis time critical, however, a new, modified instance ofthat component called with the same input might bedeployed while aborting the old version.

These aspects represent equally important concernsin the context of collaboration patterns.

Behavior similarly addresses the means for adapta-tion. Reconfiguration of collaboration patterns is notlimited to replacing a user. Again, there are multiplelevels of granularity that allow behavior adaptation.Replacement of a complete company, a team, addinganother worker, or acquiring a required skill all cor-respond to component adaptation in software systems.

Overall, adaptation goes beyond human components.Also messages between members and shared artifactsrepresent significant loci of adaptation. Actions arethe equivalent to software component Connectors ininteraction patterns. They link humans to messages,artifacts, and involved software components. Actionsthereby define how to influence and drive a collab-oration and simultaneously specify how flexibly thecollaboration can evolve by itself.

Asynchrony in collaborations refers to the time itrequires to establish a (new) team, replace a worker,become acquainted to another worker, or learn a newskill and how the joint work is affected during thatphase. This aspect likewise raises awareness on con-straints that need to be enforced during the adaptation.As an example requirement, there must always existone software development team member who is fa-miliar with any particular piece of code rather thanexchanging the whole team at once.

State aspects draw attention to direct and indirectadaptation side effects when altering the means ofcommunication, the manipulation of shared artifacts, orreplacement of workers. The most knowledgable formof direct state change is loss of implicit collaborationknow-how upon removing a worker. Handover of suchimplicit collaboration information between outgoingand incoming workers needs explicit considerationwhen adapting the human interaction structure.

Execution Context refers to the possibility to adaptduring an active collaboration session. Whether a hu-man may cease work on a particular task, or whetherit is necessary to wait until task completion dependson multiple factors such as explicit contracts, cost andtime for repeating the task, or executing compensationactions. The same holds true for the degree of couplingbetween two or more workers during an ongoinginteraction.

3. Style-Pattern Mapping

For each mapping of architectural style to interactionpattern, we provide a short description of the archi-tectural style followed by a longer discussion of thepattern. We also supply real world example systemsthat support the respective pattern.

3.1. SOA/(C)REST vs Secretary

The basic components of the World Wide Web areclients requesting data and services from a set ofservers. The REpresentational State Transfer (REST)style defines: URLs as the sole means of identify-ing resources, a limited set of resource manipulation

primitives, state-less communication interactions, andmeta data describing the exchanged resources [7].Service-oriented Architectures (SOA) follow the sameclient/server paradigm and share some of the RESTprinciples but focus on providing operations (i.e., ser-vices) rather than content [8]. Computational REST(CREST) aims to go beyond a mere combination ofthe simplicity of REST and the computational aspectsof SOA [9]. CREST enables seamless interleavingof content and computation thereby supporting the(partial) execution of services not only on the serverside but also on the client side. All three styles encour-age the use of intermediaries such as proxies [10] orbrokers [11] for adaptation purposes.

In human collaboration, secretaries (or assistants)take on a role similar to SOA/(C)REST intermediaries.Clients cannot contact the desired person directly. In-stead, they pass their request to the secretary first, whoforwards the message to the principal and relays theresponse back to the client. Alternatively, secretariesmay respond immediately on behalf of the principal.Principals in turn act as clients of their superiors.Depending on the particular application, secretariesserve as load balancing proxies, protection proxies,caching proxies, or brokers [12].

Behavior: Clients are volatile and expected to con-tact a secretary unannounced.Secretaries and principalsmay be replaced anytime, however their relation islonger lasting than between client and secretary. Theset of supported message types and artifact types variesfor each secretary and principal instance. AssociatedSecretaries and principals, however, necessarily sup-port overlapping type sets. A single secretary may becoupled to more than one principal and vice versa.

Asynchrony: The secretary may decide on how torespond and on how to route the request depending onthe client’s request and the principal’s availability. Incase neither principal nor secretary are able to respond,the secretary can ask the client to repeat the request ata later time. Where supported, the secretary may offerto put the request on hold and notify the client oncethe principal becomes available again.

State: Secretaries are initially stateless and buildup any required internal state from interactions orquerying the principals for preferences. Having thenew secretary temporarily observe the current secretaryenables rapid establishing of state. Alternatively, asecretary can refer clients to another secretary duringreplacement.

Execution Context: A principal may decide torefuse responding to any requests, forcing the secretaryto reply on behalf or reroute the request to anotherprincipal. A secretary needs to complete all current

requests before replacement but can redirect new re-quests to other assistants.

3.2. Publish-Subscribe vs Mailinglists

In the pub/sub style, publishers and subscriberscommunicate indirectly by means of events and aretypically unaware of each other’s identity [13]. Tra-ditionally, a message oriented middleware (e.g., amessage bus) manages event collection and distribu-tion. Subscribers process the received events and mayproduce new events of their own. Such strong com-ponent decoupling enables simple adaptation throughruntime adding and removing of event producers andconsumers [14]. Additional event filtering allows formore fine-grained adaptation [15].

In collaborative environments, the main purpose ofmailing lists (or newsletters) is pushing informationof general interest to a larger audience. Mostly in theform of emails (e.g., Listserv [16]), this collaborationpattern comes in different flavors, characterized by theanonymity of sender and/or receivers, the ability of re-ceivers to reply or post their own message, and whetherthe list is topic or person-centric. In recent years,micro-blogging platforms such as Twitter have becomea popular tool for rapidly disseminating informationin large-scale environments [17]. In contrast to purelytopic-centric subscriptions in pub/sub, subscriptionsin micro-blogging environments are mostly person-centric. Here additional filtering capabilities are calledfor to distinguish between truly relevant events andnoise.

Behavior: With topic-centric lists, publishers andreaders may dynamically join and leave while therespective list remains unaffected. The lifetime of aperson-centric list usually remains coupled to the pub-lishing activity of its respective author. Simultaneously,new topics emerge and existing topics loose theirrelevance.

Asynchrony: Changes to a list’s subscriber basehave no side-effects. Single changes are instantaneousand require no synchronization with other users. Au-thor removal from person-centric lists and single-publisher lists may cause receivers to resort to alter-native event sources. However, support mechanismsfor subscribing to relevant lists is outside the pattern’sscope.

State: The collaboration domain and purpose de-fines the requirements for state transfer upon swappingpublishers. Consumers build their internal state as newmessages arrive. Most mailing list and micro-bloggingimplementations maintain a history of past messagesthat enable immediate state reconstruction.

Execution Context: Message dispatching and re-ceiving is considered atomic. Hence, independent uni-directional messages pose no restrictions on the re-placement of publishers or readers. When multipleindividual messages from multiple authors create adiscussion thread the removal of an involved publisherrequires other authors to compensate. Newly joiningreaders need to build the discussion thread from his-torical records or wait for the end of the discussion.

3.3. Tuple-spaces vs Collaborative Editing

Tuple-spaces are similar to the publish-subscribestyle with respect to strong decoupling of producersand consumers. Instead of messages, a tuple-spacemanages storage and retrieval of data items (i.e., ar-tifacts) thereby imitating a (distributed) shared mem-ory [18]. Consumers have potential write access tomanipulate the shared artifacts. Any update becomesvisible to other consumers including the initial pro-ducer [19].

Collaborative editing describes any type of ac-tivity where participants communicate predominantlythrough the manipulation of a shared artifact. Researchin the domain of CSCW focused early on such capa-bilities in the context of shared workspace systems andgroupware systems [20]. Several approaches were pro-posed for large-scale environments [21], until internet-scale collaborative editing became a universal successwith the emergence of wikis [22]; the most prominentexample being Wikipedia.

Behavior: Authors and collaborators may join orleave the workspace at any time. Collaborators arefree to create new shared artifacts (thereby becomingauthors) or manipulate existing ones. Typically, onlyauthors can remove the artifacts they own. Alteringthe shared artifact’s type is usually limited to newartifact instances. How to obtain artifact access rightsis outside the pattern’s scope.

Asynchrony: Where upgrading an existing artifactis envisioned, authors and collaborators need to waitwhile the upgrade takes place. A permanently leavingauthor needs to hand over ownership for each of hisartifacts to at least one collaborator. Replacement ofregular collaborators requires termination of all theirartifact manipulation activities.

State: The shared artifact maintains the collabo-ration status. The collaborative editing system needsto disclose the manipulation log when collaboratorsrequire the artifact’s history to construct their inter-nal state. Alternatively, swapping two collaborationsrequires an out-of-band mechanism to exchange theirinternal states.

Execution Context: Multiple concurrent write re-quests need queuing and/or duplication of the item,subsequent parallel manipulation, and finally merging.The collaborative editing pattern lacks any primitivesto coordinate mutually depending artifact read andwrite actions by distributed collaborators.

Online discussions forums [23] ,bulletin boards, andblogs [24] populate the spectrum between Mailinglistsand Collaborative editing. Knowledge is distributedfrom producers to consumers, who in turn raise themessage to the level of a shared artifact throughrefinement or extension in the form of commentary.Discussion topics, and blog entries are thus more thana simple broadcasted messages but at the same timedo not offer the full range of manipulation capabilitiesthat come with shared artifacts.

3.4. Components and Connectors (C2) vs Or-ganizational Control

C2 is an event-based style to decouple componentsvia explicit connectors [25]. Components cannot in-teract directly but hand over any events and requeststo connectors which pass them on to the respectivedestination component. Components form a hierarchywhere lower-level components request operations fromhigher-level components. Communication down thehierarchy, however, is limited to notifications.

The C2 style describes also inverse hierarchical or-ganizations, with managers situated towards the bottomand workers towards the top. The two interface typesin C2 — upward requests and downward notifications— corresponds to two functions of organizationalcontrol [26]: behavior control and output control. Thesupervisor applies (pro-active) behavior control (i.e.,upward requests) to trigger a specific, desired behav-ior. Output control describes the manager monitoringwork progress (i.e., downward events) to reactivelymaintain, or respectively restore, work performance.Requests and notifications are not addressed directlyto individual employees but roles. Hence, roles arebound to particular capabilities thereby decoupling therequest addressing from the actual person executingthe request.

Behavior: Organizational structures lack the samedegree of loose coupling that C2 Connectors achieve.Assistants can be compared to connectors but are usu-ally not universally implemented (i.e., typically only inmanagement). Organizational charts describe the linksbetween the different roles and the mapping to actualhumans but cannot provide request and event buffering.Adaptation corresponds to structural updates of theorganization chart in terms of reassigning employees

to roles and rewiring role relations.Asynchrony: When replacing an employee or

rewiring a role, higher-level subordinates need to buffernotifications until adaptation has completed. Likewise,lower-level supervisors will not receive notificationsfor the adaptation duration and have to refrain fromdispatching requests to the affected employee. Withassistants in place, responsibility for buffering of re-quests and notifications is transferred from employeeto assistants.

State: Individual employees maintain their ownstate. State transfer is only required between twoswitching employees when collaboration know-howremains employee internal and cannot otherwise bemade explicit. New employees can apply the orga-nizational chart to contact colleagues to retrieve (ad-ditional) information necessary for constructing state.Organizations typically store general purpose stateinformation in corporate ”data warehouses” at thehighest relevant level in the hierarchy. Accounting data,for example, remains low at the management level,whereas travel guidelines are placed at the top of thehierarchy available to every employee.

Execution Context: Any ongoing request needs tobe completed before an employee can be replaced.If an employee becomes unavailable during requestexecution, the request has to be addressed again withher substitute employee.

3.5. Map-Reduce vs Master-Worker

Map-Reduce leverages parallel computing by divid-ing a task into multiple independent subtasks [27].A central coordinator node subsequently assigns eachsubtask to a different processing machine (map phase).In the reduce phase, the coordinator collects the indi-vidual task outcomes and distributes them again foraggregation to generate the final result.

Partitioning tasks also works well in human collabo-ration when the resulting subtasks remain independent.The Master defines the individual work packages.In contrast to Map-Reduce, task distribution occursboth in push and pull style. The former procedurehas tasks directly assigned to Workers, whereas thelatter procedure enables workers to choose which taskthey prefer to work on. The large-scale deploymentof the Master/Worker pattern is often referred to ascrowd sourcing [28], the most prominent examplebeing Amazon Mechanical Turk.

Behavior: The master decides upon the number ofworkers that can work in parallel on the same taskartifact. In the pull-style assignment, workers choosewhich tasks to perform, and whether to return a task

unfinished. In push-style assignment, workers receivenew tasks in their inbox but may still have the optionto reject or delegate a task.

Asynchrony: A task artifact completely decouplesmaster and workers. The master has the option toreassign the task to another worker (or make it avail-able again) when the worker fails to complete thetask in a predefined time-frame. The master has theresponsibility to schedule multiple identical tasks forsake of reliability, or issue multiple sequential tasksuntil the desired result quality has been achieved.

State: The task artifact contains the complete col-laboration state. Replacement of workers has no side-effect on the state.

Execution Context: All workers execute their taskindependently, hence, no synchronization of results isrequired. Multiple workers assigned to the same taskartifact work on distinct copies and have no knowledgeabout each other. They remain similarly unaware ofany replacement of the master. The new worker sim-ply obtains the task description and commences taskexecution independently of any previous work done.

3.6. Peer-to-Peer (P2P) vs Self-organization

The P2P style assumes a large number of entities,each offering the same service they simultaneous re-quest from their peers [29], but not possessing nec-essarily the same state. The major motivation behindP2P is resilience to node failures. To this end, P2Psystems usually lack a centralized control mechanismsand expect peers to arbitrarily join and leave thenetwork. Instead, nodes maintain a limited list ofneighboring peers for exchanging and updating theirview of the network. In sufficiently large networks,super peers have proven to increase efficiency by pro-viding higher-level coordination services (potentiallyforming an overlay peer-to-peer network themselves).The dominant application area of P2P technologies iscontent distribution networks [30].

The P2P style appropriately describes self-organizing teams where no dedicated coordinationstructure exists. Instead, individual memberscollaborate in an ad-hoc fashion to complete acommon goal. The flexibility provided by P2Pallows individual members to become more activewhenever they see fit without incurring muchcoordination overhead. Newcomers receive briefingsfrom multiple members and thus are quicklybrought up-to-date. Multiple communication pathsmaintain the information flow in case a memberbecomes temporarily or indefinitely unavailable.Many open-source software development efforts are

structured in a P2P fashion which allows them toform self-organizing teams [31]. Self-organization,however, also has its downside as the effect of(flash)mobs demonstrates. Another challenge posesthe mobilization of sufficiently many participants tokeep the collaborative momentum alive.

Behavior: In a self-organizing team, every memberis free to leave any time, and new members join spon-taneously. Existing members are able to form arbitrarylinks to any other member, e.g., send messages to anyother member they consider a relevant receiver. Stablemembers are suitable candidates for super peers but notexpected to serve that role permanently. In additionusually super peers introduce new message types toimprove collaboration efficiency.

Asynchrony: Typically only a (small) subset ofmembers fluctuates at a single point in time whichhardly disrupts the team. Retirement of super peerspotentially degrades a team’s performance until an-other member assumes the vacant position. The uptakeof new message types occurs gradually as the updatepercolates through the network.

State: Collaboration state is generally spread aboutmultiple members (i.e., those that were involved injoint activities). However, additional mechanisms forexternalizing member state such as shared artifacts ormessage history is outside the scope of the pattern.New members gather the required state informationfrom existing peers.

Execution Context: Members engage in joint ac-tivities and are free to leave at any time. They are,however, expected to either complete the task beforeleaving or at least externalize the task relevant partof their internal state. Abruptly leaving members mayresult in lost collaboration know-how.

4. Example Systems

In the following subsections, we present some realworld examples of mixed systems and analyze how theunderlying collaboration patterns influence the supportfor adaptation.

4.1. Amazon Mechanical Turk

Amazon Mechanical Turk 1 (MTurk) is one of themost prominent examples for crowd sourcing. TheMTurk platform implements the Master-Worker collab-oration pattern, enabling Requestors to register a Hu-man Intelligence Task (HIT). Workers are subsequentlyable to search through the set of registered HITs and

1. http://www.mturk.com

accept HITs they are interested in. Besides task spe-cific details, a requestor configures the HIT’s lifetime,monetary reward, duration, the maximum number ofassigned workers, and required worker skills. Once theworker has accepted a HIT, he has the allotted time(duration) to complete his copy of the task (i.e., his as-signment). Alternatively the worker can return the HITwithin the allotted time, or let it time out. The HIT isthen considered abandoned. Returning and abandoningreflects in a worker’s reputation. The requester retrievesthe submitted assignment and approves it when theresult quality is satisfactory, or otherwise rejects itwithout paying the worker.

Runtime adaptation focuses on those mechanismsthat provide for a satisfying collaboration of all par-ticipants; both requestors and workers. The requestoraims for timely and high quality HIT execution. Theworker’s primary goal is finding interesting and suit-able HITs and receiving pay for the work performed.

Behavior: As outlined in Section 3.5, the Master-Worker pattern’s main form of adaptation lies in thereplacement of workers, the rewiring of workers totasks, and the manipulation of the task artifacts. AsMTurk supports only pull-based task assignment andfeatures a dynamic workforce that cannot be directlycontrolled, all adaptation actions unfold their effectsindirectly through HIT manipulation.

Requestors have full control over the creation, re-configuration, and removal of HITs. They regulate thewiring of workers to HITs through (i) direct blockingof workers and (ii) specification of required skills. Therequestor has full control over the HIT relevant skillsand can assign and revoke the corresponding workerqualification anytime.

Workers have less control over HITs per se, but typ-ically filter HITs for matching qualifications, rewards,and duration. In MTurk, only workers can establisha collaboration through accepting an assignment. Al-though they are able to return or abandon a HIT, thisreflects negatively on their reputation.

Asynchrony: The crowd sourcing environment ofMTurk does not foresee explicit replacement of aunresponsive or low quality worker. In the formercase, MTurk automatically makes the HIT availableagain once the work duration has expired. In thesecond case, the requestor needs to register the HITagain. The requester decides on appropriate HIT valuesfor the number of simultaneous workers, reward, andduration to promote timely and high-quality results.Unattractive rewards or unrealistic timelines coupledwith a lack of backup workers leads to delays in HITexecution.

Similarly, MTurk addresses unresponsive requestors.

Each HIT specifies a deadline after which an assign-ment is automatically approved.

State: Workers have read-only access to the HITdescription. They also remain unaware of any otherworker having (currently or previously) accepted therespective HIT. Returning or abandoning a HIT hasthus no side-effect on any other worker assigned inparallel. The assignment results remain with the workeruntil he explicitly submits his work. No modificationsare possible thereafter. The requester obtains readaccess to an assignment as soon as it is submitted.Approval and rejection are independent of other as-signments of the same HIT but multiple results areusually compared for quality assurance purposes.

Execution Context: The collaboration between re-questor and worker ends upon assignment approvalor rejection. Both parties can prematurely terminate aHIT anytime. As outlined above, a worker can returnor abandon the HIT with reputation side-effects. Therequestor has the options to force expire the HIT suchthat it becomes invisible to new workers but allowsexisting assignments to be completed. The result isthen open for approval or rejection. Alternatively therequester can disable a HIT which removes the HITand automatically approves all submitted and pendingassignments.

4.2. Twitter

Twitter 2 is a micro-blogging platform used tocreate and maintain a social network [17] as well asdistributing news [32]. Twitter supports collaborationaccording to the Publish-Subscribe style: every user issimultaneously a publisher and subscriber. A user sub-scribes to another user’s twitter feed, thereby becominga follower of the other user.

When a user posts a message — denoted a tweetwhich may be up to 140 characters — it becomesvisible on her profile page (if the account is public).At the same time, the tweet is pushed to the hometimeline of all her followers. Twitter supports messagemeta information in the form of hash tags as topicdescriptors (e.g., #music), references to other users(so-called mentions, e.g., @BarackObama), and URLshorteners to link to external resources. Users applyretweeting to refer to a previous messages, or repliesto respond to another user.

Behavior: Run-time behavior adaptation focuseson managing subscriptions — i.e., manipulation ofthe follower list artifact — and on message content.Subscribers are free to follow any publisher with apublic profile. Subscription requests for private profiles

2. http://twitter.com

need the publisher’s approval. Twitter provides to eachpublisher a list of followers. The publisher has theoption to block a particular subscriber. This preventsmessages from showing up on the subscriber’s hometimeline, but they remain available to everyone on thepublisher’s public profile.

Although each publisher is associated with a singleaccount and thus profile, she typically distinguishesdifferent message types using hash tags. New hash tagsmay be introduced by any publisher anytime. Usersthen search for a particular hashtag and subscribe tothe respective tweeter feeds to become followers.

Asynchrony: An unavailable publisher has no directeffect on her subscribers. Followers merely cease toreceive events from that publisher but continue to re-ceive events from other publishers. A subscriber needsto search for an alternative message source in case apublisher is his single sources of (a particular type of)continuously required events. Offline followers receivethe latest events upon reconnecting to Twitter. Theyare not guaranteed to receive all messages after an ex-tended duration of absence as Twitter does not providethe complete history but only the recent messages. Thesubscription operation is typically instantaneous andnew messages are accessible immediately. Messagesare delayed until approval when requesting to followa user with private profile.

State: Users gather information (i.e., state) frompublic profiles available before following the publisher.Hence, a user having just joined Twitter can easily per-ceive which existing users to follow. On the publisher’sside, messages remain available even when there areno followers.

Execution Context: There are no constraints for(un)following a publisher or blocking a subscriber.Merely private profiles require approval before a re-lation is established.

While the main collaboration pattern is pub-lish/subscribe, twitter also supports direct messagesthat remain private between the sender and receiver.A private message can only be sent to followers, hasthe same 140 character limit as a tweet, and can bedeleted from the receiver’s inbox by the sender.

5. Discussion

Differences within the patterns become manifestin current collaboration frameworks. Support forlarge-scale collaborative work remains unsatisfactorywhereas examples of large-scale deployments existfor all architecture styles. This hints at exploitablesynergies between styles and patterns.

5.1. Differences between Patterns

The presented collaboration patterns address differ-ent approaches for coordinating work, communicationbetween users, and disseminating information.

They differ in which users can be replaced or rewiredand who has control over the respective (adaptation)actions. The Master-Worker pattern enables Mastersto decide over which worker may work on a particulartask. In pure Self-organizing teams, no worker hasexplicit control over any other collaborator.

Changes may have little to no effect on the over-all collaboration or potentially bring it to a com-plete standstill. A new Secretary might break ac-cess to a whole range of principals, while a leavingworker might cause only a small delay in the Master-Worker pattern. In Collaborative Editing, an unavail-able worker has typically no impact.

Some patterns support explicit externalization ofstate while others neglect this aspect. The Master-Worker pattern defines explicit task artifacts. Mail-inglists frequently keep a history of recent messageswhile Organizational Control has no explicit notion ofcollaboration state.

Finally, some patterns allow users to freely leave andjoin the collaboration at any time, while certain pat-terns come with explicit, non-trivial side-effects. Re-placing a Secretary or Principal requires more prepa-ration than merely adding a new Worker to a Master.A Mailinglist consumer can leave any time withouteffecting other subscribers, whereas a member of aSelf-organizing team commonly needs to externalizehis collaboration state first.

5.2. Scalability of Styles and Patterns

In recent years we have found applications andframeworks for each of the discussed architecturalstyles that support deployment in a large-scale fashion.REST represents the fundamental style of the WorldWide Web. Publish-Subscribe systems such as Sienabring together thousands of publishers and event con-sumers. Tuple-spaces serve as the underlying coordina-tion mechanism in massive agent-based systems [33].The Myx framework3 supports the implementation ofC2 style applications. Hadoop is one implementationof the Map-Reduce style supporting petabyte sized datawarehouses [34]. Finally, Bittorrent is an exemplaryprotocol for efficient internet-scale P2P content distri-bution [35].

3. http://www.isr.uci.edu/projects/archstudio/myx.html

General purpose technical systems for large-scalehuman collaboration do not cover the collaboration pat-terns to the same extent. On the simple side, message-centric systems such as Twitter and Google Groupsprovide pub/sub facilities. Email, Skype, and XMPPare examples for human P2P communication. Socialnetworks and blogging sites blur the boundary betweenmessages and artifacts. Wikis and source code repos-itories support Collaborative editing. Crowd sourcingapplications such as MTurk realize the Master-Workerpattern but severely limit human interactions. Othertask-centric frameworks such as Bugzilla remain verydomain specific without becoming true Collaborativeediting environments. At the internet-scale level, wefind no systems or frameworks that support the Secre-tary pattern, Organizational control, or Self-organizingteams that go beyond message-based interaction. Notethat these patterns are nevertheless supported by group-ware systems targeting small and medium-scale en-vironments. Furthermore, P2P style collaborations insoftware developer teams exhibit emergent behaviorsuch as secretaries (SOA/(C)REST) or managers (C2).However, corresponding tool support in large-scalesettings is virtually non existent.

As we explore new directions to cover yet unsup-ported patterns in large-scale settings, we should applylessons learned from designing and building large-scale software systems. As we point out in the nextsubsection, insights apply in both directions.

5.3. Synergies between Styles and Patterns

As the authors of the original BASE framework havepointed out [6]: the vital mechanisms for architecture-driven run-time adaptation are (i) identification of theexchangeable parts and rendering them malleable, (ii)managing the interactions involving those parts, and(iii) explicit state management. We observe the samestrategies in human collaborations: (i) establishing theinvolved roles and their respective adaptation authority,(ii) capturing and externalizing collaboration know-how, and (iii) promoting explicit shared artifacts (es-pecially task descriptions).

Adaptation plans in pure software systems are typi-cally simply enacted. This approach, however, cannotbe directly applied to human collaborations. The rulesand implications of automatic collaboration adaptationactions need to be known upfront to all involvedparties. Most often, however, individual users retain asignificant amount of control over their environment.Here, we can only give recommendations on what todo, e.g., who to contact, how to filter information,or what artifacts to manipulate. Adaptation mecha-

nism addressing such human collaborations are thusbecoming candidates for designing new techniquesfor managing software system comprising massive,autonomous, unreliable components. Individual, self-governing components cannot be directly manipulatedbut accept only recommendations. They might followthe recommendations or choose to ignore them basedon internal, unobservable constraints. Subsequently,human-inspired properties such as trust, reputation, orcooperativity potentially become applicable to softwarecomponents. Software entities might take context intoaccount when deciding upon cooperation. In turn, un-cooperative components may face resource restrictionsor have access limited to noncritical resources.

When we choose a collaboration pattern duringsystem design, we have to keep in mind that a sin-gle pattern usually fits only very simple, independenttasks. Complex work — be it large-scale, under-specified, or distributed — calls for more freedom andflexibility and thus requires combination of multiplestyles. Take platforms for open source developmentsuch as GitHub or Sourceforge as an example: theyprovide an integration of wikis, mailing lists, coderepository, and bug tracking. Note in general that thepresented patterns provide idealistic structures for un-derstanding the implications of system design choices.Most real world applications integrate two or morecollaboration patterns to cover complementary needs.Facebook, for example, primarily adopts a publish-subscribe/mailinglist style (3.2) for personal statusupdates and enables additionally a P2P style (3.6) textchat between friends for more focused communication.

Thus when collaboration complexity increases, ex-ternalizing state becomes ever more important as wehave to trade-off strong decoupling for the benefitsof joint creativity. This immediately raises privacy,respectively security issues. Large-scale collaborativeenvironments in particular need to take up design prin-ciples from software systems — e.g., least privilege,complete mediation, separation of privilege — and ap-ply them to human entities. In return, the mechanismshow humans establish trust through joint, repeatedinteractions provides an alternative, self-regulating se-curity approach in open software systems.

6. Conclusion

Architectural styles and collaboration patterns sharethe same run-time adaptation aspects: behavior, asyn-chrony, state, and execution context. We applied theseaspects to highlight how architectural styles can bemapped to collaboration patterns and vice versa. Wehope that becoming aware of the similarities helps

to cross-pollinate adaptation strategies for softwaresystems and collaborative work. Fault-resilient archi-tectural styles such as P2P or tuple spaces provideus techniques for understanding and governing self-organizing open source teams or large-scale collabora-tive editing. In return, collaboration patterns that lever-age human dynamics and autonomy provide conceptsto address adaptation of systems comprising multiple,independent software components.

Two complementary future efforts build upon thismapping of styles and patterns. On the one hand, we in-tend to refine the aspects that currently describe large-scale, dynamic systems (e.g., WWW, protein networks)to better characterize internet-scale collaborations. Weexpect relevant aspects to include the power-law linkdistribution, the rich-club phenomenon, and networkmotifs. On the other hand, we have begun work on anarchitectural description language that integrates thehuman collaboration structure and software architec-ture. Ultimately, such a description will enable rea-soning about the effects of software reconfiguration onhuman collaboration and vice versa, thereby realizinga true, unified adaptation of the overall mixed system.

Acknowledgment

This work is supported in part by the NationalScience Foundation under grants CCF-0917129, CCF-0820222, and CCF-0808783 and the Austrian ScienceFund (FWF) under grant number J3068-N23.

References

[1] T. O’Reilly, “What is web 2.0: Design patterns andbusiness models for the next generation of software,”MPRA Paper 4578, Mar. 2007.

[2] M. C. Huebscher and J. A. McCann, “A survey of au-tonomic computingdegrees, models, and applications,”ACM Comput. Surv., vol. 40, pp. 7:1–7:28, August2008.

[3] P. Oreizy, M. M. Gorlick, R. N. Taylor, D. Heimbigner,G. Johnson, N. Medvidovic, A. Quilici, D. S. Rosen-blum, and A. L. Wolf, “An architecture-based approachto self-adaptive software,” IEEE Intelligent Systems,vol. 14, pp. 54–62, May 1999.

[4] J. Kramer and J. Magee, “Self-managed systems: anarchitectural challenge,” in International Conference onSoftware Engineering, 2007, pp. 259–268.

[5] R. N. Taylor, N. Medvidovic, and P. Oreizy, “Ar-chitectural styles for runtime software adaptation,” inWICSA/ECSA, 2009, pp. 171–180.

[6] P. Oreizy, N. Medvidovic, and R. N. Taylor, “Run-time software adaptation: framework, approaches, andstyles,” in Companion of the 30th international confer-ence on Software engineering, ser. ICSE Companion’08. New York, NY, USA: ACM, 2008, pp. 899–910.

[7] R. T. Fielding and R. N. Taylor, “Principled designof the modern web architecture,” ACM Trans. InternetTechnol., vol. 2, pp. 115–150, May 2002.

[8] M. P. Papazoglou, P. Traverso, S. Dustdar, and F. Ley-mann, “Service-oriented computing: State of the artand research challenges,” Computer, vol. 40, pp. 38–45, November 2007.

[9] J. R. Erenkrantz, M. M. Gorlick, G. Suryanarayana, andR. N. Taylor, “From representations to computations:the evolution of web architectures,” in ESEC/SIGSOFTFSE, 2007, pp. 255–264.

[10] E. Gamma, R. Helm, R. E. Johnson, and J. Vlissides,Design Patterns: Elements of Reusable Object-OrientedSoftware. Reading, MA: Addison-Wesley, 1995.

[11] F. Buschmann, K. Henney, and D. C. Schmidt, Pattern-Oriented Software Architecture, Volume 4: A PatternLanguage for Distributed Computing. Chichester, UK:Wiley, 2007.

[12] S. Dustdar and T. Hoffmann, “Interaction pattern de-tection in process oriented information systems,” DataKnowl. Eng., vol. 62, pp. 138–155, July 2007.

[13] P. T. Eugster, P. A. Felber, R. Guerraoui, and A.-M. Kermarrec, “The many faces of publish/subscribe,”ACM Comput. Surv., vol. 35, pp. 114–131, June 2003.

[14] L. Fiege, F. C. Gartner, O. Kasten, and A. Zei-dler, “Supporting mobility in content-based pub-lish/subscribe middleware,” in Middleware, 2003, pp.103–122.

[15] F. Fabret, H. A. Jacobsen, F. Llirbat, J. Pereira, K. A.Ross, and D. Shasha, “Filtering algorithms and imple-mentation for very fast publish/subscribe systems,” inProceedings of the 2001 ACM SIGMOD internationalconference on Management of data, ser. SIGMOD ’01.New York, NY, USA: ACM, 2001, pp. 115–126.

[16] D. Grier and M. Campbell, “A social history of bitnetand listserv, 1985-1991,” Annals of the History ofComputing, IEEE, vol. 22, no. 2, pp. 32 –41, apr-jun2000.

[17] D. Zhao and M. B. Rosson, “How and why peopletwitter: the role that micro-blogging plays in informalcommunication at work,” in Proceedings of the ACM2009 international conference on Supporting groupwork, ser. GROUP ’09. New York, NY, USA: ACM,2009, pp. 243–252.

[18] D. Gelernter, “Generative communication in linda,”ACM Trans. Program. Lang. Syst., vol. 7, pp. 80–112,January 1985.

[19] G. P. Picco, D. Balzarotti, and P. Costa, “Lights:a lightweight, customizable tuple space supportingcontext-aware applications,” in Proceedings of the 2005ACM symposium on Applied computing, ser. SAC ’05.New York, NY, USA: ACM, 2005, pp. 413–419.

[20] C. A. Ellis and S. J. Gibbs, “Concurrency control ingroupware systems,” in Proceedings of the 1989 ACMSIGMOD international conference on Management ofdata, ser. SIGMOD ’89. New York, NY, USA: ACM,1989, pp. 399–407.

[21] F. Pacull, A. Sandoz, and A. Schiper, “Duplex: adistributed collaborative editing environment in largescale,” in Proceedings of the 1994 ACM conference onComputer supported cooperative work, ser. CSCW ’94.New York, NY, USA: ACM, 1994, pp. 165–173.

[22] A. Kittur and R. E. Kraut, “Harnessing the wisdom ofcrowds in wikipedia: quality through coordination,” inProceedings of the 2008 ACM conference on Computersupported cooperative work, ser. CSCW ’08. NewYork, NY, USA: ACM, 2008, pp. 37–46.

[23] L. A. Adamic, J. Zhang, E. Bakshy, and M. S. Acker-man, “Knowledge sharing and yahoo answers: everyoneknows something,” in Proceeding of the 17th interna-tional conference on World Wide Web, ser. WWW ’08.New York, NY, USA: ACM, 2008, pp. 665–674.

[24] B. A. Nardi, D. J. Schiano, M. Gumbrecht, andL. Swartz, “Why we blog,” Commun. ACM, vol. 47,pp. 41–46, December 2004.

[25] R. N. Taylor, N. Medvidovic, K. M. Anderson, E. J.Whitehead, Jr., and J. E. Robbins, “A component- andmessage-based architectural style for gui software,” inProceedings of the 17th international conference onSoftware engineering, ser. ICSE ’95. New York, NY,USA: ACM, 1995, pp. 295–304.

[26] W. G. Ouchi and M. A. Maguire, “Organizational con-trol: Two functions,” Administrative Science Quarterly,vol. 20, no. 4, pp. pp. 559–569, 1975.

[27] J. Dean and S. Ghemawat, “Mapreduce: simplified dataprocessing on large clusters,” Commun. ACM, vol. 51,pp. 107–113, January 2008.

[28] D. C. Brabham, “Crowdsourcing as a model for prob-lem solving,” Convergence: The International Journalof Research into New Media Technologies, vol. 14,no. 1, pp. 75–90, 2008.

[29] A. Oram, Peer-to-Peer: Harnessing the Power of Dis-ruptive Technologies. Sebastopol, CA, USA: O’Reilly& Associates, Inc., 2001.

[30] S. Androutsellis-Theotokis and D. Spinellis, “A surveyof peer-to-peer content distribution technologies,” ACMComput. Surv., vol. 36, pp. 335–371, December 2004.

[31] K. Crowston, Q. Li, K. Wei, U. Y. Eseryel, and J. How-ison, “Self-organization of teams for free/libre opensource software development,” Inf. Softw. Technol.,vol. 49, pp. 564–575, June 2007.

[32] H. Kwak, C. Lee, H. Park, and S. Moon, “What istwitter, a social network or a news media?” in WWW’10: Proceedings of the 19th international conferenceon World wide web. New York, NY, USA: ACM,2010, pp. 591–600.

[33] G. Cabri, L. Leonardi, and F. Zambonelli, “Mars:a programmable coordination architecture for mobileagents,” Internet Computing, IEEE, vol. 4, no. 4, pp.26 –35, jul/aug 2000.

[34] A. Thusoo, J. S. Sarma, N. Jain, Z. Shao, P. Chakka,N. Zhang, S. Antony, H. Liu, and R. Murthy, “Hive -a petabyte scale data warehouse using hadoop,” DataEngineering, International Conference on, vol. 0, pp.996–1005, 2010.

[35] D. Qiu and R. Srikant, “Modeling and performanceanalysis of bittorrent-like peer-to-peer networks,” inProceedings of the 2004 conference on Applications,technologies, architectures, and protocols for computercommunications, ser. SIGCOMM ’04. New York, NY,USA: ACM, 2004, pp. 367–378.