COM, RMI, and CORBA: Object Systems Compared

1. COM, RMI, and CORBA: Object Systems Compared Mark RylandSenior Technical EvangelistMicrosoft Developer Relations Group

2. What are they? • COM/ActiveX: binary/packaging/net standards for multivendor component interconnection • Small, local objects and big, remote ones • Customizable remoting, naming, etc. • Java/RMI: language/packaging/remoting technology for deploying network components • CORBA: source-level/semantic/net protocol standards for network components • Strong trend is to use Java to make up for lack of multi-vendor code packaging, deployment solution

3. Why use them? • COM: great for building extensible clients, servers • Primary value is in local, multi-language components; binary standard • Also, DCOM is great for hooking them up, but use HTTP or sockets (explicit remoting) if you prefer • Java/RMI: nice language, packaging/ deployment technology, extended to net • Analogous to COM/DCOM, Java is key, RMI is icing • CORBA: nice networking toolkit technology • No benefit for local components, no “library OA,” no binary standards; competes with HTML/HTTP

4. Simplicity of COM local model • COM’s simplicity and power have resulted in its use in entirely non-Microsoft realms • Flux OS toolkit at the University of Utah is built entirely around the COM abstraction • http://www.cs.utah.edu/projects/flux/oskit/html • Document Management Alliance (DMA) standard of AIIM is a cross-platform, multi-vendor “API” based on COM • http://www.aiim.org/dma

5. Components and networking • Initial conclusions: • CORBA competes head-to-head with HTTP/HTML (bad) • Java most useful as a local programming language (COM, CORBA, and RMI can all be used for remoting)

6. CORBA: beware • Name of generic, LCD “standard” • CORBA is to ORBs as POSIX is to UNIX • Perhaps closer to ISO seven-layer networking model; a common way to reason about very different things • ORBs differentiate with “value-added” proprietary features • Moreover, CORBA is a loosey-goosey “standard” • Vendors leave unspecified key, controversial issues • Therefore, beware discussions of “CORBA” • Real issue is what specific ORBs do

7. Basic models: object/interface • COM: multiple interfaces • One distinguished IUnknown (may also be substantive) • One “default” interface for script clients • Java/RMI: multiple interfaces • One “extends”, N “implements” per class • CORBA: no distinction • Object equated with interface • But: active RFP on topic, multiple interfaces per object likely to be added soon

8. Basic models ... • COM: • Single interface inheritance (plus multi interfaces) • No implementation inheritance, only blackbox reuse • (But COM can be used to build inheritance systems) • “Aggregation” re-use: compound objects • Objects conspire to appear as one • A small optimization over delegation • Lifetime managed by reference counting at binary level with Addref/Release • Language runtimes hide from app programmers • Works great over network (highly optimized); on by default but optional (turn off per-object with one call)

9. Basic models ... • Java/RMI: • Unlike COM and CORBA, single language only (should be obvious!) • Single interfaceandimplementation inheritance (plus multiple interfaces per class/object) • Blackbox and whitebox (inheritance) code reuse • Lifetime managed by language runtime (VM) via garbage collection • GC works over the network with RMI

10. Basic models ... • CORBA: • Multiple interface inheritance; key to polymorphism • One interface per object (that may change soon) • No implementation inheritance in CORBA model • Implementation inheritance not precluded but seldom supplied by ORBs (none of leading ORBs has it) • Arguably SOM/DSOM from IBM; but no inheritance in DSOM and SOM is not CORBA-compliant! • No distributed GC capability; left to the app! (bad) • Some ORBs (e.g., Orbix) use TCP keepalives and callbacks -- inefficient and proprietary

11. Transparency • “Transparency” refers to distinct or integrated local/remote programming models • COM: largely transparent • Clients can be aware of, control location at creation • In-proc, cross-process same machine, or remote • Or not (CLSCTX_SERVER) • At runtime clients can distinguish between in-, out-of-proc servers (QI for IClientSecurity, for example) • Same for servers (CoGetCallContext) • Client must always be prepared for more complex errors associated with non-local servers

12. Transparency ... • Java/RMI: non-transparent; explicit proxy model • Local and remote objects semantically distinct (inherit from RemoteObject, support Remote interface, throw RemoteExceptions) • Existing Java objects can’t be called remotely • CORBA: transparent in theory • However, no significant ORB has “library object adaptor” (or “in-proc servers” in COM parlance) • Arguably SOM/DSOM, but it is only CORBA-compliant for DSOM and there has an explicit proxy model! • CORBA: basically a remote-only model

13. Dynamic invocation • COM: optional feature for both clients and servers • Servers can use a mostly free system-provided implementation; will get easier • Type info (typelibs) optional (adds performance) • No DSI equivalent today (nice feature for future) • Java/RMI: makes no sense in language • CORBA: optional feature for clients • Servers normally implement statically, get DII free • Type info (interface repository) required • Dynamic Skeleton Interface (DSI) allows converse: any client calls dynamic servers (added for gateways)

14. Runtime typing/typecasting • Crucial for robust components • COM: IUnknown::QueryInterface() • Select on GUID (no type/capability collisions) • Can be “conversational” only; need not return an new interface pointer • Java/RMI: Object::instanceof() • RMI augments Java typing w/ UUID, hash of signature • CORBA: Object::is_a() • Select on RepID, theoretically a GUID but RepIDs not required (many ORBs lack IRs); often just fully-qualified interface name (problem!)

15. Datatypes • COM: de facto multiple levels for different languages (scripting, Automation, COM) • Reflects historical COM languages • Realistic but often annoying or worse • Java/RMI: language defines types • Simple primitive types, objects for constructed types • Homogenous “language bindings” so no issue • CORBA: unified set of moderate complexity, flexibility • All languages must map all types, easy and hard

16. Marshaled object references • COM: normally pass-by-reference • However, custom object marshaling (objects with IMarshal) allows any dynamic runtime behavior • Typically used for pass-by-value objects, but can do anything (reference passed as CLSID and buffer) • Will make automatic (declarative) for Java in future • Java/RMI: remote objects passed by reference; non-remote objects passed by value (copied) • CORBA: pass-by-reference only today • Scrambling to add pass-by-value to promote Java/RMI interop

17. Dynamic marshaling code • COM: proxies/stubs are dynamically loaded COM objects (one aggregated object per interface)! • MIDL compiler generates them automatically, but they can be written to the COM binary standard • Not just an implementation detail: allows custom marshaling and other features • Java/RMI: all stub/skeleton code is dynamic Java code • CORBA: non-Java ORBs statically link stub/ skeleton code to clients, servers • Implementation, not in model; some ORB could fix

18. Language issues • COM: no official “language bindings” • Allows tools vendors to innovate, make COM easy • But no portability across same-language tools • Current problem of non-unified datatypes for different languages (plan to improve, but may never eliminate) • Java/RMI: everything is perfect :-) • CORBA: official language bindings • Portability across vendors for given language • All languages stuck with all APIs, tremendous complexity (modulo proprietary extensions!)

19. Threading • COM: rich threading models • Components run in single- or multi-threaded fashion • Callbacks even for single-threaded components • Full interop even within same address space (apts) • Even better in future with “hotel threading” • Java/RMI: free-threaded language • Programmer must deal with concurrency issues • Many classes synchronize (deadlock issues) • CORBA: undefined • Most ORBs offer single-threaded processing (no callbacks, watch for deadlocks!), some offer free-threading too (sometimes for extra $$$!)

20. Security • COM: security built-in for all cross-UID interactions • Security system abstracted via GSS-like API (SSPI) • Windows includes NTLM security provider; others coming (SSL soon, NT Kerberos, DCE, etc.) • System ACLs on launching, method-calling within a process; impersonation for app-defined access • Message integrity, encryption built-in • Can be set dynamically per call, a property of the COM proxy; multiple proxies for same object possible with different security settings (CoCopyProxy) • Even works single machine if locally secure like NT

21. Security … • Java/RMI: punts! • “The intention of the design of RMI is to make as many of the security concerns as possible outside the scope of RMI.” • Wow! I wish we could do that… • “The idea was to make issues of communication privacy live in levels below the basic RMI functionality, and make issues of authentication and access control (or capabilities, if that is your favored flavor of security) live above the level of RMI.” -- Jim Waldo, JavaSoft, email sent to RMI list 1/9/97 • Amazing!

22. Security ... • CORBA: generally not there yet • No major ORB vendors shipping built-in security today: Amazing! • Orbix has callouts for hand-crafting by app developers • SecIIOP “standard” available, includes 3 profiles and Kerberos, products coming soon • Most vendors will be at level 1 for awhile, very minimal • Good luck with interop for years to come (loose yet complex “standard”) • IIOP/SSL also coming, not integrated with SecIIOP (AFAIK)

23. Naming and activation • COM: two modes • Explicit instance creation and initialization by client at named location (CoCreateInstance*, IPersist*::Load) • Typically binds to same object if same persistent state • Singleton classes have one instance for all clients of a given class factory instance • Location names are DNS names, indirection possible • Implicit creation/init: IMoniker::BindToObject wraps for clients (GetObject() in VB) • Monikers allow servers to custom-name themselves • Instance naming/publication in the filesystem today • Can use URLs/HTTP for binding but more manual/ complex today that it needs to be (hint, hint)

24. Naming and activation ... • Java/RMI: very simple URL-based access to non-persistent per-machine naming “registry” • CORBA: many ORBs implement simple CORBA naming service, used for instance publication • Normally uses implicit activation (non-existant objects published in name service, first call starts them) • ORB implementations are very simple today (no replication, fault-tolerance, etc.) • Future: trading service provides rich model for instance location, binding

25. Code availability • COM/DCOM: • Client code needs to be locally available, COM code (e.g., proxy/stub) can be bundled and registered; or dynamically installed; or in separately installed DLLs • Servers must be locally registered • Big improvements coming in next major release for auto-installation of COM code on demand • Java/RMI: can auto-download Java classes from configured server • CORBA: varies among ORBs, but basically similar to COM; some local installation needed

26. Networking implementation • COM: built on DCE RPC protocol • Multiple net transports (TCP/UDP, IPX/SPX, etc.) • CN and DG; many possible efficiencies from DG/UDP but Win95 DCOM presently supports only CN/TCP • Java/RMI: built on Java transport class • Built-in class uses TCP; scaling? • Theoretically replaceable, but not yet documented • CORBA: GIOP (definition of CN RPC except transport) and IIOP (TCP-based transport) • Clean and simple, but scaling?

27. Performance • Important issue but no hard numbers available • COM: in-proc extremely fast; cross-network very speedy • Java/RMI: reputed to be fairly slow, esp. with large serializations • CORBA: varies considerably from ORB to ORB, but best are quite fast (same as DCOM) • But this is all method call speed; real issue is scalability of servers with large numbers of clients and lots of work to do

28. Scalability (background) • Object purists have long had idea that software objects should represent real-world objects • The “invoice object”; the “debit object”; etc. • Problem: it doesn’t work! • Business applications have millions of “objects” (typically rows in a database); you don’t want code running for these • Plus, need fail-safe technology, robust durable storage (database) • Solution: wrap DB access with transactional objects; transient, carefully-managed state

29. Scalability (transactions) • COM: Microsoft Transaction Server (MTS) is an integrated TP monitor (bundled with NT Server) • Used for billion transaction per day demo • Major customer applications now in production (DCOM or HTTP to server) • IIS 4.0: MTS integrated to create first transactional web server (scripts in .asp files can use all COM objects transactionally) • Full Wolfpack clustering support this calendar year • Future: dynamic load balancing, parameterized call routing, etc.; even tighter COM/MTS integration

30. Scalability (transactions) ... • Java/RMI: <no comment> • Vague promise of future transactions using OTS wrapped under “Enterprise JavaBeans” • If OTS, then not Java/WORA (plus problems below) • Don’t hold your breath! • CORBA Object Transaction Service: lame • Not yet shipping in final form from any vendor • Implementations are glommed on top of Tuxedo • Guaranteed non-interoperable between vendors • Unlike TP monitors, explicit, complex programming model (equivalent of MS DTC, not MTS)

31. Scalability (messaging) • RPC semantics embedded in ORBs and RMI • Requires connection between client and server! • Big limit on usefulness of these systems (including DCOM today) • Need to program messaging systems as objects (explicit model) • Need method invocations on disconnected objects (implicit model)

32. Scalability (messaging) ... • COM: full object programmability of Microsoft MQ (available this year in NTS) • Explicit queuing via messaging objects • Transactional messaging via DTC integration! • Future: pervasive async calling model for COM will allow seamless Falcon transport integration • Java: vague promise in “Enterprise JavaBeans” • Anecdote from JavaOne (I can’t resist) • CORBA: RFP issued, still endless arguing, no products anywhere in sight

33. Cost • COM: free on Windows (part of OS), nearly free on non-Windows platforms • Bundled/free soon on HP-UX, Digital UNIX, VMS • Java/RMI: free, free, free • Cross-subsized by Sparc servers, presumably • CORBA: varies considerably • IONA charges hefty SDK ($1000-5000 per seat) and per-copy runtime fees ($50-100) • Visigenics’ strategy: give away low-end ORB via bundling (Netscape, etc.), charge for scalable server services (OTS, etc.)

34. Platforms • COM: Windows 95 and Windows NT retail; plus beta of Solaris, Digital UNIX, Linux; plus HP-UX and MVS OE soon; plus Java DCOM runtime • Java/RMI: many (although VM compatibility is a serious issue) • “CORBA”: leading ORBs available on many platforms; multi-vendor interop demos ok but not yet fully tested nor relied upon • CORBA experts (e.g., John Berry) tell customers it’s crazy to mix/match ORBs in a single enterprise

35. How much do platforms matter? • Uptake of DCOM is huge despite platform limitations (only Windows shipping) -- why? • Most business applications will use new object-style networking only from 1st to 2d tier • 3rd tier normally wrapped with objects in 2d tier • E.g., Microsoft Cedar (xactional LU 6.2 CICS/IMS session wrapped in a schema-generated MTS object) • E.g., Oracle/XA xactional ODBC driver; allows implicit 2PC from MTS objects to databases on any platform • Platform support matters, but not as much as one might think

36. Upcoming COM features • Continually improving Java integration • MSJVM 2.0 (in beta 2): • Automatic generation of type libraries from .class file • Java moniker (bind to any Java class directly) • System surrogate in DCOM for process creation for Java classes in cross-process or cross-net case • Much more to come • HTTP transport for ORPC • SSL/PCT security integration • Both coming fairly soon (Fall ‘97)

37. Upcoming features … • Network-based object location services, object registry • Tighter language integration and support • Asynchronous calling; disconnected calling via store-and-forward transports (Falcon) • Automatic transaction propagation; auto delegation/“inheritance”; runtime garbage collection; distributed multi-language debugging

38. RMI + CORBA: happy marriage? • RMI semantics are not/are expressible with IIOP • Huge insane debate even regarding existing IIOP • The answer is: are not • Success of Java dog and RMI tail posed major threat to CORBA cartel • ORB vendors trying to coopt Java as local component model and ubiquitous client/code deployment solution, huge holes in CORBA • JavaSoft dragged kicking and screaming into political détente between Sun and CORBA cartel

39. RMI + CORBA: are we happy yet? • Sun/JavaSoft/OMG recently announced “merger” of RMI/CORBA technology, with totally opposing “spins”: • Sun/JavaSoft: • RMI is the programming model for distributed computing • Subset of RMI will be defined for talking to legacy CORBA apps over IIOP • Future improved IIOP will increase supported subset to some unspecified but less than 100% level of RMI support (but only for interop) • CORBA vendors: RMI was a proprietary deadend, now officially dead; IIOP rules! (e.g., Annrai O’Toole, CTO, IONA) • RMI: Recently Made Irrelevant • Customers: huh????

40. COM interop with CORBA ORBs • Interoperability and co-existence happening • OMG standards for basic approach • All significant ORBs have COM integration as a high feature priority • Major ORB/OS vendors licensing, bundling COM (H-P, Digital) • H-P OMG proposal: ORPC as universal transport (much richer semantics than GIOP) • Some model convergence happening • CORBA: multiple interfaces per object; naming interfaces/types via UUIDs (aka Repository IDs)

41. ORB Market Changing Rapidly • Marketing magic of “CORBA” as a monolithic [non]reality beginning to wear off • Threat of RMI (temporarily?) headed off, but… • ORB products naturally diverge, “add value,” compete • CORBAservices have largely been total disasters, now being “sunsetted” • Huge challenge ahead: interop of security and transaction systems • Major shakeout ahead in both products, specs with (eventual) introduction of compliance testing • Or, Netscape/Oracle/Novell bundling of Visigenics may redefine market -- a de facto implementation standard!

42. COM resources • Great overview book • Understanding ActiveX and OLE (by David Chappell) • Implementations • Win95 COM upgrade including DCOM • <http://www.microsoft.com/oledev/> • Solaris and other non-Win32 versions • <http://www.sagus.com/> • Technical info • <http://www.microsoft.com/workshop/; /oledev/; /transactions/; /java/; /msdn/> • Inside COM (by Dale Rogerson) • Mailing lists • http://www.microsoft.com/workshop/resources/email.htm

43. Questions?