Old C++ Columns

Together with Dr. Douglas C. Schmidt of Vanderbilt University, I used to write about distributed object computing in our Object Interconnections column in the C/C++ Users Journal. This column started in the C++ Report magazine, and then later moved over to CUJ. In all, the column lasted from 1995-2005, which is a long time for such a focused magazine column.

  • The CORBA Component Model, Part 4: Implementing Components With CCM. Our previous columns presented the design of our stock quoter example using the CORBA Component Model (CCM) and described how the CCM container architecture and Component Implementation Framework (CIF) are designed. This column deepens our coverage of CCM by showing how the CIF can be used to implement the components in our stock quoter application using C++ and CCM and interact with component containers, which provide the runtime environment for one or more component implementations called executors, which in turn are where components are actually implemented by CCM server application developers.

  • The CORBA Component Model, Part 3: The CCM Container Architecture and Component Implementation Framework. Our previous column illustrated portions of a hybrid publisher/subscriber and request/response distribution architecture that used CORBA Component Model (CCM) features to enhance our familiar stock quoter example and alleviate key drawbacks with the use of polling-based request/response interactions. That column also focused on the use of IDL 3.x (which extends IDL 2.x with component-based features) to define the various CCM types used by our enhanced stock quoter example. In this column, CCM expert Bala Natarajan joins us to expand our coverage of CCM by describing the container architecture, which provides a powerful runtime environment for components, and the Component Implementation Framework (CIF), which generates a significant amount of code so it need not be written manually by CCM server application developers.

  • The CORBA Component Model, Part 2: Defining Components with the IDL 3.x Types. This column, part two of a series on the CORBA Component Model, shows the basics of using IDL 3.x extensions for defining CCM components.

  • The CORBA Component Model, Part 1: Evolving Towards Component Middleware. This column, the first part of a series on the CORBA Component Model, examines the history of middleware and explains how and why we’ve evolved toward component-oriented systems.

  • XML Reflection for CORBA, C/C++ Users Journal, December 2003. This column describes an approach for enabling CORBA objects to return their own metadata in an XML format to client applications that request it. It allows tools used to integrate CORBA systems with other middleware, such as .NET and Web Services, to dynamically discover CORBA object metadata without requiring the CORBA system to have deployed an Interface Repository (which very few real-world CORBA systems ever do).

  • Dynamic CORBA, Part 4: The Interface Repository, C/C++ Users Journal, January 2003. This column describes the Dynamic CORBA IFR (Interface Repository), which is a service that provides type information about CORBA interfaces and other entities defined in IDL. The IFR helps ensure the type-safety and correctness of the DII and DSI mechanisms that defer an application’s binding onto specific interface types until run time.

  • Dynamic CORBA, Part 3: The Dynamic Skeleton Interface, C/C++ Users Journal, November 2002. This column presents the CORBA Dynamic Skeleton Interface (DSI), which is the server-side counterpart of the CORBA Dynamic Invocation Interface. Some server applications, such as gateways or monitors, cannot know a priori the types or identities of the objects they must serve. In this column, we show how DSI enables CORBA developers to construct such applications portably.

  • Dynamic CORBA, Part 2: Dynamic Any, C/C++ Users Journal, September 2002. Just like their static counterparts, Dynamic CORBA applications manipulate real-world complex data types, but they must do so without having compile-time information about those types. This column shows how you can use the Dynamic Any feature of CORBA to create, examine, and modify data values of any IDL type in Dynamic CORBA applications.

  • Dynamic CORBA, Part 1: The Dynamic Invocation Interface, C/C++ Users Journal, July 2002. An important and growing class of applications requires the type of flexibility provided by Dynamic CORBA features. This column covers the basics of the CORBA DII (Dynamic Invocation Interface), which is the client-side interface used for dynamic CORBA applications.

  • Real-time CORBA, Part 4: Protocol Selection and Explicit Binding, C/C++ Users Journal, May 2002. Strict control over the association of operations, threads, and networking resources is essential for many distributed real-time and embedded (DRE) applications. This column explores Real-time CORBA features that allow DRE applications to select protocol properties and to explicitly bind clients to server objects using pre-allocated connections, priority bands, and private connections.

  • Real-time CORBA, Part 3: Thread Pools and Synchronizers, C/C++ Users Journal, March 2002. Distributed real-time and embedded (DRE) applications need strict control over the scheduling and execution of CPU and memory resources. This column describes the Real-time CORBA’s support for these needs, focusing on its thread pools and synchronizers.

  • Real-time CORBA, Part 2: Applications and Priorities, C/C++ Users Journal, January 2002. The Real-time CORBA Specification enhances regular CORBA by adding capabilities that control process, communication, and memory resources. These capabilities enable standard COTS middleware to improve the determinism of distributed real-time and embedded (DRE) applications by bounding their priority inversions and managing their system resources more predictably end-to-end. This column shows how to program the Real-time CORBA features that provide portable priority mapping and end-to-end priority preservation.

  • Real-time CORBA, Part 1: Motivation and Overview, C/C++ users Journal, December 2001. In this column, we explore distributed real-time and embedded (DRE) systems by digging into the Real-time CORBA Specification. This spec provides interfaces and policies that allow applications to control and configure processor resources (via thread pools, priority mechanisms, intra-process mutexes, and global scheduling), communication resources (via protocol properties and explicit bindings), and memory resources (via buffering requests and bounding the sizes of thread pools). This column provides an overview of these interfaces and policies.

  • CORBA and XML, Part 3: SOAP and Web Services, C/C++ Users Journal, September 2001. In this column, we extensively explore SOAP and Web Services. Both SOAP and Web Services are currently garnering a lot of industry attention, with some comparing CORBA and SOAP, or CORBA and Web Services, as if they were competitors. In disagreeing with this viewpoint, we first compare SOAP and IIOP and then argue that Web Services and CORBA are not rivals, but instead are complementary. We see Web Services serving as business process integration technology capable of combining existing middleware technologies such as CORBA, J2EE, .NET, and EAI into Internet-accessible service-oriented business processes.

  • CORBA and XML, Part 2: XML as CORBA Data, C/C++ Users Journal, July 2001. The hype surrounding XML often conceals its real utility, which ultimately boils down to providing for the structured — yet flexible — description and definition of data. XML’s capabilities therefore mesh well with those of CORBA, which primarily focuses on system functionality rather than system data. In this column, we continue our exploration of the relationship between CORBA and XML. Since our previous column advocated the passing of XML-defined data between client and server, we first discuss various alternatives for doing this using an example bug tracking system. We conclude the column with a brief discussion of SOAP and Web Services and how they relate to CORBA.

  • CORBA and XML, Part 1: Versioning, C/C++ Users Journal, May, 2001. In this column we explore the hype surrounding XML and how it might be used in a practical manner in a CORBA-based application. We specifically explore the issue of versioning support in CORBA systems – or the lack thereof – and take a look at how XML might be used to alleviate some of the problems.

  • Using Standard C++ in the OMG C++ Mapping, C/C++ Users Journal, April, 2001. In this column we complete our exploration of hypothetical OMG C++ mappings using Standard C++ by focusing on the server side. This column illustrates some of the complexity of mapping the language-neutral OMG IDL to C++ in a way allowing for flexible servant implementations. We also take a brief look at the mapping for pseudo-objects in a Standard C++ world. As usual, there are few absolutely right or wrong answers, but many choices with varying consequences.

  • Standard C++ and the OMG C++ Mapping, C/C++ Users Journal, January, 2001. The OMG mapping from CORBA IDL to C++ was standardized in 1994. As we explain, there are some good reasons to leave that mapping alone, even though the C++ language changed significantly between 1994 and 1998, when it finally became an international standard. But that doesn’t keep us from having a little fun. In this column, we explore our own alternative “what if” mappings, based on newer features of C++.

  • The History of the OMG C++ Mapping, C/C++ Users Journal, November, 2000. This column goes back in time to when the OMG C++ mapping was defined and describes some of the non-technical issues that made it the way it is.

Our old C++ Report columns are also listed below. (The later columns build on the earlier ones, so you might find them easier to understand if you read them in the reverse of the order shown.)

  • An Overview of the OMG CORBA Messaging Quality of Service (QoS) Framework, C++ Report, SIGS, Vol. 12, No 3, March, 2000. This column outlines the QoS policies defined in the OMG CORBA Messaging specification. These QoS policies provide a new degree of flexibility and control to CORBA application developers. We focus our discussion on several policies, client timeouts and reliable one-ways, that we’ve found useful when developing real-world CORBA applications. (Postscript or PDF)

  • Collocation Optimizations for CORBA, C++ Report, SIGS, Vol. 11, No. 9, October, 1999. This columns examines various techniques for collocating clients and objects in CORBA. Collocation is a technique for transparently optimizing communication overhead when clients and servants are configured into the same address space. In such cases, CORBA ORBs can transparently employ collocation optimizations to ensure there’s no unnecessary overhead of (de)marshaling data or transmitting requests/replies through a “loopback” communication device. (Postscript or PDF)

  • Time-Independent Invocation and Interoperable Routing, C++ Report, SIGS, Vol. 11, No 5, May, 1999. This column focuses on a new feature defined in the CORBA Messaging Specification called time-independent invocation (TII), which adds store-and-forward features to CORBA. In this column, we illustrate how TII essentially extends CORBA asynchronous method invocations (AMI)s with persistent ReplyHandler, Pollers, and Requests. (Postscript or PDF)

  • Programming Asynchronous Method Invocations with CORBA Messaging, C++ Report, SIGS, Vol. 11, No 2, February 1999. This column focuses on asynchronous method invocation (AMI), which is a core part of the new CORBA Messaging specification. A key feature of the CORBA AMI is that it effectively allows deferred synchronous calls using the static invocation interface (SII), thereby alleviating much of the tedium associated with using the DII. This column illustrates how to use the callback and polling AMI models with C++. (Postscript or PDF)

  • An Introduction to CORBA Messaging, SIGS C++ Report, Vol. 10, No. 10, November/December 1998. In this column we begin our coverage of asynchronous messaging and the new CORBA Messaging specification. This specification introduces a number of long-awaited features into CORBA, including asynchronous method invocation (AMI), time-independent invocation (TII), and general Quality of Service (QoS) policies. These new features greatly enhance the standard set of request/response communication models that CORBA provides. (Postscript or PDF)

  • C++ Servant Managers for the Portable Object Adapter, SIGS C++ Report, Vol. 10, No. 7, September, 1998. This column describes servant managers and default servants. Servant managers can dynamically load servants for target objects on demand, and they can help with servant clean-up. Default servants allow multiple CORBA objects to be incarnated by a single servant, thus avoiding the resource usage associated with a servant-per-object design. (Postscript or PDF)

  • C++ Servant Classes for the POA, SIGS C++ Report, Vol. 10, No 6, June, 1998. This column explains how the new POA specification separates the client-side stub hierarchy from the server-side skeleton hierarchy in order to facilitate collocation and ensure source-level portability. (Postscript or PDF)

  • Using the Portable Object Adapter for Transient and Persistent CORBA Objects, SIGS C++ Report, Vol. 10, No 4, April, 1998. This column explains how the new Portable Object Adapter (POA) can be used to support transient and persistent CORBA objects, and shows examples of each in C++. (Postscript or PDF)

  • Object Adapters: Concepts and Terminology, SIGS C++ Report, Vol. 9, No. 11. November/December 1997. This column explains what Object Adapters are and describe their roles within a CORBA-based system. In addition, it details the new Portable Object Adapter (POA) specification that was recently adopted by the OMG. (Postscript or PDF)

  • Overcoming Drawbacks With the OMG Events Service, SIGS C++ Report, Vol. 9, No 6. June, 1997. This column describes techniques for overcoming drawbacks with the OMG Events Service. These techniques range from changing the COS Events Service specification, to changing implementations of the COS Events Service specification, as well as changing applications that use a COS Events Service implementation. (Postscript or PDF)

  • The OMG Events Service, SIGS C++ Report, Vol. 9, No. 2, February 1997. This column outlines the roles of the key components in the OMG Events Service, examines the IDL interfaces of the Events Service components in detail, shows how to use it to build a flexible version of the distributed stock quoter system, and evaluates the strengths and weaknesses of the OMG Events Service model and its specification. (Postscript or PDF)

  • Distributed Callbacks and Decoupled Communication in CORBA, SIGS C++ Report, Vol. 8, No. 10, October 1996. This column examines the use of distributed callbacks in CORBA and illustrates why they are useful for decoupling relationships between consumers and suppliers in object-oriented communication applications. (Postscript or PDF)

  • Comparing Alternative Programming Techniques for Multi-threaded Servers — the Thread-per-Session Concurrency Model, SIGS C++ Report, Vol 8. No 6. June 1996. This column examines and evaluates three techniques for developing multi-threaded servers using the “thread-per-session” concurrency model. These techniques include using the socket network programming interface, using C++ wrappers for sockets, and using multi-threaded Orbix. (Postscript or PDF)

  • Comparing Alternative Programming Techniques for Multi-threaded Servers — the Thread-Pool Concurrency Model, SIGS C++ Report, Vol 8. No 4. April 1996. This column examines and evaluates three techniques for developing multi-threaded servers using the “thread-pool” concurrency model. These techniques include using the socket network programming interface, using C++ wrappers for sockets, and using multi-threaded Orbix. (Postscript or PDF)

  • Comparing Alternative Programming Techniques for Multi-threaded Servers, SIGS C++ Report, Vol 8. No 2. February 1996. This column examines and evaluates four techniques for developing multi-threaded servers. These techniques include using the socket network programming interface, using C++ wrappers for sockets, and using two multi-threaded versions of CORBA (Orbix and HP ORB Plus). (Postscript or PDF)

  • Comparing Alternative Server Distributed Programming Techniques, SIGS C++ Report, Vol 7. No 8. October 1995. This column examines and evaluates three techniques for developing the server-side a distributed application. These techniques include using the socket network programming interface, using C++ wrappers for sockets, to using CORBA. (Postscript or PDF)

  • Comparing Alternative Client Distributed Programming Techniques, SIGS C++ Report, Vol. 7. No. 4, May 1995. This column examines an evaluates three different programming techniques for developing the client-side of a distributed application. These techniques include using the socket network programming interface, using C++ wrappers for sockets, to using a distributed object computing solution based on CORBA. (Postscript or PDF)

  • Modeling Distributed Object Applications, SIGS C++ Report, Vol 7. No. 2, February 1995. This column describes the key features of DOC frameworks (such as CORBA, Network OLE, and OODCE) and explains how these frameworks address distributed application requirements (such as reliability, heterogeneity, location independence, security, and performance). (Postscript or PDF)

  • Introduction to Distributed Object Computing, SIGS C++ Report, Vol. 7, No. 1, January 1995. This column presents an introduction to distributed object computing (DOC) and briefly describes how DOC frameworks differ from conventional network programming interfaces (such as sockets or TLI) and procedural-oriented distributed computing toolkits (such as DCE and Sun RPC). (Postscript or PDF)