1 / 47

Building Internet Applications with Java and (Distributed) COM

Building Internet Applications with Java and (Distributed) COM Mark Ryland Senior Technical Evangelist Microsoft Developer Relations. Outline. Why components? Why Java and COM? Some COM details Java and COM: some scenarios Platform and interoperability issues. Wanted: software components.

agnes
Download Presentation

Building Internet Applications with Java and (Distributed) COM

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. Building Internet Applications with Java and (Distributed) COM Mark RylandSenior Technical EvangelistMicrosoft Developer Relations

  2. Outline • Why components? • Why Java and COM? • Some COM details • Java and COM: some scenarios • Platform and interoperability issues

  3. Wanted: software components • “Active wave” requires applications, content, operating systems, networking, distributed services to be integrated as never before • Monolithic solutions won’t work • No one vendor or one team of programmers can move fast enough • Need to leverage others’ work and to build and ship smaller pieces incrementally • Need to evolve smaller pieces asynchronously without sacrificing the whole

  4. Early component solutions • DLLs: 1st generation component technology • Allows interchangeability of service providers based on DLL name and common function entry points • E.g., WSock32.dll • Some immediate problems • No graceful way to have more or less features than the full API set • No way for multiple providers to coexist! • WOSA API/SPI architecture: 2d generation • E.g., ODBC • Works great but has some limitations

  5. COM: third generation components • Unified programming model • Between OS and apps — unification of system handle-based “objects” and variety of app models • Between in-process and remote interaction — unification of DLLs and RPC • Standards for binary deployment, connection • Software pieces or “components” find and connect to each other through clearly defined interfaces • Solves some fundamental problems of software integration, independent evolution

  6. COM… • COM’s initial thrust: integrating desktop applications with OLE • COM technology is generically useful, being applied to a wide range of other areas • Designed to be distributed • 1000’s of shipping, commercially available, products. • World class development tools • VB, VC, VJ, Borland C++, Delphi, PowerSoft…

  7. Examples • Manufacturing process control • Controls on the Internet/Intranet client • Componentized browser • Component based server applications • Active Server Pages • Microsoft Transaction Server (Viper) • Multi-tier “client/server” applications • Game system “APIs” (DirectX is COM-based)

  8. E.g.: components in browsers

  9. E.g.: components in browsers

  10. Components in servers • IIS 3.0 programmability (active server pages) built around COM and COM script engines • IIS 4.0 even more COM-centric • Fundamental integration of MTS-managed transactions into Asp environment; Asp scripts themselves can be fully transactional • Asp enhancements • Other BackOffice products extended via COM • Exchange, SQL Server, etc. • More so in NT5 timeframe

  11. Unexpected examples… • 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

  12. HTML Scripting Components Components Presentation Security Directory Transactions Data Access... Presentation Security Directory Transactions Data Access... System Services System Services Microsoft PlatformUnified through COM HTML Scripting Standard Protocols (HTTP, DCOM, etc.)

  13. Outline • Why components? • Why Java and COM? • Some COM details • Java and COM: some scenarios • Platform and interoperability issues

  14. Why Java and COM? • Allow Java code to access COM-based system and application services • Critical system and application services “exported” as COM objects • Allow COM objects to be written in Java • Power and productivity of language can benefit other code not written in Java • An option that strengthens both Java and COM

  15. Java and COM • MS Java VM itself is a COM component that exposes Java classes as COM objects • Use Java classes from any application/language, not just browser/Java • Any Java object is a COM object • Automatic integration of Java code with other languages and scripts • Lets Java applets talk to other Java applets • Lets Java applets talk to ActiveX components • Gives Java applets access to all PC functionality

  16. MS Java VM 2.0 and COM • Automatic disp interface on all Java classes • Availability through VM’s Java moniker • E.g., GetObject(“java:classes.myclass”) • Two way Java Beans integration • Beans inside ActiveX containers • ActiveX controls inside of Beans containers • Richer COM integration overall • More MIDL/C++ datatypes supported, etc. • Much more to come beyond 2.0…

  17. Outline • Why components? • Why Java and COM? • Some COM details • Java and COM: some scenarios • Platform and interoperability issues

  18. COM basics • Servers expose features through collections of methods in strongly-typed “interfaces” • Implementations named with UUIDs • Server types (categories) named with UUIDs • Interfaces named with UUIDs • Clients call methods as indirect function calls through “interface pointers” • Normally, object has state; methods act it • New objects created by class factories

  19. N interfaces per object • Each object has one or more interfaces • Ability of an object to “publish” multiple interfaces used to solve three distinct problems: • Extensibility—how to add discoverable “non-standard” features without risk to ignorant clients • Multiple interface inheritance—how to behave like two or more other objects • Versioning—how to support both old and new clients safely (or fail gracefully) • Strange at first, yet simple and elegant • Maps nicely to Java ::InstanceOf

  20. Component Client Client Process Server Process Component COM Client Server Machine Client Machine Component DCE ORPC COM COM Client Programming model transparency • In the same process • Direct function calls • On the same machine • Fast, secure IPC • Across machines • Secure, fast, flexible, reliable DCE RPC based DCOM protocol

  21. Isn’t COM about “objects”? • No … COM sets out to solve system software problems that arise when hooking up randomly evolving combinations of binaries • Yes … from the perspective of these new kinds of objects also called “components” • Traditional object concepts used (but adapted) to solve a different (but overlapping) set of requirements in a different problem space • Components integrate more readily o-o languages • Systems OT complements language OT

  22. Sketch of COM Client of interfaces Server (EXE) InterfacesBar_1 Bar_2 Surrogate Server (EXE) DLL Server InterfacesFoo_1 Foo_2 Process Boundary Network Boundary DLL Server InterfacesFoo_1 Foo_2 DLL Server (Proxy)InterfacesBar_1 Bar_2 Stub DLL forInterfaces Bar_1 Bar_2 DLL Server (Proxy)InterfacesFoo_1 Foo_2 Stub DLL forInterfaces Foo_1 Foo_2 DCE-compatible RPC

  23. COM and threading • Object systems traditionally have not defined relationship between objects and threads (execution behavior) • COM provides two models: • Single-threaded apartment (0->N per process) • Objects associated with particular OS thread, all calls delivered on that thread • Integrates with USER concurrency model • Multi-threaded apartment (0->1 per process) • Classic RPC/Java-style free-threaded model; calls delivered by runtime-managed pool of worker threads

  24. Distributed COM • COM “with a longer wire” • COM components communicate in the same way • on the same machine • In-process, Out-of-process • across a Local Area Network • across a Wide Area Network • across the Internet • Same tools, knowledge, code

  25. COM runtime • Secure - Security is designed and built in. Not an option • Allows cross-principle COM on single NT machine • Designed for distribution • COM working across network internally since 1993 • Shipping COM has used MS RPC runtime for communication cross-process since 1994 • Pluggable • Security • Transports

  26. Security • Class may be launched as different security principals • Start as current interactive user • Start as principle X (could be service/daemon) • Start as caller • Activation and connection access controls • ACL covering who can launch class (EXE or surrogate/DLL) • ACL covering who can access a running object in a given process (AppID)

  27. Security… • Session-level and call-level security • Authenticating, signing, sealing per call/connection (same options as DCE RPC) • “Automatic” security: COM enforces (per process) • Or “raw” server-implemented security—thread-level authentication and impersonation • Installable security providers • RPC runtime talks to providers via GSS-like API • Common provider negotiated by COM • Win NT and (coming) DCE providers

  28. Client Machine Server Machine Keep-alive packet for all connections Server Client #1 Logical “Connections” or “Sessions” Client #2 Distributed garbage collection protocol • Optional (on by default); allows objects to distinguish between quiescent and dead clients • Efficient -- very small keep-alive messages bundled for all connections between machines • Server maintains only counter, no knowledge of clients • Optimized network expression of Addref/Release

  29. Microsoft Transaction Server“Viper” • Runtime executionenvironment for middle-tier components • Extends COM archi-tecture with transactionsemantics • Provides concurrency,multi-threading, queuing, atomicity, etc. • “Easy-to-write, scalable servers” is not longer a self-contradiction

  30. HTML Scripting Components Components Presentation Security Directory Transactions Data Access... Presentation Security Directory Transactions Data Access... System Services System Services Microsoft PlatformUnified through COM HTML Scripting Standard Protocols (HTTP, DCOM, etc.)

  31. Outline • Why components? • Why Java and COM? • Some COM details • Java and COM: some scenarios • Platform and interoperability issues

  32. Scenarios • Java client uses local services on client • E.g., using other components within IE • Java client uses remote COM servers via DCOM • IIS extended via Java components • Two or three tier uses • Transactional objects in Java • Java server available via DCOM • Issues and limitations

  33. Remote COM servers • Get Java code to client somehow • Automatic download from web page via CAB file is a great choice • However the client code got there, also install type library for remote interfaces • Not necessary (IDispatch) but much more efficient • Also download information about remote machine/instance location • Or provide (say) a stringified marshaled interface pointer if DCOM server already activated

  34. Server components • Use SDK tools to create, register Java component • Call as usual from, e.g., .ASP page using registered ProgID • Or register within MTS for automatic xactional behavior, enhanced data access via ADO • See http://www.microsoft.com/transaction for detailed how-to paper on Java/MTS • IIS 4.0 (beta now downloadable, available soon) includes .ASP/MTS integration

  35. DCOM server in Java • For access from middle tier (IIS), register (or call from .ASP) to remote machine • Use JavaReg to install with DCOM system surrogate supplying process • For client access, get location info to client via HTML, etc. • Configure security to allow/disallow clients as desired (launch versus access) • In general, use DNS location names for degree of location transparency, reconfigurability

  36. Issues and limitations • Currently no way trivially to specify DCOM server location within Java • Use simple bridge component, J/Direct, or registry • GetObject() equivalent available soon • Beware of type compatbility issues in interfaces used with/from Java • Generally play safe and stick with Automation types

  37. Issues and limitations... • Beware of firewall issues when using DCOM due to use of dynamic ports • Either configure static, limited port range • Or wait a few months for DCOM over HTTP • More esoteric COM/DCOM features not readily programmable from Java right now • CoInitializeSecurity, CoGetCallContext, IClientSecurity, IMarshal • Some of these are hard/impossible to work around with bridge or J/Direct • Solutions coming in post-2.0 VM

  38. Outline • Why components? • Why Java and COM? • Some COM details • Java and COM: some scenarios • Platform and interoperability issues

  39. Java/COM platforms • Win32 platforms today • UNIX platforms with availability of Internet Explorer on UNIX • Solaris, HP-UX initially, others based on market feedback • These include full “native” COM functionality, both local and remote

  40. Java implementation of COM • Enterprise AFC includes COM/DCOM runtime written in Java • Allows any Java VM to access remote COM servers, services • Could be same machine, but not (efficiently) same process • Significant subset of MS RPC/DCOM runtime written in Java • All that’s interesting and useful in Java • Planned availability: end of ‘97/early ‘98

  41. Comparison to DCOM in MS Java VM Your Class SCM/OR com.ms.dcom EP-Mapper Your Class com.ms.rpc MS Java VM java.io Other Java VM DCOM & RPC Native TCP/IP Networking

  42. Why not RMI? • Java-to-Java only; not comparable to COM/DCOM integration • Immature distributed computing protocol • Performance weak • No security • Is Sun committed? Not clear… • Notice that RMI never mentioned in Sun’s JIBE whitepaper, while CORBA/IIOP is several times • Some RMI features will be added to COM • Pass-by-value object references generally interesting

  43. Why Not CORBA? • Many practical reasons: CORBA is not a complete component architecture • Competes only with *D*COM, not COM • No binary standards—have to cart around an ORB runtime and communicate via IIOP on single machine! • No standards for in-process objects—can’t dynamically compose many apps out of CORBA objects • No well-understood evolution/versioning policies • CORBA as currently defined cannot be the basis of a shrink-wrapped component marketplace • (Historical reasons—CORBA was too late)

  44. Interop w/ CORBA-style ORBs • Interoperability and co-existence happening • OMG standards for basic approach • All significant ORBs have COM integration as a high feature priority • Active Group licensing code to major ORB vendors • 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)

  45. Upcoming COM features • HTTP transport, SSL/PCT security integration • Both coming soon (Late Summer/Fall ‘97) • Network-based 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”; garbage collection; distributed multi-language debugging

  46. COM, Java/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/; /transaction/; /java/; /msdn/> • Inside COM (by Dale Rogerson) • This talk: ftp://ftp.microsoft.com/developr/drg/ole-info/jibe2.ppt • Mailing lists • http://www.microsoft.com/workshop/resources/email.htm

  47. Questions?

More Related