1 / 37

Viewpoint on NAC’s Component-Based Application Infrastructure

Viewpoint on NAC’s Component-Based Application Infrastructure Mark Ryland Senior Technical Evangelist Microsoft Developer Relations Group. Q1: Vision. Client tier presentation DHTML for universal client (80/20 rule) ActiveX native code for richness Win32, possibly Mac/UNIX

howe
Download Presentation

Viewpoint on NAC’s Component-Based Application Infrastructure

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related