Building Scalable Virtual Communities

1. Building Scalable VirtualCommunities Omer F. Rana (o.f.rana@cs.cardiff.ac.uk) School of Computer Science and Welsh eScience Centre Cardiff University http://www.cs.cf.ac.uk/ http://www.wesc.ac.uk/

2. Projects at WeSC EPSRC AgentcitiesUK.net EU CoreGrid EU NUMAS (?) DTI (GECEM) EPSRC/DTI (CONNOISE) EPSRC (PASOA) EPSRC (GENSS) EU (Provenance) EU (CatNets) G-QoSM

3. Talk in One Slide Grid Computing Models Workflow Integrating Workflow with Community Formation and Management Triana LEAF G-QoSM Observations Outcomes Peer-2-Peer Models Community Management eScience Dynamic Communities Communities

4. What are we “really” attempting in eScience? • “Virtually” bringing together scientists to solve complex problems – which may often be multidisciplinary • Establishing Virtual Organisations • “Managed Complexity” not Ease-of-use? • Dynamic formation of such collaborations (and their subsequent disbanding) • UKRC, EU, NSF, etc funding model • The Café/Restaurant/Pub model • Mediating support between these individuals through compute, data and visualisation resources • Resource/service challenge is secondary? • Are we really understanding the “processes”? • Where is the novelty? • Have we abandoned the initial motivation? • Power Grid may be a bad analogy? • Can we find others? Workflows + Virtual Organisations  Communities

5. Outcome of eScience? • Software should be accessible outside the Grid Community • Compare: • KaZaA (file sharing) and BitTorrent (file sharing) • Software should be useful outside the Grid community? • Integrate different aspects of a collaboration • Nothing yet? • No Science focus yet • Significant User Community • Supports DSL-modem users and high bandwidth users at the same time • Support a “Rating” mechanism • Variety of other types of groupings • (social networking): • YahooGroups • LinkedIn • Orkut (Google) • BuddySpace, etc

6. Gnutella Network -- Steve G. Steinberg).

7. Internet Social Networking (April 2004) Source: TrendIQ Uniyearbooks.com (Dan Crocker, Cardiff) Also see: http://www.gridblog.com/

8. Internet Social Networking (April/May 2004) Source: TrendIQ

9. What does this tell us? • Importance of “small world” interactions • Some participants more active than others • Need to identify “hub” points for traffic sharing • Co-authorship networks • File sharing networks • Identify resource requirements of highly active participants

10. Sounds like the Grid? “The key issues behind the Friendster abandonment trend, according to users, are the service's inability to do anything about its habitual server lag problems, and its growing reputation for heavy-handed moral policies and unilateral decisions it makes on behalf of its members.” Wired News (wired.com) http://www.wired.com/news/culture/0,1284,61150,00.html

11. User Portals/ Science Portals Application Services Layer OGSA / Web Services (co-)scheduling Service Peer Creation & resolution Services Information/ Naming Services Discovery service Security Service Accounting Service User Help Services Information Routing Monitoring Service Event/Mesg Service Workflow (+ Enactment) From: Aleksander Slominski Launch, configure And control • Orchestration Service Workflow Engine Workflow Instance Workflow Instance Workflow Instance Resource layer 1000s of PCs ->massive supercomputers and data sources Network

12. Scientific Workflows • Triana • Taverna/SCUFL • GridAnt • Condor DAG • CoG DAG • SWFL • BioOpera • BEPL4WS • OASIS WSBPEL • YAWL • GSFL • … etc Origin (?): Problem Solving Environments (MatLab, Mathematica, SciRun, NetSolve, Ninf, Nimrod etc) • What makes it different (how it is applied)? • Support for large data flows • Need to do parameterized execution of large number of jobs • Need to monitor and control workflow execution including ad-hoc changes • Need to execute in dynamic environment where resources are not know a priori and may need to adapt to changes • Hierarchical execution with sub-workflows created and destroyed when necessary • Science Domain specific requirements. Problems with “Predictability” Workflow World

13. Distributed Workflow  Community Community Performance Info. WF Executor Service Provider Manager Registry

14. Workflows  Communities • Communities may be: • functional – based on service(s) offered, applications supported • attribute – performance, security policy, trust, etc • Community structure influenced by • capability of service providers • overall objectives/goals of community as a whole • “utility” (measurable) of a provider within a community • Co-operative participants • coalition or team • Competing participants • markets Community: “logical” organisation, consisting of aset of service providers and users working towards some common objectives, or sharing some common sets of “beliefs”

15. Related Efforts • Community Formation • Learning based approaches -- co-operative agents (Sun et al.) • Market and game theoretic approaches (Wellman et al.) • Pursuit of common goals (Singh, Rao, Georgeff et al.) • Joint intentions pursuit -- team oriented programming (Jennings et al., Tambe et al.) • Shared Plans (Grosz and Kraus) • Coalitions (Sandholm, Lesser et al.) • Congregation Formation (Durfee, Vidal, Brooks et al.) Other work in Sociology and Economics

16. Community Structure • Service Providers and Users • provide or use application-specific services • providers possess “Expertise” and “Interests” • Community Support Services • registry service • event service, monitoring service, etc • Community Manager • community policy and goals • manages and monitors Service Level Agreements • access control for new providers/users

17. Community, a useful idea? • Connection Problem: Finding suitable partners to interact with • Intentions so far have been different • problem solving capability preferred • Community Stability an important concern • dependent on environment (and its variability) • What impact does community formation have on scalability? • Reduce time to search for partners • Reduce time to co-ordinate (reduce message exchanges)

18. Types of Communities • Competing Communities (identical “Expertise”) • participants offer similar services • competition between providers • Cooperative Communities (different “Expertise”) • participants need services of other providers to function • mutual dependence between providers • Goal Oriented Communities (based on “Interests”) • similar to cooperative community • differs in that goal may change over time, but Expertise may not • new providers allowed only if they posses the right “Expertise” to achieve goal • Ad Hoc Communities (based on “Interests”) • Short term interactions between providers and users • Domain-Oriented Communities (based on “Interests”) • Interaction based on “Interests” – music sharing community, open-source community, etc

19. Utility • Payoff function • assess behaviour of a particular action (reward signal) • Analysis tool • relationship between local utility vs. utility of the community • Cost function • success w.r.t. a particular task • Trust measure • measure of trust in a particular participant

20. Utility Optimisation Expected Utility – E(x) 0<g<1 Finite Horizon Infinite Horizon “U” may be negative Long term rewards less useful

21. Community Building Kit: LEAF Four core concepts: LEAF agents LEAF utility functions ESNs LEAF tasks Provides support for: JESS based policy description Reinforcement learning

23. Assigning Utility in LEAF Performance and Functional Utility P Speed of execution, number of tasks, CPU usage etc. Decision making, learning -- high level behaviour. F

24. Performance Utility • Provides a utility measure based on performance engineering related aspects • Comms metrics: • number of messages exchanged, size of message, response time • Execution metrics: • execution time, time to convergence, queue time • Memory and I/O metrics: • Memory access time, disk access time • The effect of implementation decisions(algorithms; languages) and deploymentdecisions (platforms; networks), can be assessed.

25. Functional Utility • Utility based on “problem solving” capability • Statically defined • related to service properties (capability based) • degree of match between task properties and service capability • syntax match (exact match) • range match • semantic match (subsumption/subclass) • Dynamically defined • related to execution output (MSE)

26. Utility Function Implementation • Extend the LocalUtilityFunction abstract class. • Implement the compute() method. • Functions have access to remote parameters and observable properties.

27. LEAF: Learning Agent FIPA-Compliant Community Toolkit • Coordination: utility functions are assigned to agents by an Environment Service Node. ESN f2 f1 Community

28. LEAF: Learning Agent FIPA-Compliant Community Toolkit Multiple utility functions can be assigned ESN ESN f3 f2 f1 sum f2,f3 Community b Community a

29. LEAF: Learning Agent FIPA-Compliant Community Toolkit LEAF: Learning Agent FIPA-Compliant Community Toolkit • Utility functions can have parameters that are not available locally to the agent. ESN O R f1 Community O: observable properties R: remote parameters

30. Access to utility functions double computeFunctionalUtility() Computes the sum of all currently assigned functional utility functions. double computePerformanceUtility() Computes the sum of all currently assigned performance utility functions. String[] getFunctionalUtilityRequiredProperties() Returns the observable properties required to compute the agent’s functional utility functions. String[] getPerformanceUtilityRequiredProperties() Returns the observable properties required to compute the agent’s performance utility functions. Others: UpdateTimeperiod, removePerformanceUtilityFunction, ESNConnect

31. Via Community Manager Community Performance Info. WF Executor Service Provider Manager Registry

33. Simulation: Four types of Communities • Task categories: Compute, Visualisation, Instrumentation and Storage • Mainly performance utility evaluated • Utility: rate of job completions (of those submitted, how many are completed) • Need cooperation (process locally or send to another provider)

34. Utility Functions Global Utility (G) = Si Local Utility (Ui) U = (jobs of type X processed)/(jobs of type X submitted) U = 1/(idle time) where Aa is the number of applications processed by user a, and Jais the total resource usage time used by a. c1,c2 are constants where Tr is the number of tasks processed by resource provider r, and idleris the total time spent idle by the provider. c1,c2 are constants

35. computational community Utility

36. Co-operative Community storage community Utility

37. “Maybe we should write that spot down.” How to kill a (Grid) Mammoth

38. More Info. • Triana • http://www.trianacode.org/ • http://www.gridlab.org/ • http://www.gridoned.org/ • LEAF • http://www.cs.cf.ac.uk/User/S.J.Lynden/leaf/ • G-QoSM • http://www.cs.cf.ac.uk/User/Rashid/ • http://www.wesc.ac.uk/projects/uddie/

39. Thanks to: • Steven Lynden, Newcastle University • Ian Taylor, Matt Shields, Ian Wang, Ali Shaikhali, Shalil Majithia, Asif Akram, Rashid Al-Ali and David W. Walker, Cardiff University • Luc Moreau, Southampton University • Kaizar Amin and Gregor von Laszewski, Argonne National Lab • Jose Cunha, Fernanda Barbosa and Cecilia Gomes, New University of Lisbon