Explore chapters and articles related to this topic
Next-Generation Technologies to Enable Sensor Networksa
Published in Syed Ijlal Ali Shah, Mohammad Ilyas, Hussein T. Mouftah, Pervasive Communications Handbook, 2017
Joel I. Goodman, Albert I. Reuther, David R. Martinez
Because many systems use a diverse set of hardware, operating systems, programming languages, and communication protocols for processing sensor data, the manpower and time-to-deployment associated with integration have a significant cost. A middleware component providing a uniform interface that abstracts the lower level system implementation details from the application interface is the common object request broker architecture (CORBA) [27]. CORBA is a specification and implementation that defines a standard interface between a client and server. CORBA leverages an interface definition language that can be compiled and linked with an object’s implementation and its clients. Thus, the CORBA standard enables client and server communications that are independent of the host hardware platforms, programming language, operating systems, and so on. CORBA has specifications and implementations to interface with popular communication protocols such as TCP/IP. However, this architecture has an open specification, general interORB protocol (GIOP) that enables developers to define and plug in platform-specific communication protocols for unique hardware and software interfaces that meet application-specific performance criteria.
Web Services
Published in Praveen Kumar, Jay Alameda, Peter Bajcsy, Mike Folk, Momcilo Markus, Hydroinformatics: Data Integrative Approaches in Computation, Analysis, and Modeling, 2005
CORBA is an open, vendor independent, language neutral specification, and related infrastructure that allows multiple CORBA-based applications to interoperate [11]. Applications in CORBA are all objects, as discussed previously. However, CORBA mandates that one separates the interface for the object from the implementation. The interface is described through the Object Management Group (OMG) Interface Definition Language (IDL) [12]. The IDL is the only mechanism other CORBA applications have to access functionality in another application. Note that IDL is language independent, but has mappings to many popular languages such as C++ and Java. Also, IDL requires typing of each CORBA object, and the variables used in the IDL. This works to allow interoperability between the CORBA applications. Practically speaking, after generating IDL, a CORBA developer would compile the IDL into client stubs and object skeletons, which are used in the clients and servers (respectively) to act as proxies to each other. Additionally, the stubs and skeletons work with the Object Request Broker, or ORB, to mediate client operations on object instances to make it appear that the client is directly operating on the object. Additionally, by virtue of every object instance having a unique object reference, a client is able to find the instance that they require. Finally, note that this is a binary standard for object interoperability.
Portable Software Technology
Published in David R. Martinez, Robert A. Bond, Vai M. Michael, High Performance Embedded Computing Handbook, 2018
Distributed programming frameworks provide location independence in a network. An example of such a framework is the Common Object Request Broker Architecture (CORBA), maintained by the Object Management Group (OMG). In CORBA, which comes from the world of distributed business computing, services are provided by an Object Request Broker (ORB) object. The ORB knows how to identify and find services in the system and isolates the client from the location of the service. While this approach is very flexible, it has the potential to be very time-consuming. Therefore, CORBA is most useful in HPEC systems for communication of low-volume control information. More discussion of CORBA is provided in Chapter 18.
EOS: enterprise operating systems
Published in International Journal of Production Research, 2018
Joseph Rahme Youssef, Gregory Zacharewicz, David Chen, François Vernadat
At the beginning of the 1990’s, inspired by the IIS of CIMOSA, the first version of the Common Object Request Broker Architecture, known as CORBA, was proposed as a ‘standard’ in 1991 by the object management group (OMG). The final version is CORBA 3.3 published in November 2012 (OMG 2012). CORBA was designed for facilitating and enabling the communication of systems deployed on diverse platforms, written in different languages and implemented on different operating systems and models. It offered benefits such as inheritance, information hiding, reusability and polymorphism. However, CORBA can be better considered as a simple enterprise application integration platform rather than a true enterprise operating system (Bryan, Dipippo, and Fay-Wolfe 2005). For instance, it does not provide functionality for enterprise model execution.
Smart CPS: vertical integration overview and user story with a cobot
Published in International Journal of Computer Integrated Manufacturing, 2019
One of the first attempts to guide in a standardised fashion the development of MIES was SEMATECH CIM (Hawker 1999). Built on common object request broker architecture (CORBA), a standard used to achieve interoperability between distributed systems (CORBA n.d.). SEMATECH CIM was a standardised framework developed as a solution to the obsolete and inflexible custom built MIES to implement interoperability under a standardised approach (Cheng et al. 1999).