1 / 25

Is Distributed Object Technology ready for full scale adoption?

Is Distributed Object Technology ready for full scale adoption?. Marc Laukien Email: ml@ooc.com. Is D.O.T. ready?. Platform support ? Language support ? User friendliness ? Programmer friendliness ? Multi-protocol support ? Scalability ? Reliability ? Fault tolerance ? .

bailey
Download Presentation

Is Distributed Object Technology ready for full scale adoption?

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. Is Distributed Object Technology ready for full scale adoption? Marc Laukien Email: ml@ooc.com

  2. Is D.O.T. ready? • Platform support ? • Language support ? • User friendliness ? • Programmer friendliness ? • Multi-protocol support ? • Scalability ? • Reliability ? • Fault tolerance ?

  3. About ORBacus... • OOC’s flagship product - a fully CORBA 2 compliant ORB • Formerly known as “OmniBroker” • Free for non-commercial use • See the ORBacus Royalty-Free Public License Agreement for details • No Run-Time Royalties • Available with complete source code • Can be downloaded from http://www.ooc.com/ob/

  4. Platform Support • General recommendations • Don’t dump Unix • Don’t hate NT either • Don’t ignore Linux • Make sure your ORB vendor supports them all

  5. Platform Support (cont’d) • Platforms supported by ORBacus • Unix • SGI C++ 7.1 or 7.2 SGI Irix 6.2 or 6.3 • SUN C++ 4.1 or 4.2 SUN Solaris 2.5 • HP aC++ A.01.12 HP-UX B.10.20 • AIX C Set ++ xlC 3.1.4.6 AIX Version 4.2.1 • DEC C++ 6.0 DEC OSF/1 V4.0 • GNU C++ 2.7.2 Intel- or Sparc-based OS • EGCS 1.0.x / GCC 2.8.x Sun, Linux, SGI... • Windows • Visual C++ 4.2/5.0 Windows 95/98/NT

  6. Platform Support (cont’d) • Third-party ports • Unix • EGCS 1.0.x / GCC 2.8.x FreeBSD, Sun OS… • Windows • Borland C++ Builder 3 Windows 95/98/NT • Other • EGCS 1.0.x / GCC 2.8.x LynxOS

  7. Language Support • General recommendations • Make sure that your ORB supports all of CORBA IDL • #pragma, Any, TypeCodes, recursive TypeCodes... • Don’t be religious about programming languages • Use C++ and Java • Don’t forget about scripting languages • CORBA brings them all together!

  8. Language Support (cont’d) • Languages supported by ORBacus • Fully standard compliant C++ mapping • Fully standard compliant Java mapping • Tcl/Tk (soon) • Third-party • CorbaScript (Univ. Lille) • COPE (Perl mapping) • FNORB (Python mapping)

  9. User Friendliness • Example #1: OOC’s ORBacus Names • Administrative GUI application for the naming service • Microsoft Explorer-style Look & Feel • Operations for Load & Save, rename, new, delete, cut & paste, sort, etc. • Example #2: OOC’s ORBacus Trader • Full compliance with the OMG trading service specification • “Full Trader” • Administrative GUI application for trader management • Managing the service type repository, exporting, modifying and withdrawing service offers, establishing links between trading services, performing queries, configuring the server attributes

  10. User Friendliness (cont’d)

  11. User Friendliness (cont’d)

  12. Programmer Friendliness • Example #1: OOC’s JThreads/C++ • JThreads/C++ = “Java-like Threads for C++” • A high-level thread abstraction library that gives C++ programmers the “Look & Feel” of Java threads • Reduces training significantly! If you know Java threads, you can instantly use JThreads/C++. • Example #2: OOC’s Documentation Generators • Extract documentation from comments in IDL files • Help maintain consistency between documentation and source code • Support a “Javadoc” compatible formatting syntax • Convert to HTML and RTF

  13. Programmer Friendliness (cont’d)

  14. Multi-Protocol Support • The telco industry needs pluggable protocols! • Guaranteed Quality of Service (QoS) • Protocols like ISDN and ATM offer better QoS than TCP/IP • Confidential protocols (military, banking, …) • A plug-in can be produced independently by a trusted third-party provider. • Security • Security can be realized by protocol plug-ins • Time to market • Third-party vendors can fully focus on custom-made protocol plug-ins and provide solutions fast

  15. Multi-Protocol Support (cont’d) • The ORBacus Open Communications Interface • Designed in cooperation with Humboldt University and Deutsche Telekom • Supports “byte-stream” oriented protocols • For example, TCP/IP, SSL, SCCP, SAAL, ISDN • Allows for “light-weight” plug-ins • The ORB has to handle most of the protocol logic • Quality of Service • Uses Policies to control protocol selection, connection reuse strategy, etc. • Uses POA and Messaging QoS Framework

  16. Multi-Protocol Support (cont’d) • Existing OCI protocol plug-ins: • IIOP (OOC) • IIOP w/ SSL (OOC) • SECIOP (Adiron, LLC) • ISDN-IOP (Humboldt University) • ATM-IOP (Humboldt University, University of Lille and several others) • Multi-Cast (UDP) (OOC, University of Lille)

  17. Scalability • ORB size • From small ORBs embedded into consumer devices (ISDN telephones, set-top boxes) to full-featured ORBs running on large computers • Embedded ORBs usually only need a small subset of CORBA’s functionality • Which features are needed depends on the particular application • There is no “one-size-fits-all” • ORBacus can be tailored specifically for the needs of your application

  18. Scalability (cont’d) • Number of objects • From single-object servers to servers with thousands of objects (like one object per phone call) • Many of these issues will be addressed by the Portable Object Adapter • Servant Activators/Locators, Default Servants

  19. Scalability (cont’d) • Request execution • From “one client per server” to servers with thousands of clients • ORBacus single-threaded concurrency models • No overhead for thread context switches - very fast! • Blocking Model • ORB blocks while requests are sent or received • Reactive Model • ORB does not block while requests are sent or received • Easy event loop integration with X11 and Windows - Just one initialization call is needed

  20. Scalability (cont’d) • ORBacus multi-threaded concurrency models • Threaded server • Threads are only used internally - User code does not need to do any special thread synchronization • Thread-per-client server • For each connected client a new thread is created in which requests for that client are run • Thread-per-request server • A new thread is created for each request • Thread pool server • Like thread-per-request, but threads are taken from a pool of pre-created threads

  21. Reliability • Today’s ORBs are reliable • For example, ORBacus is used in several mission critical projects • However, there’s still work to do • Programming mistakes • Can only partially be solved with general debug tools • IIOP-aware debug tools are needed to check “on the wire” • Misbehaving ORB implementations • IIOP encourages the employment of different ORB products, but it must be possible to find and eliminate faulty ORBs • Hacker attacks • “Garbage” message bodies crash most ORBs

  22. Fault Tolerance • Simple Fault Tolerance • Automatic server and object re-activation • Server is restarted upon crash • With state recovery • Object Group Communications • Clients communicate with object groups instead of individual objects • Objects join and leave object groups • Objects retrieve state from other objects of the group • Also allows for load-sharing • Best supported by multicast communications

  23. Object A Object A Group B Group A Object B Object B Fault Tolerance (cont’d) Object A Client

  24. Is D.O.T. ready ?Summary • Platform support ? + • Language support ? + • User friendliness ? + • Programmer friendliness ? + • Multi-protocol support ? + (*) • Scalability ? + • Reliability ? + • Fault tolerance ? - (*) ORB dependent

  25. Is D.O.T. ready ?Success Stories ORBacus success stories: http://www.ooc.com/success/ Other CORBA success stories: http://www.corba.org/

More Related