Component-Oriented Programming in Object-Oriented

Component-OrientedProgramminginObject-OrientedLanguagesPeterH.FrohlichandMichaelFranzDepartmentofInformationandComputerScienceUniversityofCalifornia,IrvineIrvine,CA92697-3425,USAFax:[e-mail],[e-mail]nent-orientedprogrammingarebasedontraditionalobject-orientedlanguagesandconcepts.However,mostexistingobject-orientedlanguagesfailtoaddresssubtleinterfacecompatibilityissuesthatbecomeparamountinacomponent-basedset-ting.Weexplorebothsyntacticandsemanticinterfaceincompatibilitiesanddiscusswhytheyarediculttohandle.Wearguethatresolvingtheseincompatibilitiesrequiresbreakingwithafundamentalidiomofobject-orientedlanguages:thesubordinationofmessagestointerfacesandclasses.Weproposeasolutionbasedontheconceptofstand-alonemessagesasfoundintheexperimentalprogramminglanguageLagoonaanddiscussitsramications.1IntroductionComponent-orientedprogrammingaimstoreplacetraditionalmonolithicsoft-waresystemswithreusablesoftwarecomponentsandlayeredcomponentframe-works[27].Componentsextendthecapabilitiesofframeworks,whileframeworksprovideanexecutionenvironmentforcomponents.Botharedevelopedbyinde-pendentandmutuallyunawarevendors,andtheircompositionintoarunningsystemisperformedbyathirdparty,possiblytheend-user.Acomponent-basedapproachtosoftwaredevelopmentpromisesmanyad-vantages,almostallofwhichresultfromthepossibilityofvendorsspecializinginasingledomainofexpertise.Forexample,insteadofdevelopingacompletetextprocessingapplication,independentvendorscanconcentrateonprovidingdocumentversioning,spell-checking,hyphenation,orintelligentassistantswithinacommontextprocessingframework.Developmentresourcescanthusbecon-centratedonasinglecomponent(orasingleframework),hopefullyincreasingitsreliabilityandeciencybeyondwhatwouldbepossibleotherwise.Oneofthemostimportantfactorsformakingthevisionofpervasivesoftwarecomponentsarealityareinterfaces.Aninterfaceisanabstractionofallpossibleimplementationsthatcanllacertainroleinthecomposedsystem[18].Thisabstractionallowsustoconcentrateonwhatisrequiredofanimplementation2PeterH.Frohlich,MichaelFranztofulllitstaskandtodisregardirrelevantdetails.Inthecomponent-basedset-ting,interfacesareusedtodescribeboththeassumptionsthatframeworksmakeaboutcomponentsandtheassumptionsthatcomponentsmakeaboutframe-works.However,interfacesareusuallyonlysyntacticinnature,withbehavioralspecicationsgivenasinformalcomments.Inprogramminglanguages,type-checkingcanbeusedasanapproximation,butthisonlyguardsagainstasubsetoferrors[6,27].Moreelaboratetechniquesalsoexist,forexamplegreyboxspec-icationsintherenementcalculus[5].However,behavioralconformanceofanimplementationtoaninterfacecannotingeneralbeprovenautomatically.Inthispaper,wetakethepointofviewofcomponentvendorsasopposedtoframeworkvendors.Themajortaskofacomponentvendoristodevelopasoftwarecomponentthatconformstotheinterfacespeciedbyaframeworkven-dor.Thistaskismorecomplexwhencomponentshavetoconformtomultipleinterfaces,allspeciedbymutuallyunawareframeworkvendors.Forexample,aspecializedhyphenationcomponentforan\exoticlanguagewillonlybeinter-estingtoalimitedmarketsegment.Suchacomponentmightnotbeviableasaproductifitcannotbereusedacrossmultipletextprocessingframeworks.Object-orientedprogramminghasbeendescribedasafoundationtechnol-ogyforcomponents[27,29].Indeed,conventionalobject-orientedprogramminglanguageslikeJava[1]andC++[26]areoftenusedtoimplementsoftwarecom-ponents.Componentinterfaces,ontheotherhand,areusuallydescribedusinganinterfacedenitionlanguage(IDL).TheseIDLsarespecictoacertaincompo-nentmodelsuchasCOM[3,10]orCORBA[16],andalsohaveanobject-orientedcharacter.Theresultingcomplexityofthisapproachisdauntingandpromptedustoinvestigatesimpleralternatives[12,13].Inparticular,weareinterestedindesigningaprogramminglanguage|code-namedLagoona|thatprovidesonlywhatisessentialinacomponent-basedsetting,butnotmore.Arstinsightgainedfromthisprojectisthatmostcurrentobject-orientedlanguagesarebythemselvesunsuitableasabasisforcomponent-orientedpro-gramming.Theselanguagesfailtoproperlyaddresscertaininterfaceincompat-ibilitiesthatarisewhenacomponentmustimplementseveralinterfaces,eachdenedbyanindependentframeworkvendor.Futhermore,neitherthecompo-nentvendornorthecomposingend-usercanresolvetheseincompatibilitiesinastraightforwardway.Surprisingly,wecantracetheincompatibilityproblemsbacktoafundamentalidiomfoundinobject-orientedlanguages:thesubordina-tionofmessagestointerfacesandclasses.Ourconclusionisthatbreakingwiththisidiomistheonlycleanwaytosolvetheproblem.Theremainderofthispaperisorganizedasfollows.Section2illustratestheinterfacecompatibilityproblemsthroughaseriesofexamples.Section3analyzessyntacticandsemanticincompatibilitiesindetailandexplainstheirorigin.Sec-tion4introducestheconceptofstand-alonemessagesandshowshowitsolvesthecompatibilityproblemsintheLagoonaprogramminglanguage.Section5givesabriefoverviewofadditionalLagoonalanguagefeatures.Section6re-viewsrelatedworkandcomparesittoourapproach.Section7concludesthepaperwithasummaryofcontributionsandano