180 likes | 198 Views
Introduction to the XCAT-C++ framework for building and deploying high-performance grid applications, utilizing the Common Component Architecture (CCA) model to simplify software development challenges. Learn about component architecture, composition, protocols, and more.
E N D
XCAT-C++: A High Performance Distributed CCA Framework Madhu Govindaraju
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
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
Provides Port - A set of functions which can be invoked remotely Uses port - a call site for a remote function invocation 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
Building Applications by Composition • Connect uses Ports to Provides Ports. Remote component Direct connect setImage(…) Image Database Component Image Processing Component getImage() doFFT(…) ACME FFT Component adjustColor() Single address space Image tool graphical interface component
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
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
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 Proteus: Multi-Protocol Library
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
Code Generation C++ Header File Intermediate XML Format gccxml libxml Proteus and XCAT++ Stubs and Skeletons WSDL Document WSDLPull
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
Contact Information • Madhu Govindaraju • Email: mgovinda@cs.binghamton.edu • Phone: 607 777 4904 • http://www.cs.binghamton.edu/~mgovinda
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