1 / 18

XCAT-C++: A High Performance Distributed CCA Framework

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.

lakita
Download Presentation

XCAT-C++: A High Performance Distributed CCA Framework

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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. 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

  5. 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

  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. 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

  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 Intermediate XML Format gccxml libxml Proteus and XCAT++ Stubs and Skeletons WSDL Document WSDLPull

  15. 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

  16. Contact Information • Madhu Govindaraju • Email: mgovinda@cs.binghamton.edu • Phone: 607 777 4904 • http://www.cs.binghamton.edu/~mgovinda

  17. Extra

  18. 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

More Related