CHAIMS: Mega-Programming Research
Compiling High-level Access
Interfaces for Multi-site Software
CHAIMS
Stanford University
Objective: Investigate revolutionary approaches to
large-scale software composition.
Approach: Develop & validate a
composition-only language.
Contributions and plans:
• Hardware and software platform independence.
• Asynchrony by splitting up CALL-statement.
• Performance optimization by invocation scheduling.
• Potential for multi-site dataflow optimization.
www-db.stanford.edu/CHAIMS
June 1998
CHAIMS
1
Participants
• Support
– DARPA ISO EDCS program (1996-1999)
– Siemens Corporate Research (1996-1998)
– DoD AFOSR AASERT student support (1997-1999)
– Sloan Foundation - computer industry study (1996-97)
• People
– Gio Wiederhold
(Prof. Res) PI
-
Marianne Siroker (Administration)
– Dorothea Beringer (postdoc EPF Lausanne) since Dec.1997
– Ron Burback (CS PhD cand.)
– Laurence Melloul (CS MS)
-
Neil Sample (CS PhD Student)
Woody Pollack (CS MS)
– MS and BS CS graduated: Joshua Hui, Gaurav Bhatia, Prasanna
Ramaswami, Kirti Kwatra, Pankaj Jain, Mehul Bastawala, Catherine
Tornabene, Wayne Lim (I.E.), Connan King (E.E.).
– Louis Perrochon (postdoc ETH Zurich) Fall quarter 1996
June 1998
CHAIMS
2
Gio Wiederhold: Personal Background
• 1936 born Varese, Italy
• 1957: Learned programming at NATO SHAPE ADTC
• 1958-1975 Programmer and software engineer
– at IBM, UC, Stanford, Index, MaSCOR
• 1963 - now Consultant for government, Industry
• 1974-1976 PhD on Database Design at UC SF
• 1976- now Professor Stanford
– Computer Science, Medicine, Electrical Eng., Business School
• Elected fellow ACMI, IEEE, ACM
• Innovations:
– solid rocket fuel combustion - A-format - incremental compilers – timeshared real-time data acquistion - time-oriented databases – database design - knowledge-based system concepts – object creation from relations - mediators - security filters.
June 1998
CHAIMS
3
Dorothea Beringer: Personal Background
• Masters in Computer Science: hybrid-monitoring tool
for debugging and software performance analysis for
distributed software
• Software engineer: telecommunication systems
• Consultant: software methodologies, quality
assurance, project management, CASE-tools
• PhD: Modeling scenarios in object-oriented analysis
• Teaching: Fusion
• Now: CHAIMS -- large-scale software composition,
distributed systems
June 1998
CHAIMS
4
Presentation
• Motivation and Objectives
– changes in software production
– basis for new visions and education
• Concepts of CHAIMS
– CHAIMS language
– CHAIMS architecture and composition process
– Scheduling
– Dataflow optimization
• Status, Plans, Conclusions
June 1998
CHAIMS
5
Shift in Programming Tasks
Integration
Coding
1970
June 1998
1990
CHAIMS
2010
6
Languages & Interfaces
• Large languages intended to support coding
and composition have not been successful
–
–
–
–
Algol 68
PL/1
Ada
CLOS
• Databases are being successfully composed,
using Client-server, Mediator architectures
–
–
–
–
June 1998
distribution -- exploit network capabilities
heterogeneity -- autonomy creates heterogneity
simple schemas -- some human interpretation
service model -- public and commercial sources
CHAIMS
7
Typical Scenario: Logistics
A general has to ship troops and/or various material
from San Diego NOSC to Washington DC:
–
–
–
–
–
different kind of material: criteria for preferred transport differ
not every airport equally suited
congestion, prices
actual weather
certain due or ready dates
Today:
calling different companies, looking up
information on the web, reservations by hand
Tomorrow: system proposes possibilities that take into
account various conditions
» hand-coded systems
» composition of processes
June 1998
CHAIMS
8
Scaling alternatives
?
June 1998
CHAIMS
9
CHAIMS
Megaprogram for composition,
written by domain programmer
CHAIMS
Megamodules
June 1998
CHAIMS
CHAIMS system automates
generation of client for
distributed system
Megamodules, provided
by various megamodule
providers
10
Megamodules - Definition
Megamodules are large, autonomous, distributed,
heterogeneous services or processes.
• large: computation intensive, data intensive, ongoing processes
(monitoring services)
• distributed: to be used by more than one client
• heterogeneous: accessible by various distribution protocols (not
only different languages and systems)
• autonomous: maintenance and control over recourses remains
with provider, differing ontologies ( ==> SKC)
Examples:
– logistics: “find best transportation route from A to B”,
reservation systems
– genomics: easier framework for composing various processing
tools than ad-hoc coding
June 1998
CHAIMS
11
Challenge: Fat Clients
Domain expert
Client computer
I/O
Control &
Computation
Services
c
a
b
I/O
e
d
Wrappers
to resolve
differences
Data
Resources
June 1998
CHAIMS
12
Challenge: Thin Clients
Domain expert
IO module
Client workstation
IO module
C
Computation
Services
MEGA modules
a
T
Sites
e
b
R
d
S c
U
T
Data
Resources
June 1998
CHAIMS
13
Challenge: Heavy-weight Services
Services are not free for a client:
• execution time of a service
• transfer time for data
• fees for services
What we need:
==> monitoring progress of a service
==> possibility to choose among equivalent services
based on estimated waiting time and fees
==> parallelism among services
==> preliminary overview results, choosing level of
accuracy / number of results for complex processes
==> novel optimization techniques
June 1998
CHAIMS
14
Challenge:
Empower Non-technical Domain Experts
Company providing services:
• domain experts of domain of service (e.g. weather)
• technical experts for programming for distribution
protocols, setting up servers in a middleware system
• marketing experts
“Megaprogrammer”:
• is domain expert of domain that uses these services
• is not technical expert of middleware system or
experienced programmer,
• wants to focus on problem at hand (=results of using
megaprogram)
• e.g. scientist, logistics officer
June 1998
CHAIMS
15
Challenge: Purely Compositional
Language Possible?
Which languages did succeed?
– Algol, ADA: integrated composition and computation
– C, C++ focus on computation
Why new language?
– complexity: not all facilities of a common language
(compare to approach of Java),
– inhibiting traditional computational programming (compare
C++ and Smalltalk concerning object-oriented programming)
– focus on issue of composition, parallelism by asynchrony,
and optimization
June 1998
CHAIMS
16
CHAIMS “Logical” Architecture
Customer
Megaprogram
clients
(in CHAIMS)
Network/Transport
(DCE, CORBA,...)
Megamodules
(Wrapped or Native)
June 1998
CHAIMS
17
CHAIMS Physical Architecture
Megaprogram
Clients in CHAIMS
Network
DCE, CORBA,
JAVA RMI, DCOM...
Megamodules (wrapped, native) each supporting
setup, estimate, invoke, examine, extract, and terminate.
June 1998
CHAIMS
18
Decomposing CALL statements
CALL gained
functionality
progress
in
scale of
computing
Copying
Code sharing
Parameterized computation
CHAIMS
decomposes
CALL
functions
Objects with overloaded method names
Remote procedure calls to distributed modules
Constrained (black box) access to encapsulated data
Setup
June 1998
Estimate
Invoke
CHAIMS
Examine
Extract
19
CHAIMS Primitives
Pre-invocation:
SETUP: set up the connection to a megamodule
SET-, GETATTRIBUTES: set global parameters in a megamodule
ESTIMATE: get estimate of execution time for optimization
Invocation and result gathering:
INVOKE: start a specific method
EXAMINE: test status of an invoked method
EXTRACT: extract results from an invoked method
Termination:
TERMINATE: terminate a method invocation or a connection to
a megamodule
Control:
WHILE, IF
June 1998
Utility:
GETPARAM: get default parameters
CHAIMS
20
Megaprogram Example: Overview
General I/O-megamodule
InputOutput
» Input function takes as parameter a
default data structure containing names,
types and default values for expected
input
- Input
- Output
RouteInfo
AirGround
- AllRoutes
- CityPairList
- ...
- CostForGround
- CostForAir
- ...
Routing
RouteOptimizer
- BestRoute
- ...
- Optimum
- ...
June 1998
Travel information:
» Computing all possible routes between
two cities
» Computing the air and ground cost for
each leg given a list of city-pairs and data
about the goods to be transported
Two megamodules that offer equivalent
functions for calculating optimal
routes
» Optimum and BestRoute both calculate
the optimum route given routes and costs
» Global variables: Optimization can be
done for cost or for time
CHAIMS
21
Megaprogram Example: Code
io_mmh = SETUP ("InputOutput")
route_mmh = SETUP ("RouteInfo")
...
best2_mmh.SETATTRIBUTES (criterion = "cost")
// Setup connections to megamodules.
// Set global variables valid for all invocations
// of this client.
cities_default = route_mmh.GETPARAM(Pair_of_Cities)
input_cities_ih = io_mmh.INVOKE ("input”, cities_default) // Get information from the megaprogram user
WHILE (input_cities_ih.EXAMINE() != DONE) {}
// about the goods to be transported and about
cities = input_cities_ih.EXTRACT()
// the two desired cities.
...
route_ih = route_mmh.INVOKE ("AllRoutes", Pair_of_Cities = cities)
WHILE (route_ih.EXAMINE() != DONE) {}
// Get all routes between the two cities.
routes = route_ih.EXTRACT()
…
//Get all city pairs in these routes.
//Calculate the costs of all the routes.
// Figure out the optimal megamodule for
IF (best1_mmh.ESTIMATE("Best_Route")
// picking the best route.
< best2_mmh.ESTIMATE("Optimum") )
THEN {best_ih = best1_mmh.INVOKE ("Best_Route", Goods = info_goods,
Pair_of_Cities = cities, List_of_Routes = routes,
Cost_Ground = cost_list_ground, Cost_Air = cost_list_air)}
ELSE {best_ih = best2_mmh.INVOKE ("Optimum", Goods = info_goods,
//Pick the best route and display the result.
…
...
// Terminate all invocations
best2_mmh.TERMINATE()
June 1998
CHAIMS
22
Operation of one Megamodule
• SETUP
M handle
• SETATTRIBUTES
provides context
M handle
M handle
• ESTIMATE serves
scheduling
M handle
• INVOKE initiates remote
computation
I handle
• EXAMINE checks for
completion
I handle
I handle
• EXTRACT obtains results
I handle
• TERMINATE I / ALL
M handle
June 1998
CHAIMS
23
CHAIMS Megaprogr. Language
Purely compositional:
– no primitives for arithmetic ==> math megamodules
– no primitives for input/output ==> general and problemspecific I/O megamodules
Splitting up CALL-statement:
– parallelism by asynchrony in sequential program
– novel possibilities for optimizations
– reduction of complexity of invoke statements
• higher-level language (assembler => HLLs,
HLLs => composition/megamodule paradigm)
June 1998
CHAIMS
24
Architecture: Runtime
b
CSRT
a
(compiled megaprogram)
d e
c
MEGA modules
Distribution System (CORBA, RMI…)
June 1998
CHAIMS
25
Architecture: Composition Process
Megamodule
Provider
wraps non-CHAIMS
compliant megamodules
adds information to
Wrapper
Templates
CHAIMS
Repository
b
MEGA modules
de
e
a
c
June 1998
CHAIMS
26
Architecture: Composition Process
Megaprogrammer
writes
information
Megaprogram
(in CHAIMS language)
information
CHAIMS
Repository
CHAIMS
Compiler
generates
CSRT
(compiled megaprogram)
June 1998
CHAIMS
27
Architecture: Overview
Megamodule
Provider
Megaprogrammer
writes
wraps non-CHAIMS
compliant megamodules
adds information to
information
Megaprogram
(in CHAIMS language)
information
Wrapper
Templates
CHAIMS
Repository
CHAIMS
Compiler
b
generates
CSRT
a
(compiled megaprogram)
d e
c
MEGA modules
Distribution System (CORBA, RMI…)
June 1998
CHAIMS
28
Architecture: CHAIMS-Language
and CHAIMS-Protocols
Megaprogrammer
CHAIMS API defines interface
between megaprogrammer and
megaprogram; the megaprogram
CHAIMS-language
is written in the CHAIMS language.
Megaprogram
The CHAIMS protocols
define the calls the megamodules have to understand.
These protocols are slightly
different for the different
distribution protocols, and
are defined by an idl for
CORBA, another idl for DCE,
and a Java class for RMI.
June 1998
CHAIMS-protocols
CORBA-idl
DCE-idl
Java-class
M e g a m o d u l e s
CHAIMS
29
Architecture: Gentype
Minimal Typing in CHAIMS:
Integer, boolean only for control
All else is placed into an ASN.1 bag, transparent to compiler :
A Gentype is a triple of name, type and value, where
value is either a simple type or a list of other gentypes
(i.e. a complex type).
Simple types: given by ASN.1, the ASN.1-conversion
library for C++, our own conversion routines.
Example: Person_Information
Name of Person complex
First Name
string
Personal Data complex
Joe
Date of Birth
June 1998
Last Name
date
6/21/54
CHAIMS
string
Address
Smith
Soc.Sec.No
string
345-34-345
30
Wrapper: CHAIMS Compliance
• CHAIMS protocol - support all CHAIMS primitives
• State management and asynchrony:
» clientId (megamodule handle in CHAIMS language)
» callId (invocation handle in CHAIMS language)
» results must be stored for possible extraction(s) until
termination of the invocation
• Data transformation:
» all parameters of type blob (BER-encoded Gentype)
must be converted into the megamodule specific data
types (combination hand-coding/decoding routines
June 1998
CHAIMS
31
Architecture: Three Views
Composition View
(megaprogram)
CHAIMS Layer
- composition of
megamodules
- directing of opaque
data blobs
Transport View
Distribution Layer
Objective:
June 1998
moving around data blobs
and CHAIMS messages
Clear separation between composition of services,
computation of data, and transport
CHAIMS
32
time
time
time
Scheduler: Decomposed Execution
s,i
s,i
e
e
synchronous
asynchronous
s
i
e
decomposed
(no benefit for one module)
execution of a remote method
i
e
available for other methods
June 1998
s
CHAIMS
setup / set attributes
invoke a method
extract results
33
Optimized Execution of Modules
i1
e1
M2
e2
time
i3
time
i2
M1
M3
i4
e3
i3
i1 i4
e1
i2
e4
e3
e2
i5
e5
M1
M3
M4
(>M1+M2)
(<M1+M2)
M2
M5
optimized by scheduler
M4
according to estimates
M5
data dependencies
execution of a module
e4
i5
e5
non-optimized
June 1998
invoke a method
extract results
i
e
CHAIMS
34
Decomposed Parallel Execution
M1
M4
M3
<M1+M2)
M2
M5
set up / set attributes
invoke a method
extract results
optimized by scheduler
according to estimates
June 1998
(<M1+M2)
time
Long setup times
occur, for instance,
when a subset of a
large database has
to be loaded for a
simple search, say
Transatlantic fights
for an optimal arrival.
CHAIMS
35
M2
M3
(>M1+M2)
M3
(>M1+M2)
M4
M4
(<M1+M2)
(<M1+M2)
M2
prior time
M1
M1
time
Decomposed Optimized Execution
M5
M5
set up / set attributes
invoke a method
extract results
optimized by scheduler
according to estimates
June 1998
CHAIMS
36
M2
M3
(>M1+M2)
M3
(>M1+M2)
M4
M4
(<M1+M2)
(<M1+M2)
M2
prior time
M1
M1
time
Repeated invocations
M5
M5
set up / set attributes
invoke a method
extract results
optimized by scheduler
according to estimates
June 1998
CHAIMS
37
M2
M3
(>M1+M2)
M3
(>M1+M2)
M4
M4
(<M1+M2)
(<M1+M2)
M2
prior time
M1
M1
time
Repeated Extractions
M5
M5
set up / set attributes
invoke a method
extract results
optimized by scheduler
according to estimates
June 1998
CHAIMS
38
Scheduling: Simple Example
1
cost_ground_ih = cost_mmh.INVOKE ("Cost_for_Ground", 1
List_of_City_Pairs = city_pairs,Goods = info_goods)
2
WHILE (cost_ground_ih.EXAMINE() != DONE) {}
cost_list_ground = cost_ground_ih.EXTRACT()
3
cost_air_ih = cost_mmh.INVOKE ("Cost_for_Air",
2
List_of_City_Pairs = city_pairs,Goods = info_good)
4
WHILE (cost_air_ih.EXAMINE() != DONE) {}
cost_list_air = cost_air_ih.EXTRACT()
order in
unscheduled
megaprogram
June 1998
3
4
order in automatically
prescheduled megaprogram
CHAIMS
39
Scheduling: Possible Actions
INVOKES: call INVOKE’s as soon as possible
» may depend on other data
» moving it outside of an if-block: depending on costfunction (ESTIMATE of this and following functions
concerning execution time, dataflow and fees (resources).
EXTRACT: move EXTRACT’s to where the result is
actually needed
» no sense of checking/waiting for results before they are
needed
» instead of waiting, polling all invocations and issue next
possible invocation as soon as data could be extracted
TERMINATE: terminate invocations that are no longer
needed (save resources)
» not every method invocation has an extract (e.g. print-like
functions)
June 1998
CHAIMS
40
Compiling into a Network
current CHAIMS system
Mega Program
Module B
Module F
Module D
Module A
Module C
Module E
control flow
data flow
with distribution
dataflow optimization
Mega Program
Module B
Module D
Module A
Module C
June 1998
Module F
Module E
CHAIMS
41
CHAIMS Implementation
• Specify minimal language
– minimal functions: CALLs, While, If *
– minimal typing {boolean, integer, string, handles, object}
» objects encapsulated using ASN.1 standard
– type conversion in wrappers, service modules*
• Compiler for multiple protocols (one-at-time, mixed*)
• Wrapper generation for multiple protocols
• Native modules for I/O, simple mathematics*, other
• Implement API for CORBA, Java RMI, DCE usage
• Wrap / construct several programs for simple demos
• Schedule optimization *
• Demonstrate use in heterogeneous setting *
• Define full-scale demonstration
* in process
June 1998
CHAIMS
42
Status
• Definition of architecture for Megaprogramming
– bottom up assessment of code to be generated
• examples: room reservation, shipping
– primitives
– handles for parallel operation
– heterogeneity -- common features of distribution protocols
• Minimal language that can generate the code
– no versus very few types -- ASN.1 for complex types
– natural parallelism -- still a major research issue
• Awareness of novel optimizations
– information flow constraints -- scheduling
– direct data flow between megamodules
June 1998
CHAIMS
43
Focus for Future
• Finishing basic infrastructure and demo examples.
• CHAIMS interpreter to complement compiler.
• Dynamic scheduling of invocations and extractions.
• Flexible interaction with megamodules; extracting
and handling overview results.
• Direct dataflows between megamodules
– (future project).
June 1998
CHAIMS
44
Upcoming Changes to Architecture:
PreCompiler + Interpreter
Compiler:
user megaprogram
in CHAIMS
language
network
CHAIMS compiler,
simple scheduler
Idl-file generator
and compiler
executable
client (CSRT)
client code in
C, C++, Java,
stub code
C++, Java
compiler
and linker
Interpreter:
user
user
complete
megaprogram
in CHAIMS
language
some CHAIMS
statements
June 1998
serves as input to
CHAIMS execution
machine
(interpreter and
scheduler)
CHAIMS-protocol
serve as input to
CHAIMS
network
45
Interpreter
• Dynamic scheduler:
» Parsed input is stored in an executable dependency graph.
» Execution machine (interpreter / scheduler) works through the
graph and makes appropriate calls:
– estimate-calls are inserted to get necessary run-time information for
scheduling (cost-function)
– every invocation is issued as soon as possible (data-flow) and
reasonable (according to cost-function)
– all invocations for which the CSRT waits for results are polled regularly,
and results extracted and new invocations issued as soon as possible
CSRT would still be sequential!
• Overview results, flexible interactions:
» megaprogrammer can program statement by statement and get results
immediately; results will influence what he/she does next
» like ftp, web
June 1998
CHAIMS
46
Conclusion: Research Questions
• Is a Megaprogramming language focusing only on
composition feasible?
• Can it exploit on-going progress in client-server
models and be protocol independent?
• Can natural parallelism for distributed services be
effectively scheduled?
• Can high-level dataflow among distributed modules
be optimized?
• Can CHAIMS express clearly a high-level distributed
SW architecture?
• Can the approach affect SW process concepts and
practice?
CHAIMS
June 1998
CHAIMS
47
Other Research Projects
Related by common issue: Large-Scale Interoperation
• Mediation -- modules in 3-tier Information Systems
– {acess, abstraction, integration, summarization, delivery}
– maintenance management is a major benefit
• Security and Privacy Mediators
– filter results to complement access control
– for healthcare privacy / manufacturing collaboration
• Scalable Knowledge Composition
– develop algebra ( - )over ontologies
– articulate distinct distinct domains to create user contexts
• Image databases
– rapid search by match using wavelets
– identifying pornography
– extracting text from images and icons for privacy/search
June 1998
CHAIMS
48
Paying for SW Services
You can not run an effective (SW) business and not be
reimbursed for it. How? Four approaches:
– Sell Software
sell oilfield to customer
– Lease copy / usage rights lease well
– Time / user limited access fill tank
– Charge by use instance
provide bus
General problems, effects differ
protect
– IP protection?
– keeping SW updated update
bill
– billing for est.value
perform
– performance effect
June 1998
CHAIMS
Buy
Lease Limit
Use
poor
some
fair
good
poor
ok
good
good
simple simple awkw.
hard
no
no
little
some
49
Conclusion: Questions not
addressed
• Will one Client/Server protocol subsume all others?
– distributed optimization remains an issue
• Synchronization / Concurrency Control
– autonomy of sources negates current concepts
– if modules share databases, then database locks may
span setup/terminate all for a megaprogram handle.
• Will software vendors consider moving to a service
paradigm?
– need CHAIMS demonstration for evaluation
June 1998
CHAIMS
50
Integration Science
Databases
access
storage
algebras
Systems
Engineering
analysis
documentation
costing
Integration
Science
Artificial
Intelligence
knowledge mgmt
models
uncertainty
CHAIMS
June 1998
CHAIMS
52
Backup slides
June 1998
CHAIMS
53
Composition of Processes...
• versus composition and integration of Data
» data-warehouses
» wrapping data available on web
• versus composition of Components
» reusing small components via copy/paste or shared
libraries locally installed
» large distributed components within same “domain” as
composition, e.g. within one bank or airline
CHAIMS:
» processed information
» composing autonomous execution threads
June 1998
CHAIMS
54
Summary
• CHAIMS requires rethinking of many common
assumptions
– gain understanding via simple examples
• Work focused on CALL statement decomposition
– to accomplish integration of large services
– exploit inherent asynchrony
• First version of architecture and language drafts are
completed; basic infrastructure partially available
(compiler, wrapper templates).
• More demos will come soon.
Half-way through a four year project.
 http://www-db.stanford.edu/CHAIMS
June 1998
CHAIMS
55
CHAIMS proves that...
• We can do composition in a high-level language.
» same language for Java-RMI-invocations and CORBAinvocations (and DCE, DCOM, TCP/IP protocols)
» (single megaprogram can deal with multiple protocols
simultaniously)
» multiple megamodules can run in parallel
• Large-scale composition can be automated.
» in contrast to manual non-software composition (e.g. telephone,
cut&paste)
» in contrast to fixed programs for one specific problem (e.g.
transporting military goods within US)
• We can do schedulings of programs in a way right now
only smart logistics officers can do, avoiding
unnecessary waits.
» Scheduling of invocations can be optimized.
June 1998
CHAIMS
56
Long-term Objectives of CHAIMS
1 Implementing a system for a simple and purely
compositional language hiding differences of diverse
protocols
2 Automatic optimized scheduling of invocations (taking
advantage of inherent parallelism and estimatecapabilities of megamodules, hence splitting up of
CALL-statement)
3 Decision-making support (direct) interaction with
megamodules, based on overview and incremental
results (fixed flow, not yet interactive changes to
megaprogram)
4 Automatic dataflow optimization (direct dataflows
between megamodules), not yet
June 1998
CHAIMS
57
Assumptions, Additional Constraints
• Heterogenous legacy modules ==> wrapping of modules, mixing
protocols on client side or in wrappers.
• Parallelism of megamodule-methods not through multithreading on
client side but through splitting up CALL-statement (==> sequential
program on client side); this leads to useful parallelism because we deal
with coarse-grain parallelism.
• CHAIMS-compliancy for megamodules is achieved by wrappertemplates, for new native megamodules as well as for legacy ones
(CHAIMS-compliancy is more than just knowing CHAIMS-protocol!).
• No reliance on existence of one specific higher level protocol like
CORBA, DCOM, RMI ==> implementing an independent data-encoding
and marshalling with ASN.1, instead of using one of them and then
having converters in the wrappers.
• Interfaces of megamodules match <==> no investigation into opaque
datablobs on client side necessary.
• Thin client, client should be able to run anywhere (not quite fulfilled right
now - we need local ORB, DCE, JavaVirtual-machine).
• Clear seperation client - server, minimal repository.
June 1998
CHAIMS
58
Non- (not yet)-Objectives of CHAIMS
• No commercial product.
• No specific controls over ilities (security, nameserving, etc.) that they are normally present in
distributed systems.
• No sophisticated front-end, no graphical
programming/composition, no browser for repository,
no higher-level language as input (not yet).
• Not solving all problems of megamodule composition
that are mentioned in the various CHAIMS-papers (e.g.
differing ontologies, non-matching interfaces of
megamodules), only the ones mentioned in objectives
and additional conditions.
June 1998
CHAIMS
59
Short-term Objectives of CHAIMS
Rest of 1998:
» Basic infrastructure (fixing most severe flaws, moving to consistent
architecture, all primitives, types, associative lists with handling it,
having CORBA) ==> conceptual and implementation work -CONSOLIDATION
» More examples (descriptions of scenarios as well as implemented
demos), wrapping one (maybe two) additional suites of megamodules.
==> implementation work -- CONSOLIDATION
» Mixing of protocols in client (CORBA, RMI) or/and TCP/IP-three-tier
architecture
» Preparing for more capable scheduler (examples with current
scheduler, reading about other scheduler-problems and
implementations, redesigning architecture of compiler (interpreter?),
designing scheduler algorithm and architecture, writing paper about all
this…) ==> lots of conceptual work, some implementation -- looking
ahead for better Scheduler
1999 (depending on where we are at the end of 1998):
» Scheduler
June 1998
CHAIMS
60
Upcoming Changes to Architecture:
Other Approach to Heterogeneity
client
site
Client (megaprogram)
TCP/IP sockets
CHAIMS protocol
sites of servers
different
wrapper site
June 1998
RMI
wrapper
CORBA
wrapper
RMI
wrapper
CORBA
RMI
server-specific protocols
native
server
1
native
server
2
native
server
3
CHAIMS
chaims
compliant
module
chaims
I/O
module
61
Reasons for an Alternative Architecture
Overall:
• Simpler architecture: fewer wrappers, just one protocol on client side
Server-side:
• No direct linking with legacy code also for CORBA-wrappers, different sites for
wrapper and legacy megamodule possible
• All native CHAIMS-megamodules will be built using wrapper templates ==> no reason
for several protocols, they can all use TCP/IP.
• Dataflow-optimization: direct messages between megamodules/their wrappers
necessary (without bridges)
Client-side:
• Thin client that could run everywhere (TCP/IP is available everywhere, but not CORBA
or DCE, RMI also is easily available everywhere).
• CSRT could be implemented by interpreter instead of compiler, maybe also possible
with current architecture, but more complex.
• We use just transport-facility (really true? what about native CHAIMS-types like string,
integer, boolean?) of CORBA, RMI, DCE (for data we have ASN.1); this is already
offered by TCP/IP ==> no unnecessary overkill
Drawback: missing one of the current funding objectives (heterogeinity on client side).
June 1998
CHAIMS
62