Adding Roles to CORBA Objects

The Computer …, 2001

Traditional IDLs were defined for describing the services that objects offer, but not those services they require from other objects, nor the relative order in which they expect their methods to be called. In this paper we propose an extension of the CORBA IDL that uses a sugared subset of the polyadic π-calculus for describing object service protocols, aimed at the automated checking of protocol interoperability between CORBA objects in open component-based environments. In addition, some advantages and disadvantages of our proposal are discussed, as well as some of the practical limitations encountered when trying to implement and use this sort of IDL extensions in open systems.

2000

Traditional IDLs were defined for describing the services that objects offer, but not those services they require from other objects, nor the partial ordering in which they expect their methods to be used. In this paper we propose an extension of the CORBA IDL that uses a sugared subset of the polyadic π-calculus for describing object service protocols, aimed towards the automated checking of protocol interoperability between CORBA objects in open component-based environments. Furthermore, some advantages and disadvantages of our proposal are discussed, as well as some of the practical limitations encountered when trying to implement and use this sort of IDL extensions in open systems.

Common Object Request Broker Architecture (CORBA) is a standard for hybrid applications that is designed and supported by Object Management Group (OMG). This standard defines protocols and Relational Data Model Objects / Services which can be connected into heterogeneous software (written in different languages). So we can use CORBA to share the distributed object platform, without worrying about where they are located or who has designed them. CORBA can package the codes (in some programming languages) and add the packaging information, such as the ability to execute the codes and how to implement them. So this package or object code can execute some other programs or CORBA objects that they are in the network. CORBA uses a relational language called Interface Definition Language (IDL) to specify the interface of the classes and objects. The IDL definitions can be connected to the written codes in some popular languages such as Java, C++, Ada, and Smalltalk. To know the functionality and behaviors of objects and their interfaces, we need to abstractly model their definitions and specifications. Models are in different types (e.g., physical, mathematical, numerical, software, etc.) and have a variety of critical applications in all areas of science and technology. In other words, a summary of the facts is known as the models. Therefore, it could be mentioned that there are two objectives for the model including exploration and specification, the modeling process considers either or both of them. One of the main approaches to the modeling process is based on state-transition systems such as Kripke structures, Petri nets, and Büchi automata. The paper's ultimate goal is to provide a method to model the formal behavioral specifications of CORBA objects. In this paper, we use the formalism of Büchi automata as the operational semantics for the behavior of CORBA based objects. For this purpose, two different approaches that include using Petri nets as basic operational models and translating them to Büchi automata and direct using of Büchi automata are considered. Also, we show the applicability of our suggested modeling approaches by considering them in some case studies. As result, a Büchi automaton is a better model to verify a system.

ACM SIGPLAN Notices, 2000

CORBA is now established as one of the main contenders in object-oriented middleware. Beyond the definition of this standard for distributed object systems, the Object Management Group (OMG) has specified several object services (Common Object Services, COS) that should foster the interoperability of distributed applications. Based on experiment, the goal of this paper is to show that the OMG's style of specification of the CORBA services is not suited to guarantee that implementers will produce interoperable and substitutable implementations. To illustrate our point, we give an account of an experiment based upon the formal specification of one COS, namely the CORBA Event Service. This formal specification highlights several ambiguities and under-specifications in the OMG document. We then test several commercial and public domain implementations of the CORBA Event Service, in order to assess how the implementers have dealt with these under-specifications. We show that the choi...

Proceedings of the 15th …, 2000

CORBA is now established as one of the main contenders in object-oriented middleware. Beyond the definition of this standard for distributed object systems, the Object Management Group (OMG) has specified several object services (Common Object Services, COS) that should foster the interoperability of distributed applications. Based on experiment, the goal of this paper is to show that the OMG's style of specification of the CORBA services is not suited to guarantee that implementers will produce interoperable and substitutable implementations. To illustrate our point, we give an account of an experiment based upon the formal specification of one COS, namely the CORBA Event Service. This formal specification highlights several ambiguities and under-specifications in the OMG document. We then test several commercial and public domain implementations of the CORBA Event Service, in order to assess how the implementers have dealt with these underspecifications. We show that the choices made by the implementers lead to incompatible implementations. We finally suggest a solution to overcome the problem of specification of object services, which satisfies the views of both implementers and users. Specifically, we suggest that the specification of such services be made using a formal description technique, and that implementers be provided with test cases derived from the formal specification.