Now: Compiler

1
Now Compiler
Compiler
CHAIMS compiler
client code in C, C, Java, stub code
composer
megaprogram in CHAIMS language
Idl-file generator and compiler
executable client (CSRT)
C, Java compiler and linker
network
2
Compiler Drawbacks (1)

• Compiler creates CSRT that is no longer
  changeable during execution
• all exceptions and special cases must be foreseen
  (current solution no error handing at all, or
  just total abort)
• no dynamic user interaction in case of unforeseen
  errors or results, end-user/customer has to abort
  program execution, change megaprogram, recompile
  and restart it from scratch (problem in case of
  time-intensive services!!)
• no incremental programming end-user/customer has
  to write whole megaprogram upfront, no
  step-by-step composition, user could nearly as
  well give megaprogram to technical expert who
  would write it directly in Java/CORBA (strength
  of web-browsing I can decide on next step when I
  have results of previous step)

3
Compiler Drawbacks (2)

• Access to megamodules
• Current compiler cannot access megamodules
• Access to megamodules over CORBA/BOA requires for
  each new megamodule and sequence of commands a
  cycle of IDL-generation, IDL-compilation,
  compilation of CHAIMS primitives into C,
  compilation and linking of C code and stubs.
• Integration of direct access to megamodules (e.g.
  for executing CHAIMS estimate primitives)
  requires change of current compiler into a
  execution engine anyway.

4
Reasons for having a Compiler

• Each remote object/megamodule/procedure has a
  different interface
• WRONG!
• in CHAIMS we use higher level protocol/messages
  that are the same for each megamodule and
  communicate with dispatcher (in megamodule) that
  invokes the methods
• Speed
• Starting up interpreter takes some time (as it
  takes time to start up Java interpreter), and
  preparing input takes same time (yet one of the
  basic assumptions of CHAIMS are that megaprograms
  are short)
• We assume that megaprograms are made by domain
  expert for one or two runs when and as needed,
  i.e. no real savings when separate compile step
  is needed (gt run in current CompWiz)

5
Paradigm Shift

• Invoking Methods of Remote Object
• Code example in Java
• RoomReservation rr (RoomReservation)
  Naming.lookup (//sole.stanford.edu/roomres)
• rr.makeReservation(roomnr, nrpeople, date,
  starttime, endtime) // all parameters are Java
  integers or Java strings
• ltgt
• Requesting Invocations and other Information from
  Dispatcher/Megamodule
• Code example in Java (generated by CHAIMS
  compiler)
• CHAIMSCompliantObject rr (CHAIMSCompliantObject)
  Naming.lookup (//sole.stanford.edu/RRmegamodule
  )
• rr.INVOKE(makeReservation, paramlist) //
  paramlist is a list of name-value pairs,
  containing the names and // values for roomnr,
  nrpeople, date, starttime, endtime

6
Interpreter

• Interpreter
• core part is an execution engine (client engine
  as it makes up the client side run time)
• Core Client Engine also has run-time scheduling
  and optimization
• replaces CompWiz and CHAIMS Compiler

Interpreter
composer/end-user
Core Client Engine
Input Pre Processor

• whole megaprogram and maybe
• changes to a running megaprogram or
• some steps of a megaprogram at a time,
  continuing based on returned results

network
7
Interpreter Execution Graph

• Graph - mirrors megaprogram (yet easier to
  work on a graph- representation
  than on a text file) - can be built
  up all at once or step by step

Log file
Megaprogram file
or
IO mega module
GUI for interactive input and output
Errors
CLAM primitives
Errors
CLAM primitives
Interpreter
get estimates
Core Client Engine
Pre- processor
network
Input Processor
optimize
read, mark as done
add, change
Execution Graph
8
Advantages of Interpreter

• CLAM is a simple scripting language and does not
  need compiler, it is easily interpretable (in
  contrast to C, Java)
• Interpreter better matches paradigm of a fixed
  set of CHAIMS primitives with fixed set of
  parameters, sending and receiving messages
• Interactive composition becomes feasible
• Composer can react on non-foreseen errors,
  results and requirements, not just abort and
  restart (time!)
• We can really exploit the strengths of
  incremental extraction, progress monitoring and
  cost estimation by offering a real dynamic
  environment to the composer
• Optimal exploitation of parallelism becomes easy,
  trivial in case of non-conditional invocations,
  using the ESTIMATE primitive otherwise

9
Preprocessing in Interpreter

• Now
• CLAM-file gt preprocessor gt CLAM-file gt
  CHAIMS-compiler gt C-file gt C-compiler
  gt Executable ltltgtgt network (CPAM)
• In Interpreter
• CLAM-file / graphical input / single commands
  from dialog boxes gtgt Input processor in
  interpreter ltltgtgt Internal (graph)
  representation ( ltltgtgt Preprocessor in
  interpreter ltltgtgt Internal (graph)
  representation ) ltltgtgt Core Client Engine
  ltltgtgt network (CPAM)
• red files, gt one-time (batch-like) one-way
  dataflow,
• black processing ltltgtgt repeated two-way
  dataflow

10
IO

• Three different kind of input/output for
  end-user
• interaction with Interpreter (compare with
  CompWiz now)
• input megaprogram, individual CLAM statements,
  or graphical
• output error messages like megamodule
  unavailable, (breakpoints in megaprogram that
  require user-intervention?), (prompting for next
  few CLAM statements?)
• interaction with IO-megamodules (general
  IO-megamodule or additional megamodule suite
  specific IO-megamodules)
• output and input parameters of the methods of
  the IO-megamodules as specified in the CHAIMS
  repository
• monitoring of CPAM communication (compare to
  ManualInternetServiceComposition)
• output CPAM request and response messages in XML
  or text-representation of CPAM procedure calls
  inclusive parameters

11
Interpreter instead of Compiler
12
Reasons for Interpreter

• Dynamic scheduler
• Input is parsed and stored in a dependency graph.
• Execution machine (interpreter / scheduler) works
  through the graph and makes appropriate calls
• estimate-calls are added in order 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
• composer can program statement by statement
  immediate results can influence subsequent
  programming
• like ftp, web

13
(No Transcript)
14
(No Transcript)