Dynamic Typing in CORBA Middleware

1. Dynamic Typing in CORBA Middleware Jeff Parsons ISIS Vanderbilt University Nashville, TN

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

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

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

5. Dynamic CORBA Features

6. Type Code union foo switch (char) { case ‘a’: long num; case ‘b’: string str; }; struct bar { string<12> str_mem; foo u_mem; boolean b_mem; }; • Structural representation • Basic TCs in ORB • New TCs from IDL compiler or type code factory

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

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

9. 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: AbstractFactory pattern and separate library.

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

11. Managing the Interface Repository • Problem: Providing a systematic way to manage the repository’s contents. • Forces: • Load from IDL files. • Reuse IDL compiler’s parsing and error checking. • IDL compiler is built monolithically. • Solution: Modularize the IDL compiler. • Reusable front end. • Pluggable back end. • Top-level executable.

12. Dynamic CORBA - Putting It All Together

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