Grid Computing Research LabSUNY Binghamton

http://grid.cs.binghamton.edu

1

Plans for Babelizing XCAT-C++

Madhu Govindaraju

Kenneth Chiu

2

XCAT-C++ Component: Architecture

3

Proteus: Multi-Protocol Library

• Proteus provides single-protocol abstraction to components– Allows users to

dynamically switch between protocols

XCAT-Library

Proteus API

XBMP SOAP

TCP TCP

4

What makes a distributed framework?• How does an object become remote?• What happens when a method is invoked on a remote reference?• What about nested components/sub-components?• What is the remote reference format?• How is the remote reference transported on the wire?• How does the BuilderService create a component and get back a reference?• How is a new protocol chosen?• How will the code generation for the RMI protocol be done?• During serialization how is the RMI code called?• During deserialization how is the object code called?• What about garbage collection (in, out, inout) methods?• How can multiple RMI protocols be used for the same application?• Can XCAT-C++ components serve as Web service so that they work with workflows?• How is a new provider loaded (dynamically) into an XCAT-C++ component?• How will the current code generation be affected?• What kind of Proteus-Babel adapter needs to be designed?

5

Remote Objects

• Example Remote Objects– ProvidesPorts, ComponentIDImpl– Move across address spaces

• Current Design– Hidden in generated code for each port– ProvidesPort implementations need to inherit from

generated code

• Babelized model– 3 ways for server-side creation of remote objects

• Use the API to add object to the InstanceRegistry• Modify XCAT-C++ library, generated code, and provides ports

6

Builder Service

• Current Design – can plug in different protocols for remote creation

• SSH, GRAM, …• Specified by user in the TypeMap in call to BuilderService

– implementation of builder service• separate thread waits for successful instantiation of remote

component– or else time-out and throw an exception

• The driver/main of the new component retrieves its ComponentID• use an internal RMI call to send it to the waiting BuilderService• ConnectionID returned to the user

7

Builder Service (2)

• Babelized Design – The component main will call the getURL(…) call on the

ComponentID– return it to the waiting BuilderService

• a stub will be used on the BuilderService side– May need Structs to be supported

– For now, call connect from the newly instantiated component» Will work if remote reference is converted to a string

8

Remote Reference Format

• XCAT-C++– currently all remote references are in string format

• provider name, host,port, uniqueID

– each remote object can be re-created as a local (proxy) object on the receiving side

• New Design– BabelRMI deals with passing remote references

automatically• can dynamically create stubs on the receiving side

9

Sub-components

• xcatExportAs(Port* port, string portName)– This method exports another component's port with name

"portName" as its own port (with name "newPortname").

• Helps create nested components– Need to figure out how to efficiently transfer data

• Without copying in intermediate components

• New Design– No need to change the design– Again need to ensure data copying doesn’t take place

10

Invoking Remote Methods

• Current Design– A provider is dynamically loaded – Each provider adheres to a Proteus API for pack and

unpack of arguments.– Methods on remote objects can be transferred to

generated code specific to each remote object• Proteus transfers the calls to specific provider

– Which then transports it

• New Design– BabelRMI has an API similar to ProteusAPI– BabelRMI-Proteus adapter will take care of the transfer

• So the generated code will have to change for XCAT-C++– Will be handled by Babel itself though

11

Loading Specific Providers

• XCAT-C++ can use multiple protocols in same component– Can dynamically load a new provider

• granularity is on a per call basis

• New Design– can dynamically add many protocols to the

protocolFactory• once you create a stub that uses protocol x to access object y,

you're pretty much stuck with x. • though theoretically you can get a new stub to y with a new

protocol with the connect call if you like though. [Jim Leek]

12

Garbage Collection

• Will stick to using BabelRMI model – no changes needed

13

User Interface

• C++ interface to the BuilderService Implementation• Python interface via SWIG

typeMapProv.putString( "remoteHost", “drake”)typeMapProv.putString("creationArgs", "-l xbmp.so”)

• New Design– C++ interface should be similar to current XCAT-C++

interface– Python interface via SWIG needs to be investigated

• do not expect this to be a problem though!

14

Current and Future Design Work• Investigate how to use Babelized XCAT-C++ as a Web

service so that it works with workflows• Serialization and De-serialization of Objects

– Structs– serializing arrays is important

• passing it as a remote reference will be expensive

• Interoperability with other frameworks• Dynamically swap components

– in between calls– notion of component-type and port type matching

• Incorporate a CCA-event model• Incorporate TAU tools to get trace of performance data• Incorporate monitoring and CQoS methodologies

15

Babel RMI

• Allows Babel objects to be accessed through remote Babel stubs.

• Underlying RMI uses Proteus.

• Objects that can be transmitted inherit from sidl.io.Serializable.

• Actual implementation of serialization functions is by specific protocol implementations