Dynamic Typing in CORBA Middleware

1
Dynamic Typing in CORBA Middleware

• Jeff Parsons
• Center for Distributed Object Computing
• http//www.cs.wustl.edu/doc/
• Department of Computer Science
• Washington University, St. Louis, MO

2
Emerging Trends

• Simple Connection
• Sockets
• Client/Server
• Object Model
• Enterprise Application Mobile
  Wireless
• Component Model

3
Presentation Overview

• Static vs. Dynamic Typing in Middleware

• Challenges

• Dynamic CORBA Basics/Previous Work

• New Dynamic CORBA Features in TAO

• Evaluation/Lessons Learned

• Future Work

• Concluding Remarks

4
Static Typing

• All operation names and signatures known at
  compile time.
• Advantages
• Efficient marshaling.
• Streamlined invocation.
• Disadvantages
• Larger generated code footprint.
• Inflexible.
• Unacceptable in open-ended systems.

5
Dynamic Typing

• Discovery of operation names and parameter types
  at runtime.
• Advantages
• Smaller generated code footprint.
• Flexible open-ended.
• Disadvantages
• Larger ORB footprint.
• Slower marshaling.
• Pre- and post-invocation overhead.

6
Challenges

• Devise efficient, persistent, and dynamic storage
  techniques for IDL type descriptions.

• Minimize the increase in ORB footprint associated
  with CORBA dynamic typing capabilities.

• Dont incur extra time/space overhead for
  applications that dont use dynamic typing.

7
Dynamic CORBA Features
8
TAO Dynamic CORBA Timeline
9
Type Code

• union foo switch (char)
• case a long num
• case b string str
• struct bar
• stringlt12gt str_mem
• foo u_mem
• boolean b_mem
• Structural representation
• Basic TCs in ORB
• New TCs from IDL compiler or type code factory

10
Any, NamedValue, NVList

• Any
• Represents generic IDL value
• Type code describes value
• Value is opaque
• Overloaded insertion extraction operators
• Basic types in ORB
• New types from IDL compiler
• NamedValue
• Represents operation argument
• Any name direction
• NVList
• Represents operation signature
• List of NamedValues

11
Dynamic Invocation Interface (DII)

• Used when IDL compiler generated code is not
  available.
• A request object is created by a local call on
  the target object reference.
• Dynamic Skeleton Interface (DSI) is the
  server-side counterpart to DII.

12
Static vs. Dynamic Invocation

• The request object must be incrementally composed
  and explicitly invoked.
• The ORB marshals its contents interpretively (by
  traversing the Anys Type Code structures).
• This extra overhead slows performance.
• Never by more than an order of magnitude.
• Difference decreases with payload size.

13
Type Code Factory

• Problem Creating a TypeCode at run-time.
• Forces
• Family of related TypeCodes.
• Optional use by application.
• Necessary to Interface Repository.
• Avoid penalty to static application.
• Solution Abstract Factory pattern and separate
  library.

14
Dynamic Any

• Problem Assigning examining an Any value
  without the generated operators.
• Forces
• Need incremental (de)composition.
• Optional use by application.
• Need consistent, portable API.
• Solution Composite, and Façade patterns,
  separate library.
• Refactoring inheritance stucture reduced overall
  library size by 40.

15
Adding Locality Constraints

• Local IDL interfaces
• Operations cannot be accessed remotely.
• No skeleton code is generated.
• Stub operations are pure virtual.
• Implementation inherits directly from stub.
• Applied to Dynamic Any and TypeCodeFactory.
• Large reduction in generated code size.

16
The Interface Repository (IFR)

• Problem Providing run-time IDL type information.
• Forces
• Need persistent storage.
• Need OO database - query results are CORBA
  objects.
• Must preserve nested (scoped) structure.
• Solution
• View entries as meta-objects.
• Use the Memento pattern to capture their state.
• Use tree of hash tables for underlying storage.
• Create query results on demand.

17
IFR Underlying Structure

• Hash tables contain
• String, integer, binary values
• More hash tables
• All external IDs are strings
• Root of IFR has 3 main subsections.
• Anonymous IDL types
• Primitive types
• Strings, wide strings
• Arrays, sequences
• Named IDL types
• Named type index section

18
Interface Repository Entries

• Entry values are externalized state of Interface
  Repository Objects (IR Objects).
• IR Objects are created only on demand.
• Interoperable Object Reference (IOR) of IR Object
  contains Object ID created by the repository.
• Object ID represents tree path.
• Backslash-separated string.
• Maps IR Object to repository entry.

19
Managing the Interface Repository

• Problem Providing a systematic way to manage the
  repositorys contents.
• Forces
• Load from IDL files.
• Reuse IDL compilers parsing and error checking.
• IDL compiler is built monolithically.
• Solution Modularize the IDL compiler.
• Reusable front end.
• Pluggable back end.
• Top-level executable.

20
Dynamic CORBA - Putting It All Together
21
Evaluation of Dynamic CORBA Features

• Interdependency
• Explicit
• Implicit
• Hybrid Applications
• Need not use dynamic typing throughout.
• May use subset of features.
• Generality vs. Overhead
• Tradeoff
• Portability
• Widespread ORB vendor support.

22
Lessons Learned

• Software reuse may be achieved with or without
  design patterns.
• Use of dynamic CORBA features can be flexible and
  configurable.
• ORB footprint increase can be minimized by
  various techniques.
• ORB subsetting is an alternative to Minimum CORBA
  specification.

23
Future Work

• Performance Optimizations

- IFR operation dispatch mechanism
- Any, DII/DSI, Dynamic Any data copies

• Subsetting/Configurability

• IFR Federation

• IFR Scalability

• Dynamic CORBA Extensions

- CORBA Component Model (CCM)
- Model Integrated Computing (MIC)

• Common IDL Type Representation

24
Concluding Remarks

• Dynamic typing capabilities can be added to
  middleware without penalizing applications that
  dont use it.
• Dynamically typed middleware enables applications
  to work in domains where applications using
  statically typed middleware cannot.
• The transition to a component model for
  distributed application development is increasing
  the interest in dynamically typed middleware.

25

• THANKS!!

26

• Questions?

27
Extra slides
28
Static vs. Dynamic Typing

• Static typing
• Type rules in compiler.
• New types at development time.
• No new types at run time.
• Dynamic typing
• Type rules also implicit in source code.
• Enables new types at run time.
• Dynamic CORBA contains type rules for IDL, not
  target language.

29
IFR Client Library

• TAO CORBA services compile stub, skeleton, and
  implementation code into one library.
• Application must link to the monolithic service.
• Interface Repository splits stub code into
  separate library.
• Application can link only to stub code library.

30
Breaking Dependencies in the ORB

• Problem ORB calls methods in IFR_Client and
  TypeCodeFactory libraries.
• Forces
• Avoid circular dependence.
• Minimize additional ORB footprint.
• Dont penalize all use cases.
• Solution Adapter and Component Configurator
  patterns.
• Adapter adds only pure virtual functions to ORB.
• Also, Component Configurator parameterizes
  Adapter base class, loads library at startup time
  or later.