Home > Research > Publications & Outputs > The Design and Implementation of OpenORB 2
View graph of relations

The Design and Implementation of OpenORB 2

Research output: Contribution to Journal/MagazineJournal articlepeer-review

Published

Standard

The Design and Implementation of OpenORB 2. / Blair, Gordon S.; Coulson, Geoff; Andersen, Anders et al.
In: IEEE Distributed Systems Online, Vol. 2, No. 6, 01.10.2001.

Research output: Contribution to Journal/MagazineJournal articlepeer-review

Harvard

Blair, GS, Coulson, G, Andersen, A, Blair, L, Clarke, M, Costa, F, Duran-Limon, H, Fitzpatrick, T, Johnston, L, Moreira, R, Parlavantzas, N & Saikoski, K 2001, 'The Design and Implementation of OpenORB 2', IEEE Distributed Systems Online, vol. 2, no. 6. <http://www.computer.org/csdl/mags/ds/2001/06/index.html>

APA

Blair, G. S., Coulson, G., Andersen, A., Blair, L., Clarke, M., Costa, F., Duran-Limon, H., Fitzpatrick, T., Johnston, L., Moreira, R., Parlavantzas, N., & Saikoski, K. (2001). The Design and Implementation of OpenORB 2. IEEE Distributed Systems Online, 2(6). http://www.computer.org/csdl/mags/ds/2001/06/index.html

Vancouver

Blair GS, Coulson G, Andersen A, Blair L, Clarke M, Costa F et al. The Design and Implementation of OpenORB 2. IEEE Distributed Systems Online. 2001 Oct 1;2(6).

Author

Blair, Gordon S. ; Coulson, Geoff ; Andersen, Anders et al. / The Design and Implementation of OpenORB 2. In: IEEE Distributed Systems Online. 2001 ; Vol. 2, No. 6.

Bibtex

@article{ebccd0786e7448a7a6c477d18cb63780,
title = "The Design and Implementation of OpenORB 2",
abstract = "Established middleware platforms such as CORBA and DCOM are not flexible enough to meet the needs of emerging distributed applications. This article discusses the architecture of Open ORB 2, a middleware platform based on reflection and component technology. Middleware has emerged as an important architectural component in modern distributed systems largely because it offers a high-level, platform-independent programming model that helps mask distribution problems. Examples of key middleware platforms include DCE, CORBA, DCOM, .NET, and the Java-based series of technologies, including RMI, Jini, and EJBs (for more information on these platforms, see the Middleware Platforms sidebar). Traditionally, developers have deployed such platforms in areas such as banking and finance to overcome heterogeneity and support the integration of legacy systems. More recently, however, developers have applied middleware technologies in a wider range of areas, including safety-critical, embedded, and real-time systems. It is now becoming apparent that middleware technologies cannot respond to such diverse requirements or technical challenges because of the limitations of the black-box philosophy maintained by developers of most existing middleware platforms. In particular, existing middleware platforms offer fixed services to their users; it is typically impossible to view or alter the implementation of these services. Inevitably, the architecture of this platform then represents a compromise design that features, for example, general-purpose protocols and associated management strategies. It is not possible to specialize platforms to meet the needs of more specific target domains. Other researchers in the field have also recognized these problems.1,2 Middleware designers are aware of these problems and have responded with several initiatives. The Object Management Group, focusing on CORBA, introduced a series of platform specifications that includes real-time CORBA and Minimal CORBA. But these specifications are specific solutions for specific domains, not general solutions to this problem. Modern middleware platforms also typically offer more flexibility through mechanisms such as interceptors and configurable protocol stacks. While these are important developments, they do not offer a complete solution to the problem. We believe next generation middleware platforms should be configurable, to meet the needs of a given application domain, dynamically reconfigurable, to enable the platforms to respond to changes in their environment, and evolvable, to meet the needs of changing platform design. Recently, several reflective middleware technologies have emerged in response to such requirements (see the Related Work sidebar). Reflection is a technology that has previously been deployed successfully in the design of languages and operating systems. The key to the approach is to offer a meta-interface supporting the inspection and adaptation of the underlying virtual machine. In the context of middleware, the meta-interface would support operations to discover the internal operation and structure of the middleware platform (such as the deployed protocols and management structures) and to make changes at runtime. The design of such a meta-interface is central to studies of reflection: The interface should be sufficiently general to permit unanticipated changes to the platform but should also be restricted to prevent the integrity of the system from being destroyed. This article presents the design and implementation of Open ORB, a reflective middleware platform developed at Lancaster University. Specifically, we focus on Open ORB 2, a significant redesign that builds on our experience from the first implementation.3 Note that, for simplicity, we generally refer to Open ORB 2 as simply Open ORB in the rest of this article.",
author = "Blair, {Gordon S.} and Geoff Coulson and Anders Andersen and Lynne Blair and Michael Clarke and Fabio Costa and Hector Duran-Limon and Tom Fitzpatrick and Lee Johnston and Rui Moreira and Nikos Parlavantzas and Katia Saikoski",
note = "This highly cited paper (183 citations in Google Scholar) reports on the OpenORB reflective middleware platform, universally recognized as a leading project in the field of reflective and adaptive middleware. The paper was one of 4 selected for a special issue of IEEE Distributed Systems Online on reflective middleware from the inaugural workshop on the topic (selected from a set of 38 position papers). It identifies 4 meta-models for reflective middleware, and introduces the underlying OpenCOM component technology. Distributed Systems Online is the IEEE's first online-only publication employing the same rigorous review practices as IEEE's print journals. ",
year = "2001",
month = oct,
day = "1",
language = "English",
volume = "2",
journal = "IEEE Distributed Systems Online",
publisher = "Institute of Electrical and Electronics Engineers Inc.",
number = "6",

}

RIS

TY - JOUR

T1 - The Design and Implementation of OpenORB 2

AU - Blair, Gordon S.

AU - Coulson, Geoff

AU - Andersen, Anders

AU - Blair, Lynne

AU - Clarke, Michael

AU - Costa, Fabio

AU - Duran-Limon, Hector

AU - Fitzpatrick, Tom

AU - Johnston, Lee

AU - Moreira, Rui

AU - Parlavantzas, Nikos

AU - Saikoski, Katia

N1 - This highly cited paper (183 citations in Google Scholar) reports on the OpenORB reflective middleware platform, universally recognized as a leading project in the field of reflective and adaptive middleware. The paper was one of 4 selected for a special issue of IEEE Distributed Systems Online on reflective middleware from the inaugural workshop on the topic (selected from a set of 38 position papers). It identifies 4 meta-models for reflective middleware, and introduces the underlying OpenCOM component technology. Distributed Systems Online is the IEEE's first online-only publication employing the same rigorous review practices as IEEE's print journals.

PY - 2001/10/1

Y1 - 2001/10/1

N2 - Established middleware platforms such as CORBA and DCOM are not flexible enough to meet the needs of emerging distributed applications. This article discusses the architecture of Open ORB 2, a middleware platform based on reflection and component technology. Middleware has emerged as an important architectural component in modern distributed systems largely because it offers a high-level, platform-independent programming model that helps mask distribution problems. Examples of key middleware platforms include DCE, CORBA, DCOM, .NET, and the Java-based series of technologies, including RMI, Jini, and EJBs (for more information on these platforms, see the Middleware Platforms sidebar). Traditionally, developers have deployed such platforms in areas such as banking and finance to overcome heterogeneity and support the integration of legacy systems. More recently, however, developers have applied middleware technologies in a wider range of areas, including safety-critical, embedded, and real-time systems. It is now becoming apparent that middleware technologies cannot respond to such diverse requirements or technical challenges because of the limitations of the black-box philosophy maintained by developers of most existing middleware platforms. In particular, existing middleware platforms offer fixed services to their users; it is typically impossible to view or alter the implementation of these services. Inevitably, the architecture of this platform then represents a compromise design that features, for example, general-purpose protocols and associated management strategies. It is not possible to specialize platforms to meet the needs of more specific target domains. Other researchers in the field have also recognized these problems.1,2 Middleware designers are aware of these problems and have responded with several initiatives. The Object Management Group, focusing on CORBA, introduced a series of platform specifications that includes real-time CORBA and Minimal CORBA. But these specifications are specific solutions for specific domains, not general solutions to this problem. Modern middleware platforms also typically offer more flexibility through mechanisms such as interceptors and configurable protocol stacks. While these are important developments, they do not offer a complete solution to the problem. We believe next generation middleware platforms should be configurable, to meet the needs of a given application domain, dynamically reconfigurable, to enable the platforms to respond to changes in their environment, and evolvable, to meet the needs of changing platform design. Recently, several reflective middleware technologies have emerged in response to such requirements (see the Related Work sidebar). Reflection is a technology that has previously been deployed successfully in the design of languages and operating systems. The key to the approach is to offer a meta-interface supporting the inspection and adaptation of the underlying virtual machine. In the context of middleware, the meta-interface would support operations to discover the internal operation and structure of the middleware platform (such as the deployed protocols and management structures) and to make changes at runtime. The design of such a meta-interface is central to studies of reflection: The interface should be sufficiently general to permit unanticipated changes to the platform but should also be restricted to prevent the integrity of the system from being destroyed. This article presents the design and implementation of Open ORB, a reflective middleware platform developed at Lancaster University. Specifically, we focus on Open ORB 2, a significant redesign that builds on our experience from the first implementation.3 Note that, for simplicity, we generally refer to Open ORB 2 as simply Open ORB in the rest of this article.

AB - Established middleware platforms such as CORBA and DCOM are not flexible enough to meet the needs of emerging distributed applications. This article discusses the architecture of Open ORB 2, a middleware platform based on reflection and component technology. Middleware has emerged as an important architectural component in modern distributed systems largely because it offers a high-level, platform-independent programming model that helps mask distribution problems. Examples of key middleware platforms include DCE, CORBA, DCOM, .NET, and the Java-based series of technologies, including RMI, Jini, and EJBs (for more information on these platforms, see the Middleware Platforms sidebar). Traditionally, developers have deployed such platforms in areas such as banking and finance to overcome heterogeneity and support the integration of legacy systems. More recently, however, developers have applied middleware technologies in a wider range of areas, including safety-critical, embedded, and real-time systems. It is now becoming apparent that middleware technologies cannot respond to such diverse requirements or technical challenges because of the limitations of the black-box philosophy maintained by developers of most existing middleware platforms. In particular, existing middleware platforms offer fixed services to their users; it is typically impossible to view or alter the implementation of these services. Inevitably, the architecture of this platform then represents a compromise design that features, for example, general-purpose protocols and associated management strategies. It is not possible to specialize platforms to meet the needs of more specific target domains. Other researchers in the field have also recognized these problems.1,2 Middleware designers are aware of these problems and have responded with several initiatives. The Object Management Group, focusing on CORBA, introduced a series of platform specifications that includes real-time CORBA and Minimal CORBA. But these specifications are specific solutions for specific domains, not general solutions to this problem. Modern middleware platforms also typically offer more flexibility through mechanisms such as interceptors and configurable protocol stacks. While these are important developments, they do not offer a complete solution to the problem. We believe next generation middleware platforms should be configurable, to meet the needs of a given application domain, dynamically reconfigurable, to enable the platforms to respond to changes in their environment, and evolvable, to meet the needs of changing platform design. Recently, several reflective middleware technologies have emerged in response to such requirements (see the Related Work sidebar). Reflection is a technology that has previously been deployed successfully in the design of languages and operating systems. The key to the approach is to offer a meta-interface supporting the inspection and adaptation of the underlying virtual machine. In the context of middleware, the meta-interface would support operations to discover the internal operation and structure of the middleware platform (such as the deployed protocols and management structures) and to make changes at runtime. The design of such a meta-interface is central to studies of reflection: The interface should be sufficiently general to permit unanticipated changes to the platform but should also be restricted to prevent the integrity of the system from being destroyed. This article presents the design and implementation of Open ORB, a reflective middleware platform developed at Lancaster University. Specifically, we focus on Open ORB 2, a significant redesign that builds on our experience from the first implementation.3 Note that, for simplicity, we generally refer to Open ORB 2 as simply Open ORB in the rest of this article.

M3 - Journal article

VL - 2

JO - IEEE Distributed Systems Online

JF - IEEE Distributed Systems Online

IS - 6

ER -