Grid Computing Research Lab SUNY Binghamton 1 XCAT-C++: A High Performance Distributed CCA Framework Madhu Govindaraju

2 Introduction Building and deploying high performance grid applications is challenging –Software development model can help abstracts the complexity of the grid environment simplifies the programmer’s task can take advantage of extant software The Common Component Architecture (CCA) model –presents a promising approach to address this challenge –specifically designed for high-performance –Same specification can be used for different applications serial, parallel and distributed

3 A Few Definitions What is a Component Architecture –A Software Engineering Methodology/Standard to promote code reusability & reduce application complexity.. –A Component encapsulated software module with well defined public interfaces. strict set of behavior rules defined by the architecture. –A Component framework is - A compile-time/runtime environment for instantiating, composing and running components. Provides standard services expected by components

4 Component Composition Components can be linked along shared interfaces (ports) where one component invokes the services of another –Two types of Ports Provides Ports – implements a remote interface Uses Ports – uses a remote interface –A user and a provider of the same type can be linked –Details of run-time substrate shielded in stubs and skeletons Uses port - a call site for a remote function invocation Provides Port - A set of functions which can be invoked remotely

5 Building Applications by Composition Connect uses Ports to Provides Ports. getImage() adjustColor() Image tool graphical interface component setImage(…) Direct connect Single address space Remote component Image Processing Component doFFT(…) ACME FFT Component Image Database Component

6 XCAT XCAT-Java (Indiana University) –Interoperable with emerging standards in Grid Web services –Uses XSOAP communication library Implementation of the SOAP (XML + HTTP) specification XCAT-C++ (SUNY Binghamton) –Support for most of CCA API –Uses Proteus multi-protocol communication library tested with the binary protocol of Proteus XSOAP-C++ module within Proteus is currently being tested

7 Creation Mechanism CCA does not specify how components should be created. –Needs to be handled by the framework –Same BuilderService Interface is used create, connect, and disconnect for all kinds of frameworks (serial, distributed and parallel) XCAT-C++ –Supports use of SSH needs to have an apriori setup –Current work is on adding support for GRAM provide authenticated remote process creation globus-_url_copy to stage files for legacy applications

8 Proteus: Multi-Protocol Library One protocol does not suit all applications Proteus provides single- protocol abstraction to components –Allows users to dynamically switch between protocols Example:Protocol1 & Protocol 2, in the picture –Facilitates use of specialized implementations of serialization and deserialization CCA Framework Proteus API Protocol 1 Protocol 2 TCP Myrinet

9 CCA and Grid Web Services

10 User Interface C++ interface to the BuilderService Implementation Python interface via SWIG Example Snippets typeMapProv.putString( "remoteHost", “drake”) typeMapProv.putString("creationArgs", "-l xbmp.so”) connID = builderService.connect(…); # can also get a uses port and invoke “go” # from the python script

11 XCAT-C++ Component: Architecture

12 Performance

13 Performance: 2D arrays

14 Code Generation C++ Header File WSDL Document Proteus and XCAT++ Stubs and Skeletons Intermediate XML Format gccxml libxml WSDLPull

15 How Distributed Frameworks are Different Remote Creation Launch components in remote address spaces Heterogeneity management Use resource managers to service requests on each remote resource Store, move and replicate component binaries Remote Invocation Need global pointers and not local pointers Invoke methods across machine boundaries Need global namespace for names of components and services Mechanism for implementing remote method invocation (RMI) Introspection mechanisms to allow ports and services to be discovered and accessed

16 Current and Future Work Improve the code generation module Provide stable support for platforms other than Linux Add support for other communication protocols Integrate WS-GRAM for authenticated creation Publish latest tarball on project web page

17 Contact Information Madhu Govindaraju Phone:

18 Extra

19 The DOE Common Component Architecture A specification for a CA for large scale scientific computation –Both a DOE project and an open forum Sandia, llnl, argonne, pnnl, ornl, nasa (icase), utah, indiana, Maryland, ncsa, … about 50 people. Key concepts –An Interface Definition Language to support scientific data types (SIDL) –A concept of a “parallel data object” –Component composition model Support 0 copy data movement for components within the same addresss space as well as secure remote RPC. –Component services Event model, invocation services, composition services Component metadata directory