internet billing service design and prototype implementation

internet billing service design and prototype implementation

ID:34135986

大小:95.83 KB

页数:19页

时间:2019-03-03

上传者:xinshengwencai
internet billing service design and prototype implementation_第1页
internet billing service design and prototype implementation_第2页
internet billing service design and prototype implementation_第3页
internet billing service design and prototype implementation_第4页
internet billing service design and prototype implementation_第5页
资源描述:

《internet billing service design and prototype implementation》由会员上传分享,免费在线阅读,更多相关内容在教育资源-天天文库

INTERNETBILLINGSERVICEDESIGNANDPROTOTYPEIMPLEMENTATIONbyMarvinA.Sirbu*AbstractAgroupofstudentsintheM.S.programinInformationNetworkingatCarnegieMellonUniversityhavedesignedandimplementedaprototypeofanInternetBillingService--anelectroniccreditcardservicefortheInternetenvironment.Theserviceprovidesaccountmanagement,authentication,accesscontrol,creditverification,managementreporting,billingandcollectionservicestonetwork-basedserviceproviders.1.IntroductionAworldwidedatanetworkinginfrastructureisgraduallyfallingintoplacewhichwillallowconsumersandserviceproviderstointeractinavastelectronicmarketplace.InFrancesome9,000servicesareavailableovertheMinitelnetwork.IntheU.S.,accesstoelectronicdatabasesgeneratesbillionsofdollarsayearinbusiness.Asnetworkedcomputersproliferateathomeandintheworkplace,moreandmoreconsumersareinapositiontoshopintheelectronicmarketplace._________________________________*Thisreportrepresentsthecollectiveworkof13studentsinCMU'sMasterofSciencePrograminInformationNetworkingandisderivedfromtheirfinalprojectreport:RichardBatelaan,RichardButler,ChunYiChan,TieJuChen,MichaelEvenchick,PaulHughes,TaoJen,JohnJeng,JonMillett,MichaelRiccio,EdSkoudis,ChrisStarace,PeterStoddard.TheprojectwasdirectedbyWilliamArms,JohnLeongandDennisSmithofCMU.DhananjayGodeservedasTeachingAssistantandpreparedthefirstdraftofthispaper. AnInternetBillingServerAlreadytheInternet,alooseconfederationofindependentlymanagednetworks,linkseightmillionusersandsomeonemillioncomputerson10,000separatesubnetworksinmorethan40countries.1Onceusedonlybyuniversitiesandresearchorganizations,theInternetisusedtodaybyindividualsandcorporationsforawiderangeofcommercialpurposesincludingdisseminatinginformation,searchingremotedatabases,andprovidingaccesstospecializedcomputerresources.MajorinformationserviceproviderssuchasDialogandBRScannowbereachedviatheInternet.WhileitisrelativelysimpleforanentrepreneurtosetupasmallcomputercapableofprovidinginformationtotheworldwideInternetcommunity,itismuchmoredifficulttoarrangeamechanismtochargeusersfortheservicesrenderedandtocollectpayments.Currentbillingmechanismsforelectronicservicesarecostlyandinconvenientforbothserviceprovidersandendusers.Intheabsenceofacentralizedbillingservice,usersmustinitiateaserviceagreementwitheachserviceproviderbeforeusingitsservices,andmustkeeptrackofitsaccesspoint,password,andbills.Also,thereisnocentraldirectoryofserviceproviders.Itisuneconomicalforsmallserviceproviderstoadvertise,checkcredit,authenticateusers,controlaccess,billandcollectpayments,maintainaudittrails,andkeepusagestatistics.Bothserviceprovidersandendusersneedareliable,easilyaccessible,fastandinexpensiveintermediary,abillingservice.Thebillingservicecouldbecomparedtoanelectroniccreditcardforservicesonanetwork.Itwouldallowsmallserviceproviderstocontractoutthefunctionsofbillingusersandcollectingpaymentsandconcentrateonprovidingservices.Thisdocumentdescribesthedesignandimplementationofaprototypeofacomputer-basedInternetBillingServer(IBS)developedbyaprojectteamfromtheInformationNetworkingInstitute(INI)atCarnegieMellonUniversity.Theprojectteamhadtwomajortasks:(1)specifyfunctionalrequirementsforafullscalebillingserver,and(2)designanddevelopaprototypewhich,whilesatisfyingonlyasubsetoftheserequirements,demonstratesthefeasibilityoftheconcept.Specificationofthefullsetofrequirementsbringsoutimportantissuesandensuresthattheprototypedesignhasnomajorflawswhichlimititsextensibilitytoafull-scalesystem.Wewillsummarizethefullsetofrequirements,notinginpassingwheretheactualprototypediffers.2OurdesigndemonstrateshowanInternetBillingServercouldfacilitatetheemergenceofarealelectronicmarketplace.2.UniqueCharacteristicsofNetwork-BasedMarketsThedesignofanetworkbillingserverisdifficultbecausemarketsforelectronicservicesaredifferentfrommarketsforphysicalgoodsandnon-electronicservices.Anetworkbillingserver-2- AnInternetBillingServermustbedesignedtotakethesedifferencesintoaccount,inordertoavoidfraudanddisputes.Thesedifferencesareoutlinedbelow.First,inanetwork,theusers,theserviceproviders,andthebillingservicearegeographicallyseparated.Creditcardsaredesignedforsituationswheretheusersphysicallypresenttheircreditcardsatthetimeofpurchasesothatmerchantsmayvalidatetheirsignature.Althoughcreditcardsareusedtodayforplacingordersoverthephone,suchmethodsarehighlyinsecure;orderingoveranetworkmakesitdifficulttoverifytheidentityoftheparties.Indeed,toreducefraudulentcharges,manymerchantswillonlyshipgoodsorderedoverthephonetothebillingaddressofthecreditcardholder.Securenetworkauthenticationprotocols,suchasKerberos,3maybepartofasolutionbutthelegalliabilityandresponsibilityofparticipantsinanelectronicmarketisnotwelldefined.Second,giventhehighprocessingspeedsofelectronicservices,ausercanaccidentallyrunupahugebillwithinamatterofsecondswithouthavinganopportunitytocancelit.Incontrast,ifthereisamistakeinorderingaphysicalproduct,itcanbecorrectedbeforetheproductisshippedortheproductcanbereturnedafterdelivery.Eventhoughanon-electronicservicecannotbereturned,theusercanstillcancelitwhileitisbeingperformed:onecanleaveahotelifitsserviceisnotsatisfactoryoristooexpensive.Providingasimilarcapabilityforhaltingtheprovisionofnetworkbasedservicesinmidstreamiscomplex.Third,incontrasttophysicalgoods,itisdifficulttodeterminethepriceforanelectronicserviceinadvance.Forexample,ifthepriceofadatabasequerywerebasedonthenumberofbytesofinformationitgenerates,itwouldbedifficulttodeterminethequery’spricewithoutsearchingthedatabase.Itisinfeasibletolettheuserhavealookattheinformationtoassessitsvalue;itisalsoinfeasibletopriceinformationsolelyuponobjectivemeasuressuchasitssizeinbytes.Thisdifficultyinjudgingthequalityofinformationmaygiverisetodisputeswhicharedifficulttoresolve.Thismakesitimportanttocarefullydefinethelegalroleofthebillingserver.Fourth,electronicinformationcanbeeasilyduplicatedandredistributed.Thismakesproduct“returns”meaninglessbecauseausercancopyanelectronicfilebeforereturningit.Itisalsomucheasiertocopyandredistributeanelectronicversionofabookthancopyandredistributeaprintedversionofthesamebook.TheINIInternetBillingServerisabletoaddresssome,butnotall,oftheseissues.Securityisprovidedusingpasswordsandencryption.TheIBSalsoprovidesacapabilityforsettingand-3- AnInternetBillingServerenforcingspendinglimits.Thebillingserverprovidesaflexiblemechanismforchargingfornetworkservices,andforpricenegotiation,butitdoesnotpretendtoresolvetheproblemofdeterminingaservice'svalue.Nordoesitaddresstheissueofillegalcopyingandredistributionofpurchasedinformation.3.FunctionsProvidedbyaBillingServerAbillingserverplaysthesamerolevis-à-visendusersandserviceprovidersasacreditcardcompanydoesvis-à-viscardholdersandmerchants.Consideracreditcardholdergoingtorentacar.Hebeginsbyidentifyinghimselftotherentalcarcompanybypresentinghiscreditcardanddriver'slicense.Henegotiateswiththecarcompanyfortheservicehedesires,thecostperdayandthemaximumnumberofdaysheexpectstokeepthecar.Themerchantthenverifiesthecustomer'screditwiththecreditcardissuerandplacesaholdonthecustomer'screditforthemaximumamountoftherental.Whenthecustomerreturnsthecar,thetransactioniscomplete,andthecarrentalagencysendsafinalinvoicetothecreditcardcompany,withacopytotheconsumer.Attheendofthebillingcycle,thecreditcardcompanysendsabillforallpurchaseschargedtothecard,includingthecarrental,andthecustomersendsbackhispayment.Thecreditcardcompanypaysthemerchantafterdeductingitsfees.Ourmodeloftransactionsinthenetworkmarketplaceissimilartothecarrentalscenario:acustomerorenduser—throughhiscomputer—interactsoveranetworkwithtwoothercomputersystems:theserviceprovider,andtheInternetBillingServer.asillustratedinFigure1.[putfigure1here]Allofthestepsdescribedaboveforrentingacarhavetheircounterpartsinthenetworkmarketplace.However,insteadofface-to-facecommunicationsasinthecarrentalscenario,theenduser'scomputerinteractswiththeserviceprovider'scomputeroverthenetwork.EachstepintheinteractionformspartoftheInternetBillingProtocol(IBP),aproposedstandardizedmethodofinteractionamonganenduser'scomputer,theserviceprovider'scomputer,andtheInternetBillingServercomputer.TheInternetBillingServerismorethanacomputerandasetofstandardizedprotocols,however;itisamodelforabusinesswhichprovidesvaluableservicestonetworkmarketplaceentrepreneurs.TheInternetBillingServiceactsasafactorfortheserviceprovider,providingpromptpaymentwhiletakingoverallaspectsofbillingandcollections.Tobesuccessfulasabusiness,theInternetBillingServicemustsatisfytwosetsofcustomers.Itmustattractmerchants-4- AnInternetBillingServerbygivingthemeasyaccesstoalargegroupofcustomers,andprovidingthemacost-effectivewaytoreceivepaymentforservicesprovided.ItmustmakeitaseasyaspossibleforserviceproviderstomakeuseoftheInternetBillingServer,workingwiththeproviderstomodifybothclientandserversoftwaretoimplementtheInternetBillingProtocol.Itmustattractendusersbyprovidingapowerfulandflexiblecapabilityformanagingend-useraccountsandbygivingendusersaccesstoalargenumberofserviceproviders.WhilewehavedescribedtheInternetBillingServiceasanindependentbusiness,largeorganizationsoftenhaveaneedtocreateaninternalequivalentofanInternetBillingServer.Forexample,thecentraladministrationatauniversitysuchasCMUcouldoperateabillingserverasasinglemechanismtobillforonlinelibraryaccess,computingservices,printingservices,andelectronicmail.Whilewerecognizethisasanotherpotentialapplicationforthebillingserversoftwaredevelopedinthisproject,thefocushasbeenonthedesignandimplementationofapublic,third-partybillingserver.Asdesignedbytheprojectteam,theINIInternetBillingServerprovidesthefollowingfunctionstoserviceprovidersandendusers:•AccountManagement.TheIBSenablesenduserstoestablishanaccountrelationshipwiththeBillingServerwhichwillpermitthemaccesstoanynumberofserviceproviders.ServiceprovidersestablishaccountswhichenablethemtousetheIBStobilltheirclientsforservicesrendered.•Authentication:TheIBSprovidesaserviceforauthenticatingbothendusersandserviceproviderspriortoanytransactionandforsecurecommunicationsbetweentheparties.•AccessControl:TheIBSprovidesaccesscontrolforbothendusersandserviceproviders.Informationassociatedwithanenduseraccountcanspecificallydesignatealistofservicesthatmaybeaccessed,oralistofservicesthatspecificallymaynotbeaccessed.•PriceNegotiation:UsingtheInternetBillingProtocol,theendusermaydeterminetheservicesavailablefromtheserviceproviderandthepostedprices.TheInternetBillingServercanrecordthemutualagreementoftheenduserandtheserviceprovideronasetofprices,andthemaximumamountwhichtheenduserhasauthorizedforthissetoftransactions.-5- AnInternetBillingServer•CreditVerification:TheInternetBillingServicewillverifytotheserviceproviderthatthecustomerhassufficientcredittopayfortheproposedtransactionuptotheagreedcap.•FinalInvoice:Attheconclusionofthetransaction,theserviceprovidercansendafinalinvoicetotheBillingServerusingtheIBP.TheInternetBillingServerwillsendanauthenticatedcopyoftheinvoicetotheenduser.•PeriodicBilling:TheInternetBillingServerwillgenerateperiodicbillingstatementstocustomersdetailingalloftheirtransactionsandthesumsowed.•Collections:TheInternetBillingServicewillcollectfundsfromendusersandmakepaymentsfromthesefundstoserviceproviders.•DirectoryServices:TheInternetBillingServiceprovidesa"whitepages"and"yellowpages"serviceforidentifyingserviceproviders•HelpService:TheInternetBillingServerprovidesanonlinehelpmanualservice.•Softwarelibraries.Intheclientservermodel,everyserviceprovidermustmakeavailabletoendusersclientsoftwarecapableofaccessingtheserviceprovider'sservice.AsuccessfulInternetBillingServicemustprovideasetoflibraryroutineswhichmakeitsimpletoupgradebothclientandserversoftwaretosupporttheInternetBillingProtocol.ThesemodulesareshownlogicallyinFigure2.[putfigure2here]4.DesignObjectivesIndevelopingtheInternetBillingServerandtheInternetBillingProtocolwewereguidedbyseveralfundamentalconsiderations.-6- AnInternetBillingServer•TheInternetBillingServerwilloperateinatransaction-orientedenvironment.Allcommunicationsbetweenthepartieswillbebasedonaremoteprocedurecallcommunicationsparadigm.Thisisinsharpcontrasttomostcurrentnetwork-basedinformationservices.Thesetypicallyhavebeenprovidedvialargetimesharedcomputers.Usersloginoverlow-speednetworksfromdumbterminals–orPCsemulatingdumbterminals–andarechargedbyconnecttime.However,asdesktopcomputershavereplaceddumbterminalsandnetworkshaveincreasedinspeed,anewinformationaccessparadigmhasemerged:client-server.Inthisparadigm,powerfuldesktopcomputersrunninguser-friendlyclientsoftwareinteractwithremoteserversonatransactionbasis.Inafewsecondslargefilesofinformationcanberequestedandtransferredfromserverstoclients.FileTransferProtocol,Gopher,andWideAreaInformationServicearebutafewoftheclientserverprotocolsusedbynumerousclientsandserversontheInternet.Inaclient-serverenvironmentthereisnonotionofconnecttime.Accordingly,servicesmustbebilledonaper-transactionbasis.•Thebillingservershouldhavehighavailabilitysince,initsabsence,theserviceproviderswillnotbeabletooffertheirservicestoendusers.•Thebillingservershouldbescalable.Itisdifficulttopredicttheinitialnumberofcustomersandthegrowthpattern,eventhoughthenumberofpotentialcustomersislarge.Theselattertwopointssuggestthatthebillingservershouldbedesignedtorunonreplicated,distributedcomputers,thusprovidingmodularscalabilityandhighavailabilitythroughredundancy.•Communicationsbetweentheparties—enduser,serviceprovider,andbillingserver—shouldbebasedonwidelyavailabletelecommunicationsstandardstoensurethelargestmarketfortheservices.•Secureauthenticationandencryptionarecriticalbecauseallthreepartieswillbeconnectedviainsecurepublicnetworks.Withoutasecureauthenticationmechanismthereisasubstantialpotentialforfraud.•Beforeusingaservice,theendusermustunderstandandagreetothepricesandtermsoftheexchange.Thetransactionprotocolinthebillingsystemmustsupportaninitialpricenegotiationbetweentheenduserandtheserviceprovider.Thebillingservershouldbeinformedabouttheoutcomeofthisnegotiationbyboththeserviceproviderandtheenduser.Toavoiddisputesthebillingservershouldmakesurethattheuserandtheserviceproviderhavethesameversionoftheagreement.-7- AnInternetBillingServer•Theusersshouldbeabletolimittheirfinancialexposureonatransactionbyspecifyingaspendingcap.Ifthecostofanongoingtransactionexceedsthisspendingcapthentheendusershouldbeabletochoosewhethertoabortthetransaction,orcontinueitbyraisingthespendingcap.•Thebillingservershouldnotbecomeabottleneckslowingthespeedofinteractionbetweentheenduserandtheserviceprovider.Inparticular,thebillingservershouldnotbeagatewayforcommunicationbetweentheenduserandtheserviceprovider.Interactionswiththebillingservershouldbeasfewandassimpleaspossible.•Thebillingseversoftwareshouldhelpusersintheiraccountmanagement.Itshouldsupporthierarchicalaccountssothatcorporateuserscangetbillsaggregatedbyorganizationalunitssuchasdepartments,regionsordivisions.Similarly,aproviderofmultipleservicesmayuseanaccounthierarchytoorganizeinformationontheuseofeachservice.Withthesegeneralrequirementsinmind,theprojectteampreparedadetailedrequirementsdocumentspecifyingallofthecapabilitiesrequiredoftheInternetBillingServer.45.DesignoftheInternetBillingServerOurprototypeInternetBillingServicewasimplementedusingwidelyavailabletechnology.TheBillingServerprototypeisdesignedtorunonaDigitalEquipmentCorporationworkstationclassmachinerunningtheUltrixoperatingsystem.ItwaswritteninCandusestheIngresDatabaseManagementSystem.ItalsousesTransarcCorporation'sBaseDevelopmentEnvironment(BDE)toprovidemultithreading,whichallowstheprototypetoprocessconcurrentrequestsefficiently.Forcommunicationbetweenthebillingserver,endusers,andserviceproviders,theprototypeusestheremoteprocedurecall(RPC)portionoftheDistributedComputingEnvironment(DCE)providedbytheOpenSoftwareFoundationandtheTransmissionControlProtocol/InternetProtocol(TCP/IP)protocolsuite.ImplementationsofDCEareavailablefortheOS2/2.xandMicrosoft'sWindowsNToperatingsystemsaswellasUnix.AuthenticationisimplementedusingtheKerberosprotocoldevelopedatM.I.T.AllcommunicationsbetweenthepartiesareencryptedforsecurityusingtheDataEncryptionStandard(DES)encryptionmethod.CodelibrariesenablingrapidmodificationofclientandserversoftwaretosupporttheInternetBillingProtocolwerewritteninC.Asatestofthecompletesystem,wemodifiedversionsofFile-8- AnInternetBillingServerTransferProtocol(FTP)clientandserversoftwaretomakeuseoftheInternetBillingServer.Usingthesesoftwarepackages,aserviceprovidercoulddistributeinformationusingFTPandbillforitusingtheInternetBillingServer.6.TransactionSequenceFigure3illustratesthesequenceofstepsinvolvedintheuseoftheInternetBillingServer.[putfigure3here]Step0.EstablishinganAccountPriortoengaginginanetwork-basedtransaction,anendusermustfirstestablishanaccountwiththeInternetBillingServer.Inourdesign,anynumberofaccountsmaybeorganizedinahierarchicalfashionbyallowingeachaccounttohavesub-accounts,eachofwhichisalsoanaccount.SeeFigure4foranexampleofasinglehierarchicalaccountstructure.[putfigure4here]Thehierarchicalstructurerepresentsauthorityoveraccounts;theenduserofaparentaccounthasauthorityovertheenduserofasub-account.EveryhierarchyhasanAccountAdministrator,whoisabletoviewfinancialinformation,andmodifycertainaccountcharacteristicsforalltheaccountsinthehierarchy.Billingandusageinformationcanbeaggregatedbyvariousbranchesofthehierarchicalstructure,ordetailedinformationforeachnodeinthestructurecanbesupplied.Anorganizationshouldhavetheabilitytogivemanagersprivilegestomodifysomeoftheinformationfortheaccountsoftheirsubordinates.ThishierarchicalstructureallowstheaccountenvironmentwithintheInternetBillingServertomirrortheenvironmentwithinorganizations.Accounthierarchiesmaybeindividuallyorcollectivelybillable.Inthefirstcaseeachaccountisfullybillable,i.e.,itcontainsallthefinancialinformationsuchasbalancedue,adjustments,paymentsandusageinformation;thehierarchyisusedmerelytoprovideaggregatebillinginformationformanagementandcontrol.Thismodelmaybemoreappropriatefordecentralizedorganizations.Inthesecondtypeofhierarchyonlytheparentorrootofthehierarchyisfullybillable,i.e.,onlytherootaccountcontainsthefullbillinginformationforthehierarchywhereas-9- AnInternetBillingServerforotheraccountsonlytheusageinformationislisted.Theprototypeonlysupportshierarchieswhereeachaccountisafullybillableaccount.Serviceproviderswhichoffermultipleservicesmaywanttoordertheiraccountsinahierarchytohelpmaintainvaluablemarketingandusageinformation.SinceeachdistinctservicerequiresauniqueKerberosidentifierandanaccountwillnotprovidemultipleKerberosidentifiers,eachservicemustbegivenaseparateaccountwithintheInternetBillingServer.Byallowingtheseaccountstobeplacedintoahierarchicalstructure,theInternetBillingServercanmakeoneaggregatedpaymenttotheserviceproviderinsteadofaseparatepaymentforeachservice.Inaddition,hierarchicalaccountsmakeiteasiertosupplytheserviceproviderswithonestatementcontainingusageinformationforalloftheirservices.Step1-UserAuthenticationandAccessControlSinceanetworkisamutuallysuspiciousenvironment,theserviceproviders,theendusers,andthebillingservermustauthenticateeachotherpriortoanytransaction.Thisstepmaybecomparedtocreditcardusersshowingtheirdriver’slicensetoprovetheiridentitywhileusingacreditcard.Asnoted,weuseaKerberos-basedauthenticationsystemforsecurecommunicationbetweenendusers,serviceproviders,andthebillingserver.Cross-realmKerberosauthenticationmayberequiredinthefull-scalesystemiflargeusersauthenticateenduserswithintheirorganizationandthenaskthebillingservertoaccepttheirauthentication.However,ourprototypedoesnotneedcross-realmKerberosauthenticationbecauseitfunctionswithinasmallgroupofendusersandserviceproviders.AllcommunicationisencryptedusingtheDataEncryptionStandardforsecurity.Afterauthentication,theendusersmaydirectlyrequestaccesstoaspecificserviceprovider,ormaysearchthroughanindexofserviceprovidersclassifiedbyservicecategoriestoselecttheservicetheywant.Theprototypedoesnotsupportthedirectoryservice.Thebillingservercheckstheaccesscontrollistsofboththeenduserandtheserviceprovidertoensurethattheenduserisallowedtoaccesstherequestedservice.Inthefullsetofrequirements,theend-userandservice-provideraccountsmayhavetwotypesofaccesscontrollists:(1)twopositiveaccesscontrollists--onelistingspecificserviceproviders/endusersandtheotherlistingcategoriesofserviceproviders/end-users;and(2)similarly,twonegativeaccesscontrollists.Endusers'listsspecifywhichserviceproviderstheycan(positivelists)orcannot(negativelists)access;similarly,serviceproviders’listsspecifywhichendusersareallowedornotallowedaccesstothem.Thenegativeaccesscontrollistsoverridethepositivelists,anddeterminewhichspecificservicesorservicecategoriescannotbeaccessedfromtheaccount.Corporateuserscouldusepositive-10- AnInternetBillingServeraccessliststoallowaccessonlytocompany-approvedserviceproviders.Parentscouldusenegativeaccesslists,analogousto900telephoneserviceblocking,topreventtheirchildrenfromaccessingfrivolousorhigh-costservices.Wehaveimplementedonlynegativeaccesslistsforendusersandonlypositiveaccesslistsforserviceproviders.Ifaccessisallowed,thebillingserverissuestheenduseraKerberosticketfortheserviceprovider;thatauthenticatestheendusertotheserviceprovider.Asmentionedbefore,theendusermusthavetheclientsoftwarespecifictotheserviceprovider(forexampleFTPorInternetGopherinterfacesoftware)inordertoaccesstheserviceprovider.Steps2and3-PriceNegotiationandSpendingCapAftergettingaKerberosticketfromthebillingserver,theenduserandtheserviceprovidernegotiateapricefortherequestedserviceandaspendingcapforthetransaction.Thisiscalledanagreement.Notethattheenduseriscommunicatingwiththeserviceprovider'scomputer,notwithahumanrepresentativeoftheserviceprovider.Theendusersendsacopyoftheagreement,encryptedwithhisprivatekey,totheserviceproviderwhoforwardstheenduser’scopytothebillingserver,alongwithhisowncopyoftheagreement.Thispreventsanunscrupulousserviceproviderfromchangingtheagreementbeforesendingittothebillingserver.Italsoreducesthecommunicationloadonthebillingserver,sinceitreceivesonlyonecombinedmessageratherthantwoseparatemessagesfromtheserviceproviderandtheenduser.Thefull-scalebillingserverallowsrenegotiationofspendingcapsiftheinitialspendingcapprovestobeinsufficient.Howeverthiscapabilitywasnotimplementedintheprototype.Step4-VerifyingSpendingCapandCreditThebillingserverdecryptsthetwocopiesoftheagreementandcomparestheenduser’sversionwiththeserviceprovider’sversion.Ifthetwocopiesmatch,thenthebillingserverchecksiftheenduserhassufficientfundstopayforthetransactionandplacesaholdontheenduser'sfundsintheamountofthespendingcap.Itthensendsanauthorizationtotheserviceprovider.Inthefull-scaleserver,theenduserscanspecifytheirpreferredpaymentmethod;thiscouldbehistoricalbilling,advancedepositorcreditcard.Withhistoricalbillingtheuserreceivesabillfor-11- AnInternetBillingServertheservicesthattheyusedattheendofaspecifiedperiodoftime.Advancepaymentmeansthattheuserdepositsfundswiththebillingserverbeforeusingservices,andreceivesaperiodicstatementoftheservicesusedandthefundsremaining.Withcreditcardbilling,theircreditcardisbilledwhenaccumulatedchargesreachaspecifiedlimit.Inadditiontothesethreeoptions,corporateuserscanusepurchaseorders,aformofhistoricalbilling,formakingpayments.Theprototypeallowsdepositinadvanceastheonlypaymentmethod.Step5-PerformingtheServiceMessagesareexchangedbetweentheclientandtheserviceprovidertoperformtheservice—e.g.retrieveinformation,performcalculations,orspoolaprintfile.Step6-GeneratinganInvoiceAftertheserviceproviderhasrenderedtheservice,itsendsthebillingserveraninvoicedetailingtheservicesperformedandtheactualamountstobecharged.Thebillingservercheckswhetherthepriceinformationontheinvoiceisidenticaltothepriceinformationreceivedearlierduringthepricenegotiationstage.Thisprotectstheusersfromunscrupulousserviceproviders.Thebillingserverthenforwardsthisinvoicetotheuser.Sincetheidentityandcreditcapacityoftheenduserswerepreviouslycheckedbythebillingserver,theserviceprovidershaveassuredpaymentfortheirservices.Theserviceprovidersarerequiredtomaintainanaudittrailtohandlecustomerinquirieswhichcannotberesolvedbythebillingserver.7.AccountManagementEnduseraccountscangothroughvariousstates,asillustratedinFigure5.Toopenanaccount,theenduseraccountadministratorsendsarequesttothebillingserver.Oncealloftheinformationrequiredforthecreationofanaccountisentered,theaccountentersthe“new”state.Anaccountcannotbegintoaccessservicesuntilthebillingserver'saccountadministratorverifiesandapprovestheaccountcharacteristicsandthebillingserver'sfinancialadministratorverifiesandapprovesthefinancialinformation.Oncetheseverificationsarecomplete,theaccountisactivated.Anaccountwhichhasbeenactivatedentersthe“active”stateandisthenallowedtoaccumulatechargesforservicesitaccessesthroughthebillingserver.[putfigure5here]-12- AnInternetBillingServerAnaccountgoesintothe“deactive”stateifithasanoverduebalanceforanunreasonableperiodoftime.Itgoesbacktothe“active”stateifthebalanceispaid.Anaccountcanalsoenterthe“closed”statebyenduserrequestorifpaymentisnotreceivedwhileitisinthe“deactivated”state.Accountsmayenterthe“paid,”“writtenoff,”or“referredtoagency”statesafterbeinginthe“closed”state.Anaccountentersthe“paid”stateifthefinalbalancedueispaidinfull.Anaccountentersthe“writtenoff”stateifthebillingserverfinancialadministratordeterminesthatpaymentforthebalanceduewillnotbereceived.Anaccountentersthe“referredtoagency”stateifthebillingserver'sfinancialadministratorreferstheaccounttoacollectionagency.Sincetheprototypehandlesonlydebitmodelaccountswhereuserspayinadvance,thereisnoneedforanapprovalprocess.The“new”stateisnotneeded.Againbecauseofpaymentinadvanceandthecreditcheckperformedduringtransactions,endusers'accountscannotowemoneytothebillingserver.Therefore,the“deactive,”“paid,”“writtenoff,”and“referredtoagency”statesarealsonotneeded.Intheprototype,whenanaccountis“closed”itisremovedfromthedatabase.Thereforeaccountstatesarenotsupportedbytheprototype.Userscanaccesstheirownaccountinformationatthebillingserverthroughaninterfacethatallowsthemtoviewfinancialinformation,andtomodifycertainaccountcharacteristics.Thefull-scalebillingserveralsoprovideson-linehelptoitsusers.Thehelp,whichcanbeaccessedthroughakeywordsearch,consistsoftextscreensdescribinghowtoperformbasicoperations.Sinceon-linehelpisnotcentraltothebillingserver,itisnotimplementedintheprototype.8.ConclusionWhatdistinguishestheCarnegieMellonprojectfromotherpiecemealorservice-specificsolutionsisitscomprehensiveanalysisofthenetworkservicesbillingproblem.Theprojecthasmadetwocontributions:(1)ithashighlightedthecomplexandchallengingissuesinvolvedinthedesignoftheInternetBillingServer;and(2)ithasdemonstratedthefeasibilityofitsproposedsolutionthroughthesuccessfuldesignandimplementationoftheprototype.Eventhoughtheprototypeimplementsonlyasubsetofthefullrequirementsandmayhavetobesignificantlymodified,itisanimportantfirststep.AcommercialservicebasedontheconceptsintheINIInternetBillingServercouldbethekeytotherapidgrowthofentrepreneurialserviceprovidersintheInternetenvironment.-13- AnInternetBillingServerForfurtherinformation,pleasecontactTheInformationNetworkingInstituteatCarnegieMellonUniversity,Pittsburgh,Pennsylvania15213.Tel:(412)-268-7195.References1JohnQuarterman."InDepth.(WhatcanbusinessesgetoutoftheInternet?)"Computerworld,February22,1993,p.81.2ForacompletereportoftheprojectincludingthefullRequirementsSpecificationandPrototypeDesignDocuments,contacttheInformationNetworkingInstitute,CarnegieMellonUniversity,Pittsburgh,Pennsylvania15213-3890.3JenniferSteiner,CliffordNeumanandJeffereySchiller.“Kerberos:anauthenticationserviceforopennetworksystems.”USENIXWinterConference,9-12February1988,Dallas,Texas.4RichardBatelaan,et.al.AnInternetBillingServer:SystemRequirements.CarnegieMellonUniversityInformationNetworkingInstitute,August1992.-14- [FIGURES]NetworkServiceProviderEndUserBillingServerFigure1.ElectronicMarketplace AnInternetBillingServerEndBillingUserServerClientSoftwareIBPInterfaceIBPPricingInterfaceModuleModuleServiceCodeServiceProviderFigure2.InterfaceLibrariesProvidedbyInternetBillingService-16- AnInternetBillingServer2UserService52Provider130465DirectoryBillingServerAuthenticationFigure3:TransactionSequencefortheBillingserver-17- AnInternetBillingServerAccount#1sub-accounts:3,5,9Account#3Account#5Account#9sub-accounts:sub-accounts:sub-accounts:2,8None4Account#2Account#8Account#4sub-accounts:sub-accounts:sub-accounts:NoneNoneNoneFigure4:AnExampleAccountHierarchy-18- AnInternetBillingServerRequestNewapprovalActiveRequestRequestorNon-PaymentRequestorPaymentDeactiveClosedNon-Paymentoffamount<=wriitten>writtenoffamountpaidbillWrittenReferredPaidOfftoAgencyFigure5:AccountStateDiagram-19-

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。
关闭