Issues on real-time object request brokers

Problem statement: This study presents an in-depth analysis of the performance of Software Communications Architecture (SCA) component-based waveform applications in terms of inter-component communications. The main limitation with SCA, in the context of embedded systems, is the additional cost introduced by the use of Object Request Broker (ORB) middleware. The ORB middleware handles the interaction between components and objects in SCA distributed environment. This interaction should be highly efficient, due to the real time nature of SCA systems and transparent to the application programmer. Approach: We can achieve high efficiency in SCA systems by enhancing the Inter-Process Communications (IPC) mechanisms in Operating systems (OS) micro kernels, while we achieve transparency through Interface Definition Language (IDL). Different encoding mechanisms like “External Data Representation (XDR), Network Data Representation (NDR) and Common Data Representation (CDR) facilitate inter-component communication transparently and efficiently”. Marshalling procedures format data from the local machine representation to common network representations. A most common encoding mechanism for Common Object Request Broker Architecture (CORBA) systems is CDR representation. Measurements have been performed with ORBExpress DSP as a CORBA distribution and Open Source SCA Implementation Embedded (OSSIE) for SCA implementation. In order to perform these measurements we proposed two metrics for profiling the ORB that are invocation and marshalling. In addition, we propose three elements of data types to evaluate the performance of ORB middleware that are, Basic, Array and Sequence data types. Results: The CORBA bus is really the part, which brings an overhead to the SCA radio systems. This overhead is due to method invocations that have been carried out by ORB middleware. Conclusion: Performance benchmarks of ORBExpress DSP middleware show that, although using CORBA for inter-component communications introduces delays and overheads, the overall effect can be reduced by sending packets of data instead of basic data type elements.

One of the most attractive aspects of the Common Object Request Broker Architecture (CORBA) lies in its open standard nature. Code that is based only on constructs described in the CORBA specification is portable between object request brokers (ORBs) without depending on any single ORB implementation. However, this portability feature is not completely achieved in real-world applications. This paper discusses CORBA portability issues through our experience in implementing a CORBA object group service (OGS) and porting it on different ORBs. In particular, we discuss some implementation choices we made with Orbix and VisiBroker, and we point out the impact of these choices on the service portability and interoperability. This sheds some light on whether the current CORBA specification is mature enough to be deployed in industrial systems that have requirements regarding portability and interoperability. We also present how new CORBA specifications solve part of the shortcomings mentioned in this paper.

This paper describes an innovative framework for a scalable, secure, transparent and distributed medical image-database system which functions in a heterogeneous computer environment using CORBA and DCOM. The framework is designed for implementing telemedicine applications with maximal resource reusability and load balancing. This will enable an existing computer system to be adapted easily to the new system with minimal effort and cost. We have developed a heterogeneous distributed image-database system called MIRage, composed of three subsystems and ORB, based on the CORBA specification as underlying middleware. The ORB, which is a distributed demon structure, enables a cluster of heterogeneous computers to be seen as a single MIRage system, regardless of location and operating system.

The National Solar Observatory is nearing completion of the Synoptic Optical Long-term Investigations of the Sun (SOLIS) project. SOLIS will replace the existing capabilities of the Vacuum Telescope on Kitt Peak near Tucson, Arizona and will provide new scientific capabilities over its expected 25 year life-time. The evolution of the Common Object Request Broker Architecture (CORBA) and the availability of compliant Object Request Brokers (ORBs) and Common Object Services (COS) facilitates the development of cross-platform, multi-language software systems that are reliable and flexible. The SOLIS Communications System employs three ORBs, a naming service and a notification service to support the project's core distributed and real-time control systems that are written primarily in Java or C++ for the Linux, Solaris and VxWorks operating systems. One particularly useful aspect of the communications system is the ease of event monitoring demonstrated by the development of tools such as a logging service and a generic instrument control graphical user interface.

This tutorial addresses how both the Object Management Group (OMG) specifications and the implementation choices made by middleware providers and application developers affect Common Object Request Broker Architecture (CORBA) application scalability. We will cover a range of scalability issues, starting with Object Request Broker (ORB) internals and working outward to full-scale applications, addressing issues such as connection management, Portable Object Adapter (POA) scalability features, multithreading, object lifecycle issues, object location, system configuration, maintenance, and management, and common application architectures. This tutorial is not language-centric and is useful to developers using Java, C++, or any other language to develop CORBA-based applications.

This tutorial addresses how both the Object Management Group (OMG) specifications and the implementation choices made by middleware providers and application developers affect Common Object Request Broker Architecture (CORBA) application scalability. We will cover a range of scalability issues, starting with Object Request Broker (ORB) internals and working outward to full-scale applications, addressing issues such as connection management, Portable Object Adapter (POA) scalability features, multithreading, object lifecycle issues, object location, system configuration, maintenance, and management, and common application architectures. This tutorial is not language-centric and is useful to developers using Java, C++, or any other language to develop CORBA-based applications.

Distributed computing applications rely on transmissions of messages between processes. However, as workstations are not intended to manage this kind of communications, it is necessary to use some communication tools known as message passing libraries. Currently, MPI (Message Passing Interface) and PVM (Parallel Virtual Machine) are the most used. In addition, the need for interoperability among the rapidly proliferating amount of hardware and software led to the definition of CORBA (Common Object Request Broker Architecture), which standardizes the execution support of distributed object applications. This architecture offers good interoperability and encapsulation support. Moreover, its method invocation mechanism, offers several features and can be used as a good communication model. Consequently, the use of such an architecture for distributed and grid computing applications seems interesting and promising. However, CORBA is always criticized on the performance level. By taking account of all these elements, a performance evaluation of CORBA seems necessary. The aim of the paper is to present benchmark results of some CORBA implementations (ORBacus and TAO) and to compare them with those of the two message passing libraries MPI (MPICH and LAM) and PVM, by using a Network of WorkStations (NOW).

Designing with the 68008 microprocessor: Barth, A JWireless World Vol 90 No 1579 (April 1984) p 30

The authors intention is to demonstrate how the principles of the federated database systems and the mediator approach can be applied for mastering the software systems integration problems in the distributed production management. This chapter gives an insight into the Institute’s internal research on the integration mechanisms for tailoring autonomous and heterogeneous systems in a multi-site production environment. This research combines results of several CEC ESPRIT and national projects and is focused on integration of already existing, independent software systems — mostly large commercial products. An integration approach chosen is based on both tightly and loosely coupled federations with mediators as building blocks for virtual interfaces. As a data exchange mechanism a Common Object Request Broker Architecture is applied.KeywordsOrganizational AspectCommon Object Request Broker ArchitectureVirtual ProcessorObject Request BrokerInformation ArchiveThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

This chapter introduces a programming environment for SCI clusters that takes advantage of both parallel and distributed programming paradigms. It aims at helping programmers to design high performance applications based on the assembling of generic software components. This environment is based on CORBA (Common Object Request Broker Architecture), with our own extensions to support parallelism across several cluster nodes within a distributed system. Our contribution concerns extensions to support a new kind of object, which we call a parallel CORBA object (or parallel object), as well as the integration of message-passing paradigms, mainly MPI, within a parallel object. These extensions exploit as much as possible the functionality offered by CORBA and require few modifications to an available CORBA implementation. This paper reports on these extensions and the description of a runtime system, called Cobra, which provides resource allocation services for the execution of parallel objects.

The robot middleware is a key concept in developing complex robot systems even in geographically distributed environment. Giving a handy API, reusable standardized components and communication channels together with some automatism, the robot middleware helps the user to build easily reconfigurable systems. The behavior of the components and the manner of interaction among them are standardized by the Robotic Technology Component (RTC) specification. One implementation of the RTC specification is the OpenRTM-aist. It is a well written and convenient modular system built upon the Common Object Request Broker Architecture (CORBA). The first version of CORBA is released in 1991. Nowadays the CORBA is getting more and more out of date. Our ultimate goal is developing a new robot middleware in which we apply a modern distributed framework instead of CORBA. As a first step of the substitution we suggest some practical extensions of the OpenRTM-aist by the adaptation of the Internet Communication Engine (ICE) for component communication and the introduction of the web application concept for system editing and control. Having these structural modifications the resulting system became more powerful than the original system has been. The chapter introduces some structural and implementation details of the OpenRTM-aist together with the results of the experiments done for the performance comparison of the original and extended system.

Robot systems are comprised of several elements working together as a whole. The specific task of the robot system determines which elements are required. These reusable, fungible elements can be implemented as components which connect each other via communication channels and well-defined interfaces. The behavior of the components and the manner of interaction among them can be standardized by the Robotic Technology Component (RTC) specification. One promising implementation of the RTC specification called OpenRTM-aist is a software platform assisting to the component-oriented robot system development. In OpenRTM-aist both the specification and the implementation is based on the Common Object Request Broker Architecture (CORBA) and its remote method invocation. The first version of CORBA was released in 1991. In spite of the updates CORBA is getting more and more out of date. Several solutions exist which can replace or extend CORBA. Our ultimate goal is replacing the CORBA and setting up a modern distributed robot system development framework which is based on the original OpenRTM-aist specification. To be the first step of this task in this paper we suggest some practical extensions of the existing OpenRTM-aist robot middleware. These modifications are the adaptation of the Internet Communication Engine (ICE) for inter-component communication and as a new scheme, the introduction of the web application concept. After these structural modifications the resulting system became more powerful, and thanks to the web application concept much more user friendly.

The distributed object standards Component Object Model (COM) and Common Object Request Broker Architecture (CORBA) apply object technology to design and use software components. While COM forms a good front end for the Microsoft Systems, CORBA is well suited for middle tier and back end Unix servers. By integrating them, the user can get a combination of the best attributes of both the systems. Bridging software is needed to transparently couple components from both the systems. This paper discusses a static method of achieving COM/CORBA interworking using a generic IDL compiler. It maps the COM and CORBA IDLs onto an intermediate representation from which stubs and skeletons are generated. Further, threading is used to allow multiple COM clients to contact a single CORBA server using Internet Interoperable Protocol / Transmission Control Protocol (IIOP/TCP) as a communication medium. To improve the networking speed and to bring about multicasting, IIOP/UDP has also been tried as a communication medium. The Object Reference (OR) from the implementation repository (IMR) and the Object Identifier (OID) from the registry have also been cached to improve the speed of the name lookup mechanism.

Efficient and predictable demultiplexing is necessary to provide real-time support for distributed object computing applications developed with CORBA. This paper presents two contributions to the study of demultiplexing for real-time CORBA endsystems. First, we present an empirical study of four CORBA request demultiplexing strategies (linear search, perfect hashing, dynamic hashing, and active demultiplexing) for a range of target objects and operations. Second, we describe our use of the perfect hashing and active demultiplexing strategies to develop a high-performance, real-time object request broker (ORB) called TAO.

DIMMA - A Distributed Interactive Multi-Media Architecture - is an open distributed processing (ODP) platform that facilitates the production of distributed applications. It has particular support for those applications that have soft real-time constraints, and those that make use of multi-media. DIMMA consists of a portable layer of distribution engineering (middleware), together with tools to interface applications to this engineering. The most popular commercial ODP platform is the Common Object Request Broker Architecture (CORBA) whose definition is managed by the Object Management Group (OMG). In recognition of this popularity, DIMMA supports a CORBA compliant API so that CORBA applications may be easily ported to or from the DIMMA platform. This paper describes the example implementation of DIMMA. It gives an overview of the motivations behind the design of DIMMA and then highlights some key features of the DIMMA implementation. It concludes with a brief analysis of DIMMA's performance