1. Grids and the Globus Community
Dr. Jennifer M. Schopf
Argonne National Lab

2. What is a Grid? Resource sharing Coordinated problem solving
Computers, storage, sensors, networks, …
Sharing always conditional: issues of trust, policy, negotiation, payment, …
Coordinated problem solving
Beyond client-server: distributed data analysis, computation, collaboration, …
Dynamic, multi-institutional virtual orgs
Community overlays on classic org structures
Large or small, static or dynamic

3. Why Is this Hard or Different?
Lack of central control
Where things run
When they run
Shared resources
Contention, variability
Communication and coordination
Different sites implies different sys admins, users, institutional goals, and often socio-political constraints

4. So Why Do It? Computations that need to be done with a time limit
Data that can’t fit on one site
Data owned by multiple sites
Applications that need to be run bigger, faster, more

5. What Kinds of Applications?
Computation intensive
Interactive simulation (climate modeling)
Large-scale simulation and analysis (galaxy formation, gravity waves, event simulation)
Engineering (parameter studies, linked models)
Data intensive
Experimental data analysis (e.g., physics)
Image & sensor analysis (astronomy, climate)
Distributed collaboration
Online instrumentation (microscopes, x-ray) Remote visualization (climate studies, biology)
Engineering (large-scale structural testing)

6. Grid Infrastructure Distributed management Unified treatment
Of physical resources
Of software services
Of communities and their policies
Unified treatment
Build on Web services framework
Use WS-RF, WS-Notification (or WS-Transfer/Man) to represent/access state
Common management abstractions & interfaces

7. Globus is…
A collection of solutions to problems that come up frequently when building collaborative distributed applications
Software for Grid infrastructure
Service enable new & existing resources
Uniform abstractions & mechanisms
Tools to build applications that exploit Grid infrastructure
Registries, security, data management, …
Open source & open standards
Each empowers the other
Enabler of a rich tool & service ecosystem

8. Higher-Level Services
Globus is an Hour Glass
Local sites have their own
policies, installs – heterogeneity!
Queuing systems, monitors, network protocols, etc
Globus unifies – standards!
Build on Web services
Use WS-RF, WS-Notification to represent/access state
Common management abstractions & interfaces
Higher-Level Services
and Users
Standard
Interfaces
Heterogenity:
Trying to support heterogenity: no preconditions:
- different hardware (types of machines, different configurations, different “data producers”, etc.)
- different software (different applications, different languages, different operating systems, etc.)
Standards:
Standards enable interoperability. An example:
- If the community agrees to standardize certain patterns for interacting with a type of service, then services
can interact with each other
- WSRF
Local heterogeneity

9. Globus is a Building Block
Basic components for Grid functionality
Not turnkey solutions, but building blocks & tools for application developers & system integrators
Highest-level services are often application specific, we let aps concentrate there
Easier to reuse than to reinvent
Compatibility with other Grid systems comes for free
We provide basic infrastructure to get you one step closer

10. dev.globus Governance model based on Apache Jakarta
Consensus based decision making
Globus software is organized as several dozen “Globus Projects”
Each project has its own “Committers” responsible for their products
Cross-project coordination through shared interactions and committers meetings
A “Globus Management Committee”
Overall guidance and conflict resolution

11. Infrastructure (CVS, email, bugzilla, Wiki)
Guidelines (Apache
Jakarta)
Infrastructure (CVS, , bugzilla, Wiki)
Projects
Include …

12. Globus Software: dev.globus.org
Globus Projects
OGSA-DAI
GT4
MPICH G2
Java Runtime
Delegation
MyProxy
Data
Rep
Replica
Location
GridWay
C Runtime
CAS
GSI-
OpenSSH
GridFTP
MDS4
Incubation
Mgmt
Python Runtime
C Sec
GRAM
Reliable
File
Transfer
GT4 Docs
Incubator
Projects
Swift
GEMLCA
MonMan
GAARDS
MEDICUS
Cog WF
Virt WkSp
NetLogger
GDTE
GridShib
OGRO
UGP
Dyn Acct
Gavia JSC
DDM
Metrics
Introduce
PURSE
HOC-SA
LRMA
WEEP
Gavia MS
SGGC
ServMark
Common
Runtime
Security
Execution
Mgmt
Data Mgmt
Info
Services
Other

13. Globus Technology Areas
Core runtime
Infrastructure for building new services
Security
Apply uniform policy across distinct systems
Execution management
Provision, deploy, & manage services
Data management
Discover, transfer, & access large data
Monitoring
Discover & monitor dynamic services

14. Web Service Basics
Web Services are basic distributed computing technology that let us construct client-server interactions
Client program – wants to access weather info
Contacts Web Service (in the server) and sends service request asking for info, gets response through a service response
Borja Sotomayor ,

15. Core Runtime Provides Web Service Basics
Web services are platform independent and language independent
Client and server program can be written in diff langs, run in diff envt’s and still interact
Web services describe themselves
Once located you can ask it how to use it
Web service is *not* a website
Web service is accessed by sw, not humans
Web services are ideal for loosely coupled systems
Unlike CORBA, EJB, etc.
Re-emphasis on heterogeneity of underlying resources

16. WSDL: Web Services Description Language
Define expected messages for a service, and their (input or output parameters)
An interface groups together a number of messages (operations)
Bind an Interface via a definition to a specific transport (e.g. HTTP) and messaging (e.g. SOAP) protocol
The network location where the service is implemented , e.g.

17. Real Web Service Invocation
Discover
Describe
Invoke
As we said before, a client may have no knowledge of what Web Service it is going to invoke. So, our first step will be to discover a Web Service that meets our requirements. For example, we might be interested in locating a public Web Service which can give me the weather forecast in US cities. We'll do this by contacting a discovery service (which is itself a Web service).
The discovery service will reply, telling us what servers can provide us the service we require.
We now know the location of a Web Service, but we have no idea of how to actually invoke it. Sure, we know it can give me the forecast for a US city, but how do we perform the actual service invocation? The method I have to invoke might be called "string getCityForecast(int CityPostalCode)", but it could also be called "string getUSCityWeather(string cityName, bool isFarenheit)". We have to ask the Web Service to describe itself (i.e. tell us how exactly we should invoke it)
The Web Service replies in a language called WSDL.
We finally know where the Web Service is located and how to invoke it. The invocation itself is done in a language called SOAP. Therefore, we will first send a SOAP request asking for the weather forecast of a certain city.
The Web Service will kindly reply with a SOAP response which includes the forecast we asked for, or maybe an error message if our SOAP request was incorrect.
Borja Sotomayor ,

18. Web Services Server Applications
Web service – software that exposes a set of operations
SOAP Engine – handle SOAP requests and responses (Apache Axis)
Application Server – provides “living space” for applications that must be accessed by different clients (Tomcat)
HTTP server- also called a Web server, handles http messages
Container
Web service: First and foremost, we have our Web service. As we have seen, this is basically a piece of software that exposes a set of operations. For example, if we are implementing our Web service in Java, our service will be a Java class (and the operations will be implemented as Java methods). Obviously, we want a set of clients to be able to invoke those operations. However, our Web service implementation knows nothing about how to interpret SOAP requests and how to create SOAP responses. That's why we need a...
SOAP engine: This is a piece of software that knows how to handle SOAP requests and responses. In practice, it is more common to use a generic SOAP engine than to actually generate server stubs for each individual Web service (note, however, that we still need client stubs for the client). One good example of a SOAP engine is Apache Axis (this is, in fact, the SOAP engine used by the Globus Toolkit). However, the functionality of the SOAP engine is usually limited to manipulating SOAP. To actually function as a server that can receive requests from different clients, the SOAP engine usually runs within an...
Application server: This is a piece of software that provides a 'living space' for applications that must be accessed by different clients. The SOAP engine runs as an application inside the application server. A good example is the Jakarta Tomcat server, a Java Servlet and Java ServerPages container that is frequently used with Apache Axis and the Globus Toolkit.
Many application servers already include some HTTP functionality, so we can have Web services up and running by installing a SOAP engine and an application server. However, when an application server lacks HTTP functionality, we also need an...
HTTP Server: This is more commonly called a 'Web server'. It is a piece of software that knows how to handle HTTP messages. A good example is the Apache HTTP Server, one of the most popular web servers in the Internet.
Borja Sotomayor ,

19. Let’s talk about state Plain Web services are stateless
Plain Web services are usually stateless (even though, in theory, there is nothing in the Web Services Architecture that says they can't be stateful). This means that the Web service can't "remember" information, or keep state, from one invocation to another. For example, imagine we want to program a very simple Web service which simply acts as an integer accumulator. This accumulator is initialized to zero, and we want to be able to add (accumulate) values in it. Suppose we have an add operation which receives the value to add and returns the current value of the accumulator. As shown in the following figure, our first invocation of this operation might seem to work (we request that 5 be added, and we receive 5 in return). However, since a Web service is stateless, the following invocations have no idea of what was done in the previous invocations. So, in the second call to add we get back 6, instead of 11 (which would be the expected value if the Web service was able to keep state).
Borja Sotomayor ,

20. However, Many Grid Applications Require State
Borja Sotomayor ,

21. Keep the Web Service and the State Separate
Instead of putting state in a Web service, we keep it in a resource
Each resource has a unique key
Giving Web services the ability to keep state information while still keeping them stateless seems like a complex problem. Fortunately, it's a problem with a very simple solution: simply keep the Web service and the state information completely separate.
Instead of putting the state in the Web service (thus making it stateful, which is generally regarded as a bad thing) we will keep it in a separate entity called a resource, which will store all the state information. Each resource will have a unique key, so whenever we want a stateful interaction with a Web service we simply have to instruct the Web service to use a particular resource.
For example, take the accumulator example. As shown in the next figure, our Web service could have three different resources (A, B, C) to choose from. If we want the integer value to be 'remembered' from invocation to invocation, the client simply has to specify that he wants a method invoked with a certain resource.
In the figure we can see that the client wants the add operation invoked with resource C. When the Web service receives the add request, it will make sure to retrieve resource C so that add is actually performed on that resource. The resource themselves can be stored in memory, on secondary storage, or even in a database. Also, notice how a Web service can have access to more than one resource.
Borja Sotomayor ,

22. Resources Can Be Anything Stored
Web Service +
Resource =
WS-Resource
Address of a WS-resource is called an end-point reference

23. Need For Standards Web services are self describing using WSDL
But we’d really like is a common way to
Name and do bindings
Start and end services
Query, subscription, and notification
Share error messages

24. Standard Interfaces Service information State representation
Resource
Resource Property
State identification
Endpoint Reference
State Interfaces
GetRP, QueryRPs, GetMultipleRPs, SetRP
Lifetime Interfaces
SetTerminationTime
ImmediateDestruction
Notification Interfaces
Subscribe, Notify
ServiceGroups
Web
Service
GetRP
GetMultRPs
SetRP
QueryRPs
Subscribe
SetTerm
Time
Destroy
Client

25. WSRF & WS-Notification
Naming and bindings (basis for virtualization)
Every resource can be uniquely referenced, and has one or more associated services for interacting with it
Lifecycle (basis for fault resilient state management)
Resources created by services following factory pattern
Resources destroyed immediately or scheduled
Information model (basis for monitoring & discovery)
Resource properties associated with resources
Operations for querying and setting this info
Asynchronous notification of changes to properties
Service Groups (basis for registries & collective svcs)
Group membership rules & membership management
Base Fault type

26. WSRF vs XML/SOAP
The definition of WSRF means that the Grid and Web services communities can move forward on a common base
Why Not Just Use XML/SOAP?
WSRF and WS-N are just XML and SOAP
WSRF and WS-N are just Web services
Benefits of following the specs:
These patterns represent best practices that have been learned in many Grid applications
There is a community behind them
Why reinvent the wheel?
Standards facilitate interoperability

27. Leveraging Existing and Proposed Standards
WSRF and WS-N (GGF, OASIS)
WS-Agreement, WSDL 2.0, WSDM
GridFTP v1.0 (GGF)
OGSI v1.0 (GGF)
SSL/TLS v1 (from OpenSSL) (IETF)
X.509 Proxy Certificates (IETF)
SAML, XACML

28. Globus and Web Services
User Applications
Globus WSRF Web
Services
and Admin
Registry
Globus Container (e.g., Apache Axis)
WS-A, WSRF, WS-Notification
WSDL, SOAP, WS-Security
Globus Core: Java , C (fast, small footprint), Python

29. Globus and Web Services
User Applications
Custom
WSRF
Services
Globus WSRF Web
Services
and Admin
Registry
Globus Container (e.g., Apache Axis)
WS-A, WSRF, WS-Notification
WSDL, SOAP, WS-Security
Globus Core: Java , C (fast, small footprint), Python

30. Globus and Web Services
WSDL, SOAP, WS-Security
Custom
Web
Services
WS-A, WSRF, WS-Notification
WSRF
Globus WSRF Web
and Admin
Registry
Globus Container (e.g., Apache Axis)
User Applications
Globus Core: Java , C (fast, small footprint), Python

31. Globus Technology Areas
Core runtime
Infrastructure for building new services
Security
Apply uniform policy across distinct systems
Execution management
Provision, deploy, & manage services
Data management
Discover, transfer, & access large data
Monitoring
Discover & monitor dynamic services

32. Grid Security Concerns
Control access to shared services
Address autonomous management, e.g., different policy in different work groups
Support multi-user collaborations
Federate through mutually trusted services
Local policy authorities rule
Allow users and application communities to set up dynamic trust domains
Personal/VO collection of resources working together based on trust of user/VO

33. Globus Security Tools Basic Grid Security Mechanisms
Certificate Generation Tools
Certificate Management Tools
Getting users “registered” to use a Grid
Getting Grid credentials to wherever they’re needed in the system
Authorization/Access Control Tools
Storing and providing access to system-wide authorization information

34. Globus’s Use of Security Standards
Supported, Supported, Fastest,
but slow but insecure so default

35. Execution Management: GRAM
GRAM: Grid Resource Allocation Manager
A uniform service interface for remote job submission and control
Unix, Condor, LSF, PBS, SGE, …
More generally: interface for process execution management
Lay down execution environment
Stage data
Monitor & manage lifecycle
Kill it, clean up

36. GRAM4 (aka WS GRAM) GRAM is not a scheduler.
2nd-generation WS implementation
optimized for performance,
flexibility, stability, scalability
Streamlined critical path
Use only what you need
Flexible credential management
Credential cache & delegation service
GridFTP & RFT used for data operations
Data staging & streaming output
Eliminates redundant GASS code
GRAM is not a scheduler.
Used as a front-end to schedulers,

37. GridWay Meta-Scheduler
Scheduler virtualization layer on top of Globus services
A LRM-like environment for submitting, monitoring, and controlling jobs
A way to submit jobs to the Grid, without having to worry about the details of exactly which local resource will run the job
A policy-driven job scheduler, implementing a variety of access and Grid-aware load balancing policies
Accounting
GridWay:

38. Application-Infrastructure decoupling
PBS
GridWay
SGE
$>
CLI
Results
.C, .java
DRMAA
Infrastructure
Grid Middleware
Applications
Globus
Grid Meta-
Scheduler
standard API (OGF DRMAA)
Command Line Interface
open source
job execution management
resource brokering
Globus services
Standard interfaces
end-to-end (e.g. TCP/IP)
highly dynamic & heterogeneous
high fault rate
Application-Infrastructure decoupling
GridWay:

39. GT4 Data Management Stage/move large data to/from nodes
GridFTP, Reliable File Transfer (RFT)
Alone, and integrated with GRAM
Locate data of interest
Replica Location Service (RLS)
Replicate data for performance/reliability
Distributed Replication Service (DRS)
Provide access to diverse data sources
File systems, parallel file systems, hierarchical storage: GridFTP
Databases: OGSA DAI

40. GridFTP in GT4 A high-performance, secure, reliable data
Disk-to-disk on TeraGrid
GridFTP in GT4
A high-performance,
secure, reliable data
transfer protocol
optimized for high-bw
wide-area networks
GSI support for security
3rd party and partial file transfer support
IPv6 Support
XIO for different transports
Parallelism and striping  multi-Gb/sec wide area transport
Future: integration of provisioning
E.g., storage reservation

41. Reliable File Transfer
Fire-and-forget transfer
Web services interface
Many files & directories
Integrated failure recovery
Has transferred 900K files
RFT Client
SOAP Messages
Notifications (Optional)
RFT Service
GridFTP Server
GridFTP Server
Master DSI
Protocol Interpreter
Data Channel
IPC Receiver
Slave DSI
IPC Link
Data Channel
Protocol Interpreter
Master DSI
Slave DSI
IPC Receiver
IPC Link

42. Replica Location Service
Identify location of files via logical to physical name map
Distributed indexing of names, fault tolerant update protocols
New WS-RF version available
Managing ~40 million files across ~10 sites
Index
Index
Local DB
Update send (secs)
Bloom filter (secs)
Bloom filter (bits)
10K
<1 2
1 M 24
10 M
5 M 7
175
50 M

43. OGSA-DAI Grid Interfaces to Databases Extensible & Efficient framework
Data access
Relational & XML Databases, semi-structured files
Data integration
Multiple data delivery mechanisms, data translation
Extensible & Efficient framework
Request documents contain multiple tasks
A task = execution of an activity
Group work to enable efficient operation
Extensible set of activities
> 30 predefined, framework for writing your own
Moves computation to data
Pipelined and streaming evaluation
Concurrent task evaluation

44. Monitoring and Discovery System (MDS4)
Grid-level monitoring system
Aid user/agent to identify host(s) on which to run an application
Warn on errors
Uses standard interfaces to provide publishing of data, discovery, and data access, including subscription/notification
WS-ResourceProperties, WS-BaseNotification, WS-ServiceGroup
Functions as an hourglass to provide a common interface to lower-level monitoring tools

45. Schedulers, Portals, Warning Systems, etc.
Information Users :
Schedulers, Portals, Warning Systems, etc.
WS standard interfaces for subscription, registration, notification
Standard Schemas
(GLUE schema, eg)
Cluster monitors
(Ganglia, Hawkeye,
Clumon, Nagios)
Queuing systems
(PBS, LSF, Torque)
Services
(GRAM, RFT, RLS)

46. Globus Technology Areas
Core runtime
Infrastructure for building new services
Security
Apply uniform policy across distinct systems
Execution management
Provision, deploy, & manage services
Data management
Discover, transfer, & access large data
Monitoring
Discover & monitor dynamic services

47. Non-Technology Projects
Incubation Projects
Incubation management project
And any new projects wanting to join
Distribution Projects
Globus Toolkit Distribution
Documentation Projects
GT Release Manuals

48. Globus Software: dev.globus.org
Globus Projects
OGSA-DAI
GT4
MPICH G2
Java Runtime
Delegation
MyProxy
Data
Rep
Replica
Location
GridWay
C Runtime
CAS
GSI-
OpenSSH
GridFTP
MDS4
Incubation
Mgmt
Python Runtime
C Sec
GRAM
Reliable
File
Transfer
GT4 Docs
Incubator
Projects
Swift
GEMLCA
MonMan
GAARDS
MEDICUS
Cog WF
Virt WkSp
NetLogger
GDTE
GridShib
OGRO
UGP
Dyn Acct
Gavia JSC
DDM
Metrics
Introduce
PURSE
HOC-SA
LRMA
WEEP
Gavia MS
SGGC
ServMark
Common
Runtime
Security
Execution
Mgmt
Data Mgmt
Info
Services
Other

49. Incubator Process in dev.globus
Entry point for new Globus projects
Incubator Management Project (IMP)
Oversees incubator process form first contact to becoming a Globus project
Quarterly reviews of current projects
Incubator_Process

50. 24 Active Incubator Projects
CoG Workflow
Distributed Data Management (DDM)
Dynamic Accounts
Grid Authentication and Authorization with Reliably Distributed Services (GAARDS)
Gavia-Meta Scheduler
Gavia- Job Submission Client
Grid Development Tools for Eclipse (GDTE)
Grid Execution Mgmt. for Legacy Code Apps. (GEMLCA)
GridShib
Higher Order Component Service Architecture (HOC-SA)
Introduce
Local Resource Manager Adaptors (LRMA)
MEDICUS (Medical Imaging and Computing for Unified Information Sharing)
Metrics
MonMan
NetLogger
Open GRid OCSP (Online Certificate Status Protocol)
Portal-based User Registration Service (PURSe)
ServMark
SJTU GridFTP GUI Client (SGGC)
Swift
UCLA Grid Portal Software (UGP)
Workflow Enactment Engine Project (WEEP)
Virtual Workspaces

51. Active Committers from 28 Institutions
Leibniz Supercomputing Center (Germany)
NCSA
National Research Council of Canada
Ohio State Univ.
Semantic Bits
Shanghai Jiao Tong University (China)
Univ. of British Columbia (Canada)
UCLA
Univ. of Chicago
Univ. of Delaware
Univ. of Marburg (Germany)
Univ. of Muenster (Germany)
Univ. Politecnica de Catalunya (Spain)
Univ. of Rochester
USC Information Sciences Institute
Univ. of Victoria (Canada)
Univ. of Vienna (Austria)
Univ. of Westminster (UK)
Univa Corp.
Aachen Univ. (Germany)
Argonne National Laboratory
CANARIE (Canada)
CertiVeR
Children’s Hospital Los Angeles
Delft Univ. (The Netherlands)
Indiana Univ.
Kungl. Tekniska Högskolan (Sweden)
Lawrence Berkeley National Lab

52. Globus Software: dev.globus.org
Globus Projects
OGSA-DAI
GT4
MPICH G2
Java Runtime
Delegation
MyProxy
Data
Rep
Replica
Location
GridWay
C Runtime
CAS
GSI-
OpenSSH
GridFTP
MDS4
Incubation
Mgmt
Python Runtime
C Sec
GRAM
Reliable
File
Transfer
GT4 Docs
Incubator
Projects
Swift
GEMLCA
MonMan
GAARDS
MEDICUS
Cog WF
Virt WkSp
NetLogger
GDTE
GridShib
OGRO
UGP
Dyn Acct
Gavia JSC
DDM
Metrics
Introduce
PURSE
HOC-SA
LRMA
WEEP
Gavia MS
SGGC
ServMark
Common
Runtime
Security
Execution
Mgmt
Data Mgmt
Info
Services
Other

53. Globus Software: dev.globus.org
Globus Projects
OGSA-DAI
GT4
MPICH G2
Java Runtime
Delegation
MyProxy
Data
Rep
Replica
Location
GridWay
C Runtime
CAS
GSI-
OpenSSH
GridFTP
MDS4
Incubation
Mgmt
Python Runtime
C Sec
GRAM
Reliable
File
Transfer
GT4 Docs
Incubator
Projects
Swift
GEMLCA
MonMan
GAARDS
MEDICUS
Cog WF
Virt WkSp
NetLogger
GDTE
GridShib
OGRO
UGP
Dyn Acct
Gavia JSC
DDM
Metrics
Introduce
PURSE
HOC-SA
LRMA
WEEP
Gavia MS
SGGC
ServMark
Common
Runtime
Security
Execution
Mgmt
Data Mgmt
Info
Services
Other

54. GT4 Distribution Usability, reliability
All components meet a quality standard
Testing, logging, coding standards
Documentation at acceptable quality level
Guarantee that interfaces won’t change within a major version (4.0.1 == 4.0.any)
Consistency with latest standards (WS-*, WSRF, WS-N, etc.) and Apache platform
WS-I Basic Profile compliant
WS-I Basic Security Profile compliant

55. Versioning and Support
Evens are production (4.0.x, 4.2.x),
Odds are development (4.1.x)
We support this version and the one previous
Currently stable version 4.0.5
We support 3.2.x and 4.0.x
We’ve also got the dev release available

56. Several “Next” Versions
4.0.6 – stable release
100% same interfaces
When we get enough bug fixes
4.1.4 – development release(s)
New functionality
Expected every 6-8 weeks (mid September)
stable release
Tested, documented 4.1.x branch
Likely Q1 2008
Discussed on
5.0 – substantial code base change
With any luck, not for years :)

57. Tested Platforms Debian Fedora Core FreeBSD HP/UX IBM AIX Red Hat
Sun Solaris
SGI Altix (IA64 running Red Hat)
SuSE Linux
Tru64 Unix
Apple MacOS X (no binaries)
Windows – Java components only
List of binaries and known platform-specific install bugs at
docbook/ ch03.html

58. Globus User Community Large & diverse Successful
10s of national Grids, 100s of applications, 1000s of users; probably much more
Every continent except Antarctica
Applications ranging across many fields
Dozens (at least) of commercial deployments
Successful
Many production systems doing real work
Many applications producing real results
Hundreds of papers published because of grid deployments
Smart, energetic, demanding
Constant stream of new use cases & tools

59. Global Community

60. Examples of Production Scientific Grids
APAC (Australia)
China Grid
China National Grid
DGrid (Germany)
EGEE
NAREGI (Japan)
Open Science Grid
Taiwan Grid
TeraGrid
ThaiGrid
UK Nat’l Grid Service

61. How Can You Contribute? Create a New Project
Do you have a project you’d like to contribute?
Does your software solve a problem you think the Globus community would be interested in?
Contact

62. How Can You Contribute? Help an Existing Project
Contribute code, documentation, design ideas, and feature requests
Joining the mailing lists
*-dev, *-user, *-commit for each project
See the project wiki page at dev.globus.org
Chime in at any time
Regular contributors can become committers, with a role in defining project directions

63. Globus Next Steps Expanded open source Grid infrastructure
Updates for current standards
New services for data management, security, VO management, troubleshooting
End-user tools for application development
Virtualization
Some infrastructure work
Outside projects joining Globus
Expanded outreach:
And of course responding to user requests for other short-term needs

64. For More Information Jennifer Schopf Globus Alliance Dev.globus
Globus Alliance
Dev.globus
Upcoming Events