XCATC : A High Performance Distributed CCA Framework

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

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
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
• ExampleProtocol1 Protocol 2, in the picture
• Facilitates use of specialized implementations of
  serialization and deserialization

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
WSDL Document
Proteus and XCAT Stubs and Skeletons
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
• Email mgovinda_at_cs.binghamton.edu
• Phone [phone]
• http//www.cs.binghamton.edu/mgovinda

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