Object-Oriented Interoperability and CORBA

Dimitri Konstantas

Jan VitekMay 1994(possition paper)

University of Geneva

Centre Universitaire d’Informatique

24 rue General-DufourCH-1211 Geneva 4tel: +41 22 705.76.47fax: +41 22 320.29.27e-mail: dimitri@cui.unige.ch

Abstract

The Object Management Group's Common Object Request Broker Architecture(CORBA) aims to become the standard for application interoperability. But, inits present form, the architecture has some serious shortcomings, we address twoof them in this report: The binding between server and client is exceedingly tight,thus any difference in interfaces renders the connection impossible. Second, in acommercial environment where the cost and quality of offered services varies,CORBA is lacking a contract negotiation service. We present remedies for theseshortcomings based on previous work in the Cell framework as new CORBA ser-vices: an interface adaption service and a contract negotiation serviceTo Appear in:

Deliverable of the CHASSIS SPP project.

This project was supported by the FNRS SPP project CHASSIS (Configurable, Heterogeneousand Safe Secure Information Systems), (Project number 5003-34355/2) of the Swiss FederalGovernment.

Object–Oriented Interoperability and CORBA

Dimitri Konstantas

Jan VitekWorking PaperMarch 14, 1994

Abstract

The Object Management Group’sCommon Object Request Broker Architecture (CORBA) aimsto become the standard for application interoperability. But, in its present form, the architecturehas some serious shortcomings, we address two of them in this report: The binding between serv-er and client is exceedingly tight, thus any difference in interfaces renders the connection impos-sible. Second, in a commercial environment where the cost and quality of offered services varies,CORBA is lacking a contract negotiation service. We present remedies for these shortcomingsbased on previous work in the Cell framework as new CORBA services: an interface adaptionservice and a contract negotiation service.

1.Shortcomings ofCORBA

CORBA [1][2] is likely to become thede facto standard for interoperability of applications.

However, in its present definition, the architecture truly offers interoperability only for newlydeveloped applications, and lacks the facilities needed to negotiate connection that will beneeded in a commercial environment. On the first count,CORBA is guilty of enforcing a too tightbinding between client and server interfaces and failing to provide support for evolution of theseinterfaces. On the second count, just like it includes security and licencing services,CORBAshould include a truecontract negotiation service.

The problem of interfaces is quite important because for an application to access a serverthrough theORB the application must talk to theORB through a specific and immutable inter-face, and it must talk to the server using the server’sIDL stub interface.CORBA provides nosupport for cases when the interface expected by the application and the interface provided bythe server (through theORB) do not match. This means that existing applications cannot bene-fit, or even use, theCORBA. Furthermore, there is no provision inCORBA for evolution of inter-faces, which is a serious restriction even forCORBA–based applications. The following threescenarios demonstrate those restrictions.

Case 1:Existing applications.

Let us assume an existing application using a specific, existing, service found on thenetwork. For example, a database front–end application using the services offered by adatabase server. The application communicates with the server using a specific interface,which can well be a standard database server interface. When the database is incorpo-rated in theCORBA, it gains a new,CORBAIDL–based, interface. Of course, the data-base application cannot, without extensive source code changes, use this interface. Thealternative is therefore to leave the application as is, which can be, among other things,a security risk, or to reimplement, at best, a part of it.

1

Dimitri Konstantas2

Case 2:CORBA–based applications — multi–server access.

Let us assume an application designed and implemented to access aCORBA server. Forexample, a database front–end accessing diverse database servers. At some point, a newdatabase server is put on–line, but it has an interface which is slightly different from theothers, providing however exactly the same services. In this case the application can notaccess the new services. The interface mismatch, even if it is minute, will prevent the twoprograms from talking to each other.Case 3:CORBA–based applications — server upgrades.

Another problem that can, and in our opinion will, appear is that of upgrades of theserver. This means that if, in order to provide better service, a server is upgraded and itsinterface changed, its clients would not be able to access it anymore.Although cases 2 and 3 are not problems specific only toCORBA applications, we believe thatan architecture that claims to support application interoperability should address them. In all ofthe scenarios given above the problem is that of an interface mismatch. Clearly, some way ofadapting the requested interface to the one being offered is what is required here. To avoid aprofusion of, mutually incompatible,ad hoc solutions, this interface transformation mechanismshould be part of the standard.

A generic solution to the problem of interface transformation was introduced in the Cellframework with the concept ofObject–Oriented Interoperability (OOI) [3][4]. The Cell frame-work was designed to provide powerful interoperability support for object–based stronglydistributed systems. The Cell framework specifies how a collection ofindependent systems cancooperate to form a distributed system without compromising their autonomy and indepen-dence. Object–Oriented Interoperability [5] allows the reliable and consistent interoperation ofapplications at high levels of abstractions, like the objects. An important aspect of this technol-ogy is that it allows to bridge differences between the interface requested by the client and theinterface offered by the server. In the Cell framework prototype implementation, this interfaceadaption was achieved via theType Matching Specification Language(TMSL) [4].

To solve the interface mismatch problems described earlier, we propose to extendCORBAwith anInterface Adaption Service based on our Object–Oriented Interoperability ideas. Specif-ically, we propose an Interface Adaption Language (IAL) as a high level description of interfacetransformations. Interface transformations written inIAL will then be compiled to generate thenecessary interface adaption layer.

Another concept of the Cell framework lacking inCORBA is that ofContract NegotiationService. That is, a service that it will allow the cooperating entities (client and server) to specifythe terms under which the service is provided. These terms include, but are not limited to, thesecurity level, the service level, the duration of the contract, the cost of the service etc.

2.The Interface Adaption Service

The concept of object-oriented interoperability [5] introduced in the Cell framework providesthe basis of the new interface adaption service we propose to add toCORBA. The basic elements

3

of object–oriented interoperability areType Matching andObject Mapping. Type matchingprovides the means for abstractly describing the relation between the interfaces of differentapplications based on their functionality. Object Mapping provides the run–time support for theimplementation of the interoperability links.

2.1Type Matching: Interface Adaption Language

The interfaces ofCORBA–based services are expressed in theInterface Description Language(IDL). A programmer developing an application using such a service needs to know more thanjust theIDL interface of the server he or she is going to access. The developer needs also to knowthe specificIDL language mapping for his development environment. For instance, if the clientprogram is written in Ada then the programmer needs to know how theIDL specification of theinterface maps down to Ada procedures and types. The program will thus use the server’sIDLstub interface (or the Dynamic Invocation Interface), where, in this case would be in Ada.For the purpose of interface adaption, we distinguish between applications developed with-outCORBA andCORBA–based applications. The former case corresponds to the first scenarioof interface mismatch described in the previous section where the interface expected by theapplication bears no relation to theIDL stub interface. The later case corresponds to scenarios 2and 3 described above, where the application expects a stub interface but in a (slightly) differentformat. The interface adaption service has to be able to handle both cases. That is, interface adap-tion can occur from non–IDL toIDL, and fromIDL toIDL based interfaces.

We propose an Interface Adaption Language (IAL), based on the Type Matching specifi-cation language of the Cell framework, to express interface transformations. For the first case,the interface adaption language will be designed specifically for the application developmentlanguage in order to have the full power of the language available to express interface adaption.TheIAL.X compiler (whereX is the target language, for exampleIAL.C for C andIAL.C++ forC++) will generate the interface adaption code which will offer to the client application an inter-face identical to the requested interface, and will dispatch the calls to theORB using either theIDL stubs or the dynamic invocation interface. For the interface adaption betweenIDL inter-faces, theIAL.IDL compiler will take as option the application’s language and generated accord-ingly the interface adaption code.

Note that in the case of interface adaption from non–IDL toIDL, theIAL is bound to aspecific language. While in the other case, there is no language dependency. In practice, thismeans that anIAL.IDL mapping applies to all clients of the old interface regardless of theirimplementation language.

Also note thatIAL can be used to simplify the introduction of services inCORBA. In orderto introduce a new service we need to define two things: first theIDL definition of its interfaceand second the access skeletons at the server side. Although it is clear inCORBA how theIDLinterfaces are used and how theIDL stubs at the client side are generated, nothing has beendefined on how the skeletons are defined. If they are to be generated automatically from theIDLinterfaces, the same functionality will be used for theIAL compiler. If, on the other hand, theskeletons are programmed by hand, theIAL will drastically simplify this task.

Dimitri Konstantas4

2.2Object Mapping

The Object Mapping mechanism of the Cell framework provides run–time support for object–oriented interoperability as well as taking charge of mapping objects from client to the server.One of the most important ideas ofOOI is the distinction of objects into those objects which canbe migrated between applications, (equivalent and translated types), and those which can not,(type matched types). For the latter kind, the Object Mapping mechanism creates inter-objectswhich are real objects acting as (kind of) proxies for the target object.

For the new interface adaption service ofCORBA part of this functionality is implementedby theORB. TheORB takes care of forwarding and dispatching the service requests, providesinformation about the object interfaces and manage the exchanged object references. The inter-face adaption service will have to handle the transformation ofORB object references to eitherinter–objects, in the case where we have interface adaption between non-IDL andIDL interfaces,or to object references of a different type (casting), when we have interface adaption betweenIDL interfaces. In addition the interface adaption service will handle the management of theobjects used in the interface adaption.

For theOOI concepts of equivalent, translated and type matched types some support existsinCORBA but not to the extent needed forOOI. That is, in theCORBA we have the basic types,the constructed and template types and the object references. TheCORBA basic types can beconsidered as theOOI’s equivalent types (accepting that theCORBA basic types have the samesemantics to all environments) and the constructed and template types can be seen as translatedtypes (since strings, arrays etc. may have different internal representation in each environment).However theCORBA object references are not the same asOOI’s inter-objects. The most impor-tant difference is that object references are opaque handles to the target server object. An objectreference is simply included with the request and it is theORB that will dispatch the request tothe target object, while inter-objects are real objects in the client’s environment. From theclient’s point of view, the inter–object acts as if it was the server and it will “compose” therequest to be forwarded to theORB after processing the data passed and possibly obtain morefrom other sources.

3.Related Issues

We discuss two issues related to interface adaption: how will the server be actually accessed andtheCORBA trading service.3.1AccessingCORBA Servers

The choice of whichCORBA interface to use to access a server is an important implementationissue for the interface adaption service. There are two possibilities, either use theIDL stub inter-face or the Dynamic Invocation Interface (DII). For theORB, both interfaces are equivalent, anda server receiving a request cannot distinguish which interface was used. The use of theIDL stubprovides a simple programmatic interface that simplifies the complexity of interface adaption.The dynamic invocation interface, on the other hand, is more flexible and provides a better basisfor automatic generation.

5

3.2Trading ServiceOne of the services that is in the planning for theOMGCORBA is thetrading service1. TheCORBA trading service will be very similar to the trading service specified byANSA[6]. That isits main functionality will be to find the servers that support a specific interface and return ahandle to the requesting client. However the matching of service requests and service offers willbe based in the exact matching of the interfaces. That means that servers offering the exactrequested service but under a slightly different interface will not be included in the list of avail-able servers.The introduction ofOOI inCORBA with an Interface Adaption Service will greatly enhancetheOMG trading service. With the Interface Adaption Service present the server interface willbe a secondary issue and the selection of a server will be done based on its functionality. If theserver interface is different from the requested one then an interface adaption layer will be usedallowing transparent access to the server.4.The Contract Negotiation ServiceAlthoughCORBA’s target is to provide interoperability support for large networks few thingshave been anticipated for commercial requirements’ support. What is needed to be introducedinCORBA is an integratedContract Negotiation Service2 that will allow the client and the serverto define in a consistent way all the aspects of the service. That is, the client and the server willnegotiate, depending on their priorities and policies, service terms like service cost, accessrights, service duration, security requirements, service quality etc. These type of commercialrequirements clearly surpass the presently anticipatedTradingandLicencing services ofCORBA.SinceCORBA offered services are request oriented and since the same server can havemore than one connections at a time, each service request will need to include an identifier spec-ifying the effective service contract. In the absence of a service contract or when new terms needto be applied a contract negotiation session will be initiated. Of course the security services willneed to be used in order to protect against the forging of the established contracts.The Contract Negotiation Service can be introduced inCORBA as just another objectservice. Its use is not mandatory for accessingCORBA offered services. If however a server ora client have special requirements for offering or accessing the service they can invoke thecontract negotiation service and specify their requirements. How the negotiation will beperformed and what algorithms will be used for establishing the actual service terms is up to theparticipating peers to define. The service will simply provide the basic protocols to use and willensure that they are applied. The set of negotiable terms is yet to be defined as well as the basicnegotiation protocols.1. OtherCORBA services include Name, Event, Life Cycle, Persistence, Transaction, Relations, Time,Externalization, Security, Trading, Replication, Licencing, Query and Version Service.2. Also calledConnection Tradingin the Cell Framework.Dimitri Konstantas6

The reason that we include the Contract Negotiation in theOOI concept is that the termsunder which a service is offered can be seen as being part of its interface. Eventually we targetin merging the access interface and the service terms into a generalized interface concept. Thisway the interface adaption will not only bridge the differences between the requested and offeredinterfaces but also bridge the differences between the terms under which the service is requestedand offered.

5.Conclusions

Although theCORBA provides a powerful interoperability platform there several cases where itsinteroperability support fails. The reason for this failure is thatCORBA is not designed to supportinteroperability forexisting applications but rather provide a framework for the design andimplementation ofnew applications. As a result existing information systems will not be able tobenefit from theCORBA advantages. As a solution to this problem we propose the introductionof Object Oriented Interoperability in the form of an object service which we callInterfaceAdaption Service.

The Interface Adaption Service will allow older non-CORBA based applications to accessCORBA offered services via an interface adaption layer that will transform the requested serviceinterface to the offeredIDL-basedCORBA server interface. In additionCORBA based applica-tion will also be able to benefit since they will be able to access different servers offering thesame or similar services but under different interfaces. Finally the providers of services will alsobenefit from the interface adaption service since they will be able to create the requiredIDL skel-etons with a simple specification of an interface relation.

In the near future we plan to define first anIDL Interface Adaption Language (IAL.IDL) thatwill allow the adaption ofIDL interfaces and continue with an C++ Interface Adaption Language(IAL.C++). In parallel we will study the issues related to aCORBA Contract Negotiation serviceand the definition of generalized service interface notion that will include both the access inter-face and the service terms.

References

[1][2][3][4]

The Common Object Request Broker: Architecture and Specification, Document Number 91.12.1 Revision1.1, Object Management Group and X Open.

Object Management Architecture Guide, OMG TC Document 92.11.1, Revision 2.0, Object ManagementGroup, September 1992.

Dimitri Konstantas, “Cell: A Framework for a Strongly Distributed Object Based System,” Ph.D. Thesis No.2598, University of Geneva, May 1993.

Dimitri Konstantas, “Hybrid Cell: An Implementation of an Object Based Strongly Distributed System,” Pro-ceedings of the International Symposium on Autonomous Decentralized Systems ISADS 93, Kawasaki, Ja-pan, March 30 1993.

Dimitri Konstantas, “Object Oriented Interoperability,” proceedings of the Seventh European Conference onObject Oriented Programming ECOOP 93, Kaiserlautern, Germany, July 26-29 1993, Also in Visual Objects,ed. D. Tsichritzis, CUI, University of Geneva, 1993.

TheANSA Reference Manual, Vol. A, Architecture Projects Management Ltd., July 19.

[5]

[6]