Transcript The Common Component Architecture and XCAT Indiana University Extreme! Lab What is a Component Architecture? • A systematic way of encapsulating special functionality and behaviors.

The Common Component
Architecture and XCAT
Indiana University
Extreme! Lab
What is a Component Architecture?
• A systematic way of encapsulating special
functionality and behaviors of a piece of
software into reusable units.
• More than an object model.
• It defines the rules for the way objects can be
instantiated and composed.
• It defines the environment of services that a component
can use.
• It defines the way in which we discover how to interact
with them.
Isn’t this what a subroutine library
does?
– Subroutine libraries or class libraries have
• well defined interfaces
• encapsulate functionality
– But are often hard to reuse because they
• often have complex resource requirements
• make conflicting assumptions about their operating
environments.
– Subroutine libraries that follow very strict sets of
design and use rules get reused.
• Above all else, a component architecture is framework of
standard rules of behavior for objects.
Standard Component Archtectures
• Examples:
– Microsoft COM/DCOM, COM++
• the foundation of all Microsoft office products
– Java Beans
• Java standard for building user interfaces
– Enterprise Java Beans
• a standard for client-server applications in Java
– CORBA 3.0
• The new component spec for CORBA.
Look at One Design in Detail
• The U.S. Dept of Energy DOE2000 project
– The Common Component Architecture
•
•
•
•
•
Lawrence Livermore National Lab
Sandia Labs
Argonne National Labs
Los Alamos National Labs
Universities: Utah, NCSA, Indiana
– A specification for component design for parallel
and distributed applications
Two parts to the CCA Architecture
• Components
– An encapsulated “object” defined by its public
interfaces.
– Can be Java, C, Python, C++ or C++ and Fortran.
• Frameworks
– The software systems that provides basic services
to components
– Used to compose components to make apps.
– Many implementations: Parallel and Distributed.
Some Concepts in Detail
• Ports: the public interfaces of a component
– defines the different ways we can interact with a
component and the ways the component uses
services and other components.
setImage(Image I)
Uses Ports - interface of a
service used by component
Image getImage()
adjustColor()
Image Processing
Component
setFilter(Filter)
Provides Ports - interfaces
functions provided by component
calls doFFT(…)
How do you “compose” two
components?
• There are three basic approaches:
– Events: A component can generate an “event” of a particular
type. Other components are added as “listeners” for such
events from that component.
– Services: A source component “uses” services “provided” by a
target components.
• “use” = calls a function provided by the target.
– Dataflow: A typed data “output” stream is connected to a
similarly typed “input” port of another.
• In XCAT all three are supported.
– The services model is the basic mechanism.
– Dataflow is emulated in CCA by “pushing” data from a user to
a provider, or by having a user “pull” data from a provider.
– Events are managed by a separate mechanism.
Building Applications by
Composition
• Connect uses Ports to Provides Ports.
Image
database
component
setImage(…)
getImage()
Image Processing
Component
adjustColor()
Image tool graphical interface component
doFFT(…)
Acme
FFT
component
Ports and Interfaces (CCA)
• Component composition:
– Connect (possibly at runtime) a “provides” port of one
component to a “uses” port of another.
– A provides port is simply an implementation in the component
of the interface defined by the port type (interface defn.).
– A Uses port is a “proxy” that a component “uses” to make a
request of another component.
Source
Component
A Provides port
A uses port
Target
Component
How do you describe the interfaces a
port has?
• Standard Methods:
– Use an Interface Definition Language - a formal
description of the interface objects.
• CORBA IDL is one.
• The LLNL Scientific IDL by Scott Kohn, Andrew Cleary,
Steven Smith, and Brent Smolinski is better for CCA.
– A simple IDL compiler can be used to automatically
generate the Uses and Provides Port code for a
specific IDL type.
– For the XCAT java version the interface of a
component port are defined as Java interfaces.
Component Communication
• Use a simple Remote Procedure Call Mechanism
– XSOAP
• Implementation of Simple Object Access Protocol (SOAP)
• Performance Issues
– in-process calls
– Events/Messages
• Objects encoded as XML documents
– Proteus
• Multiprotocol Messaging and RMI
Creation Service
• Creates a running instance of another
component
• Encapsulates authentication issues
Launch an instance of
component X on resource Y
Returns: remote reference
to new component instance
Globus
resource Y
Creation
Service
Component
X
Connection Service
• A component that can be used to connect a
“uses” port of one component to the
“provides” port of another
• Can export ports of another component
X
Connect port A of component X
to port B of component Y
A
Connection
Service
Component
B
Y
Builder Service
• combination of Creation and Connection
service
• standardized as part of recently updated CCA
specification
• we are now in process of implementing it in
XCAT
Simple Example in Java
public class SimpleEchoImpl
implements SimpleEcho
{
public String echoHello(String s)
throws RemoteException
{
return "SimpleEchoImpl says: Hello " + s;
}
}
Simple Example in Java
public class EchoPrinterComponent
implements Component
{
public void setServices(Services cc){
PortInfo portType = new PortInfoImpl(
"simpleEchoProvidesPort",
"http://example.com/echo.wsdl");
simpleEchoImpl = new SimpleEchoImpl();
cc.addProvidesPort(simpleEchoImpl,portType);
}
}
Simple Example in Java
public class EchoGeneratorComponent
implements Component
{
public void setServices(Services cc){
PortInfo portType = new PortInfoImpl(
"simpleEchoUsesPort",
"http://example.com/echo.wsdl");
cc.registerUsesPort(portType);
}
}
Simple Example in Java
SimpleEcho usesSimpleEcho = (SimpleEcho)
cc.getPort("simpleEchoUsesPort");
usesSimpleEcho.echoHello("Extreme Lab");
cc.releasePort(“simpleEchoUsesPort");
Echo
Generator
Component
A Provides port
simpleEchoProvidesPort
A uses port
simpleEchoUsesPort
Echo
Printer
Component
Scripting XCAT Applications
import xcat
generator = xcat.createComponent(‘GeneratorComponet’)
printer = xcat.createComponent(‘Printer’)
xcat.setCreationMechanism(generator, ‘gram’)
xcat.setCreationMechanism(printer, ‘ssh’)
xcat.createInstance(generator)
xcat.createInstance(printer)
xcat.connectPorts(generator, ‘simpleEchoUsesPort’,
printer, ‘simpleEchoProvidesPort’)
Scripting XCAT Applications
generatorComponent = EnvObj()
generatorComponent.put("exec-name",
"simpleGeneratorComponent")
generatorComponent.put("exec-fqn",
"samples.simpleEchoGenerator.SimpleEchoGe
neratorComponent")
printerComponent = EnvObj()
printerComponent.put("exec-name",
"simplePrinterComponent")
printerComponent.put("exec-fqn",
"samples.simpleEchoPrinter.SimpleEchoPrinte
rComponent")
# create component wrappers
generator =
cca.createComponent(generatorComponent)
printer =
cca.createComponent(printerComponent)
# assign a machine name
printermc = "exodus.extreme.indiana.edu"
generatormc = "exodus.extreme.indiana.edu"
cca.setMachineName(generator,generatormc)
cca.setMachineName(printer, printermc)
# create live instances
cca.createInstanceWithTimeOut(printer,
120000)
cca.createInstanceWithTimeOut(generator,
120000)
# connect their ports
cca.connectPorts(generator,
"simpleEchoUsesPort", printer,
"simpleEchoProvidesPort")
# start the components – invoke go() on GoPort
usesGoPortClassName =
"samples.idl.goPort.UsesGoPort"
usesPortType = "http://example.com/go.wsdl"
providesPortName = "providesGoPort"
methodName = "go"
methodParams = zeros(0, Object)
cca.invokeMethodOnComponent(generator,
usesGoPortClassName, usesPortType,
providesPortName, methodName,
methodParams)
print "Done"
•
•
•
Scientific Components and
Applications
Recognized as one of the “Top Ten Science Achievements
in 2002” by the DOE Office of Science (see
http://www.sc.doe.gov/sub/accomplishments/top_10.htm)
Many demonstrated at SC2001 and SC2002
Combine application-specific components with more
general-purpose components that can be reused across a
range of applications
– More than 40 components, many reused in apps such as
•
• PDEs on unstructured and adaptive structured meshes
• Unconstrained minimization problems
Leverage and extend parallel software developed at
different institutions
– Including CUMULVS, CVODES, Global Arrays, GrACE, MPICH,
PETSc, PVM, and TAO
Current Interface Development
Activities
CCA Scientific Data Components
•
Working Group
Other Groups
Basic Scientific Data Objects
•
– Lead: D. Bernholdt (ORNL)
•
Unstructured Meshes
– Lead: L.F. Diachin (SNL, formerly
ANL)
– Collaboration with TSTT ISIC
– TSTT = Terascale Simulation Tools and
Technologies, PIs: J. Glimm, D. Brown, •
L.F. Diachin, http://www.tsttscidac.org
•
Structured Adaptive Mesh
Refinement
– Lead: P. Colella (LBNL)
– Collaboration with APDEC ISIC
– APDEC = Algorithmic and Software
Framework for Applied PDEs, PI: P.
Colella, http://davis.lbl.gov/APDEC
•
Linear and nonlinear solvers,
eigensolvers, and optimizers
– Coordinator: L.C. McInnes (ANL)
– Collaboration with TOPS ISIC
– TOPS = Terascale Optimal PDE
Simulations, PI: D. Keyes,
http://tops-scidac.org
MxN Parallel Data
Redistribution
– Lead: J. Kohl (ORNL)
– Part of CCTTSS MxN Thrust
Quantum Chemistry
– Leads: C. Janssen (SNL) and T.
Windus (PNNL)
– Part of CCTTSS Applications
Integration Thrust
Motivation for Common Interfaces
• Many-to-Many couplings
require Many 2 interfaces
– Often a heroic effort to
understand details of both codes
– Not a scalable solution
• Common Interfaces: Reduce
the Many-to-Many problem
to a Many-to-One problem
– Allow plug-and-play
interchangeability &
interoperability
– Require domain specific experts
– Typically difficult & timeconsuming
– A success story: MPI
– Challenges
• Interface agreement
• Functionality limitations
• Maintaining performance
AOMD
Hypre
MDB/CUBIT
PETSc
NWGrid
SuperLU
Overture
linear solver
libraries
mesh libraries
AOMD
MDB/CUBIT
NWGrid
Overture
Others …
D
a
t
a
S
o
l
v
e
r
s
TSTT
TOPS
Data
Solver
Interfaces Interfaces
Hypre
PETSc
SuperLU
Others …
Framework Stays
“Out of the Way”
of Component Parallelism
• Single component multiple
data (SCMD) model is
component analog of widely
used SPMD model
• Each process loaded with the
same set of components wired
the same way
P0
P1
P2
P3
•Different components in same
process “talk to each” other via
ports and the framework
•Same component in different
processes talk to each other
through their favorite
communications layer (i.e.,
MPI, PVM, GA)
Components: Blue, Green, Red
Framework: Gray
MCMD/MPMD also supported
There are 3 CCA Frameworks
Uintah
Threaded
Ccaffeine
SPMD
Distributed
• There’s 3 parallelism models in scientific
computing
Ccaffeine
Ccaffeine
Characteristics
• SPMD
• GUI and Scripted
Interface
• Interactive or Batch
• Serial or Parallel
• Components written in
C++
Achievements
• Separates CCA Pattern
from Implementation
– 3 Bindings
• Classic Components
• SIDL Components
• Chasm Components
• Demonstrated at
SC2001 & SC2002
• Used in CCA Tutorials
SCIRun/BioPSE/Uintah
Characteristics
• multithreaded & distributed
• C++ only
• Used in “real science” (gov’t,
academic, commercial) 1K
procs
Achievements
• Testbed for CCA Concepts
• Novel work in IDL-based MxN
• Parallelism and concurrency
research for CCA done on
Uintah
• SCIRun2 will integrate SCIRun,
BioPSE and Uintah
XCAT
Characteristics
Achievements
• Distributed/Grid model
• Web Services
• Developed Proteus multiprotocol communication
package
• Novel MxN work at MPI-I/O
level
• Java and C++ components
8 Application control
exported
exported
GS Go
Go
2
Directory/
Discovery Service
1
7 wsdl
3
Application
Specific component
Application
Factory
Service
4
Authorization
Service
5
Resource
Broker
Service
6
Application
Coordinator
exported
sendParameters, start, kill
Go
Data
Data Provider Comp
Cntl GS
Go GS
Simulation
Component
Ensemble Application
Material Archive
A Science Portal View of “programming” the Grid
App
Instance
Launch, configure
And control
App
factory
User Portals/ Science Portals
• A Science Portal is a Web server that
– Uses a “prepackaged” set of scripts to
• Get the users proxy cert from a cert repository
• Configure a specific application to users needs
• Contact the appropriate application factories
– Look for event histories of application
execution
– Allow the user to contact and control the app.
Application Factory Service
• A service that understands a how
to instantiate a running instance of
an app component.
– You provide it with appropriate
requirements initial conditions, etc.
via an XML file
– The service
• checks you credentials and authorization
• May consult resource broker
• launches the app or runs the appropriate
grid script.
Provide me with
an instance of
application X
App
factory
App
Instance
Application Component Execution Environment
Specification
The information needed
<componentStaticInformation>
to generate input to the
<componentInformation>
factory service
<uniqueID>WebsterComponent</uniqueID>
<name>Webster Component</name>
<author>Indiana University Extreme! computing</author>
<componentAuthor>Dennis Gannon</componentAuthor>
</componentInformation>
<executionEnv>
<hostName>olympus.cs.indiana.edu</hostName>
<hostName>linbox2.extreme.indiana.edu</hostName>
<hostName>rainier.extreme.indiana.edu</hostName>
<creationProto>gram</creationProto>
<creationProto>ssh</creationProto>
<nameValuePair>
<name>exec-dir</name>
<value>/u/gannon/xcat_tutorial/scripts</value>
</nameValuePair>
….
Steps in creating a app instance from the portal to the
factory
•
•
User Configures Application from
Web Browser
•
Sets application parameters
•
Launches job
Web Server contacts appropriate application
factory service (FS)
•
•
•
Supplies FS with task parameters
FS contacts Resource Broker and secures job
launches.
Returns App WSDL to server to browser
User Portals/ Science Portals
Event
channel
Web
Server
App
factory
•Job begins execution
•Publishes its contact point (WSDL) to discovery
service
•Begins publishing status events to event channel.
•Web server discovers application
•Allows user to interrogate it or retrieve event traces
Resource
Broker
App
Instance
Disc
serv
An Application Instance
• Typical Instance
– Publishes event stream
to “well known”
channel.
– Has a Control
Interface to allow
portal level
interrogation or
remote steering
– May be linked to other
components/services
Event
stream
Control Interface
• check status
• control messages
Application
Instance
Links
To
Other
Apps/
services
Encapsulating Legacy Apps
• Common Case
Control
– Legacy App that reads
files and writes files.
– Use a “scripted
component” called an app
manager.
Event
Stream
App Mgr
App
Script
• Component runs a python
script loaded at startup or
through a control command
– The App Script
• Stages files
• Launches and monitors
application
• Writes Output files
• publishes event streams
application
input
files
output
files
XCAT And OGSI
• A component based model to the Grid
services
– Component Assembly: Composition in space
– Workflow: Composition in time
• Ability to use widely available Web services
tooling to interact with components
• A richer messaging and notification system
that extends the model proposed by OGSI
• An application factory service that extends
the standard OGSI factory service
XCAT-OGSI Big Picture
ComponentID (GSH)
(uniquely identifies
Component)
GridService Port
(for lifecycle and
metadata)
Other XCAT
Provides Ports
ServiceData
XCAT Component
(includes list of
Port references)
Incorporating OGSI into XCAT
• Converting an XCAT component to a Grid service
– Addition of an OGSI GridService Port
– Addition of Service Data Elements (SDEs) containing
references to each of the other ports
– Uniquely identifying the component using a ComponentID
(GSH)
– Using a WSDL representation for the GSR
• Adding a set of helper services that are OGSI
compliant
– A HandleResolver service for mapping a GSH to a GSR
– Modifications to the XCAT Creation service to make
appropriate calls to the Factory and GridService ports for
lifetime management
XCAT Vs OGSI Messaging
• OGSI messaging is simple, point-to-point, and nonreliable, whereas XCAT uses XMessages that
provides a reliable, persistent network of message
channels suited for application level messaging and
events
• OGSI messaging is push based, and only current
moment state can be pulled by accessing SDEs
whereas XMessages can be both push and pull based
• In XCAT, clients can have more mobility and
interoperate more easily with firewalls
• there is no assumption that client has IP reachable address
Factories in XCAT and OGSI
• OGSI provides a standard Factory Port type for
instantiating services
• XCAT generalizes this Factory Port type to
instantiate a set of XCAT components that constitute
an application
– Accepts a description of a connected network of components
– Launches an Application Coordinator for each application that
creates, and links together instances of the described
network of components
– Exports a subset of the functionality of the components,
which are useful for the application, to the end-user
– Enables creating and managing complex distributed
applications