multi-technology distributed objects and their integration · framework for transparent...

Ž .Computer Standards & Interfaces 23 2001 157–168www.elsevier.comrlocatercsi

Multi-technology distributed objects and their integration

Konstantinos Raptis a,), Diomidis Spinellis b, Sokratis Katsikas a

a Department of Information and Communication Systems, UniÕersity of the Aegean, GR-83200 KarloÕasi, Samos, Greeceb ( )Department of Technology and Management, Athens UniÕersity of Economics and Business AUEB , EÕelpidon 47A,

11362 Athens, Greece

Received 14 November 2000; received in revised form 8 March 2001; accepted 15 March 2001

Abstract

Research on software objects, components, middleware, and component-based applications concerns among othersŽ . Ž . Ž .ActiveX controls, JavaBeans JBs , the Microsoft Transaction Server MTS , Enterprise JavaBeans EJBs , and how they

can interoperate with each other. Is their interoperation possible? Which elements are responsible for the software objects’incompatibility? Is compatibility a responsibility of the objects or of their underlying architectures? In this article, we discussobject compatibility problems by outlining three basic middleware remoting technologies: the OMG’s Common Object

Ž . Ž .Request Broker Architecture CORBA , Microsoft’s Distributed Component Object Model DCOM , and Sun’s Java RemoteŽ .Method Invocation RMI , discussing the basic incompatibility points, and overviewing the basic strategies for bridging the

gap between CORBA, DCOM, and RMI. q 2001 Published by Elsevier Science B.V.

Keywords: Software objects; Components; Bridge; Midlleware; Object compatibility; Interoperation

1. Introduction

Software development is becoming increasinglycomplicated. Business requirements for clientrserverapplications, support for multiple platforms, and so-phisticated end-user functionality have forced devel-opers to adopt new approaches. One of the conceptsthat changed the rules in software development is

Ž .object-oriented programming OOP , which is orga-nized around objects rather than actions. According

w xto Budd 1 , AAll objects are instances of a class. Themethod invoked by an object in response to a mes-sage is determined by the class of the receiver. All

) Corresponding author. Tel.: q30-273-25-282; fax: q30-273-25-282.

Ž .E-mail addresses: [email protected] K. Raptis , [email protected]Ž . Ž .D. Spinellis , [email protected] S. Katsikas .

objects of a given class use the same method inresponse to similar messagesB.

The need to develop software based on existingcode rather than development from scratch led to thedevelopment of component-based software. Compo-nents are typically object-oriented, or at least used as

w xobjects. Szyperski 16 defines a software componentas Aa unit of composition with contractually speci-fied interfaces and explicit context dependenciesonly. One that can be deployed independently and issubject to third-party compositionB.

To be composable, components need to be identi-fied by meaningful characteristics, namely: the com-ponent name, which provides the developer with theability to identify it; the component interface, whichidentifies the operations fulfilled by the component;and the component model which specifies the seman-tics and execution context of the component.

0920-5489r01r$ - see front matter q 2001 Published by Elsevier Science B.V.Ž .PII: S0920-5489 01 00070-8

( )K. Raptis et al.rComputer Standards & Interfaces 23 2001 157–168158

Moreover, a software component must meet threebasic demands:

1. it must be directly usable: the component mustcontribute to the development process;

2. it must be a defined and discrete unit: thecontent of the component must be explicitlyidentified; and

3. it must be separable from its original contextand usable in other contexts: any componentmust be reusable in applications other than theone it was first defined.

The rapid deployment of software componentsand the advantages of component-based applicationsagainst the monolithic applications drive many enter-prises to deploy their network applications based oncomponents. Although software components addressmany enterprise application development issues, theiruse unavoidably generates new problems. As we willsee below, the components must comply with aspecific underlying middleware architecture in orderto interact with each other efficiently. This depen-dency on the underlying architecture creates compat-ibility problems between components based on dif-ferent architectures. These problems become criticalby changes in company information systems due to

w xacquisitions, mergers, and infrastructure upgrades 2 .As a component’s instance is typically an object

and anything applying to objects also affects compo-nents, in the next paragraphs our discussion willfocus on software objects.

2. Middleware technologies

The ability to construct applications using objectsfrom different vendors, running on different ma-chines, and on different operating systems, it is notan easy task. The need for interaction between thesoftware objects led to the specification of middle-ware models. The Object Management Group’sComponent Object Request Broker ArchitectureŽ .CORBA , Microsoft’s Distributed Component Ob-

Ž .ject Model DCOM , and the Sun MicrosystemsŽ .Remote Method Invocation RMI are three models

that enable software objects from different vendors,running on different machines, and on different oper-ating systems, to work together.

To provide our readers with a feeling of thedifferent technologies, we have implemented threeversions of a very simple clientrserver application,

Ž . Ž .utilizing CORBA Listing 1 , DCOM Listing 2 ,Ž .and Java RMI Listing 3 . The application client uses

the server to sum two numbers. The client, Sum-Client, initially sends two numbers to the server,

()SumSerÕer, through the SetNum function, and then()calls the Sum function through which the server

returns to the client the sum of the two numbers. Wepresent the code for those applications without in-cluding the automatically generated helper files. Theclientrserver applications are implemented using theJava language in order to provide a uniform lan-guage-layer presentation through which the differ-ences of CORBA, DCOM and Java RMI can beeasily identified.

2.1. OMG CORBA

The Common Object Request Broker ArchitectureŽ . w xCORBA 10 is an open standard specifying aframework for transparent communication betweenapplications and application objects. It is defined and

Ž .supported by the Object Management Group OMG ,a nonprofit, trade association of over 700 softwaredevelopers, vendors, and end-users. According toCORBA, a client which asks for some services froman object makes a request which is transferred to theobject request broker. The ORB is responsible forforwarding the request to the right object implemen-tation. This request contains all the information re-quired to satisfy the request: target object, opera-tions, zero or more parameters, and an optionalrequest context.

The client’s request to the ORB and the forward-ing of the request from the ORB to the objectimplementation must be in a form that will be under-standable independently from the specific ORB. Theclient invocation style depends on the component’sinterface details available to the client at compilationtime: if the client has access to the appropriatecomponent and its interface then it can use the staticinterface, otherwise the client has to deposit itsrequest to the ORB through the dynamic interface.To allow ORB-neutral invocation, the request ismade to the ORB through an interface called AIDLStubB, if there is a static invocation, or through theADynamic InvocationB, if there is a dynamic invoca-

( )K. Raptis et al.rComputer Standards & Interfaces 23 2001 157–168 159

tion. In the server end, the promotion of the requestto the object implementation is also made throughinterfaces called AStatic IDL SkeletonB and ADy-namic SkeletonB.

We stress that clients never come in direct contactwith the objects, but always with the interfaces ofthese objects. The interfaces are determined through

Ž .OMG’s IDL Interface Definition Language . Theclients are not AwrittenB in OMG’s IDL, but in alanguage for which there is a mapping to OMG’sIDL.

In addition, the communication of a client with anobject running as a different process or on a differentmachine uses a communication protocol to portablyrender the data format independently from the ORB.For this reason, the OMG has designed the General

Ž .Inter-ORB Protocol GIOP , a protocol which en-sures the connection of the ORBs no matter wherethey came from. The Internet Inter-ORB ProtocolŽ .IIOP is a specific mapping of the GIOP to TCPrIPconnections, the most popular protocol for networkconnectivity.


2.2. Microsoft DCOM

Microsoft’s Distributed Component Object ModelŽ . w xDCOM 7 is an object-oriented model designed topromote interoperability of software objects in adistributed, heterogeneous environment. It’s an ex-tension of Microsoft’s Component Object ModelŽ . w xCOM 8 . COM’s target is to allow two or moreapplications or objects to easily cooperate with oneanother, even if they have been written by differentvendors at different times, in different programminglanguages, or if they are running on different ma-chines, and under different operating systems.

A client requests services from an object via theobject interface represented as a pointer. Therefore,the programming language in which the client isimplemented must have the ability to create pointersand call functions through these pointers and theclient must have the right pointer to that interface.The interfaces are determined through Microsoft’s

ŽInterface Description Language different from.OMG’s IDL which allows the developers to con-

struct the object interfaces.

In case the client does not have the right pointerto the appropriate interface, it addresses COM givingas input the class identification, CLSID, of the objectand the server’s type of object class: Ain-processB,AlocalB, or AremoteB. COM then uses the Service

Ž .Control Manager SCM to search and find the appli-cable server and give back to the client the requestedpointer. The laying down of the client’s request andits promotion to the appropriate object implementoris done via proxy and stub interfaces, respectively.These interfaces are responsible to marshal and un-pack the transmitted data. Similarly, the stub mar-shals the object’s response and the proxy unpacksand promotes the response back to client.

Obviously, every client must provide at least theŽ .class identification CLSID of the object it needs

and the type of the server. The client may be imple-mented in any programming language as long as thelanguage supports the construction and managementof pointers. Inter-process communication is per-

Ž .formed using Remote Procedure Calls RPCs . Theremote procedure call mechanism is based on theDistributed Computing Environment Remote Proce-

Ž .dure Call mechanism DCE RPC .


On July 2000, Microsoft announced its .net plat-form as the new base for developing Web-basedapplications. The .net platform as a programmingmodel represents the next evolution of Microsoft’sComponent Object Model. The .net platform consistsof a set of application level frameworks, a set of baseframeworks, and a common language runtime. At thecenter of the .net framework is an object modelcalled the Virtual Object System providing a middle-ware infrastructure for components based on differ-

w xent technologies across the Web 6 . The interoper-ability among the different technologies across theWeb is made possible using open Web protocolssuch as XML and SOAP.

2.3. JaÕarRMI

Ž . w xThe Remote Method Invocation RMI 14 is alsoan object-oriented model designed to promote inter-operability of Java objects in a distributed, heteroge-neous environment. RMI is the mechanism for thetransparent communication exclusively between Javaobjects.

For an RMI client to use an object’s services, itmust submit a request to the RMI which contains anobject reference, the desired methods of that object,and the necessary parameters for the implementation

of the request. RMI is then responsible to find andpromote the request to the right object. The submis-sion of the client’s request is made to a stub. Thestub is the top level of the RMI which makes theobject appear as if it is in the same process as theclient. The stub presents the request in the right formto be transmitted to the server-side RMI part. Afterthe stub, the request passes through the remote refer-ence layer to the transport layer which is responsiblefor transmitting the request. At the server side, theobject collects the request in a reverse way throughthe RMI layers and responds back to the client viaRMI in the same way that the client did.

To deposit a request, the client must have anobject reference to the needed object. In the casewhere the client does not have the object reference itcan look for it through the appropriate service pro-vided by the Java RMI namely the jaÕa.rmi.Namingclass. Like the other two technologies the RMI clientscome in contact only with the interfaces of theobjects. Those interfaces are defined using the Javalanguage and not via a special IDL.

The clientrobject communication procedurethrough RMI is the same irrespective of whether theobject resides locally or remotely. In the case wherethe client communicates with an object residing on adifferent machine the use of the Java Remote Method

Ž .Protocol JRMP is necessary.


3. Object incompatibility

For software objects to interact with each other,they must comply with the rules of at least one ofthe above models. However, it is difficult if not im-possible for two objects conforming to dissimilartechnologies to interact with each other. The incom-patibility reasons stem from the differences of theunderlying models and the way they present and usethe software objects. We can identify three basic

w xincompatibility points 12 .

3.1. Different interface approaches and implementa-tions

One of the basic elements of an object are itsinterfaces. Through their interfaces objects exposetheir functionality. An interface consists of a descrip-tion of a group of possible operations that a clientcan ask from an object. A client interacts only withthe interfaces of an object, never with the objectitself. Interfaces allow objects to appear as blackboxes. Different approaches and implementations ofobject interfaces make them invisible to clients ofother technologies.

Both CORBA and DCOM use special InterfaceŽ .Definition Languages IDLs for the interface speci-

fication. Java RMI uses the Java language to definethe interfaces. In DCOM, every interface has a Uni-

Ž .versally Unique Identifier UUID , called the Inter-

Ž .face Identifier IID , and every object class has itsŽ .own UUID, called Class Identifier CLSID . More-

over, every object must implement the IUnknowninterface. When using the Java language to specifyDCOM objects every Java class implements thatinterface behind the scenes through the Microsoft

Ž .Java Virtual Machine MSJVM . In Java RMI theinterface must be declared as public, it must extendsthe interface jaÕa.rmi.Remote and each method mustdeclare jaÕa.rmi.RemoteException in its throwsclause.

3.2. Different object references and storage

When a client wishes to interact with an object itmust first retrieve information on the object’s inter-face. A client’s underlying technology must recog-nize an object’s name, it must know where to look,and how to retrieve its information, i.e. it must knowhow the required object’s technology stores and dis-seminates its information. If a client’s technologydoes not have that kind of ability then it is impossi-ble for the necessary information of the neededobject to be found.

Ž .In CORBA Listing 1 , the IDL compiler gener-ates the appropriate client stubs and server skeletonsfor a client to deposit a static invocation to therequested object. Moreover, all the necessary infor-mation is stored in the Interface Repository throughwhich a client can get run-time information for a


dynamic invocation. The client is searching for theneeded methods using the object’s name referenceand invokes it statically, through the client stubinterface, or dynamically, through the dynamic invo-cation interface, depending on its run-time knowl-edge. For the interaction to be possible the CORBAserver program must bind the server object using theCORBA Naming Service. Prior to the above interac-tion, the CORBA server and the CORBA clientprogram must first initialize the CORBA ORB

()through the ORB.init method.ŽIn the DCOM clientrserver interaction Listing

.2 , the MSJVM hides many of the code detailsneeded in the previous CORBA example. The server

Žobject binding is performed using the jaÕareg util-.ity through the system registry where the COM

clients search for the needed COM components. Inthe DCOM client, the instantiation of the DCOMobject is done using the new keyword. Although itseems that the client is referring to the neededremote object by its name, the system is looking forthat object based on its CLSID. All the necessarycalls to the IUnknown and IDispatch interfaces usedby the client to acquire the appropriate pointer to theserver object and for the management of server’sobject life cycle are accomplished transparentlythrough the MJVM.

Ž .Looking at the Java RMI example Listing 3 , inthe server side program one creates the server objectand binds it to the RMIRegistry using the

()Naming.rebind method by assigning a URL-basedname. On the client side, the Java RMI client gets areference from the server’s registry using the URL-

()based object’s name through the Naming.lookupmethod.

3.3. Different protocols

Another basic element in distributed object inter-actions is the protocol used for the data transmission.In our case, a protocol does not denote only thetransport-level protocol, such as TCPrIP but in-cludes the presentation and session level protocols

Ž .supported by the Request Brokers RBs . The trans-port-level protocol is responsible for the transmissionof the data to the end point. The presentation andsession level protocols are responsible for the for-matting of the data transmitted between differentRBs from a client to an object, and vice versa.

w xAccording to Geraghty et al. 5 : AAlthough theclient and server may speak the same protocol, it iscritical that they speak the same language, orhigher-level protocolB.

In Table 1 we present the basic differences of thethree models according to the above incompatibilitypoints. These differences are not the only ones be-tween these three architectures and the only reasonsfor objects’ incompatibility. If we made a detailedcomparison between these models, we would seemany more differences and find many additionalreasons; the differences we described are howeverthe prime causes of incompatibilities. As we will seein the next paragraphs, all attempts for bridging theseobject middleware architectures focus their attentionon these points.

4. Bridging the gap

When two or more objects, based on differenttechnologies must to interoperate the mission target

Table 1CORBArDCOMrRMI basic differences in relation with incompatibility points

Incompatibility points CORBA DCOM RMI

Interface approaches IDL MIDL Javaand implementationsObject identification Identification through Object Identification through Identification through URL-based

Ž .and Interface Names GUID CLSID and IID Object Name and Interface NameObject reference Reference through Object Reference through Reference through

Ž .Reference OR Interface Pointer URL-based Object ReferenceObject storage Storage in Implementation Storage pointers in the Storage in rmiregistry

Repository System RegistryŽ .Protocols GIOPrIIOPrESIOP Object RPC ORPC JRMPrIIOP


is to make the objects hide the fact that the otherobjects are functioning under a different technologywithout changing their characteristics and behavior.According to object technology the Ashop-windowBof an object is its interface. When an object wishesto contact another it must be able to view, under-stand, and work out with the other object’s interfacein order to request the needed methods. Each tech-nology has its own way to create the objects’ inter-faces using its own IDL. Therefore, for two tech-nologies to interoperate any object must be able tounderstand the other technology’s IDL. Suppose aclient deposits to its RB a request for some methods.The RB must be able to look for the appropriateobject which exposes these methods. The RB musttherefore know the way the other RB names andstores the information of its objects in order to beable to find them and forward the request. For theabove operations to be feasible, the requests and theresponses to be transmitted must be formatted in amutually understandable way i.e. different RBs mustcommunicate using the same protocols.

The goals we outlined can be achieved by using aw xproxy bridge object 11 . This object is used as a

mechanism to translate the requests and the re-sponses in an understandable form and maintain themain characteristics and behavior of the real object.Moreover, the bridge object is provided with all thenecessary attributes so that it can be viewed from thedifferent technology’s object as if it was part of thesame technology. Figs. 1 and 2 are examples of classand activity diagrams of the interaction of differenttechnology objects.

We can distinguish three cases depending onwhere the bridge object resides. It could reside in theclient’s machine, in the server’s machine, or on athird machine. If the bridge object resides in theclient’s machine, the client’s environment must sup-

port two or more different middleware technologies.Moreover, if the server object changes its state, thismust be propagated to every bridge object, i.e. to themachine of every client. When the bridge objectresides on the server’s or an entirely different ma-chine, then the above problems are not relevant, butperformance problems are likely to occur. In the nextparagraphs, we outline some of the attempts forbridging CORBA, DCOM, and RMI.

4.1. CORBA–DCOM bridge

CORBA and DCOM, as an extension of COM,are the two most widespread middleware technolo-gies. Their importance stems from their AparentsB.CORBA is child of the Object Management Groupan association including Sun Microsystems, Com-paq, Hewlett-Packard, IONA, Microsoft and others,while DCOM comes from Microsoft which has thehighest share in the desktop operating system mar-ket. Although COM and its extension DCOM arebuilt-in in Microsoft’s OSs and there are no otherproviders of these technologies, the widespreadadoption of Microsoft’s OSs and the development ofprogramming languages which support rich COMrDCOM frameworks, led to the production of manycomponents based on Microsoft’s architecture. Onthe other side, the fact that the OMG providesCORBA as specifications for ORBs instead of aproduct led many companies to create their ownCORBA compliant request brokers providing thedevelopers and the users with a range of ORBscapable to satisfy different demands.

After the first OLErCORBA bridge from IONATechnologies in 1995, OMG decided to include aspart of its updated revision 2.0 of CORBA architec-ture and specification the Interworking Architecturewhich is the specification for bridging OLErCOM

Fig. 1. Class diagram of Object A–Object B interaction.


Fig. 2. Activity diagram of Object A–Object B interaction.

and CORBA. The Interworking Architecture ad-dresses three points:

Ø Interface Mapping. As both models use IDLs todefine the interfaces and as any object is exposed

by its interface, there must be a mapping betweenthem in order for a CORBA object to be viewedas a COM object and vice versa. Particularly, OMGspecifies four distinct mappings: CORBArCOM,


CORBArOLE Automation, COMrCORBA, andOLE AutomationrCORBA.

Ø Interface Composition Mapping. One of the ba-sic differences between the CORBA and COM inter-faces is the characteristic of inheritance. WhileCORBA supports multiple interface inheritance,COM supports multiple interfaces for objects andtherefore provides single inheritance. For a bridge towork, there must be a map from CORBA’s multipleinheritance to COM’s single inheritance and viceversa.

Ø Identity Mapping. This specification is con-cerned with the mapping between the different Inter-face IDs used by CORBA and COM.

As we saw, OMG provides the specificationsregarding the mappings between COM and CORBAIDLs and interfaces. One point that the InterworkingArchitecture does not specify concerns the approachthat should be taken to bridge COM and CORBA.We can distinguish two basic approaches for bridg-

w xing, the static bridging, and the dynamic bridging 5 .Under static bridging, the creation of an interme-

diate code to make the calls between the differentsystems is required. That intermediate code would bethe client’s side proxy which could be different inorder to receive an object system’s call, transform it,and forward it to another object system. The mainadvantage of static bridging is that it can be easilyimplemented because it has to deal with object inter-faces which contain known code. The disadvantageof the static bridge is that any changes on theinterfaces require a change in the bridge.

In dynamic bridging, there is no code dependenton the types of calls, i.e. the interfaces that must begenerated. The operation of a dynamic bridge isbased on the existence of a dynamic mechanismwhich can manage any call in spite of the interfaces.The dynamic bridging appears as an enhanced solu-tion by which many problems of static bridging canbe avoided. The ability of CORBA to handle dy-namic invocation calls through the Dynamic Invoca-

Ž .tion Interface DII and the similar ability of DCOMthrough dynamic OLE Automation, makes the use ofdynamic bridging quite versatile especially in anapplication environment where a large number ofinterfaces are involved.

The OMG does not provide an implementation ofa COMrCORBA bridge but only specifications. The

implementation belongs to commercial companieswhich have released many bridge tools, compliantwith OMG’s specification. Some of these productsare PeerLogic’s COM2CORBA, IONA’s Orbix-COMet Desktop, and Visual Edge’s ObjectBridge.All the above products realize one of the interfacemappings that OMG specifies. Their main goal is toprovide a two-way interworking between COM andCORBA applications.

4.2. RMI–CORBA bridge

The widespread deployment of the Java languageand its use in the development of Web-based appli-cations in combination with the presence of CORBAas a mature middleware technology quickly led tothe combination of these two. Although Sun pro-vided its own model for remote Java-object interac-

Ž .tions-the Java Remote Method Protocol RMI -theeffective combination of the Java language with theCORBA architecture led OMG and Sun to contem-plate the interoperation of RMI and CORBA. Ac-

w xcording to Sun Microsystems 15 , the Java develop-ers would be able to use RMI-based Java objects andinteroperate with CORBA-based remote objects. InJune 1999, Sun and IBM announced the release ofthe RMI architecture over IIOP protocol. Accordingto RMI-IIOP any RMI-based object can be accessedby a CORBA one and vice versa. For this goal to beachieved, OMG has adopted two standards for AOb-ject By ValueB and AJava-to-IDLB mapping.

Apart from the adoption of IIOP as RMI’s alterna-tive protocol, a new version of the rmic compiler hasbeen developed to generate IIOP stubsrties and IDLinterfaces. Furthermore, the use of new commandsand tools, for example for naming and storing in theregistry the RMI-objects and for ORB activation, isrequired so that RMI-IIOP-based objects can be ac-cessed by CORBA-based ones.

4.3. DCOM–RMI bridge

No special work has been done for bridgingCOMrDCOM with RMI. In this field, the attentionis focused on the attempts for integrating the Javalanguage and COM and on the bridging of Jav-aBeans with ActiveX.


Until recently, Microsoft supported COMrDCOMin its own edition of the Java language, VisualJqq. To provide Java users access to COM tech-nology, Microsoft supported the Microsoft Java Vi-

w xsual Machine. According to Microsoft 9 , theMSJVM provided all the mechanisms required for aJava object to be viewed like a COM object and fora COM object to be accessible like a Java object.With the release of Visual Studio .net Microsoft hasstopped the active support of Java in favor of Ca.

As for JavaBeans—ActiveX bridging, a numberof companies, including Microsoft and Sun, providebridges for JavaBeans and ActiveX components tointeroperate with each other taking advantage of theJavaBeans architecture flexibility in conjunction withthe underlying protocols. Moreover, a lot of the workconcerns the possibility of a JavaBean component tobe used in ActiveX-component based environmentslike Microsoft Office or Visual Basic.

5. Conclusions

Most of the work in the area we surveyed con-cerns bridging CORBA and DCOM. This is expectedconsidering the widespread deployment of Mi-crosoft’s operating systems and the acceptance ofCORBA as the most mature middleware architecture.Moreover, the early presence of a variety of COMcomponents and ORB products from commercialcompanies led developers to use those products. As aresult the bridging between CORBA and DCOM wasan urgent need.

The attempts to bridge CORBA and RMI indicatethat although Sun states that it will continue tosupport JRMP concurrently with IIOP as the RMI’scommunication protocol, the CORBA architecturewill prevail over RMI. Besides, OMG’s intention tosupport Enterprise JavaBeans confirms that notion.On the other hand, Microsoft’s and Sun’s work onbridging ActiveX and JavaBeans apparently focusmore on the interoperation between their componentmodels than between their middleware remotingtechnologies.

In the latest versions of CORBA and COM, whichare CORBA 3 and COMq , there is no furthercontribution on the aspect of interoperability.CORBA 3 adds three new features to the previous

specifications concerned with Java and Internet inte-gration, quality of service control, and the CORBA

w xcomponent architecture 13 . On the other hand,COMq enriches its ancestor with new features andservices like just-in-time activation, object pooling,load balancing, in-memory databases, queued com-ponents, automatic transactions, role-based security,

w xand events 4 . Moreover, Microsoft’s promotion ofits .net platform for next-generation Internet applica-tions caused confusion about the future of technolo-

w xgies such as DCOM 3 .The interoperation between different technology

objects is in practice much more complex and diffi-cult than in theory. Although many attempts havebeen undertaken to bridge the gap between the un-derlying object architectures, these are currently notproviding true vendor-, language-, and technology-independent interoperation between different soft-ware objects. Unfortunately, until now the use of asingle middleware product is the most reliable solu-tion. Compatibility problems between products ofdifferent vendors persist even if the products are

w xcompliant with the same technology 2 . Even for theavailable bridge tools their Afully compliantB state-ments many times refer to a single vendor’s productsselection that does not support the vendor’s indepen-dence theory. In the future, we hope that middlewareimplementations using a common XML-based proto-col will provide a new opportunity for truly interop-erable objects.

References

w x1 T. Budd, An Introduction to Object-Oriented Programming.Addison-Wesley Professional, Boston, USA, 1991.

w x2 J. Charles, Middleware Moves to the Forefront. IEEE Com-Ž . Ž .puter 32 5 1999 17–19, May.

w x3 D. Deckmyn, Uncertainty surrounds Microsoft’s .net plans.Ž . Ž .Computerworld 34 27 2000 12, July.

w x4 G. Eddon, COMq: the evolution of component services.Ž . Ž .IEEE Computer 32 7 1999 104–106, July.

w x5 R. Geraghty, S. Joyce, T. Moriarty, G. Noone, COM–CORBA Interoperability. Prentice-Hall Inc., New Jersey,USA, 1999.

w x6 B. Meyer, The significance of Adot-NetB. Software Develop-Ž . Ž .ment 8 14 2000 51–60, November.

w x7 Microsoft, DCOM Architecture, White Paper. Microsoft,Redmond, WA, USA, 1998.

w x8 Microsoft, The Component Object Model Specification, Ver-sion 0.9. Microsoft, Redmond, WA, USA, 1995 October.


w x9 Microsoft, Integrating Java and COM, A TechnologyOverview. Microsoft, Redmond, WA, USA, 1999 January.

w x10 Object Management Group, The Common Object RequestŽBroker: Architecture and Specification, Revision 2.0 Up-

.dated . Object Management Group, Needham, USA, 1996July.

w x11 K. Raptis, D. Spinellis, S. Katsikas, Java as distributed objectglue. World Computer Congress 2000, Beijing, China, Au-gust. International Federation for Information Processing,2000.

w x12 K. Raptis, D. Spinellis, S. Katsikas, Distributed object bridgesand Java-based object mediator. InformatikrInformatique 2Ž .2000 4–8, April.

w x Ž .13 J. Siegel, A preview of CORBA 3. IEEE Computer 32 5Ž .1999 114–116, May.

w x14 Sun Microsystems, Java Remote Method Invocation Specifi-cation, Beta Draft Revision 1.2. Sun Microsystems, Moun-tain View, CA, USA, 1996 December.

w x15 Sun Microsystems. Java-Based Distributed Computing, RMIand IIOP in Java, Sun Microsystems, Mountain View, CA,USA, June 26, 1997. Online, Sun Microsystems. Availableonline: http:rrwww.javasoft.comrprr1997rjunerstate-ment970626-01.html, February 2001.

w x16 C. Szyperski, Component Software: Beyond Object-OrientedProgramming. Addison-Wesley, 1998.

Konstantinos Raptis is a PhD student inthe Department of Information andCommunication Systems at the Univer-sity of the Aegean. His research inter-ests include distributed applications,software component models and dis-tributed component interoperation tech-nologies. Contact him at [email protected].

Diomidis Spinellis is an assistant profes-sor in the Department of Technologyand Management at the Athens Univer-sity of Economics and Business. Contacthim at [email protected].

Sokratis Katsikas is vice rector at theUniversity of the Aegean. He is also aprofessor in the Department of Informa-tion and Communication Systems at theUniversity of the Aegean. Contact himat [email protected].

multi-technology distributed objects and their integration · framework for transparent...

Documents