The following are electronic versions of the Object Interconnections column that Steve Vinoski and I write for the C/C++ Users Journal (CUJ) and C++ Report. Steve is the Chief Architect at IONA Technologies, Inc. and has written an excellent paper called CORBA: Integrating Diverse Applications Within Distributed Heterogeneous Environments. He's also written a nice series of columns on other middleware topics for IEEE Internet Computing magazine. In addition, Matthew Newhook writes an online column on CORBA, as well.
All of the columns below address issues related to programming with CORBA. If you have any problems downloading these papers via the WWW they are also available via anonymous ftp from wuarchive.wustl.edu.
This column deepens our coverage of the CORBA Component Model (CCM) by showing how the CORBA Implementation Framework (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.
This column expands 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 needn't be written manually by CCM server application developers.
This column illustrates a hybrid publisher/subscriber and request/response distribution architecture that uses CCM features to implement our familiar stock-quoter example, which has been the driving application in our columns for years.
This column examines the CORBA Component Model, starting with the evolution of programming abstractions from subroutines to modules, objects, and components.
This column shows an alternative approach to supporting reflection in CORBA, which involves having each object returns its own metadata, rather than relying on an external service, such as the IFR. With this approach, each object is capable of returning its own reflection metadata, guaranteed to be accurate and up to date, to clients.
This column describes CORBA Portable Interceptors, which are objects that an ORB invokes in the path of an operation invocation to monitor or modify the behavior of the invocation transparently. Portable Interceptors are a metaprogramming mechanism that implements the Interceptor pattern, which allows applications to extend and control the behavior of a framework.
The Dynamic CORBA Interface Repository provides type information about CORBA interfaces and other entities defined in IDL. It helps ensure the type-safety and correctness of the DII and DSI mechanisms that defer an application's binding onto specific interface types at run-time.
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 the CORBA Dynamic Skeleton Interface enables developers to construct such applications portably.
Like their static counterparts, Dynamic CORBA applications manipulate real-world complex data types, but without having the types compile-time information. This column shows how to use CORBAs Dynamic Any feature to create, examine, and modify data values of any IDL type in Dynamic CORBA applications.
An important and growing class of applications requires the flexibility provided by Dynamic CORBA features. This column covers the basics of the CORBA DII, which is the client-side interface used for dynamic CORBA applications.
Strict control over the association of operations, threads, and networking resources is essential for many distributed real-time and embedded 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.
Distributed real-time and embedded applications need strict control over the scheduling and execution of CPU and memory resources. This column describes Real-time CORBA's support for these needs, focusing on its thread pools and synchronizers.
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 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 is designed for applications with hard real-time requirements, such as avionics mission computing, as well as those stringent soft real-time requirements, such as telecommunication call processing. In this column, we explain the need for the capabilities offered by Real-time CORBA.
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.
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.
A frequently asked question in CORBA circles these days is how the XML (eXtensible Markup Language) relates to CORBA applications. Since there's so much hype surrounding XML, it's hard to know what its real benefits are for CORBA-based systems. In this column, we discuss how XML fits into the overall CORBA picture.
This article illustrates some of the complexity of mapping a language-neutral interface definition language to a feature-rich language like C++. The focus is on server-side mappings and pseudo-objects.
In this column, we explore some ideas for hypothetical alternative mappings of OMG IDL to C++ that use Standard C++ features. The primary design criteria for these alternative mappings are flexibility and ease of use, though we also pay attention to performance issues.
CORBA is a distributed object computing system that aims to be programming language neutral, but ultimately, all CORBA programs must be implemented in one or more programming languages. What enables this to happen is the existence of mappings between CORBA and those languages. Good mappings are thus critical to the long-term success of CORBA. In this colum, we recount the process of developing a C++ mapping for CORBA, a process that was by turns both technical and political, which underscores both the difficulty and importance of standardization.
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.
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.
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
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++.
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 messaging quality of service (QoS) policies. These new features greatly enhance the standard set of request/response communication models that CORBA provides.
This column describes servant managers and default servants. Servant managers are responsible for managing the association of an object (as characterized by its Object Id value) with a particular servant, and for determining whether an object exists or not. Default servants can process requests for an object if no other servant is available for it.
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.
This column explains the use of several POA policies, including transient and persistent CORBA objects.
This column explains what Object Adapters are and describe their roles within a CORBA-based system. In addition, it outlines the new Portable Object Adapter (POA) specification that was recently adopted by the OMG.
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.
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 implementation of the distributed stock quoter system, and evaluates the strengths and weaknesses of the OMG Event Services model and its specification.
This column examines distributed callbacks in CORBA and illustrates why they are useful for decoupling relationships between consumers and suppliers in object-oriented communication applications. The source code examples are based on the HP ORB Plus CORBA implementation.
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.
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.
This column examines and evaluates four techniques for developing multi-threaded servers using the ``thread-per-request'' concurrency model. 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).
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.
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.
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).
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).
Back to C++ Report home page.
Last modified 06:47:37 CDT 13 September 2011