Integrating COTS Software Components into Dependab

IntegratingCOTSSoftwareComponentsintoDependableSoftwareArchitecturesPauloAsteriodeC.GuerraAlexanderRomanovskyRogériodeLemosCecíliaMaryF.RubiraInstitutodeComputaçãoUniversidadeEstadualdeCampinas,BrazilSchoolofComputingScienceUniversityofNewcastleuponTyne,UKComputingLaboratoryUniversityofKentatCanterbury,UK{asterio,cmrubira}@[e-mail]@ukc.ac.ukic.unicamp.brncl.ac.ukAbstractThispaperconsiderstheproblemofintegratingcommercialoff-the-shelf(COTS)softwarecomponentsintosystemswithhighdependabilityrequirements.Thesecomponents,bytheirverynature,arebuilttobereusedasblackboxesthatcannotbemodified.Instead,thesystemarchitecthastorelyontechniquesexternalwithrespecttothecomponentforresolvingmismatchesoftheservicesrequiredandprovidedthatmightariseintheinteractionofthecomponentanditsenvironment.AnapproachisdescribedinthispapertohowthesetechniquesshouldbestructuredaroundtheCOTScomponenttoobtainanidealisedfault-tolerantcomponent.Theapproachemploysthelayer-basedC2architecturalstyleforstructuringmechanismsoferrordetectionandrecoverythatshouldbeintegratedintothesoftwarearchitecture.ThefeasibilityoftheproposedapproachispresentedinthecontextofasteamboilersystemwhichcontainsaCOTScontroller.1.IntroductionComponent-basedsoftwaredevelopment(CBSD)isrecognizedtodayasaneffectivewaytoreducedevelopmentcostsandtime-to-market[S98].Untilrecently,themajorityofCBSDuseswasprimarilyforclient-tierapplications,withlittleattentionpaidtoserver-tiercomponents[BW98].Componentsattheclientsideareusuallyfine-grainedclassesofsimpleobjects,suchasboxesandbuttonsontheuser'sscreen.Theircounterpartsattheserversidearelarge-grainedcomponents1encapsulatingcomplexbusinessrulesorinfrastructureservices,usuallycomprisingasetofrelatedcomponentssuchascommercialoff-the-shelf(COTS)applicationframeworksanddatabasemanagers.Todaythemainchallengesofcomponent-basedsoftwareengineering(CBSE)areinguaranteeingsystemsafety,reliability,andsecurity[V98].AlthoughthefundamentalprinciplesofCBSDapplytobothclient-sideandserver-sideportionsofasystemequally,theirdependabilityrequirementsaresubstantiallydifferent.ACOTScomponentisusuallyprovidedasablackboxtobereusedasitis,whichcanindependentlyevolveafteritwasintegrated.Thesecomponentsusuallydonothavecompleterigorously-writtenspecification,thereisnoguaranteethatthedescriptiontheintegratorshaveintheirdisposaliscorrect(veryoftenitisambiguous).Thesecomponentscanhavebugs,moreover,thespecificcontextinwhichtheyareusedisnotknownattheirdevelopmenttime.Whenintegratingsuchacomponentintoasystemwithhighdependabilityrequirementsweshouldemploysolutionsatthearchitecturalleveltoensurethattheserequirementsaremet,irrespectiveoffaultsintheCOTScomponentitselforinthewayitinteractswiththeothersystemcomponents.Researchintodescribingsoftwarearchitectureswithrespecttotheirdependabilitypropertieshasrecentlygainedconsiderableattention[SI99,S01,S98].In[GRL02]theidealisedfault-tolerantcomponentconcept[AL81]isappliedinthearchitecturaldescriptionoffault-tolerantcomponent-basedsystems.[PR01]putsforwardageneralapproachtodevelopingprotectivewrapperstobeusedforbuildingdependablesoftwaresystemsbasedonCOTScomponents.InthispaperwecombinetheconceptsofanidealisedarchitecturalcomponentandprotectivewrapperstodevelopanarchitecturalsolutionthatprovidesaneffectiveandsystematicwayforbuildingdependablesoftwaresystemsfromCOTSsoftwarecomponents.Therestofthepaperisorganisedasfollows.Inthenextsection,webrieflydiscussbackgroundworkontheidealisedfault-tolerantcomponent,architecturalmismatchesandtheC2architecturalstyle.Section3describesthearchitecturalrepresentationofidealisedfault-tolerantCOTS.Thecasestudydemonstratingthefeasibilityoftheproposedapproachispresentedinsection4.RelatedworkonhowtobuilddependablesoftwaresystembasedonCOTScomponentsisdiscussedinsection5.Finally,section6presentssomeconcludingremarksanddiscussesourfuturework.22.Background2.1.ArchitecturalMismatchesandCOTSComponentIntegrationDealingwitharchitecturalmismatches[GAO95]isoneofthemostdifficultproblemssystemintegratorsfacewhendevelopingarchitecturalapproachestointegratingsystemswithCOTScomponents.Anarchitecturalmismatchoccurswhentheassumptionsthatacomponentmakesaboutanothercomponentortherestofthesystemdonotmatch.Thatis,theassumptionsassociatedwiththeserviceprovidedbythecomponentaredifferentfromtheassumptionsassociatedwiththeservicesrequiredbythecomponentforbehavingasspecified[OWZ98].Whenbuildingsystemsfromexistingcomponents,itisinevitablethatincompatibilitiesbetweentheservicedeliveredbythecomponentandtheservicethattherestofthesystemexpectsfromthatcomponent,giverisetosuchmismatches.Thesemismatchesarenotexclusivetothefunctionalattributesofthecomponent;mismatchesmayalsoincludequalityattributes,suchasdependability,whichcanberelatedtothecomponentfailuremodeassumptionsoritssafetyintegritylevels.WeviewallincompatibilitiesbetweenaCOTScomponentandtherestofthesystemasarchitecturalmismatches.This,forexample,includesinternalfaultsofaCOTScomponentthataffectotherssystemcomponentsoritsenvironment,inwhichcasethefailureassump