Interoperability and Granularity: Some limits of Corba Patrice Cros Onera, CERT 2 Ave E. Belin, BP 4025 31055 Toulouse Cedex [email protected]

Louis F´eraud Universit´e P. Sabatier, IRIT 118 rte de Narbonne 31077 Toulouse Cedex [email protected] February 27, 1998

Abstract In order to discuss Corba granularity, we present two case studies addressing fine grained objects (the Hector system), and coarse grained ones (Corba applicability in CAD Airplane). Finally we give a synthesis of some Corba limits which are very similar in both cases.

1 Introduction Ten years ago the framework concept was already known as ”semi-complete application that can be specialized to produce custom applications”, [5]. In contrast to OO reuse techniques such as classes libraries, frameworks are targeted for much larger application domains. Thus implementations of OMG’s Corba, (but also other frameworks such as DCE, Java RMI, and so on) play an important role in software development either at fine or coarse grained level. There are no architectural arguments about Corba only managing fine or coarse grained distributed objects, but operational ones remain in interest. Indeed, the Corba specification told explicitly that it takes into account a wide range of granularities, but there is not scaling marker in the Corba specification, which can help us to characterize the granularity itself. For new distributed object applications (see below in section 3.1 the Hector system developed at IRIT [1]), objects would normally be finely grained. Nevertheless, current trends at industrial level are to begin with Corba, using existing applications (see below a short description of Corba applicability in CAD Airplane1in section 3.2), and obviously objects are much larger than they are at programming language level. For example in such a context, a whole application could be a Corba object. This paper mainly addresses two viewpoints when putting in practice a middleware: the former one is devoted to micros level, (i.e. programming using classical components), the latter one concerns a macros level defining large applications (using several components based applications). In practice, Corba is used in both cases. 1

This work was partially supported by A´erospatiale Toulouse under contract number 552.0020.97

2 Confronting Corba to “Frameworks” and “Components” We can make the assumption that large applications and classical programs possesses the same structure: in both cases objects are working using a client/server model in a distributed information system. However, this appearance leads to confusions since problems occurring at micro and macro level are very different. The main difference is obviously the size of the objects. For that reason, this paper addresses the problem of granularity in the Corba practice. For the sake of clarity, we will first introduce the concepts of a framework and of granularity features occurring in implementation of Corba, (Orbix [4]).

2.1 Framework Design principles underlying frameworks are independent of domain to which they are applied. Nevertheless, as proposed in [2] there is a possible frameworks classification (UWS model) according to their scope as follows, User Infrastructure, primarily used internally within a software organization (for example IHM, Web tools and more generally user oriented tools), Wrapping, or middleware commonly used to manage distributed applications, are rapidly becoming commodities (ORB frameworks and transactional database), and finally Services, or Enterprise application supporting the development of products directly, (such as avionics and manufacturing engineering). In such a classification levels U and W are very generic, and the framework concept (semi-complete application) is of great interest for developers working on tools integration. But for enterprise applications itself the component concept is better than the framework one due to specificities of problems. As a consequence, the granularity could be coarse grained at U and W level, and coarse or fine grained at S level (enterprise applications).

2.2 Granularity features in Corba implementation In Orbix terminology, a server is made of one or several objects offering one or several methods through interfaces. Server activation can be done in three ways according to the number of clients and to the size of resulting process. Shared mode: given by persistent servers which makes that all server’s objects are loaded in the same process for all clients. Unshared mode: in which all server’s objects are loaded in the same process for only one client. Calling method mode: in this case there is only one object implementation in the process, but it is not always possible, (it is possible if an object implementation exists for the method). Since objects are distributed in Corba, it is possible to force granularity at operational level. Indeed, not depending on functional specification, object decomposition into several servers must be done according to some operational concerns. 2

In such a way, granularity of servers allows to define client server architecture and communication protocols; as an example, communication between a client and a persistent server can be done either by shared memory or by message passing. If the choice is not relevant at functional level, it can result in several incompatible architectures during implementation

3 Presentation of test applications In order to compare fine grained applications with coarse one, we take an example of each one, HECTOR which is at S level in the previous classification is fine grained, and middleware for ASA (in French, Atelier Syst`emes Avions) is obviously coarse grained. For both applications HECTOR and Conception of Airplane Software Products with ASA, we give a short overview and present main properties in interest for granularity purpose.

3.1 An overview of the HECTOR model The HECTOR (HiErarchical parallel ComponenTs fOr Reusability) model was designed to program parallel and distributed applications using an object oriented approach. Basically objects are split in two parts: a functional part (”what is the object?”) a synchronization part (”when is used the object?”). Both of these parts are described by the means of two ancestors lines: a traditional one (”action classes”) and an original other one (”synchronization classes”). In a synchronization class, a guard is devoted to each method. This guard is composed of a boolean expression and a statement list. Crossing a guard occurs when its boolean expression is true and then the statement list is executed. The major originality of the HECTOR model rests on its large possibilities of reuse. Action classes, of course, are reusable, so are synchronization classes. These possibilities allow the inheritance of synchronization classes and extensions to new methods avoiding the inheritance anomaly. The above approach is not related to a specific object oriented language : HECTOR can be seen as a super language (a model) aiming at extending any sequential oriented language (abbreviated OOL) to parallelism. Example : SYNCH READERS AND WRITERS is a synchronization class related to an action class implementing a file. The file may be used w.r.t. readers and writers access policy. SYNCH_READERS_AND_WRITERS : class synchronizes op1, op2 constraints for op1 : guarantee no_current (op2) end guarantee ; for op2 : guarantee no_current (op1) and no_current (op2) end guarantee ; end class SYNCH_READERS_AND_WRITERS;

3

FILE: class exports READ, WRITE features read: procedure ... end prodecure; write: procedure ... end procedure; end class FILE ; The construction of a class implementing a file in a parallel environment may be obtained by inheriting the class FILE and through the class SYNCH READERS AND WRITERS as follows: READERS_AND_WRITERS: class exports READ, WRITE inherits FILE via SYNCH_READERS_AND_WRITER The HECTOR model can also be used for building distributed applications running on networks. To achieve this goal, we supposed that HECTOR is a tool for the objects designer who wants to master distribution at run time. In such a case, the problem of extending a sequential OOL to distribution supposes the ability of furnishing the designer with programming concepts allowing him to describe the location of objects during the execution of the application. It is to notice that a distributed object may be fragmented, replicated or may migrate from an host to another one. Dealing with this problem in HECTOR is reached using the original concept of a ”configuration” class, 2, 10. The HECTOR approach to express distribution control lies on the notion of a ”virtual configuration”. Such a configuration describes a virtual topology and the evolution of objects or fragments of objects at run time. A dynamic location strategy can be applied to objects belonging to different classes. 3.1.1 Distribution with HECTOR Basically, a virtual configuration is composed by an initial distribution of fragments of objects on hosts and set of rules describing their evolution at run time. An evolution rule contains a boolean expression describing a state of the topology, and an action (replicate, delete, move...). A virtual configuration can grow while increasing the number of sites, with adding new evolution rules, with threading new fragments i.e using specializations. The possibilities of reuse and of specialization lead us to consider a virtual configuration as a software component described by a class: the ”configuration class”. As usual classes, configuration classes are organized in hierarchies built using an inheritance mechanism. When programming distributed applications, it is now possible to design HECTOR distributed objects : these objects are instantiated using ”action” classes, ”synchronization” classes (as initially) and ”configuration” classes. This approach of distributed programming permits three degrees of freedom and consequently three degrees of reuse. The HECTOR model has been implemented on a workstation network. The possibilities of HECTOR have first been tested using traditional synchronization problems 4

such as readers and writers we presented in the introduction of this section. Addressing this kind of problems only necessitate to deal with small granularity. When implementing solutions of realistic problems using HECTOR, this granularity will increase up to the one used in classical object object oriented programs. It is to be noticed that the concept of ”reusability” appearing in the acronym HECTOR refers the one occurring in the object oriented methodology and does not cover the large field of software reuse. 3.1.2 Integration of interoperability As we stated in the above presentation, HECTOR is an OO model devoting to the extension of OO sequential languages to parallelism and distribution. In this approach the sequential OO language is a kind of parameter occurring a simple tool to design the architecture of a parallel and distributed application. Thus, it appears very natural to use different parameters in an parallel application, for that person putting in practice interoperability in the HECTOR model was a logical continuation of our work. In order to implement interoperability we chose to use standard Corba [6]. The main motivation for this choice was the large facilities provided by Corba even though, as we will discuss in the last section of this paper, Corba suffers from important limitations. In the following subsections, we will present how we solved the integration of interoperability in the HECTOR model. The main problem we were confronted to, when putting in practice interoperability, was the implementation of synchronization classes. In order to keep the benefits of Corba, we decided to increase the so-called IDL by annotations depicting additional specifications to describe synchronization constraints. These annotations occur as comments in a standard IDL specification. This strategy guarantees that specifications of the sequential parts of the concurrent application remains standard, logically separated from specifications of concurrency. The former ones can be processed by the usual tools provided by Corba environments while the latter ones need a special treatment. Processing the annotations lead to the implementation of the synchronization of objects in the Corba environment. When defining such a process, several possibilities can be used : introducing synchronization code within the synchronized objects inserting an intermediate object devoted to synchronization between the client and the server using a proxy implementing the interface of controlled methods. Among the above approaches, the first one is operationally unrealistic. The use of an intermediate object necessarily induces modifications of the ”stub” and ”the skeleton” generated by the IDL specification because of the new communication on one hand between the client and the intermediate object and on the other hand between this object and the server. In fact, we put in work the third solution, i.e. the use of a proxy. The solution consists in substituting the server by a synchronized object called a ”surrogate”, (cf. figure 1). The surrogate possesses the same interface and the same name of the replaced server, it is obtained by multi inheritance of the server and the synchronization class. 5

Client

Server Class

Synchronisation Class

Server

Server Stub

Server Skeleton

ORB

Figure 1: Synchronized object as surrogate server The implementation of this method necessitates, the translation of the annotation of IDL in the definition of the synchronization class and the instantiation of the server by multi-inheritance. This process can easily be automated. The only weak point of this approach is the requirement of coding the server in an object oriented language supporting multi- inheritance. When this requirement is not satisfied, we proposed a new scheme. In this case, the synchronization is implemented by a proxy depicting the server in the environment of the client, (cf. figure 2). Client

Synchronized Class

Server

Synchronized Server Skeleton

Server Stub

Server Skeleton

ORB

Figure 2: Proxy server When applying such a scheme activation, condition are verified in the space of the client.

6

3.2 Conception of Airplane Software Products In order to develop new airplane software products for Airbus, there is several industrial actors; A´erospatiale, but also Partners, such as members of Airbus Consortium and electronic fittings factories (Sextant for example). The actual problem concerns improvement of interoperability and communications between workshops, while upgrading used systems. In such a context the future workshop must be defined using distributed systems concepts and tools. 3.2.1 Workshop Architecture (A´erospatiale) The process redesign project began implementation steadily, involving experimentation with Corba during several prototype projects. Beginning with simple single-user applications experimenting with OO technology, some directions emerge that take into account existing workshop architecture.

STA / EGC

EMdoc

SAO+

VAPS

Geode

Doc

Grif Sgml

Lustre

Bds

Lds/Msc

Données

Figure 3: Existing Workshop Architecture Workshop access is designed via STA (StrucTure d’Accueil in French) which is implemented using Metaphase (from Control Data). Visible on figure 3, STA looks like an ORB Corba, since it receives requests from applications and prepares answer, may be using other application by some activation mechanism. We present below the list of tools given on figure 3. EGC, Configuration manager EMdoc, Textual Formalism using SGML SAO+/LUSTRE, Synchronous Dataflow manager, known as SCADE VAPS, Screens cockpit definition formalism BDS, Oracle database for input and output signals GEODE, LDS Model Doc, Documentation In our experiment we start with a replacement of STA using a Web environment and Corba, (a browser as IHM, Common Gateway Interface for command and control and Orbix for Corba).

7

Then, in order to check Corba capabilities in this context, we first try SCADE editor, which is a specification tool allowing to express formal definition of a given airplane equipment such as FWC (Flight Warning Computer). Such an application gives means to produce technical data which are stored in EGC technical data base. It defines the Scade/Egc Specification Mode of the workshop (see figure 4) IHM, CGI and Orbix

Sélection Restitution

Activation - Batch - Graphical Edition Termination

EGC

SCADE

Technical Data Base

Figure 4: Scade/Egc Specification Mode

3.2.2 Scade Branch Implementation In such a context, it is quite clear that objects are very large, and as a consequence, the used framework will be very coarse grained. So, in a first stage, standard interfaces must be very general in order to unify the scope of third party applications at framework level. As shown on the figure 5, the unshared Scade proxy server (see paragraph 2.2), allows to make communication between user and Scade tool via only one IDL interface including batch command as a string. The resulting size of object server is obviously the size of the whole Scade tool. Batch Interface Corba Server

WEB Pages

Corba Client

ad hoc Client

SCADE PROXY

SCADE

Submit

Multi Client

File System

Wrapper

SCADE SERVER

Figure 5: Implementation Architecture

8

4 Some results about Corba granularity Both of the above applications have been implemented using Corba. These implementations has caused some problems when using this middleware. Although HECTOR and ASA have not the same granularity, it clearly appears that in both cases, we can put the encountered weak points in the same categories. In the remainder of this section, we will discuss each of the following weak points, the global state of the system and the classification of objects, which are obviously the best way for control, the real time concerns, mastering causal ordering the location of objects occurring when dealing with fragmented objects and finally security and privacy.

4.1 Global state and classification of objects According to granularity there are two kind of interfaces, Control interfaces, which are system oriented, i.e. independent of application, (for example, interfaces including activation, suspension, exception, and more generally task management methods). In this case the granularity is related to size of application itself, since the server object is exactly the whole application. In ASA application the global state problem is solved via a centralized database (EGC). But in the future, such a solution will be impossible due to distributed architecture, (several partners). The solution is not possible using only Corba, and a transactional monitor will be used on top of Corba. Classical interfaces defined with respect to user requirements can be classified depending on global state application. One of the originalities of HECTOR is the concept of a synchronization class. These classes are devoted to implement a controls to access shared objects. A lot of synchronization problems necessitates the knowledge of a global state of the object. The global state is generally depicted by attributes which are unaccessible from a client in a Corba environment. This problem can be easily solved by the introduction of methods reading attributes values. These methods are considered as standard ones, their profiles are described using standard IDL. The systematic introduction of such methods implies a certain methodology of OO programs which, if not respected, prevents to include them in Corba application. Consequently, this methodology induces a classification of objects methods in three categories, (read, write, construct methods). Paradoxically, this classification derives from Corba constraints is not mappable in IDL.

9

4.2 Real time Many synchronization problems in HECTOR concerns causal ordering, (requests are to be serviced according to priority policy). Here programming synchronization runs into a problem because such an ordering is not available in Corba. Real time applications cannot be implemented because of the lack of global clock allowing to define delays, time out, rendez vous and so on. In the same way the ASA time problem concerns causal ordering which is obviously mandatory if there is some direct link between tools as shown figure 6 (dotted line). IHM, CGI and Orbix

Other Tool

SCADE

EGC

Figure 6: Direct link between tools

4.3 Location of objects Mastering the distribution of fragmented objects at run time is obtained using configuration classes of the HECTOR model. Thanks to this concept, the programmer may define a reusable strategy for distributed objects on a set of processors. Standard Corba does not allow to program migration, replication and deletion of fragments. Thus it is impossible to implement HECTOR configuration classes. However in Corba2 using the COSS facilities of Externalization Service permits to deal with the above problem in redistributing outside an internalized object. For ASA application location of objects is more simple, since there is a static policy related to work organization between partners. Nevertheless, location induces security and privacy considerations.

4.4 Security and privacy For the time beeing, the HECTOR model does not take into account any security or privacy features. But in ASA, there is a lot of security and privacy rules which must be included in the distributed information system. Unfortunately, Corba implementations does not offer useful security and privacy features for such an application. Then in a pragmatic view, security requirements must be covered in another way, knowing that coarse granularity makes things not so hard. For example, classical systems such as routers or firewalls could be used between partners. To day, the ASA prototype is not secure, and there is some work to do in order to make security and privacy requirements compatible with our Corba run time model. 10

5 Conclusion The results of our investigations when putting in practice Corba on the test applications shaw some semantics restrictions for fine and coarse grains softwares. In our experiments, the lack of internal informations on objects and of real time features lead to huge difficulties to build up object oriented systems based on this middleware. Nevertheless, the current Corba2 specification offers some facilities to deal with concurrency by the means of a new control service component (COSS2) [6], and there are some projects dealing with real time requirements [3]. The practical lesson to be learned from our study mainly concerns the following point: The industrial production of software implies an homogeneous view of OO distributed programming and, in a certain way, a standardization of objects. Consequently, Corba appears as an initial (primitive?) specification tool from which framework programming and composing programming as well can take advantageous benefits.

References [1] JP. Bahsoun, L. F´eraud, JF. Pouilly, and JC. Sakdavong. Object Oriented Distributed Programming with HECTOR. In Max M¨uhlh¨auser, editor, Special Issues in Object Oriented Programming. Dpunkt.Verlag, July 1996. [2] P. Bieber, P. Cros, P. Michel, and V. Wiels. Specification and Implementation Aspects of Interoperability. In JP. Bahsoun, Takanobu Baba, and JP. Briot, editors, 2nd France-Japan Workshop, Object Based Parallel and Distributed Computing, OBPDC’97, Toulouse France. IRIT, 15-17 October 1997. [3] Andy Gokhale, Tim Harrison, and Guru Parulkar. A High Performance Endsystem Architecture for Real-time CORBA. IEEE Communications Magazine, February 1997. [4] IONA. Orbix, A Technical Overview. Short report Number PR-TEC-7-5, IONA Technologies Ltd, July 1993. [5] Ralph Johnson and Brian Foote. Designing Reusable Classes. Journal of OO Programming, (SIGS 1,5):22–35, June/July 1988. [6] Z. Yang and K. Duddy. CORBA: A Platform for Distributed Object Computing. Operating System Review, ACM, 30(2):pages 4–31, April 1996.

11