CORBA AND MPI-BASED “BACKBONE” FOR COUPLING ADVANCED SIMULATION TOOLS

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).

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

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.

Describes the initial design work of the New Zealand Distributed Information Systems (NZDIS) research project, which seeks to develop an architecture for building distributed information systems from existing information resources, based on software agent and distributed object technologies. An agent-based architecture is used, with messages exchanged via the FIPA (Foundation for Intelligent Physical Agents) agent communication language (ACL). Novel features of this system include the use of standards from the object-oriented programming community, such as the Common Object Request Broker Architecture (CORBA) as a communications infrastructure, the Unified Modeling Language (UML), which is used as an ontology representation language, the Object Data Management Group's Object Query Language (OQL), which is used for queries, and the Object Management Group's Meta Object Facility (MOF), which is used as the basis for an ontology repository agent. 'Stringified' object references may be returned as the content of ACL messages, allowing query results to be made available via a variety of CORBA interfaces.

Today, more and more distributed computer applications are being modeled and constructed using real‐time principles and concepts. In 1989, the Object Management Group (OMG) formed a Real‐Time Special Interest Group (RT SIG) with the goal of extending the Common Object Request Broker Architecture (CORBA) standard to include real‐time specifications. This group's most recent efforts have focused on the requirements of dynamic distributed real‐time systems.One open problem in this area is resource access synchronization for tasks employing dynamic priority scheduling. This paper presents two resource synchronization protocols that the authors have developed which meet the requirements of dynamic distributed real‐time systems as specified by Dynamic Scheduling Real‐Time CORBA (DSRT CORBA). The proposed protocols can be applied to both Earliest Deadline First (EDF) and Least Laxity First (LLF) dynamic scheduling algorithms, allow distributed nested critical sections, and avoid unnecessary runtime overhead. In order to evaluate the performance of the proposed protocols, we analyzed each protocol's schedulability. Since the schedulability of the system is affected by numerous system configuration parameters, we have designed simulation experiments to isolate and illustrate the impact of each individual system parameter. Simulation experiments show the proposed protocols have better performance than one would realize by applying a schema that utilizes dynamic priority ceiling update. Copyright © 2004 John Wiley & Sons, Ltd.

In this paper, we present the management of mobile switching center (MSC) trunks and trunk groups in cellular and personal communications systems (PCS) networks. We discuss platform-centered network management approaches based on simple network management protocol (SNMP) and common management information protocol (CMIP). We also describe the Common Object Request Broker Architecture (CORBA <sup xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">∗</sup> ) solution for distributed computing and implementation of distributed objects based on Object Management Group (OMG) Interface Definition Language. <sup xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">∗</sup> CORBA appears to provide a better backbone for manager and agent applications than CMIP. In higher-level designs, the manager and agent applications can be adapted to a CMIP-style interface.

A growing class of real-time systems require end-to-end support for various quality-of-service (QoS) aspects, including bandwidth, latency, jitter and dependability. Applications include command and control, manufacturing process control, videoconferencing, large-scale distributed interactive simulation, and testbeam data acquisition. These systems require support for stringent QoS requirements. To meet this challenge, developers are turning to distributed object computing middleware, such as the Common Object Request Broker Architecture, an Object Management Group (OMG) industry standard. In complex real-time systems, DOC middleware resides between applications and the underlying operating systems, protocol stacks and hardware. CORBA helps decrease the cycle time and effort required to develop high-quality systems by composing applications using reusable software component services rather than building them entirely from scratch. The Real-Time CORBA specification includes features to manage CPU, network and memory resources. The authors describe the key Real-Time CORBA features that they feel are the most relevant to researchers and developers of distributed real-time and embedded systems.

Traditionally, most definitions seeking to characterize middleware suggest that it is the software that facilitates remote database access and systems transactions. More recently, the term has come to be associated-somewhat limitingly-with distributed platforms such as the Open Software Foundation's Distributed Computing Environment (DCE) and the Object Management Group's Common Object Request Broker Architecture (CORBA). And some have loosely applied it to systems as diverse as workflow support environments and even to the Web itself. We believe the essential role of middleware is to manage the complexity and heterogeneity of distributed infrastructures and thereby provide a simpler programming environment for distributed-application developers. It is therefore most useful to define middleware as any software layer that is placed above the distributed system's infrastructure-the network OS and APIs-and below the application layer.

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.

The integration of heterogeneous networks and systems is one of the more urgent requirements expressed by networks and computer users. ISO and ITU-T normalisation bodies have contributed in a significant manner to the definition of a global management framework called TMN (Telecommunication Management Network). TMN is an agreed framework that permitted to a number of public and private network operators to build their management system. However, these existing systems are confronted to the heterogeneity of emerging technologies. In fact, new equipment is built with specific management interfaces, which are not conforming, to the TMN one. The heterogeneity considered in this paper is the one that emerges from the OMG (Object Management Group) CORBA (Common Object Request Broker Architecture). In fact, a lot of CORBA based systems are emerging in the field of management. In this context, telecommunication operators are willing in the short term to use their existing management systems to control them in a uniform way. The aim of this paper is to propose solutions to these problems through the use of Q Adapter that permits to integrate CORBA based equipment into the global management framework based on TMN.KeywordsManagementCORBAOSIAdaptationObjectProtocolService

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.

The Robocop project defines an open, component-based architecture for the middleware layer in high-volume consumer electronic products. This architecture supports component trading, dynamic upgrading and extension of products in the field, and robust and reliable operation. The architecture consists of a development framework, an execution framework and optional download and resource management frameworks. The core of the architecture is the component model, which is defined at two levels. At the development level, a component is defined to be a collection of models and the relations between these models. These models allow system builders to reason a-priori about systems composed from the components. At the execution level a binary component model has been defined, combining elements of Object Management Group (OMG), Common Object Request Broker Architecture (CORBA), Microsoft's Component Object Model (COM), and Philips' Koala. Key elements of the executable component model are explicit dependencies, dynamic third party binding, and a well-defined lifecycle that includes explicit interaction points with the resource management framework.

Various benchmarks exist for assessing performance characteristics of commodity hardware utilized in high performance computing (HPC) cluster environments. An additional assessment of bandwidth for Intel's 44-core processors considers network saturation via message passing focused on indirectly connected cores. The benchmark developed in this work provides a means of measuring bandwidth of two Broadwell nodes when communicating inter-chassis with all cores of each node utilized. This benchmark was developed in three phases using Message Passing Interface (MPI). First, the bandwidth measure was tested for MPI_Send operations in point-to-point communication. Second, the merge sort algorithm was implemented as a means of assessing bandwidth and a tree-structured communication algorithm was developed and implemented to maximize internode communication and minimize intra-node communication. Third, the benchmark was tuned to the configuration of the Distributed Environment for Academic Computing (DEAC) Cluster. A second benchmark removing local computation from the merge sort algorithm effectively performs a gather operation in a tree-structure. These benchmarks were tested and compared with relevant Intel MPI Benchmarks (IMB) tests. In the developed benchmarks, the nodes requested significantly more bandwidth than in the existing MPI_Gather operation and IMB benchmarks due to the large size of the messages simultaneously placed on the network.

Many universities and research laboratories have developed low cost clusters, built from Commodity-Off-The-Shelf (COTS) components and running mostly free software. Research has shown that these types of systems are well-equipped to handle many problems requiring parallel processing. The primary components of clusters are hardware, networking, and system software. An important system software consideration for clusters is the choice of the message passing library. MPI (Message Passing Interface) has arguably become the most widely used message passing library on clusters and other parallel architectures, due in part to its existence as a standard. As a standard, MPI is open for anyone to implement, as long as the rules of the standard are followed. For this reason, a number of proprietary and freely available implementations have been developed. Of the freely available implementations, two have become increasingly popular: LAM (Local Area Multicomputer) and MPICH (MPI Chameleon). This thesis compares the performance of LAM and MPICH in an effort to provide performance data and analysis of the current releases of each to the cluster computing community. Specifically, the accomplishments of this thesis are: comparative testing of the High Performance Linpack benchmark (HPL); comparative testing of su3_rmd, an MPI application used in physics research; and a series of bandwidth comparisons involving eight MPI point-to-point communication constructs. All research was performed on a partition of the Wyeast SMP Cluster in the High Performance Computing Laboratory at Portland State University. We generate a vast amount of data, and show that LAM and MPICH perform similarly on many experiments, with LAM outperforming MPICH in the bandwidth tests and on a large problem size for su3_rmd. These findings, along with the findings of other research comparing the two libraries, suggest that LAM performs better than MPICH in the cluster environment. This conclusion may seem surprising, as MPICH has received more attention than LAM from MPI researchers. However, the two architectures are very different. LAM was originally designed for the cluster and networked workstation environments, while MPICH was designed to be portable across many different types of parallel architectures.

To improve the presentation of B2B (Business to Business) and B2C (Business to Consumer) regarding venture wide Service Oriented Architecture (SOA), we need middleware interoperability particularly with agent building to be specific CORBA (Common Object Request Broker Architecture) proposed by Object Management Group ORB programming named ORBeline. Unmistakable models for client server correspondences have just been created and executed specifically Handle Driven ORB (H-ORB), Forwarding ORB (F-ORB), and the Adaptive ORB (A- ORB). This paper concentrates how to improve the presentation of the interoperability in Adaptive ORB (A-ORB) as for client server collaboration in N-level engineering alongside multithreading condition. We have presented a strategy called linear discriminant interoperable support learning method and how it will in general be used for improving the presentation of interoperability is examined. The outcome gives the framework conduct especially the impact of message measure, between hub deferrals; torpidity and flexibility of solicitation/reaction administration times for the A-ORB engineering are broke down.