Viewpoint on NAC’s Component-Based Application Infrastructure

1. Viewpoint on NAC’s Component-Based Application Infrastructure Mark RylandSenior Technical EvangelistMicrosoft Developer Relations Group

2. Q1: Vision • Client tier presentation • DHTML for universal client (80/20 rule) • ActiveX native code for richness • Win32, possibly Mac/UNIX • Java (test everywhere) • Dynamic selection via ASP logic (optional) • Client to mid-tier communication • HTTP 1.x for universal access • DCOM for direct client->component access • Java->DCOM servers via Java-DCOM runtime

3. Q1… • Client authentication • Intranet clients authenticated traditionally • Internet/extranet clients authenticated by PK->user/group mappings (NT5) • Middle tier(s) focus is on Windows NT • Windows NT IIS/ASP provides gateway from universal clients to components • Business logic, data access components run inside MTS on Windows NT • DCOM wire protocol; components in VB, Java, VC++ • Universal data access via ADO/OLE DB/ODBC

4. Q1… • Mid-tier backup technologies • Wrap existing UNIX code with DCOM servers, clients (or write new) via Software AG EntireX DCOM • ORB clients, servers via vendor-specific gateways • Mid-tier security (tough problem) • WinNT authentication/authorization among NT-based components • DCOM mappings to be provided in EntireX, DCE • PKI, Kerb ticket interop possible in NT5 timeframe • NT5 supports Athena wire protocol, plaintext userIDs • Good PKI working going on IETF

5. Q1… • Mid-tier security... • Zero thought given (yet) to CORBA interop given • relative non-existence of secure ORBs • too many other more important things to worry about • Fairly optimistic about authentication interop in ’98-’99 timeframe • But multi-platform authorization is a Hard Problem • Pesky things called operating systems need to do the work

6. Q1… • Data tier: No fundamental changes required; use existing databases, authentication models, and wire protocols • Obviously, deprecate stored procedure code • Data access via layered ODBC works great • DTC is RM/TM to XA and vice versa • Now supports 2PC for SQL Server (via DTC), Oracle (via XA RM support in MTS/DTC) • Informix and Sybase coming • Native OLE DB rowset providers, query processors will provide richer range of transactional datasources • E.g., OLE docfile, NT filesystem as RMs

7. Q1… • Data tier… • Mainframe IMS/CICS integration via MS “Cedar” • Schema-driven COM/MTS objects that incorporate mainframe transactions (in beta) • Don’t change code on your mainframes! • (Ssshh! A little secret: ORBs on mainframes (including DCOM) are marketing gimics—don’t bother) • Must upgrade your OS and change your development approach because most use POSIX subsystem of OS/390 (aka MVS Open Edition) • Another key piece: Just demonstrated MTS coordinating distributed SAP R/3 transactions (future technology)

8. Q1… • Last but not least, NAC’s beloved: component directories • LDAP seems like a no-brainer for components, and it is (don’t worry!) but… • Works great for some things (code availability, references to some long-lived components) but other components are stateless or more ephemeral • Directories may contain references to factory objects • Or to (as yet non-standard) referral/rendezvous services

9. Q2: Interoperation of All to All • Everything is perfect—trust me

10. Q2: Interoperation of All to All • Java: Good Java/COM integration in MS JVM • Call COM objects just like Java objects and via versa • Java exceptions mapped to IProvideErrorInfo • Bind to arbitrary Java objects via the Java moniker (GetObject(“java:/class1/class2/desiredclass”) • Many many improvements planned • RMI (you didn’t ask, but…) • Will provide declarative and programmatic pass-by-value semantics for all COM objects (can do it today with custom marshaling but complex) • No current plans to support APIs

11. Q2… • Leaving ORB interop up to ORB vendors • Not (just) because we’re big/nasty but because real demand is low; and big practical problems • MS takes interop commitments seriously -- we have labs full of Netware machines for example • No OMG test suites to guarantee interop, so we would have to provide interop on ORB-by-ORB basis • ORBs vary enormously in value-added features; easier to map COM to some than others • Even for allegedly common subset, many unspecified/underspecified aspects • Which ORBs? Orbix leads but others interesting

12. Q2… • In short, there is no practical alternative to leaving interop up to individual ORB vendors • By contrast, they have only one (popular) target; better incented than MS • Have good working relationship with ORB vendors that are Windows ISVs (IONA, etc.) • Working closely with IONA at some large mutual customer sites • Also have good working relationship with Visual Edge, licensor of COM/CORBA mapping technology to IBM, Sun, and others

13. Q3: Success Factors • Start small • E.g., great successes with MTS 3-2-1 program • Think big • Start thinking about issues (see NAC whitepaper) • Think about corporate repository of not only components but developer knowledge • Don’t be ashamed of scripting (in ASP or client side) to tie things together • But don’t sprinkle code everywhere; keep it modular • Don’t just prototype, build some apps! • We (MCS) can help

14. Q4: Windows NT 5.0 Integration • Excellent

15. Q5: CORBA Integration • Leaving it to ORB vendors for now; see above

16. Q6: Object Wars • Yes, there are always wars in any industry • Except when players are asleep and don’t care about shareholders • However, Java doesn’t align with CORBA except in the minds of (some) ORB vendors • Javasoft says RMI is strategic, deprecates CORBA as legacy integration • Microsoft says Java is fantastic COM programming language, great way to provide DCOM connectivity • Many ORB players (O’Toole of IONA, Soley of OMG) are expressing concern about the Java-ization of CORBA, now pushing back

17. Q7: Long-term Interop • Multi-version interop, continuity, and easy migration is a major goal of Microsoft systems group • Not directly on point, but huge amount of work going into making NT5 upgrade and coexistence as painless as possible • Good track record on systems side

18. Q8: Repository • Microsoft Repository shipping and gaining momentum • Major partnership with Rational Rose; MS Repository incorporates UML support • Being ported to other platforms by Platinum • Aggressive licensing policy for this enabling technology • Dozens of vendors have announced support via Metadata Coalition • See http://www.microsoft.com/repository for more info

19. Q9: Directory Stuff • Provide and prefer ADSI, including full Java support • Will support LDAP C APIs as well • CORBA naming is to trivial to be interesting (directory/file stuff) • CORBA trader is fairly cool, but not clear we need a special-purpose rendezvous programming model, why not use ADSI/LDAP?

20. Q10: Security Stuff • (Question seems to confuse APIs, models/ semantics, and protocols) • SS[ervice]PI (close cousin of ever-changing GSS API) wraps (for applications, RPC/DCOM): • NTLM, SSL/PCT today, NT Kerberos in NT5 • Crypto API: abstraction for crypto services • Kerberos with PK extensions as protocol/ semantic model • NT Kerb and Athena Kerb for wire protocols (DCE possible in future)

21. Additional Qs Today • When Components? • Never just wrap something as a component for its own sake • Two primary advantages • Standard for tools integration • Useful when you expect more than one implementation of a given service in a given system at the same time • NT Kerberos interop? • NT tickets should work with Athena servers, and vice versa • DCE interop possible not planned • Nirvana of single user account not there

22. Additional Qs... • Effect of COM+ on issues? • Richer extensibility/hookability • Pervasive, extensible type information • Questions about DS “objects” versus components • Lots of interesting questions, deserves a full treatment (in addition to components in DS) • Distinguish between collections of data (e.g., DS objects), operations that can be performed on the data “extrinsically” (DS APIs), and behavior “in” the data (“real object”); need all of the above

23. Additional Qs... • Not just client interfaces to services; instead, declarative composition; “automatic” stuff • Strong direction for MS is declarative (not programmatic) relationships between components and services, “automatic everything” (see MTS) • Points of hookability where you can extend vendor services (insert your own behavior) • Good example is IAccessControl in DCOM, ADSI • Description of services needed by components • COM component categories model has “needs a” UUID property; map it as you choose

24. Comments on Whitepaper: Myth of “CORBA” • Biggest problem is the misleading reduction of the multifarious ORB market into a monolithic, fully interoperable unity opposed to Microsoft • This is what the ORB vendors want you to believe until it’s too late—you’ve bought their product and you’re stuck • Not just value-added features, but also underspeci-fied features (e.g., now-defunk BOA) or unspecified “features” (so-called “Implementation Respository”) • Existence of the ImpRep as an OMG standard is one of those great CORBA myths that is swallowed whole by the paper; Persistence Service is another

25. Myth of “CORBA”... • Better to think of a spectrum of similarity/ interoperability with COM on one side and ORB products ranging across the remainder • Something like 30% divergence of COM and CORBA spec, range of 10-20% divergence of ORBs on either side of spec • After all, Visual Edge sells not only COM->ORB code but ORB-to-ORB gateways to increase fidelity of, say, NEO->SOM or ORB+->Orbix mappings • Only an insane person would mix ORB products in an enterprise (ask any good CORBA consultant), so pick your vendor carefully

26. Myth of “Off-the-Shelf” CORBA • There is literally no retail CORBA component in world today • Why? Because no binary standards; interop is based on IIOP only; components packaged in EXEs with a bundled ORB runtime are not that practical or interesting • That is exactly why CORBA folks are so enamored with Java; solves this problem for them (in a non-CORBA-compatible but mappable way)

27. Myth of Java/CORBA: Prelude • 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)

28. Myth of Java/CORBA • Similarly, the paper accepts the quasi-mythological convergence of Java and CORBA • Three camps: • Java/RMI über alles (JavaSoft part of Sun) • Java should fill CORBA’s gaping hole of no local component architecture, CORBA should pick up Beans, etc. (NEO part of Sun, IBM, Netscape, Oracle) • Java is just another CORBA language (IONA, OMG staff) • Attempt to smooth over differences with PR about future RMI/IIOP work failed within days

29. Myth of CORBA Security • Paper constantly references this as a done deal, but reality is much less impressive • No major ORB shipping today w/ security at all • Anyone here use ICL Dais? • Defines three levels of compliance, nobody committed to anything but level 1 in near term • Integrates with what vendors’ OSes??? • Cool stuff like non-repudiation is years away • “Standard” is complicated, vague in key respects; will take years to iron out interop issues

30. Lack of Appreciation for MTS • MTS is a huge step forward for Microsoft and the industry • Hard to overstate its importance for building business applications • Transactions and scalability without all the hard stuff like programming DTC/OTS • Integration into ASP environment in IIS 4.0 is awesome • Paper needs to show a bit more understanding/ appreciation of what MTS means

31. Tidbits • Myths around CORBA OTS • Not an MTS equivalent—akin to DTC • MS is way ahead; Bob Orfali is quaking in his boots • Only one or two vendors shipping (BEA? Orbix/Encina in beta) • 0% chance of interop across ORBs • Interop is years away; no RFP even issued • “Compete on functionality, not component models” • What does that mean? Orbix shouldn’t have smart proxies?? Sounds great but means practically nothing

32. Tidbits... • “Eye on the prize” = “universal client”: huh? • Not politically correct to say it, but Windows is the near-universal client • E.g., note major shift of Java proponents (IBM, Marimba) to server-side arguments • So this is at least not always the right approach • Slap at “retrograde” HTTP/CGI (p6) • Right out of the CORBA vendor playbook • Just plain silly: great apps built quickly; plus, history of scalability is history of batch/stateless processing! • We all want objects, but let’s not over-value O-O models or undervalue things that work today

33. Tidbits... • Push for vendor frameworks á là San Francisco • Given unimpressive state of the infrastructure, not clear that this makes sense yet • Need true componentized frameworks, not big Java class library (don’t want “MFC for business objects”) • Personal opinion: not clear to me that there are frameworks that are horizontal enough for MS • COM summary • Objects are not located through registry, code is • Objects either created manually by clients from uninitialized code or bound through monikers • Local registry for all code location goes away in NT5

34. Tidbits... • CORBA summary • Weak understanding of relationship between CORBA, Java, and JavaBeans • Wrong about no “client” software; code calling methods on ORB-managed object isn’t necessarily an object • Wrong about “client needs to know nothing” about object location; must at least know location of (undefined) ImpRep or name service root

35. Tidbits... • Java summary • Java is at most an application platform; misleading to call it a “platform ... in the same sense [as] Windows” • Beans are not platform-neutral, they require the Java platform • “CORBA and Java convergence” is not as certain as the paper claims • JavaSoft has no plans to replace the RMI native wire protocol, only plans to make RMI work better with IIOP

36. “Real World” Story Not So Real • “Security component” -- what is that? • Why not use SoftWindows and run the ActiveX controls on Mac and UNIX? • Impossible for XYX apps to be “tightly integrated with CORBA-based security/directory” • Problem with Tuxedo apps in MTS has nothing to do with DLL packaging • Scenario based on MS JVM failing compatibility test is bogus and unfair: • Must test every JVM! • MS JVM passes more of Sun’s secret tests than JDK!

37. Resources • Great overview book • Understanding ActiveX and OLE (by David Chappell) • Implementations • Win95 DCOM: http://www.microsoft.com/com • Solaris and other non-Win32 versions: http://www.sagus.com> • Technical info • <http://www.microsoft.com/com; /workshop; /transactions; /repository; /java; /msdn • Inside COM (by Dale Rogerson); upcoming Don Box book • Mailing lists • http://www.microsoft.com/workshop/resources/email.htm • This talk and others on COM/CORBA/RMI, Java, etc. • ftp://ftp.microsoft.com/developr/drg/com