Data Grids: Globus vs SRB
Maturity SRB Older code base Widely accepted across multiple communities Core components are tightly integrated Globus Data transfer components stable Control, web service protocols are in flux Optional value-added components have varying levels of stability
Interoperability SRB Proprietary data and control protocol Limited documentation available Many language bindings Globus Standards based protocols GGF Grid-ftp OGSI, WSRF Common underlying communications protocol Components are modular and can be mixed together in often arbitrary ways
Ease of use SRB GUI and command line clients available All developed clients must use provided tools Simplified central administration Globus Custom clients need to be designed. Multiple entry points, so clients need not be aware of complete system Each component has separate administration module
Cost SRB Free software Easy setup for simple installations High cost to extend core functionality Ease of developing clients through multiple tools Ease of user access through supplied tools Globus Free software Complex setup of multiple disjoint components Easier to extend core functionality using standard protocols Clients may be complex due to multiple components User access is up to grid developer Custom portals, registry services
Target Audiences SRB Data access, preservation, management groups Groups requiring ease of multiple datasets across administrative and technological boundaries Limited to no internal data transformation requirements Globus Computing and service based needs Data components designed to feed into other services and usually not directly accessible to end users Data exposed as a service
Support SRB Single point of contact for support Mailing lists, bug tracking, online manuals Occasional tutorials at SDSC Globus Multiple support groups depending on number of components used From the Globus Alliance and the Globus community Manuals, Mailing lists, online tutorials Numerous seminars and tutorials around the world Commercial support forthcoming (IBM, HP)
Component Comparison: Security SRB Clear text passwords, GSI authentication Central authorization Complete separation between underlying operating system and SRB Globus GSI authentication Authorization depends on local sites and individual components Commonly just map GSI entities to local system users
Component Comparison: Data Access SRB Srbmasters provide srb specific data moving protocol MCAT tracks all available data holdings on srbmasters Tight coupling, all available data MUST be registered in MCAT Globus Gridftp provides extended ftp services (striping, GSI authentication, etc) Data locating handled through RLS Not tightly coupled to gridftp
Component Comparison: Data Discovery SRB MCAT stores metadata system and descriptive centrally Can be queried using SQL- like syntax Database pass-throughs can be registered and directly queried with limited output transformation Globus MCS can track limited descriptive metadata OGSI-DAI can provide 3 rd party access to existing data sources Not tightly coupled to underlying data on ftp services Sepeaation between system and descriptive
Component Comparison: Processing SRB Limited remote execution Must be registered in MCAT and application installed on srbmaster Cannot execute arbitrary code Globus Easy to design add on services as web service Can tie into existing compute resources In hpc manner, many components can execute arbitrary jobs
Lessons Learned SRB The SRB can easily handle textual metadata. Extended metadata support requires extensive code modification SRB needs to be treated as an end to end data grid and not as individual components Globus Globus is flexible, but also complicated Some Globus components are fragile (MCS, RFT) while others are very solid and reliable (GSI interfaces, GridFTP) Globus is evolving and improving: the implementation was made much better with subsequent toolkit releases