Tải bản đầy đủ - 0 (trang)
Chapter 1. Object-Oriented Frameworks for Network Programming

Chapter 1. Object-Oriented Frameworks for Network Programming

Tải bản đầy đủ - 0trang

1.1AnOverviewofObject-OrientedFrameworks

Evenascomputingpowerandnetworkbandwidthincrease

dramatically,thedevelopmentofnetworkedapplication

softwareremainsexpensive,timeconsuming,anderrorprone.

Thecostandeffortstemsfromthegrowingdemandsplacedon

networkedsoftware,aswellasthecontinualrediscoveryand

reinventionofcoresoftwaredesignandimplementation

artifactsthroughoutthesoftwareindustry.Moreover,the

heterogeneityofhardwarearchitectures,diversityofOSand

networkplatforms,andstiffglobalcompetitionmakesit

increasinglyhardtobuildhigh-qualitynetworkedapplication

softwarefromscratch.

Thekeytobuildinghigh-qualitynetworkedsoftwareinatimeto-market-drivenenvironmentistheabilitytoreusesuccessful

softwaredesignsandimplementationsthathavealreadybeen

developed.Reusehasbeenapopulartopicofdebateand

discussionforover30yearsinthesoftwarecommunity

[McI68].Therearetwogeneraltypesofreuse:

Opportunisticreuse,inwhichdeveloperscutandpaste

codefromexistingprogramstocreatenewones.

Opportunisticreuseworksinalimitedwayforindividual

programmersorsmallgroups.Itdoesn'tscaleupacross

businessunitsorenterprises,however,andtherefore

doesn'tsignificantlyreducedevelopmentcycletimeand

costorimprovesoftwarequality.Worse,opportunisticreuse

canactuallyimpededevelopmentprogresssincecut-andpastecodeoftenbeginstodivergeasitproliferates,forcing

developerstofixthesamebugsmultipletimesinmultiple

places.

Systematicreuse,whichisanintentionalandconcerted

efforttocreateandapplymultiusesoftwarearchitectures,



patterns,frameworks,andcomponentsthroughouta

productline[CN02].Inawell-honedsystematicreuse

process,eachnewprojectleveragestime-provendesigns

andimplementations,onlyaddingnewcodethat'sspecific

toaparticularapplication.Thistypeofreuseisessentialto

increasesoftwareproductivityandqualitybybreakingthe

costlycycleofrediscovering,reinventing,andrevalidating

commonsoftwareartifacts.

Middleware[SS02]isaclassofsoftwarethatcanincrease

systematicreuselevelssignificantlybyfunctionallybridgingthe

gapbetweentheend-to-endfunctionalrequirementsof

networkedapplicationsandtheunderlyingoperatingsystems

andnetworkprotocolstacks.Middlewareprovidescapabilities

thatarecriticaltonetworkedapplicationsbecausethey

automatecommonnetworkprogrammingtasks.Developers

whousemiddlewarecanthereforeprogramtheirnetworked

applicationsmorelikestand-aloneapplications,ratherthan

wrestlingwiththemanytediousanderror-pronedetails

associatedwithlow-levelOSeventdemultiplexing,message

bufferingandqueueing,marshalinganddemarshaling,and

connectionmanagementmechanisms.Popularexamplesof

middlewareincludeJavavirtualmachines(JVMs),Enterprise

JavaBeans(EJB),.NET,theCommonObjectRequestBroker

Architecture(CORBA),andtheADAPTIVECommunication

Environment(ACE).

Systematicallydevelopinghigh-quality,reusablemiddlewarefor

networkedapplicationspresentsmanyhardtechnical

challenges,including

Detectingandrecoveringfromtransientandpartialfailures

ofnetworksandhostsinanapplication-independent

manner

Minimizingtheimpactoflatencyandjitteronend-to-end



applicationperformance

Determininghowtopartitionadistributedapplicationinto

separatecomponentservices

Decidingwhereandwhentodistributeandloadbalance

servicesinanetwork

Sincereusablemiddlewareisinherentlyabstract,it'shardto

validateitsqualityandtomanageitsproduction.Moreover,the

skillsrequiredtodevelop,deploy,andsupportreusable

networkedapplicationmiddlewarehavetraditionallybeena

"blackart,"lockedintheheadsofexpertdevelopersand

architects.Thesetechnicalimpedimentstosystematicreuseare

oftenexacerbatedbyamyriadofnontechnicalimpediments

[Hol97],suchasorganizational,economic,administrative,

political,sociological,andpsychologicalfactors.It'stherefore

notsurprisingthatsignificantlevelsofsoftwarereusehave

beenslowtomaterializeinmanyprojectsandorganizations

[Sch00].

Whileit'snevereasytomakereuseworkuniversally,we'veled

thedevelopmentofpowerfulhostinfrastructuremiddleware

calledACEthat'sdesignedspecificallywithsystematicreusein

mind.Duringthepastdecade,we'vewrittenhundredsof

thousandsoflinesofC++codewhiledevelopingandapplying

ACEtonetworkedapplicationsaspartofourworkwithdozens

oftelecommunication,aerospace,medical,andfinancial

servicescompanies.Asaresultofourexperience,we've

documentedmanypatternsandpatternlanguages[POSA2,

POS00]thathaveguidedthedesignofreuseablemiddleware

andapplications.Inaddition,we'vetaughthundredsoftutorials

andcoursesonreuse,middleware,andpatternstothousands

ofdevelopersandstudents.Despitethemanytechnicaland

nontechnicalchallenges,we'veidentifiedasolidbodyofwork

thatcombinesadvancedresearch,time-provendesign

knowledge,hands-onexperience,andsoftwareartifactsthat



cansignificantlyenhancethesystematicreuseofnetworked

applicationsoftware.

Attheheartofthisbodyofworkareobject-oriented

frameworks[FJS99b,FJS99a],whichareapowerfultechnology

forachievingsystematicreuseofnetworkedapplication

software.[1]Below,wedescribethethreecharacteristicsof

frameworks[JF88]thathelpthemtoachievetheimportant

networkedapplicationqualitieslistedonpagexi.Figure1.1

(page4)illustrateshowthesecharacteristicsworktogether.

[1]Intheremainderofthisbookweusetheterm



frameworktomeanobject-orientedframework.

Figure1.1.SynergyofFrameworkCapabilities



Aframeworkprovidesanintegratedsetofdomainspecificstructuresandfunctionality.Systematicreuseof

softwaredependslargelyonhowwellframeworksmodelthe

commonalitiesandvariabilities[CHW98]inapplicationdomains,

suchasbusinessdataprocessing,telecomcallprocessing,

graphicaluserinterfaces,ordistributedobjectcomputing

middleware.Sinceframeworksreifythekeyrolesand

relationshipsofclassesinapplicationdomains,theamountof

reusablecodeincreasesandtheamountofcoderewrittenfor

eachapplicationdecreases.



Aframeworkexhibits"inversionofcontrol"atruntime

viacallbacks.Acallbackisanobjectregisteredwitha

dispatcherthatcallsbacktoamethodontheobjectwhena

particulareventoccurs,suchasaconnectionrequestordata

arrivingonasockethandle.Inversionofcontroldecouplesthe

canonicaldetection,demultiplexing,anddispatchingsteps

withinaframeworkfromtheapplication-definedeventhandlers

managedbytheframework.Wheneventsoccur,theframework

callsbacktovirtualhookmethodsintheregisteredevent

handlers,whichthenperformapplication-definedprocessingin

responsetotheevents.

Sinceframeworksexhibitinversionofcontrol,theycansimplify

applicationdesignbecausetheframework—ratherthanthe

application—runstheeventlooptodetectevents,demultiplex

eventstoeventhandlers,anddispatchhookmethodsonthe

handlersthatprocesstheevents.Theuseofvirtualhook

methodsinthehandlerclassesdecouplestheapplication's

classesfromtheframework,allowingeachtobechanged

independentlyaslongastheinterfacesignatureandinteraction

protocolsaren'tmodified.

Aframeworkisa"semi-complete"applicationthat

programmerscancustomizetoformcompleteapplicationsby

inheritingfromandinstantiatingclassesintheframework.

Inheritanceenablesthefeaturesofframeworkbaseclassesto

besharedselectivelybysubclasses.Ifabaseclassprovides

defaultimplementationsofitsmethods,applicationdevelopers

needonlyoverridethosevirtualmethodswhosedefault

behaviordoesn'tmeettheirneeds.

Sinceaframeworkisasemi-completeapplication,itenables

larger-scalereuseofsoftwarethancanbeachievedbyreusing

individualclassesorstand-alonefunctions.Theamountofreuse

increasesduetoaframework'sabilitytointegrateapplicationdefinedandapplication-independentclasses.Inparticular,a

frameworkabstractsthecanonicalcontrolflowofapplicationsin

adomainintofamiliesofrelatedclasses,whichcancollaborate



tointegratecustomizableapplication-independentcodewith

customizedapplication-definedcode.



1.2ComparingSoftwareDevelopmentandReuse

Techniques

Object-orientedframeworksdon'texistinisolation.Class

libraries,components,patterns,andmodel-integrated

computingareothertechniquesthatarebeingappliedtoreuse

softwareandincreaseproductivity.Thissectioncompares

frameworkswiththesetechniquestoillustratetheirsimilarities

anddifferences,aswellastoshowhowthetechniquescanbe

combinedtoenhancesystematicreusefornetworked

applications.



1.2.1ComparingFrameworksandClassLibraries

Aclassisageneral-purpose,reusablebuildingblockthat

specifiesaninterfaceandencapsulatestherepresentationofits

internaldataandthefunctionalityofitsinstances.Alibraryof

classeswasthemostcommonfirst-generationobject-oriented

developmenttechnique[Mey97].Classlibrariesgenerally

supportreuse-in-the-smallmoreeffectivelythanfunction

librariessinceclassesemphasizethecohesionofdataand

methodsthatoperateonthedata.

Althoughclasslibrariesareoftendomainindependentandcan

beappliedwidely,theireffectivescopeofreuseislimited

becausetheydon'tcapturethecanonicalcontrolflow,

collaboration,andvariabilityamongfamiliesofrelatedsoftware

artifacts.Thetotalamountofreusewithclasslibrariesis

thereforerelativelysmall,comparedwiththeamountof

application-definedcodethatmustberewrittenforeach

application.Theneedtoreinventandreimplementtheoverall

softwarearchitectureandmuchofthecontrollogicforeach

newapplicationisaprimesourceofcostanddelayformany

softwareprojects.

TheC++standardlibrary[Bja00]isagoodcaseinpoint.It



providesclassesforstrings,vectors,andothercontainers.

Althoughtheseclassescanbereusedinmanyapplication

domains,theyarerelativelylowlevel.Applicationdevelopers

arethereforeresponsiblefor(re)writingmuchofthe"glue

code"thatperformsthebulkoftheapplicationcontrolflowand

classintegrationlogic,asshowninFigure1.2(1).

Figure1.2.ClassLibraryversusFrameworkArchitectures



Frameworksareasecond-generationdevelopmenttechnique

[Joh97]thatextendsthebenefitsofclasslibrariesinseveral

ways.Mostimportantly,classesinaframeworkcollaborateto

provideareusablearchitectureforafamilyofrelated

applications.Classcollaborationinaframeworkyields"semicomplete"applicationsthatembodydomain-specificobject

structuresandfunctionality.Frameworkscanbeclassifiedby

variousmeans,suchastheblackboxandwhiteboxdistinctions

describedinSidebar1(page6).



Sidebar1:OverviewofWhiteboxandBlackboxFrameworks

Frameworkscanbeclassifiedintermsofthetechniquesusedtoextendthem,

whichrangealongacontinuumfromwhiteboxframeworkstoblackbox

frameworks[HJE95],asdescribedbelow:

Whiteboxframeworks.Extensibilityisachievedinawhiteboxframework

viaobject-orientedlanguagefeatures,suchasinheritanceanddynamic

binding.Existingfunctionalitycanbereusedandcustomizedbyinheriting

fromframeworkbaseclassesandoverridingpredefinedhookmethods

[Pre95]usingpatternssuchasTemplateMethod[GoF],whichdefinesan

algorithmwithsomestepssuppliedbyaderivedclass.Toextenda

whiteboxframework,applicationdevelopersmusthavesomeknowledgeof

itsinternalstructure.

Blackboxframeworks.Extensibilityisachievedinablackboxframework

bydefininginterfacesthatallowobjectstobepluggedintotheframework

viacompositionanddelegation.Existingfunctionalitycanbereusedby

definingclassesthatconformtoaparticularinterfaceandthenintegrating

theseclassesintotheframeworkusingpatternssuchasFunctionObject

[Kuh97],Bridge/Strategy[GoF],andPluggableFactory[Vli98b,Vli99,

Cul99],whichprovideablackboxabstractionforselectingoneofmany

implementations.Blackboxframeworkscanbeeasiertousethanwhitebox

frameworkssinceapplicationdevelopersneedlessknowledgeofthe

framework'sinternalstructure.Blackboxframeworkscanalsobeharderto

design,however,sinceframeworkdevelopersmustdefinecrispinterfaces

thatanticipatearangeofusecases.



Anotherwaythatclasslibrariesdifferfromframeworksisthat

theclassesinalibraryaretypicallypassivesincetheyperform

theirprocessingbyborrowingthethreadfromso-calledselfdirectedapplicationsthatinvoketheirmethods.Asaresult,

developersmustcontinuallyrewritemuchofthecontrollogic

neededtobindthereusableclassestogethertoformcomplete

networkedapplications.Incontrast,frameworksareactive

sincetheydirecttheflowofcontrolwithinanapplicationvia

variouscallback-driveneventhandlingpatterns,suchas

Reactor[POSA2]andObserver[GoF].Thesepatternsinvertthe

application'sflowofcontrolusingtheHollywoodPrinciple:

"Don'tcallus,we'llcallyou"[Vli98a].Sinceframeworksare

activeandmanagetheapplication'scontrolflow,theycan

performabroaderrangeofactivitiesonbehalfofapplications



thanispossiblewithpassiveclasslibraries.

Frameworksandclasslibrariesarecomplementarytechnologies

inpractice.Frameworksprovideafoundationalstructureto

applications.Sinceframeworksarefocusedonaspecific

domain,however,theyaren'texpectedtosatisfythebroadest

rangeofapplicationdevelopmentneeds.Classlibrariesare

thereforeoftenusedinconjunctionwithinframeworksand

applicationstoimplementcommonlyneededcodeartifacts,

suchasstrings,files,andtime/dateclasses.

Forexample,theACEframeworksusetheACEwrapperfacade

classestoensuretheirportability.Likewise,applicationscanuse

theACEcontainerclassesdescribedin[HJS]tohelpimplement

theireventhandlers.WhereastheACEcontainerclassesand

wrapperfacadesarepassive,theACEframeworksareactive

andprovideinversionofcontrolatruntime.TheACEtoolkit

providesbothframeworksandalibraryofclassestohelp

programmersaddressarangeofchallengesthatarisewhen

developingnetworkedapplications.



1.2.2ComparingFrameworksandComponents

Acomponentisanencapsulatedpartofasoftwaresystemthat

implementsaspecificserviceorsetofservices.Acomponent

hasoneormoreinterfacesthatprovideaccesstoitsservices.

Componentsserveasbuildingblocksforthestructureofan

applicationandcanbereusedbasedsolelyuponknowledgeof

theirinterfaceprotocols.

Componentsareathird-generationdevelopmenttechnique

[Szy98]thatarewidelyusedbydevelopersofmultitier

enterpriseapplications.Commonexamplesofcomponents

includeActiveXcontrols[Egr98]andCOMobjects[Box98],.NET

webservices[TL01],EnterpriseJavaBeans[MH01],andthe

CORBAComponentModel(CCM)[Obj01a].Componentscanbe

pluggedtogetherorscriptedtoformcompleteapplications,as



showninFigure1.3.

Figure1.3.AComponentArchitecture



Figure1.3alsoshowshowacomponentimplementsthe

businessapplicationlogicinthecontextofacontainer.A

containerallowsitscomponenttoaccessresourcesandservices

providedbyanunderlyingmiddlewareplatform.Inaddition,

thisfigureshowshowgenericapplicationserverscanbeusedto

instantiateandmanagecontainersandexecutethecomponents

configuredintothem.Metadataassociatedwithcomponents

provideinstructionsthatapplicationserversusetoconfigure

andconnectcomponents.

Manyinterdependentcomponentsinenterpriseapplicationscan

resideinmultiple—possiblydistributed—applicationservers.

Eachapplicationserverconsistsofsomenumberofcomponents

thatimplementcertainservicesforclients.Thesecomponents

inturnmayincludeothercollocatedorremoteservices.In

general,componentshelpdevelopersreducetheirinitial

softwaredevelopmenteffortbyintegratingcustomapplication

componentswithreusableoff-the-shelfcomponentsintogeneric

applicationserverframeworks.Moreover,astherequirements

ofapplicationschange,componentscanhelpmakeiteasierto

migrateandredistributecertainservicestoadapttonew

environments,whilepreservingkeyapplicationproperties,such

assecurityandavailability.



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

Chapter 1. Object-Oriented Frameworks for Network Programming

Tải bản đầy đủ ngay(0 tr)

×