1. CHAIMS: Mega-Programming Research
Compiling High-level Access
Interfaces for Multi-site Software
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

2. Participants Support DARPA ISO EDCS program (1996-1999)
Siemens Corporate Research ( )
DoD AFOSR AASERT student support ( )
Sloan Foundation - computer industry study ( )
People
Gio Wiederhold (Prof. Res) PI Marianne Siroker (Administration)
Dorothea Beringer (postdoc EPF Lausanne) since Dec.1997
Ron Burback (CS PhD cand.) Neil Sample (CS PhD Student)
Laurence Melloul (CS MS) 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

3. Gio Wiederhold: Personal Background
1936 born Varese, Italy
1957: Learned programming at NATO SHAPE ADTC
Programmer and software engineer
at IBM, UC, Stanford, Index, MaSCOR
now Consultant for government, Industry
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

4. 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

5. 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

6. Shift in Programming Tasks
Integration
Coding
June 1998
CHAIMS 2

7. 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
distribution -- exploit network capabilities
heterogeneity -- autonomy creates heterogneity
simple schemas -- some human interpretation
service model -- public and commercial sources
June 1998
CHAIMS

8. 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

9. Scaling alternatives ?
June 1998
CHAIMS

10. CHAIMS Megamodules C H A I M S
Megaprogram for composition, written by domain programmer
CHAIMS system automates generation of client for distributed system
CHAIMS
Megamodules, provided by various megamodule providers
Megamodules
June 1998
CHAIMS

11. 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

12. Challenge: Fat Clients
Domain expert
Client computer
I/O
I/O
Control &
Computation
Services c e a b d
Wrappers to resolve
differences
Data
Resources
June 1998
CHAIMS

13. Challenge: Thin Clients
Domain expert
Client workstation
IO module
IO module C
Computation
Services e b
MEGA modules a d T S c U T
Sites R
Data
Resources
June 1998
CHAIMS

14. 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

15. 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

16. 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

17. CHAIMS “Logical” Architecture
Customer
Megaprogram
clients
(in CHAIMS)
Network/Transport
(DCE, CORBA,...)
Megamodules
(Wrapped or Native)
June 1998
CHAIMS

18. 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

19. Decomposing CALL statements
progress in
scale of
computing
Copying
Code sharing
Parameterized computation
Objects with overloaded method names
Remote procedure calls to distributed modules
Constrained (black box) access to encapsulated data
CALL gained
functionality
CHAIMS
decomposes
CALL
functions
Setup
Estimate
Invoke
Examine
Extract
June 1998
CHAIMS 5

20. CHAIMS Primitives Pre-invocation: Invocation and result gathering:
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: Utility:
WHILE, IF GETPARAM: get default parameters
June 1998
CHAIMS

21. Megaprogram Example: Overview
InputOutput
- Input
- Output
General I/O-megamodule
Input function takes as parameter a default data structure containing names, types and default values for expected input
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
RouteInfo
- AllRoutes
- CityPairList
- ...
AirGround
- CostForGround
- CostForAir
- ...
Routing
- BestRoute
- ...
RouteOptimizer
- Optimum
- ...
June 1998
CHAIMS

22. Megaprogram Example: Code
io_mmh = SETUP ("InputOutput")
route_mmh = SETUP ("RouteInfo")
...
best2_mmh.SETATTRIBUTES (criterion = "cost")
cities_default = route_mmh.GETPARAM(Pair_of_Cities)
input_cities_ih = io_mmh.INVOKE ("input”, cities_default)
WHILE (input_cities_ih.EXAMINE() != DONE) {}
cities = input_cities_ih.EXTRACT()
route_ih = route_mmh.INVOKE ("AllRoutes", Pair_of_Cities = cities)
WHILE (route_ih.EXAMINE() != DONE) {}
routes = route_ih.EXTRACT() …
IF (best1_mmh.ESTIMATE("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,
best2_mmh.TERMINATE()
// Setup connections to megamodules.
// Set global variables valid for all invocations
// of this client.
// Get information from the megaprogram user
// about the goods to be transported and about
// the two desired cities.
// Get all routes between the two cities.
//Get all city pairs in these routes.
//Calculate the costs of all the routes.
// Figure out the optimal megamodule for
// picking the best route.
//Pick the best route and display the result.
// Terminate all invocations
June 1998
CHAIMS

23. Operation of one Megamodule
SETUP
SETATTRIBUTES provides context
ESTIMATE serves scheduling
INVOKE initiates remote computation
EXAMINE checks for completion
EXTRACT obtains results
TERMINATE I / ALL
M handle
M handle
M handle
M handle
I handle
I handle
I handle
I handle
M handle
June 1998
CHAIMS

24. CHAIMS Megaprogr. Language
Purely compositional:
no primitives for arithmetic ==> math megamodules
no primitives for input/output ==> general and problem-specific 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

25. Architecture: Runtimeb d e
CSRT (compiled megaprogram) a c
MEGA modules
Distribution System (CORBA, RMI…)
June 1998
CHAIMS

26. Architecture: Composition Process
Megamodule
Provider
wraps non-CHAIMS
compliant megamodules
adds information to
Wrapper
Templates
CHAIMS
Repository b d e e a
MEGA modules c
June 1998
CHAIMS

27. Architecture: Composition Process
Megaprogrammer
writes
information
Megaprogram
(in CHAIMS language)
CHAIMS
Repository
information
CHAIMS
Compiler
generates
CSRT (compiled megaprogram)
June 1998
CHAIMS

28. Architecture: Overview
Megamodule
Provider
Megaprogrammer
wraps non-CHAIMS
compliant megamodules
writes
adds information to
information
Wrapper
Templates
Megaprogram
(in CHAIMS language)
CHAIMS
Repository
information
CHAIMS
Compiler b
generates d e
CSRT (compiled megaprogram) a c
MEGA modules
Distribution System (CORBA, RMI…)
June 1998
CHAIMS

29. Architecture: CHAIMS-Language and CHAIMS-Protocols
Megaprogrammer
CHAIMS API defines interface between megaprogrammer and megaprogram; the megaprogram is written in the CHAIMS language.
CHAIMS-language
Megaprogram
The CHAIMS protocols define the calls the mega-modules 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.
CHAIMS-protocols
CORBA-idl
DCE-idl
Java-class
M e g a m o d u l e s
June 1998
CHAIMS

30. 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
Personal Data
complex
Address
First Name
string
Joe
Last Name
string
Smith
Date of Birth
date
6/21/54
Soc.Sec.No
string
June 1998
CHAIMS

31. 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

32. Architecture: Three Views
Composition View
(megaprogram)
- composition of
megamodules
- directing of opaque
data blobs
Data View
- exchange of data
- interpretation of
data
- in/between
megamodules
CHAIMS Layer
Transport View
moving around data blobs
and CHAIMS messages
Distribution Layer
Objective: Clear separation between composition of services, computation of data, and transport
June 1998
CHAIMS

33. Scheduler: Decomposed Execution
time
time
time
s,i
s,i i e e e
synchronous
asynchronous
decomposed
(no benefit for one module)
execution of a remote method
invoke a method i e
extract results
setup / set attributes s
available for other methods
June 1998
CHAIMS

34. Optimized Execution of Modules
(>M1+M2) i2 M1 M4
(<M1+M2) M2 e1 i2 M2 e2
time e4 i3 e3 M3 e2
time i5 M5 e5 e3
optimized by scheduler
according to estimates i4 M4 e4
data dependencies i5 M5 e5
execution of a module
invoke a method i
non-optimized e
extract results
June 1998
CHAIMS

35. Decomposed Parallel Execution
time M4
(<M1+M2) M3
<M1+M2)
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. M2 M5
set up / set attributes
optimized by scheduler
according to estimates
invoke a method
extract results
June 1998
CHAIMS

36. Decomposed Optimized Execution
(<M1+M2) M5 M2 M3
(>M1+M2)
time
prior time M3
(>M1+M2) M1 M4
(<M1+M2) M2 M5
set up / set attributes
optimized by scheduler
according to estimates
invoke a method
extract results
June 1998
CHAIMS

37. Repeated invocations optimized by scheduler set up / set attributes
(<M1+M2) M5 M2 M3
(>M1+M2)
time
prior time M3
(>M1+M2) M1 M4
(<M1+M2) M2 M5
set up / set attributes
optimized by scheduler
according to estimates
invoke a method
extract results
June 1998
CHAIMS

38. Repeated Extractions optimized by scheduler set up / set attributes
(<M1+M2) M5 M2 M3
(>M1+M2)
time
prior time M3
(>M1+M2) M1 M4
(<M1+M2) M2 M5
set up / set attributes
optimized by scheduler
according to estimates
invoke a method
extract results
June 1998
CHAIMS

39. 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) {} 3
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) {} 4
cost_list_air = cost_air_ih.EXTRACT()
order in
unscheduled
megaprogram
order in automatically
prescheduled megaprogram
June 1998
CHAIMS

40. 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 cost-function (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

41. Compiling into a Network
Mega Program
Module A
Module B
Module C
Module E
Module D
Module F
current CHAIMS system
control flow
data flow
with distribution dataflow optimization
Mega Program
Module A
Module B
Module C
Module E
Module D
Module F
June 1998
CHAIMS 6

42. 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

43. 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

44. 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

45. Upcoming Changes to Architecture: PreCompiler + Interpreter
CHAIMS compiler,
simple scheduler
user
megaprogram
in CHAIMS language
client code in
C, C++, Java,
stub code
Idl-file generator
and compiler
executable
client (CSRT)
C++, Java
compiler
and linker
network
Interpreter:
user
CHAIMS execution
machine
(interpreter and
scheduler)
complete megaprogram
in CHAIMS language
serves as input to
CHAIMS-protocol
user
some CHAIMS
statements
serve as input to
network
June 1998
CHAIMS

46. 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

47. 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?
June 1998
CHAIMS

48. 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

49. 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
IP protection?
keeping SW updated
billing for est.value
performance effect
poor
some
fair
good ok
simple
awkw.
hard no
little
Buy
Lease
Limit
Use
protect
update
bill
perform
June 1998
CHAIMS 8

50. 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

51. Integration Science Artificial Intelligence knowledge mgmt models
uncertainty
Databases
access
storage
algebras
Systems
Engineering
analysis
documentation
costing
Integration
Science

52. June 1998
CHAIMS

53. Backup slides
June 1998
CHAIMS

54. 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

55. Summary Þ http://www-db.stanford.edu/CHAIMS
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. Þ
June 1998
CHAIMS

56. CHAIMS proves that... We can do composition in a high-level language.
same language for Java-RMI-invocations and CORBA-invocations (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

57. 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 estimate-capabilities 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

58. 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 wrapper-templates, 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

59. Non- (not yet)-Objectives of CHAIMS
No commercial product.
No specific controls over ilities (security, name-serving, 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

60. 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

61. Upcoming Changes to Architecture: Other Approach to Heterogeneity
client
site
Client (megaprogram)
TCP/IP sockets
CHAIMS protocol
different
wrapper site
RMI
wrapper
CORBA
wrapper
RMI
wrapper
sites of servers
CORBA
RMI
server-specific protocols
native
server 1
native
server 2
native
server 3
chaims
compliant
module
chaims
I/O
module
June 1998
CHAIMS

62. 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