Institute of Computer Science AGH MOCCA – A Distributed CCA Framework based on H2O Maciej Malawski, Dawid Kurzyniec, Vaidy Sunderam Distributed Computing Laboratory in the Dept. of Math and Computer Science, Emory University, Atlanta Institute of Computer Science AGH, Krakow, Poland

CCA Meeting, Atlanta, Jan 2005 Institute of Computer Science AGH 2 Outline CCA and H2O: a good match H2O as underlying platform Goals of MOCCA (Metacomputing Oriented CCA framework) MOCCA technical overview Initial performance results Towards Babel compatibility Future directions and research perspectives

CCA Meeting, Atlanta, Jan 2005 Institute of Computer Science AGH 3 Why CCA and H2O CCA Component standard for HPC Uses and provides ports described in SIDL Support for scientific data types Existing tightly coupled (CCAFFEINE) and loosely coupled, distributed (XCAT) frameworks H2O Distributed resource sharing platform Providers setup H2O kernel (container) Allowed parties can deploy pluglets (components) Separation of roles: decoupling –Providers from deployers –Providers from each other RMIX: efficient multiprotocol RMI extension

CCA Meeting, Atlanta, Jan 2005 Institute of Computer Science AGH 4 H2O Resource sharing platform Providers own resources They independently share them over the network –access control policies Clients discover, locate, and utilize resources Resources configurable via plugins Aggregation and reselling: cascading pairwise relationships

CCA Meeting, Atlanta, Jan 2005 Institute of Computer Science AGH 5 H2O Component Model Nomenclature –container = kernel –component = pluglet Pluglet = remotely accessible object –implements Pluglet interface, used by kernel to signal/trigger pluglet state changes Remote access: based on the RMI model –Pluglets export functional remote interfaces Pluglet Functional interfaces Kernel Clients (e.g. Hello ) tutorial/step1/srv/Hello.java public interface Hello extends Remote { String hello() throws RemoteException; } Interface Pluglet { void init(RuntimeContext cxt); void start(); void stop(); void destroy(); }

CCA Meeting, Atlanta, Jan 2005 Institute of Computer Science AGH 6 Example scenarios of H2O 1. Provider = deployer e.g. resource = legacy application 2. Reseller:= developer = deployer e.g. computational service offered within a grid system 3. Client = deployer e.g. client runs custom distributed application on shared resources

CCA Meeting, Atlanta, Jan 2005 Institute of Computer Science AGH 7 RMIX Communication Substrate Extensible framework Remote Method Invocations paradigm Pluggable protocol providers Multiple protocols supported –JRMPX, ONC-RPC, SOAP Request-Response and Asynchronous calls Combines simplicity, flexibility, and performance ONC-RPC Web Services SOAP clients Myrinet RMIX RMIX XSOAP RMIX RPCX RMIX MYRI RMIX JRMPX Java Service

CCA Meeting, Atlanta, Jan 2005 Institute of Computer Science AGH 8 RMIX: multiple protocols Protocol switching Protocol negotiation Various protocol stacks for different situations –SOAP: interoperability –SSL: security –ARPC, custom (Myrinet, Quadrics): efficiency Harness Kernel Internet security firewall efficiency H2O Kernel

CCA Meeting, Atlanta, Jan 2005 Institute of Computer Science AGH 9 H2O: Current research areas (More) Interoperability –Support for Globus proxy credentials –Naming services: JNDI bridge to multiple implementations Peer-to-peer grids –JXTA transport provider for RMIX; enables RMI over JXTA sockets –JXTA-JNDI naming provider: peer-to-peer resource sharing and discovery Fault-tolerant MPI across shared resources –FT-MPI & H2O: staging, sharing, heterogeneity, scalability

CCA Meeting, Atlanta, Jan 2005 Institute of Computer Science AGH 10 H2O: Feature Summary Resource sharing –Deploying components on shared resources Component isolation and hot-swapping –Pluglets deployed in separate class loaders Performance –Pluglets run in a single process; efficient local bindings –Distributed communication: efficient binary protocols –Support for asynchronous calls Security –SSL transport, JAAS authentication, Java sandbox model, security policies Interoperability –Multiple RMI protocols: SOAP, JRMP, RPC, … –API support for native code: resource staging, linking dynamic libraries

CCA Meeting, Atlanta, Jan 2005 Institute of Computer Science AGH 11 Requirements for a Metacomputing-oriented CCA Framework Facilitated deployment - provide easy mechanisms for creation of components on distributed shared resources; Efficient communication - both for distributed and local components; Flexible - allow flexible configuration of components and various application scenarios; Support native components, i.e. components written in non-Java programming languages and compiled for specific architecture. Interoperable with Grid standards (Web services)

CCA Meeting, Atlanta, Jan 2005 Institute of Computer Science AGH 12 Existing CCA Frameworks CCAFFEINE –Tightly coupled –Support for Babel –MPI support XCAT –Loosely coupled –Globus-compatible –Java-based DCA –MPI based –MxN problems SCIRun2 –Metacomponent model LegionCCA –Based on Legion Metacomputing system

CCA Meeting, Atlanta, Jan 2005 Institute of Computer Science AGH 13 MOCCA implementation in H2O Each component running in separate pluglet Thanks to H2O kernel security mechanisms, multiple components may run without interfering Two-level builder hierarchy ComponentID: pluglet URI MOCCA_Light: pure Java implementation (no SIDL)

CCA Meeting, Atlanta, Jan 2005 Institute of Computer Science AGH 14 Remote Port Call

CCA Meeting, Atlanta, Jan 2005 Institute of Computer Science AGH 15 How to use MOCCA (step by step) Implement component code extending CCA interfaces (cca.Port, cca.Component) Compile component classes into JAR file Publish application JARs on HTTP server Use the Java client API or write a Jython script to assemble application from components –Specify components and their connections –Specify locations of H2O kernels where to instantiate components Running the script automatically deploys necessary pluglets into H2O kernels and spawns application

CCA Meeting, Atlanta, Jan 2005 Institute of Computer Science AGH 16 Example script builder = MoccaMainBuilder() uriKernel1 = URI.create(" uriKernel2 = URI.create(" userBuilderID = builder.addNewBuilder(uriKernel1, "MyBuilderPlugletA") providerBuilderID = builder.addNewBuilder(uriKernel2, "MyBuilderPlugletB") properties = MoccaTypeMap() properties.putString("mocca.plugletclasspath", " properties.putString("mocca.builderID", userBuilderID.getSerialization()) userID = builder.createInstance("My StarterComponent", "mocca.samples.pingpong.impl.MoccaStarterComponent”, properties) properties.putString("mocca.plugletclasspath", " properties.putString("mocca.builderID", providerBuilderID.getSerialization()) providerID = builder.createInstance("MyPingComponent", "mocca.samples.pingpong.impl.PingPongComponent", properties) connectionID = builder.connect(userID, "PingPongUsesPort", providerID, "PingPongProvidesPort") MoccaBuilderClient.invokeGo(userID)

CCA Meeting, Atlanta, Jan 2005 Institute of Computer Science AGH 17 Automatic Flow Composer Example Compose application graph from initial data (e.g. initial ports) or incomplete graph First implemented for XCAT framework Easy migration to MOCCA Modification of code required (xcat.Port) Similar performance for XCAT and MOCCA (exchange of text documents)

CCA Meeting, Atlanta, Jan 2005 Institute of Computer Science AGH 18 Communication Intensive Application Benchmark Simplified scenario: –2 components –Provides port: receive and send-back array of double (ping-pong) Tested on local Gigabit Ethernet and on transatlantic Internet between Atlanta and Krakow 2.4 Ghz Linux machines Comparison with XCAT

CCA Meeting, Atlanta, Jan 2005 Institute of Computer Science AGH 19 Small Data Packets Factors: SOAP header overhead in XCAT Connection pools in RMIX

CCA Meeting, Atlanta, Jan 2005 Institute of Computer Science AGH 20 Large Data Packets Encoding (binary vs. base64) CPU saturation on Gigabit LAN (serialization) Variance caused by Java garbage collection

CCA Meeting, Atlanta, Jan 2005 Institute of Computer Science AGH 21 Support for Babel Components Currently: MOCCA_Light – pure Java framework Approach: –Use Java bindings to Babelized components –Automatically generate wrapping code Issues: –Babel remote bindings –Remote references –Package hierarchy: gov.cca.Port extends gov.llnl.sidl.BaseInterfac e, sidl.BaseInterface

CCA Meeting, Atlanta, Jan 2005 Institute of Computer Science AGH 22 Future directions of MOCCA Support for multilingual components –Goal: to enable loading of Babel CCAFFEINE components into MOCCA –Automatic generation of wrappers from SIDL Support for dynamic component reconfiguration and adaptiveness –CCA standard allows for dynamic creation of ports and connecting/reconnecting at runtime –Framework needs to support such behavior –Especially interesting for interactive (portal/PSE) usage Investigation of using hierarchical components –By using CCA BuilderService components may act as sub- frameworks creating hierarchies of subcomponents inside them

CCA Meeting, Atlanta, Jan 2005 Institute of Computer Science AGH 23 Beyond CCA ? Supporting multiple component standards –Goal: to enable loading of components written for different standards (e.g. Corba CCM, other) –Examples of similar solutions: CCAFFEINE supports „classic” and „Babel” components; SCIRun2 implementing meta- component model Using MOCCA as promising platform for feasibility studies in various aspects of Grid components –For experiments with advanced features Scheduling and load-balancing Fault-tolerance Semantic description and composition –As a platform for higher-level grid services and tools

CCA Meeting, Atlanta, Jan 2005 Institute of Computer Science AGH 24 References Maciej Malawski, Dawid Kurzyniec, and Vaidy Sunderam. MOCCA – towards a distributed CCA framework for metacomputing, Accepted for: 10th International Workshop on High-Level Parallel Programming Models and Supportive Environments (HIPS2005), H2O Project homepage: