Network Computing

MunindarP. Singh�andMladenA. Vouk

�

Departmentof ComputerScienceNorthCarolinaStateUniversity

446EGRC/Box7534,1010Main CampusDriveRaleigh,NC 27695-7534,USA

singh@ncsu.edu, vouk@csc.ncsu.edu

�MunindarSingh’sresearchis partiallysupportedby theNCSUCollegeof Engineering,theNationalScienceFoundationunder

grantsIRI-9529179andIRI-9624425(CareerAward),andIBM corporation.�MladenVouk’s researchis partially supportedby the NationalScienceFoundationundergrantACS-9696131,NASA, EPA,

andIBM corporation.

Contents

1 Intr oduction 11.1 Whatis Network Computing? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 A Brief Historyof NC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 ScopeandOrganization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Applications 62.1 EnterpriseIntegration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Virtual EnterprisesandManufacturing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 ElectronicCommerce. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 ComputerSupportedCooperative Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.5 ScientificComputing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.6 DistanceEducation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.7 OpenInformationEnvironments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.8 UbiquitousComputing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Paradigmsand Ar chitectures 113.1 DistributedObjects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Collaborative Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3 MultidatabasesandInteroperableSystems. . . . . . . . . . . . . . . . . . . . . . . . . . . 133.4 TransactionProcessing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.4.1 TraditionalTransactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.4.2 ExtendedTransactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.5 Workflow Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.5.1 Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.5.2 ProgrammingandEnactment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.6 AgentsandMultiagentSystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.7 EnhancedWorkflow Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Technologies 174.1 DistributedComputing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2 SystemIntegration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.3 Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3.1 MessagePassing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.3.2 ObjectExchange. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.4 ItinerantandStationaryAgents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.4.1 Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.4.2 CommunicationLanguages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5 Infrastructur e 235.1 ComputersandOperatingSystems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1.1 Network Computers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.1.2 Mobile Computers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.2 NetworkingSupport. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.2.1 Network Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.2.2 InternetandIntranets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.2.3 Network Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.3 Network Functionalities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.4 Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6 Research Issues 266.1 FormalMethods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.2 Interaction-OrientedProgramming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.3 Qualityof Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.4 Performanceof NC Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

7 ReadingList 33

8 CrossReferences 33

3

1 Intr oduction

1.1 What is Network Computing?

The rapidexpansionof the computingandcommunicationsinfrastructureis not only enablingnew grandapplications,but alsoinfluencingthescienceof computingin termsof

� themetaphorswith whichweview computing

� thearchitecturesof computingsystems

� thespecifictechnologiesthatrealizethosearchitectures

� thetoolsandtechniqueswith whichweconstructthem.

The termoftenusedfor this new paradigmis networkcomputing(NC). NC environments(NCEs)areen-visionedascollectionsof interactive andcooperatingprograms,tools,clients,andintelligentagents.Thesecomponentsare(ultimately) integratedinto an“appliance-like” environmentthat facilitatesusers’(profes-sional,learning,entertainment)activities by maximizingactive, friendly supportfor themandminimizingtheir interactionswith theunderlyingsystems.

For example,consideraNetwork-BasedEducation(NBE) system,a typicalNC application.Theprimefunctionof anNBE systemis to maximizeknowledgetransferandretentionto a largenumberof studentsdistributedin bothtimeandspace.Thestudentuseris primarily concernedwith theavailability andqualityof theeducationalmaterial,oftenat timesotherthantheoneswhenthe lecturesaregiven. The instructor,anothertypeof NBE user, dealswith bothin-classstudentsand“li ve” remotestudentswhoattendtheclass.Theinstructor’s immediateconcernsrangefromtheavailability of thenetwork-basedpresentationmaterials,the ability to interactwith both in-classandremotesynchronousstudents,andthe ability to captureclassmaterialsandexchangesto enableasynchronousstudentsto accessthe materialat a later time. Neithercategory is really interestedin, nor hastime, to worry abouttheunderlyingissuesof network availability,storage,throughputguarantees,andsoon. Thelatterareexpectedto beprovidedby theinfrastructuresandmodelsthatsupportNBE systemsin aseamlessandunobtrusive way, andenabletheusersto goabouttheirworkflowsof learning(students)andteaching(instructors)withouthaving to givetheNC “appliances”morethoughtthanthey would to apen,paper, chalkboard,or anoverheadprojector.

An exampleof a moregeneralenvironmentfor NC is theWorld Wide Web(WWW) [10, 9]. It couldbe the immediateplatform for the above-mentionedNBE system(e.g.,Web LectureSystem[109]). Thesupportinginfrastructureis theInternetwhichcanbethoughtof astheglobalcomputernetworkconsistingofcomputersrunningtheTransmissionControlProtocol/InternetProtocol(TCP/IP).TheWWW is thesubsetof theInternetthatsupportstheHypertext TransferProtocol(HTTP).TheWWW is almostalwaysidentifiedwith theHTML-basedcontentto which it enablesaccess.Beyondthis low-level description,however, whatmakestheWWW worthusingandstudyingis thepresenceof thematerialthatWWW supports.

Fundamentally, whatmakesnetwork computingworthwhilein anengineeringsenseis thecombinationof

� the needfor someresource-intensive “killer” applications,alongwith the opportunityfor develop-ing thoseapplicationsin a network-centricmannerto sharethecostandmaximizetheutilization ofavailableresources

1

Figure1: Perspectivesona Network ComputingArchitecture

2

� the needto provide lessdemanding,but guaranteedservices,to thousandsandmillions of usersbythousandsof providersseparatedin bothtimeandspace.

This article surveys network computingin the large, as the intellectualdiscipline that underliestheapproachesthataddressboththegrandandeverydayapplicationsof today. Therehasbeensomeindustryinterestin theconceptof networkcomputers, machinesthatmaylack a local disk andrely on thenetworkfor functioningat all. This is to becontrastedwith thenotionof nationaldataandcomputinggrids, whichpromiseto helpamelioratetheresourcecrunchthatis facingthenationandtheInternetusers.Weview theformerasonespecializedinfrastructureandarchitecturefor network computingandshalladdressit only atahigh level here,while thelatteris morerepresentative of thegeneralnetwork computingparadigm.

1.2 A Brief History of NC

Computingtechnologyhasevolved enormouslyover the pastfew decades.In our view, the evolution oftheparadigmsandarchitectures,andtechnologyandinfrastructurehastrackedtheevolution in applications.Eachsuccessive generationof technologyhassoughtto remove thebottlenecksthatprevent theexpansionof thepreviousgeneration.

Network computing,asa concept,hasbeenpresentsincethe early daysof computing—inthe formof distributedterminalsservicedby centralizedcomputingfacilities, thenthroughthe workstation,client-server, andpeer-to-peerparadigms,andnowadaysthrougha combinationof theseandconceptssuchasthevirtual localareanetworks(LANs), wide-area“compute-girds,” theWWW, andsoon.

3

generation technology example data proc UI maint NWMbps

central main DP S S S S �timeshare main,phone DP S S C S ���C-S mini, LAN DBMS C/S C/S C C/S ��Peer workstn,LAN CSCW L/R L/R L L/R ����HPC main,workstn,OC3 OLAP L/R L/R L L/R �����Limited NC workstn,ATM OfficeWF R L/R L R �����OpenNC workstn,Internet VE, EC R L L L ��� - ����

Table1: TheGenerationsof ComputingTechnology

4

Table1 summarizesthekey featuresassociatedwith eachgenerationof computingtechnology:central-ized, timeshare,client-server, peer-to-peer, high performancecomputing,limited NC, andopenNC. Thecorrespondingrepresentative examplesarefile-baseddataprocessing(DP), databasemanagementsystems(DBMS), computersupportedcooperative work (CSCW),office workflows (WF), online analyticalpro-cessing(OLAP), virtual enterprises(VE), andelectroniccommerce(EC). The data,processing,UI, andmaintenancecolumnsareaboutthelocationof thecorrespondingfunctionalityor component.C, S,L, andR referto client,server, local,andremote,respectively.

Whencomputerswerefirst networked in the sixties,they wereexpensive mainframes.The paradigmof usagewastime-sharein which multiple userscouldaccessa singlemainframe.All of thecomputationwasperformedon themainframe;theuserscommunicatedthroughplain terminals.With thedevelopmentof databasetechnologyandminicomputersandthe expansionof computinginto newer applications,thisparadigmwaspreservedalthoughthesizeof thenetwork grew andthetypeof end-userstationschanged.

The early eightiessaw the emergenceof the client-serverparadigm,which is a form of weak dis-tributedcomputing. In this paradigm,the usersits on a computer, which handlesthe userinterfaceandotherapplication-specificcomputation.Thecomputercouldbea genuineworkstation-typecomputer, PC,or anX-station.Theclient,however, relieson theserver for all of its datamanagement.Theservercanbeasimplefile server or adatabaseserver. Thelatteralsoprovidesadvancedfunctionalitysuchas

� concurrency control—tokeepthevariousclientsfrom inadvertentlydestroying eachother’s work

� transactionalsupport—toguaranteeatomicityof thework performedby aclient

� backupandrecovery—incaseof mediaor systemfailure

Theclient-server architecturecanbe thoughtof asbasedon theremote-procedurecall (RPC)mechanism.RPCprovidesaprogrammaticinterfacethroughwhichcomputingresourcesatremotehostscanbeaccessed.However, its fundamentalshortcomingis thatit is synchronousor blocking—inotherwords,thecallerwaitsuntil thecalleecanproducea result.Thusit is notanefficientmeansto usecomputationalresources.

Thenext generationof computing,alreadybeingdeployed, is truedistributedcomputing.This is alsocalledthepeer-to-peerparadigm.In this paradigm,thedifferentnodesexchangeasynchronousmessages,in whichneitherpartywaitsunnecessarily.

Interestingly, theWWW in its presentincarnationfollows theclient-server paradigm.This is becauseHTTP, the protocol that underliesthe WWW is a client-server protocol. A browser (working as client)canrequestinformationfrom a WWW server; the server cannotunilaterallysendupdatesto the browser.Thenext versionof HTTP will, however, admitboth thepresentpull-basedparadigmandthepeer-to-peerpush-basedparadigm.

1.3 Scopeand Organization

Over theyears,the focal solutionsweredriven by the technologicalandusagebottlenecks.Network bot-tleneckstendto put thecomputingpower on thedesktop,centralprocessingunit (CPU)bottleneckstendtoprovidedistributedaccessto powerful centralizedresources,while informationdistributiontendsto promotepeer-to-peerinteractions.The main resultof this evolution is the conclusionthat, in general,asthe com-plexitiesof thesocialandphysicalworld in whichcomputersaredeployedarebetteraddressed,it turnsoutthatnetwork computingcanprovide greaterefficiency—andhencereducedcostandimprovedquality—intheconstructionandmaintenanceof complex computationalapplications.

5

Consequently, we baseour presentationon a workflow-basedtreatmentof network computing.Work-flows area seriesof structuredhumantasks,computationsandinteractionsamongthemthat ariseduringaccomplishmentof any setof focusedactivities(e.g,teaching,scientificproblem-solving).In otherwords,aworkflowis amultitaskactivity thatconsistsof humanandcomputationaltaskscoordinatedin anappropriatemanner. Workflows areoftenexecutedon a numberof computersystemsandover a numberof databases.Nowadays,it is commonto associatesuchsystemswith agents.Althoughagentsarea commonbuzzword,all too often,agentsmay be nothingelsebut daemons,or specializedutility processesandprogramsthathelp NC systemsoperatein a moreintegratedandautonomousfashion. In general,agentsarepersistententitieswith someautonomy, which perceive, reason,act,andcommunicate.Theagentmetaphoris apow-erful one,but only whencoupledwith the metaphorof interaction. Whenwe couplethe two, we obtainmultiagentsystems. NC is fundamentallybasedonthenotionof interaction.For thisreason,webelieve thatNC environmentsof the futurewill almostcertainlybepopulatedby hostsof agentsof the latterkind. Inthatcontext, four importantlayersof considerationare:

� NCapplicationswhichreferto theend-usersystemsthatmaybethoughtof asprovidingdirectsupportin responseto userworkflow needs.

� NCparadigmsandarchitecturesarewaysof thinkingabouthow userworkflow needsmaybeprovidedin distributed computationalsystems. They provide the meansand methodologiesfor the globaldesignof systemsthatrealizeuserapplications.

� NCtechnologiesaresystem-level building blockswith which theglobaldesignsareinstantiated.

� NC infrastructures provide the network and computingsystemfunctionalitieson which the abovetechnologiessubsist.

Theabove conceptsarediscussedin moredetailin thesectionsthatfollow.

2 Applications

Network computinghasa large numberof importantapplications.Theseapplications,thoughin widelydifferentdomains,sharethecharacteristicsthat they areoftenlarge-scale,distributed,heterogeneous(bothin their softwareandhardware),open(in that they cangrow andshrink dynamically),andcomposedoflocally autonomousunits. We provide anoverview of someof themostinterestingandimportantproblemdomainsin whichNC is applied.

2.1 Enterprise Integration

Enterpriseintegration is oneof the oldestapplicationsof NC, and in fact predatesthe emergenceof theWWW by several years.This applicationaroseasa consequenceof thesuccess,but alsothe limitations,of previous dataprocessingtechnology. As computingsystemscamemorepowerful, databasesbecameever moreprevalentin all kindsof organizations.For ourpurposes,enterprisesaregovernmentor businessorganizationsviewed in termsof the informationthey acquire,own, andmanagein pursuit of their keyfunctions. Enterprisesbecameto dependon online databasesfor almostall of their businessneeds.Alltoo often, several databaseswerebuilt in an ad hoc mannerin differentpartsof an organization. These

6

databases,althoughindividually useful,would not andcould not talk to eachother. Not only could theknowledgeof anenterprisenot beput together, it wasoftenalsothecasethat thedifferentdatabasesweremutuallyinconsistent.Naturallyenough,this led to poordecision-supportleadingto lossesin productivity,qualityand,ultimately, in thebottomline.

In a conceptualsense,integrating preexisting systemsis in generala harderproblemthandesigningdistributedsystemsafresh.Many systems,especiallythosebasedon oldermainframearchitectures,allowdatato beaccessedonly throughnarrow, inflexible interfaces.Suchsystemsarefrequentlytermedlegacysystems—apparently, the term waschosenwith a disparagingconnotation.Legacy systemsandtheir in-terfacescannotbeeasilymodified. No reasonableapproachwould try to modify themsignificantly. Thisis becauseof two main reasons:(1) the complexity of the programmingeffort that would be requiredtoachieve any modifications,and(2) the constraintthat older applicationscontinueto run asbefore,sincethey typically have a wideuserbasethatreliesheavily uponthem.Thus,theintegrationmustpermitnewlydevelopedapplicationsto coexist with previousapplications.

However, integratingpreexisting systemshasmajoradvantagesover implementingdistributedsystemsfrom scratch:

� Theexisting systemstypically serve importantbusinessfunctions,which it would beundesirabletodisrupt.

� Theneedfor theintegrationresultsfrom thegrowth or restructuringof anenterprise,e.g.,becauseofmergersandacquisitions,or becauseof anew wayof understandingtheinformationprocessescarriedout in theenterprise,e.g.,becauseof reengineeringor refocusing.Thisneedis notof thesortthatcanbeaddressedonceandfor all, but ratherwill naturallyemergeagainandagainover time.

� Theintegrationoffersanopportunityfor preservingwhateverwecanof theautonomyof theindividualcomponents.A redesignthat resultsin a new conceptuallymonolithic system,even if improved,wouldnotbequiteeasyto reuse.This is becausemonolithicity is a liability whenever asystemneedsto be modified. Modificationsmaybeessentialasneedswithin the componentschange,or anotherrestructuringtakesplaces,e.g.,to separateoutthebusinessdivisionsthathadbeenputtogetherbefore.

As a concreteexample,onwhich oneof theauthorspreviously worked[98], considera largecompany thatprovidesa varietyof telecommunicationservices.We studiedtheworkflow for establishinga telecommu-nicationlink betweentwo specifiedpoints(this is termedserviceprovisioning). In theoriginal workflow,a setof paperforms wasreceived that gave a numberof relevant detailsaboutthe servicebeingordered.Theseformswereenteredinto thesystem.A testwasthenperformedto determineif the telecommunica-tionsequipmentrequiredfor theorderwasalreadyin place.If so,theservicecouldbeprovidedrelativelyquickly; otherwise,theprocessingwouldbedelayeduntil theequipmentwasadded.

In theoriginalworkflow, serviceprovisioningtypically would take severalweeksandrequirecoordina-tion amongmany operation-supportsystems.Configuringthe operation-supportsystemsto performsucha taskoftenwould take several months.Our goalswereto reducethis time to lessthantwo hoursandtoprovideaway in whichnew servicescouldbeintroducedmoreeasily. Ourstrategy for accomplishingthesegoalswasto (1) interconnectandinteroperateamongthepreviously independentsystems,(2) replaceserialoperationsby parallelonesby makingappropriateuseof relaxed transactionprocessing[16, 35], and(3)automatepreviouslymanualoperations,therebyreducingtheincidenceof errorsanddelays.

7

The reductionin time is of competitive significancein the modernbusinessenvironment. The UStelecommunicationshasgonethrougha phaseof deregulation,which reducesor abolishesseveralgovern-mentalregulations,but alsoenablesnew companiesto competein marketsthatwerepreviously controlledby government-supportedmonopolies. In the caseof the enterprisewe arediscussing,a majority of itscompetitorsemergedrelatively recently. As a consequence,thecompetitorstypically hadnewer computingsystems,whichwerebetteroptimizedfor thespecifictaskathand.As remarkedabove,thisadvantageof thecompetitorsis only temporary—aseachmaturesandasregulationsandotheroperatingconditionschange,eachof thesewould inevitably endupwith a heterogeneousmix of legacy systems.

2.2 Virtual Enterprisesand Manufacturing

Virtual enterprises(VEs) area conceptthat resemblesenterpriseintegration,but goesbeyond it in termsof allowing multiple independententerprisesto cometogether, sometimesfor only thedurationof a singlecollaborative project[105]. For thedurationof theproject,thedifferentparticipantsin a VE behave asifthey werepartof thesameenterprise,althoughthey mightpreserve theirautonomyandprivacy with greaterintensitythanin thetraditionalcase.VEssometimesemergefrom thebusinessinterestsof theparticipatingentitieswhomutuallydecideto form thegivenVE. At othertimes,e.g.,in largegovernment-fundedprojects,aVE maybeformedby thefundersby distilling andcombiningthebestexpertiseof theindividualbidders.VEsthusemphasizethechallengesof opennessanddynamism,andin thefaceof maintainingtheautonomyof thecollaboratingorganizations.

In principle,virtual enterprisescanarisein any domain.However, they areoftenassociatedwith man-ufacturing,becausethatdomainlendsitself well to collaborationamongautonomousorganizations.A rep-resentative effort is SMART, which is a multiyear, multimillion dollar manufacturingapplicationsprojectbeingsponsoredby theUS government[99]. SMART standsfor MES-AdaptableReplicableTechnology.MES standsfor ManufacturingExecutionSystems,which describesthemajorkind of flexible manufactur-ingsystems.SMART is beingconductedby theUSNationalIndustrialInformationInfrastructuresProtocols(NIIIP) consortium[45]. SMART usesintelligentagentsto controlmanufacturingexecution[42]. A virtualprivate network(VPN) is a network that is restrictedto the membersof a virtual enterprise.Oneof theinterestingSMART technologiesis basedon informationcontracts, which apply amongthe participatingenterpriseswithin a VPN. Suchcontractsarekey in having autonomousentitiesinteroperatefor flexiblemanufacturing.

2.3 Electronic Commerce

Electroniccommerce(EC) roughly correspondsto doing businessthroughelectronicor network-centricmeans.EChasbeenaroundasaconceptsincetheearlydaysof computing.However, earliereffortsat EC,which achievedonly moderatesuccess,werelimited in their goals.Whatthey primarily offeredwassomestandardizedmeansof exchanginginformation: suchstandardsareknown aselectronic data interchangeor EDI standards.EDI standardstypically did not achieve industry-wideacceptanceandwereoften justenforcedby largevendorsor suppliersonothercorporationsthatsoughtto dobusinesswith them.Also, byandlarge,EDI andrelatedECwork did notaddresscommerceor tradeassuch,but only soughtto facilitatetheflow of informationoncethedetailshadbeennegotiatedandagreeduponin advance.

Themodernvisionof ECis farmoresophisticatedandambitious.It is now consideredwithin our reachto haveautomatedmeansof conductingtradein anopensetting.Serviceprovidersanduserscanbethought

8

of asagentsthatcannegotiatewith another, andwhocanrepresentandreasonaboutcontractualdetails,andcommitthemselves,i.e.,beempoweredto committhehumanwhoseinterestgovernstheir actions.

2.4 Computer SupportedCooperativeWork

ComputerSupportedCooperativeWork (CSCW)isaclassof applicationsthatinvolvehumansto collaboratein performingsometaskover thecomputer. CSCWinvolvestools throughwhich humanscanachieve theeffectof asharedworkspaceevenwhenphysicallydistributed.Naturalandimportantapplicationsof CSCWareauthoring—ofprogramsor documents.

Someissuesin CSCWarepurely of a distributed computingnature,for example,to ensurethat thedocumentsbeingproducedcanbe consistentlyviewed at differentsites. Otherwork concernstechniquesfor versionmanagementand for assistinghumansin merging divergent versionsinto a singleconsistentone—thistaskcanin generalnot befully automated,becausemerging two versionsof documentsrequiresintimateunderstandingof theircontent.

Anotherclassof issuesdealswith explicit sharedworkspaces,not only thoseindirectly reflectedin theartifactsbeingmanipulated.This requiresmoresophisticatedtechniquesof userinterfacesandthecreationof realisticor believableenvironments,for example,for virtual reality.

2.5 ScientificComputing

Like all otherNC environments,modernscientificcomputingandproblem-solvingenvironments(PSEs)arecollectionsof cooperatingprograms,tools, clients,andintelligentagents[38]. Thesecomponentsareintegratedinto anenvironmentthat facilitatesuserinteraction(suchasproblemstatementandsolutionen-gineering)andcooperative executionof the componentscharged with the solutiontasks. An exampleisa systemthat would helpanenvironmentalscientistor regulatorto poseenvironmentalengineeringques-tions (problems),develop, executeand validatesolutions,analyzeresults(e.g., including coupling withGeographicalInformationSystemdataandvisualizations),andarrive at a decision(e.g.,a cost-effectivestrategy to controlchemicalemissions).Sucha PSEwould consistof a management,analysisandcompu-tationalframework thatwould bepopulatedwith a varietyof numericalmodelsanddatathatdescribethesciencebehindthephenomena,thesolutionsof interestandthedecisionrules[31]. It is usuallyassumedthat a modernPSEis distributedacrossa numberof centralprocessingunits that may or may not residein onephysicalcomputer. In fact, the advent of high-performancecomputingenginesandnetworks, thepotentialof new technologiesto guaranteequality of service(QoS), andthereadyaccessto network-basedinformationthroughtheWWW is bringingseriousnumericalandproblem-solvingapplicationscloserto abroadbaseof potentialusers.The next generationof large-scalePSEsis expectedto operatein national‘compute-girds: a meshof high-performancecomputation,datastorageanddatabasenodesinterconnectedby ahighspeedbackbone( ����� – ��� Gbits/second)[4, 56].

Usersexpectnot only the provisioning of high quality numericalcomputingalgorithmsandsoftware,but alsointegrationof thesesolutionswith advancedcomputationalandnetworking frameworks,andwithday-to-dayoperationalenvironmentsandworkflows. Theworkflow paradigmenablesappropriatedescrip-tion andanalysisof coexistenceandmeldingof scientificworkflows with otherworkflows into which theyhave to fit, andof certainquality constraintsdictatedby theselarger workflows. By describingscientificcomputingandproblemsolving asworkflows, we allow for the advancedtechniquesbeingdevelopedinworkflows research,aswell asperformanceandQoSwork deriving from thehigh-performancenetworking

9

andcommunicationsarena.Theseincludesophisticatednotionsof workflow specificationandof toolkitsandenvironmentsfor describingandmanagingworkflows,andrecognitionof performanceissuesthathavepreviouslybeenreservedfor analysisof networks(e.g.,thatend-to-endthroughputobservedby auserat theapplicationlevel will typically be thatof thedevice or processwith the lowestthroughputcapacityin thepath). In this way, NC supportedscientificworkflows areto problem-solvingenvironmentswhatbusinessworkflowsareto NC-basedenterpriseintegration.

2.6 DistanceEducation

Network-BasedEducation(NBE) refersto provision of educationusingNC resources.We take a systemview of sucheducationusing the workflow concept[91, 108, 107]. This conceptrecognizesthe educa-tional processasa systemwhich involves interactionsamonga variety of individuals including teachers,researchers,learners,advisors,andadministrators;througha seriesof workflows primarily involving theaccess,creation,teaching,or manipulationof thesubjectmatter. Theseactivities canbecomeparticularlyintenseanddifficult to manageandsynchronize.Understandingtheeducationalworkflows is key to effec-tiveapplicationof technologyto education.Only whenadvancedcomputertechnologyis correctlymappedto theeducationalprocessthroughtheworkflow model,canits fundamentalbenefitsbegin to approachfullrealization.

The mostimportantNBE systementity, andthe principalquality driver andconstraininginfluenceis,of course,theuser. NBE userscanbeclassifiedinto a numberof categories.Four nonexclusive importantcategoriesarestudents,instructors,authors,andsystemdevelopers[11, 107]. Examplesof otherimportantgeneralcategoriesof usersareparentsof thestudents,employersof continuingandadulteducationstudents,andeducationaladministrators.Specialcategoriesof specialinterestareK-12 users,communitycollegeusers,universityusers,andadulteducationusers.Functionalandusabilityrequirementsderive,for themostpart,directly from theNBE userprofile.

Systemdevelopersareresponsiblefor the developmentandmaintenanceof the systemsoftware andresources,authoringtools,coursewaretools,andsoon. Authorsarecoursewaredevelopers.It is essentialthatauthorsbepedagogicalandcontentexperts,but not thatthey besystemexperts.Instructorsdeliver thecoursematerial. They sampleandcombineexisting lessons,customize,andupdateanddevelop coursesandprojects.Systemsupportfor tutoring,student-instructorinteraction,andstudentevaluationis essential.Studentsarethemostimportantusersof thesystem.They requireappropriatelyreliableandtimely lessondelivery, easy-to-useinterfaces,collaborative supportin local andremotejoint projects,instructor’s help,andsoon. Sincetheclassof thefutureis likely to includestudentsandinstructorswhoarewidely separatedgeographically, who may not able to attendlectureson a presetschedule,and who comewith differentbackgrounds,thetasksfor systemsupportandinstructionshouldscalethebarriersof spaceandtimeaswellasof studentdiversity. Therefore,asuccessfullarge-scalewide-areaNBE systemshould:

� supporta largenumberof studentsthatrangefrom naive to sophisticated.

� supportconstructionanddelivery of curriculato thesestudentsby facilitatingthework of thousandsof instructors,teachers,professorsandparentsthatserve thestudents.

� supportgenerationof adequatecontentdiversity, quality andrange. This may requiresupportformany hundredsof authors.

� bemaintainablewith a relatively smallnumberof systemspersonnel.

10

2.7 Open Information Envir onments

Openinformationenvironmentswere indirectly discussedin someof the applicationsabove. They area unified way of thinking aboutenvironmentsin which informationresourcesmay be addedor removeddynamically. Thusthe informationresourcesareautonomous—apropertythey inherit from their humanowners.Currentenvironmentsbasedon theWWW areusuallyopenin theabovesense.This is whatmakesit difficult to enforceany consistency on thebehavior of specificapplications.A consequenceof opennessis thatstandardsemergeslowly andaretypically “leastcommondenominator”in their extent. Thuson theWWW, HTTP, andHTML arestandardized,but thecontentor evenadditionalstructureof thedocumentsservedontheWWW arenot. A numberof othereffortsandstandardseitherexist, or arein themaking(e.g.,OpenGL).

Openinformationenvironmentsrequirea wider variety of informationaccesstechniques.Traditionalstructuredor text databasessupportquerying,wherea queryis formulatedby the user, andits evaluationyields someresultsthat are returnedby the database.We often have sourcesthat produceinformationcontinuallyin astreamof “articles.” Suchinformationstreamsmustbefiltered,by specifyingsomekind ofapatternthatselectsthedesiredarticles.

A major issuein openenvironmentsis resourcediscoverybecause,unlike in closedenvironments,it isnot clearwherea queryor filtering requestmaybedirected[88, 13]. Whereasin retrieval, theconsistencyof the resultsis oftenan issue,in filtering andresourcediscovery, consistency is not well-defined,but therelevanceof the resultsis crucial. Retrieval andfiltering areof aboutthe samecomplexity in closedandopenenvironments,but discovery is significantlymorecomplex in openenvironments.To bescalableandmanageable,it requiressomekind of distributedindexing techniques[28].

2.8 Ubiquitous Computing

Ubiquitouscomputingrefersto thevision—fastbecominga reality—thatcomputingshouldbeaccessibleto usersno matterwherethey are[52, 59, 82]. Onesuchitem arewearablecomputers, continuouslyactivecomputersthat, in the future,areexpectedto inhabitour wallets,briefcases,clothes,andpossiblybodies(e.g., communicationimplants,health-monitoringimplants,small information applianceswith powerfulfunctionality)[64]. Ubiquitouscomputingthustypically requiresmobilecomputersaswell asinfrastructurefor mobile telecommunications,suchascellular telephony. While cellular telephony is not yet availableeverywhereon earth,severalmajorefforts areunderway in populatingour skieswith networksof satellitesto enhanceits availability in thenearfuture.Wirelessnetworkinghasnotyetbeenstandardizedto theextentthatonemayuseasinglephoneor wirelessdata-lineevenacrosstheregionswheresomecellulartelephoneinfrastructureexists,but thatdayis coming.

3 Paradigmsand Ar chitectures

3.1 Distributed Objects

An NC environmentprovidesall thecomputationalfacilitiesnecessaryto solve a targetclassof queries,in-teractionsor problemsefficiently. A naturalunit for interactionis anobject. Theadventof wide-areahigh-performancenetworks hasprompteddevelopmentof distributed object-orientedenvironmentsthat makeuseof geographicallywidely separatedcomputingresources,andallow anequallydistributedcommunity

11

of users.A typical distributedobjectenvironmentis a combinationof distributeduserinterfaces,agents,objectlibraries,knowledgebasesanda varietyof enablingandintegratingtechnologiesthat facilitateuserinteraction(suchasproblemstatementandsolutionengineering)andcooperative executionof thecompo-nentschargedwith thesolutiontasks,e.g.,[38, 81].

This needfor effective andefficient communicationamongtheNCE components(or objects)is recog-nizedby bothresearchersandsoftwaremanufacturers.In recentyears,thishasresultedin aproliferationofcommunicationbuilding blocks,or middleware, for distributedscientificcomputingandproblemsolving.The functionalityandthemodeof operationof middlewareusuallyintroducesextra overhead.This over-headis accentuatedin environmentswherethe NC resources(suchasworkstationsandsupercomputers)areinterconnectedby high-speedlinks (e.g.,switched ����� or ����� Mbps links). Suchanenvironmentcanmagnifyany middlewarecommunicationdeficienciesandmakethemiddlewareamajorperformancebottle-neck.Somespecificexamplesof themiddleware(e.g.,CORBA, DCOM, PVM, MPI), andits performancearediscussedbelow.

A higher-level issueassociatedwith distributed objectsis in the managementof their interfaces. Anumberof approaches,basedlooselyon the notion of directories—whitepagesandyellow pages—exist.A typebroker is anobject,listeningat a well-known address,which carriesinformationaboutthe“types”supportedby otherobjects.Thesetypesarenot just thedatatypesbut includethesignaturesof thedifferentfunctionsor servicessupportedby thoseobjects.An applicationcanusea broker to find the objectsthatoffer servicesof adesiredtypeandthencommunicatewith themdirectly.

3.2 CollaborativeEnvir onments

Studentstaking classesat a distanceneedto interactwith eachotherandwith the instructor, distributedgroupsof scientistsandengineersthatwork on a problemor a reportneedto communicatewith eachotherandshow their work, geographicallydistributedphysiciansmaywish to consultwith eachotherregardinga patient.All thesetaskscanbemadeeasierandmoreproductive throughuseof NC. In general,network-basedcollaborationamong,andwith, usersof NC systemscansignificantlyenhancetheir experiencesandimprove their joint work results.This requiresgroupwarethatfacilitatesfile sharing,collaboration,discus-sion,andsoon.

For example,in theareaof NBE, PLATO andNovaNET[11] werethefirst multimedialearningenvi-ronmentsthatsupportedextensive interactionamongstudentsaswell ascommunicationbetweenthetutorsandthe studentsthrougha facility that lets oneor moreof the collaboratorswatchandinteractwith thescreenof anothercollaborator. Thereis currentlya hostof commercialtools thatprovide similar or moreextensive facilities. Theserangefrom teleconferencing,to white-boardsharingto chat-rooms.Examplesarefull versionsof graphicalWWW browsers,theMBONE toolset[65], numerousVideo-over-IP ventures,Microsoft’s Netmeeting,andsoon. In general,groupwarefor collaborative projectdevelopmentneedstoconsiderbothsynchronousandasynchronousinteractions,groupdocumentcontrolandmaintenance.A re-lated,but moreencompassing,conceptis thatof collaboratory [89, 84, 79]. Collaboratoriesprovide virtualspacesthat enablecollaborationamongpartiesthat arenot presentat the sametime or place. Interactiongroupsform asneededandgroupmemberssharetheir documents,software,data,instrumentsandknowl-edgein avirtual environmentthatis anextensionof theirnaturalwork environment.

12

3.3 Multidatabasesand InteroperableSystems

The conceptualschemaof a databasedescribesthe structureand contentof the informationstoredin adatabaseindependentof its storagein physicalmemory[7].

Traditionaldatabaseskeepall of their dataat onesite. This hasobvious problemsof accesstime andreliability. Accordingly distribution of somekind is desirable. The simplestform of distribution is byreplicationin which the differentsiteshave the sameschema.A variant is onewhich the informationispartitionedsystematicallyto improve localprocessingandreduceredundancy. For example,eachbranchofabankmaystoreonly its local information.However, theschemasarethesameeverywhere.A moregeneralapproachallowsdifferingschemas,but theschemasarestill built from thesamevocabularyandaredesignedto combineproperlywith eachother. Thelocalschemasaremerelyprojectionsof theglobalschema,whichprovidesthesoleway of accessingthedatabase.The locationandreplicationof the informationis hiddenfrom theuser. Theabove kindsof systemsfall underthecategory of distributeddatabases.

More generaland powerful approachesare obtainedwhen the siteshave different schemas,and theschemaswerenot designedat the sametime. Suchapproachesareheterogeneousin their schemas.Het-erogeneityis typically not addedby design,but arisesbecauseof a realizationthattheinformationalreadystoredin the variousdatabasesoughtto be shared.New applicationprogramsarewritten that accessin-formationfrom thedifferentdatabases.However, thepreviously designedprogramsthatneedinformationfrom a singlesitecontinueto functionasbefore.This is calleda federateddatabaseor amultidatabase.

Interoperablesystemsarebasedon the ideasthat the componentsandtheir schemasareentirely au-tonomous. No global schemais required,althoughmiddleware would be requiredto make the alreadyfunctioningcomponentsinteroperate.The datamay be accessedthroughmultiple applicationsand lan-guages.

3.4 TransactionProcessing

We think of transactionsasan abstractionfor programmingcompositeactivities in informationenviron-ments.

3.4.1 Traditional Transactions

A traditionaltransactionis a setof operationson a databasethat satisfiesthe ACID properties.That is, atraditionaltransactionmustatomic (all or noneof theoperationshappen),consistent(concurrentexecutionof thetransactionsdo not violateany integrity propertiesof thedatabase),isolated(concurrentlyexecutingtransactionsdonotshareany data,anddurable(onceatransactioncommits,its resultsarepermanent,unlessupdatedby anothertransaction).ACID transactionshave provedremarkablyeffective in a numberof dataprocessingapplications[46]. Unfortunately, they arenotwell-suitedto heterogeneoussystems,whicharealargeandimportantcomponentof theenvironmentsfor network computing.Therearetwo mainreasons.

� Atomic commitprotocolsareinefficient becauseof distribution andoftenimpossiblebecauseof au-tonomouslegacy applications.Localautonomyis oftensacrosanct,becauseof technicalandpoliticalreasons.Someresources,e.g., legacy databases,aretechnicallyclosedin that they have no visibleprecommitstate. A visible precommitstateis essentialfor executingtwo-phasecommit andothermutualcommitprotocolsinvolving thoseresources.Further, somecomponentsof heterogeneoussys-

13

temsareownedandmanagedby differentorganizationsor divisionsof anenterprise,whichcannotorwouldnotgrantcontrolto anotheragency.

� Thesemanticrequirementsin heterogeneousapplicationsareoftencomplex andneedmoresophisti-catedtaskstructuringthanACID transactions[35].

3.4.2 ExtendedTransactions

For theabove reasons,a numberof extendedtransactionmodels(ETMs) have beenproposed[35], whichgeneralizetheACID modelin differentways.EachETM requirescustomizedscheduling.

Let’sconsidertheDOM modelasanexampleextendedtransactionsmodel[15]. Thismodelconsidersacompositeactivity asamultitransaction, whichconsistsof anumberof componentactivities. Theactivitiesmay be mutually temporallyordered;somemay be optional. Someactivities aredesignatedvital, whichmeansthat their failurecausesthe failureof theentiremultitransaction.Activities canhave dependenciesamongthemto indicatethestepsnecessarywhendifferentcombinationsof theactivities fail or succeed.

3.5 Workflow Management

3.5.1 Modeling

Recallthatworkflows arecompositeactivities thatachieve interoperationof avarietyof systemandhumantasks. Workflows mustsatisfysubtledomain-specificintegrity andorganizationalrequirements.Conse-quently, flexibility in executionis crucial. A promisingmeansto achieve flexibility is throughdeclarativespecificationswith automaticdistributedschedulingtechniques.

For traditional(homogeneousor centralized)environments,databasetransactionsprovide effective androbustsupportfor building applications.Unfortunately, correspondingsupportis not availablein heteroge-neousenvironments.Theapplicationprogrammermustprocedurallyencodeall necessarysemanticrequire-ments. Workflows arewidely regardedasthe appropriateconceptfor structuringcomplex activities, andworkflow managementsystemswouldprovide functionsanalogousto thoseprovidedby present-generationtransactionmonitors.Accordingly, increasingattentionhasfocusedonworkflows [29, 49].

As the prevalenceof heterogeneityis being appreciated,the importanceof workflows is increasing.Althoughscoresof workflow productsexist, relatively few of theseareintegratedwith databases.Eventhebestof thoseintegratedwith databasesoftenhave centralizedimplementations,andoffer little supportforsemanticor recoverability properties.For example,XSoft’s InConcertoperateson a singleserver—it listsdistribution asa futurechallenge[86]. Action Technology’s ActionWorkflow is alsocentralized,andmoregearedtowardcomputer-supportedcollaborative work thandatabasetransactions[117]. IBM’ s Flowmarkoffersstrongsupportfor businessprocesses,but hasacentralizedimplementation.However, associatedwiththeseproductsareuseful techniquesfor processmodelingandcapture.TheseincludeActionWorkflow’s“language/action”modelof humaninteraction,andFlowmark’s activity-network modelof processes[60].

3.5.2 Programming and Enactment

Workflows arenot only modeledbut mustalsobeenacted.Thereis muchanecdotalevidencethat thebestway to programworkflows (or any kind of softwaremodels)is to make themodelsthemselvesexecutable.Indeed,this is whatis donein all theworkflow systemsandprototypes.

14

Procedural Approaches Thetraditionalapproachesto programmingandenactingworkflows areproce-dural. Theworkflows arespecifiedessentiallyasactivity graphs.Executablecodeis generatedfrom thesegraphsin a straightforward manner. Hooksareaddedin for whatever externalproceduresor applicationsmustbeinvoked. Theimplementerhasto do a fair amountof systemintegrationwork in ensuringthat thedatabasesareaccessedproperlyandthegraphicaluserinterfacesreflecttheongoingstateof theworkflow.

Declarative Approaches A newer classof approachesis declarative. It is motivatedby the fact thatactivity graphsby themselves give no ideaof the structuralpropertiesof the workflow, but higher-levelabstractionsto capturetheinterrelationshipsamongthecompositeactivities mustbecaptured.

Thesimplerabstractionsinvolvingcontrolanddataflow canbeborrowedfromtheETM literature.How-ever, thesheervarietyof ETMs precludeshardwiredapproachesfor schedulingeachETM. Thedeclarativeapproachesprovideasmallnumberof primitivesthatcanbeusedto specifyETMs[41, 24,2].

The successof the declarative approachesdependson whetherthey includea languagethat is simpleyet expressive, and whetherspecificationsstatedin that languagecan be automaticallyprocessed.Thepioneeringwork of Chrysanthis& Ramamrithamdevelopeda simpletemporallanguagethatcouldcapturetheschedulingaspectsof all of theknown ETMs. However, they didn’t studytheschedulingaspectsperse.Work by Attie etal. [2] andSingh[91] hasaddressedthelatterchallengeaswell.

3.6 Agentsand Multiagent Systems

Thetermagent is overloadedin theliterature.For ourpurposes,agentsmaybedefinedaspersistentcompu-tationswith someautonomy, andwhichperceive,reason,act,andcommunicate.Agentscancaptureor servetheinterestsof humanusers,informationsources,or serviceproviders.Theseagentsmaybeindependentlycreatedby differentparties,or mayevenbepreexisting. For this reason,agentscanbenaturallyappliedinNC.

The simplestapplicationsof agentsarein simplistic userinterfaces,asprogramsthat filter electronicmail, or thosethat perform network searches.Suchapplicationsof agentsdo not rely on many of thepropertiesthatmake agentsscientificallyinteresting,andoftencouldbemoresuccinctlydescribedin termsof ordinaryprograms.

Theagentmetaphoris themostvaluablewhencoupledwith themetaphorof interactionamongcompu-tations.Their combinationyieldsmultiagentsystems. Multiagentsystemspromiseanatural,compositionalway of building complex NC systems[51]. The interactionsspecifyhow the computationsof the agentscometogetherto obtainthedesiredbehavior. In contrastwith asingle-agentsystem,in amultiagentsystem,theagentsmaycooperateto searchdifferentcomponentsof theinformationspaceandsharetheir findings.Conversely, theagentsmaycompeteor negotiateasin electroniccommerceor evento decidehow to splittheinformationspacethatthey aresupposedto search.

Multiagentsystemsalsopromisethedevelopmentof compositionalsystemsfrom autonomous,hetero-geneous,but interoperatingparts.This is becausetheagentscanbelocusof autonomy;they cansatisfytheminimumstandardsfor interactionwhile hiding theimplementationdetailsof thesystemsthey representinamultiagentsystem.Theneedfor interoperabilityis driving a lot of researchinto languagesandtechniquesfor

agentmanagement,by whichagentscanregisterthemselveswith somesortof adomainnameserver,advertisetheircapabilities,befound,andhave requestsmadeof them.

15

! agentcommunication,by whichagentsmaysendmeaningfulmessagesto otheragentsto inform themof variousfacts,to requestservices,or to promiseservicesof theirown.

! ontologies,by which the agentscansharethe terminologyin which their assertions,requests,andpromisesareexpressed.

! interactionprotocols,by which agentsmayparticipatein certainroutinizedinteractionssuchasin aspecificauctionprotocol.

A defactostandardfor multiagentsystemarchitectureis emerging. Thisarchitectureincludesrolesforagentsto representhumanusers,informationresources,brokers,andontologies.Wereturnto thisbelow.

3.7 EnhancedWorkflow Management

Section3.5 describesworkflow technologyasit exists today. Although muchprogressis beingmadeonworkflow technology, someimportantissuesremainunaddressed.Theseinclude(1) semanticor recover-ability propertiesdemandedby seriousapplications;(2) distributedimplementations;(3) easeof specifyingandmodifying workflows; and(4) formal modelsof workflow computationsto give a solid foundationforthereasoningnecessaryto design,analyze,andreliablyenactworkflows. Thisisnottoblametheproducts—theabovepropertiesthatarenothandledby theproductsremainaresearchchallengetoday[54]. Indeed,it istheirsuccessin importantapplications,e.g.,[67], thatfuelsa continuedinterestin researchinto workflows.

To remove theselimitationsrequiresextensionsalongat leasttwo dimensions.We envision workflowsas incorporatingboth semanticand organizationalrequirements.The former category includesabstrac-tions from extendedtransactionmodelsthat relateto correctness,concurrency control, failure handling,andrecovery. Thelattercategory includesabstractionsfrom businessmodelingthatrelateto organizationalstructure,rolesof participants,andcoordinationamongthemand the informationsystem. Thesetopicsarebeingactively researched,e.g.,[18, 78]. However, it is significantthat theseefforts would be greatlyfacilitatedby aninfrastructurethat includesa genericandrigorousapproachto workflow specificationandscheduling.For its intendeduse,the specificationandschedulingfunctionalityshouldapply to activitieswhosecomponenttasksarenot restrictedin any way, our primaryinterestis in workflows with a databasesand informationsystemsfocus. Someof the constituenttasksmay be databasetransactions;somemayinvolve humaninteraction;somemaybeotherkindsof computations.

Enhancedworkflow managementis a naturalapplicationof agenttechniques.Agentscanprovide theflexibility andhigh-level interactionsthatit requires.Furtheragentscanhelpusthink notof isolatedwork-flows,but workflows that interactwith otherworkflows, horizontallyandvertically. We discussthesecon-ceptsafterin thecontext of theeducationexampleintroducedin Section2.6.

Horizontal Integration of the Flows Educationworkflows areexpectedto coexist, cooperateandmeldwith otheruserworkflows. Therefore,they mustsupportcompatibleinterfacesandconstraints.Wecall thishorizontalintegrationof theworkflows at the level of end-users.For example,many studentsfrom indus-try thatwork duringthedaymaypreferto incorporatethemajority of their continuingeducationinto theirdaily or weeklyroutineat timesthatsuit them,e.g.,eveningsor weekends,becausethey cannotmatchtheirwork-placeprocesseswith the traditionalschoolor college teachingworkflows. However, this particularchallengeto traditionaleducationworkflows cannotbemetwithout extensive technologicalandpedagog-ical supportwhich allows (1) decompositionof the synchronousteaching/learningcycle into a primarily

16

asynchronouscomponent(with minor synchronousinteractions),and(2) at the sametime preserves andmaximizesthequalityof learningandtheknowledgetransferratethatis normallyassociatedwith theclas-sicalsynchronousteacher-studentinteraction.Otherfunctionalitiesareneededin thecaseof othertypesofhorizontalintegration.This frequentlyrequiresstrongsupportfor collaborative activities.

Vertical Integration of the Flows Interactionsandnegotiationsalsohave to take placebetweentheend-userlayerof anNBE environmentandtheunderlyinginfrastructure(platforms,software,computerhard-ware,interconnectingnetworks) in orderto provide the throughput,keystroke delays,jitter, andotherser-vices,thatanNBE applicationor userexpects.Wecall thisvertical integrationof educationworkflowswithevent, control anddataflows that occurat infrastructurelayers. The network- andplatform-relatedflowsandQoScapabilitiesof the informationinfrastructure(e.g.,power of theuserplatform,network capacity,supercomputingfacilities) have to be appropriatelymatchedand interfacedwith the needsof the user’seducationalandtrainingworkflows.

Applying workflow technologyto a specificuniversitycourserequiresinformationaboutthesyllabus,participants(both faculty andstudents),schedules,andinstructionalfacilities andtechnology, anddevel-opmentof the correspondingoperational profile. An operationalprofile is the setof relative frequenciesthat tell us how often a particularfunction or capability is requestedin practice[68]. Specifically, givena syllabus, schedule,andthestudentprofiles,onewould first categorizethestudentsby qualificationsandlearningstyles,thenproducea mappingbetweenthesyllabus topicsandthestudentlearningmodels.Thiswould allow mappingof theneededcontentteachingapproachesto contenttopics. This mappingmayin-cludetheplacementof feedbackpoints,anestimateof theprocessfeedbackrates,locationof testingpointsandreinforcementof learnedmaterial. The final stepwould be to maptheseneedsto NBE systemfunc-tionalities,basedon instructor/authorqualificationsandpreferences,availableresources,etc.,to obtainanoperationalprofile that needsto be supportedduring the course. The mappingsandthe operationalpro-file allow us to recognizeteachingalternatives and introduceadaptive or fault-tolerantteachinginto theeducationalmodel.

4 Technologies

4.1 Distributed Computing

Typically, anNC environmentconsistsof anumberof cooperatingsubsystems.Eachof thesubsystemscanbe a “mini-NC” consistingof modulesthat work togetherto solve a problem. This is moreevident in anenvironmentwherethe workloadis distributedamonga numberof machines.In fact, thereis a growingtrendto view NC modulesas(specialized)dynamicsoftwarepartsor objects.For example,somecanberepositoriesfor high-level scalablecomputationalmodelswhich canbeusedby othernetwork-basedPSEsubsystemswhenever necessary, otherscanbedatacenters,yetothercanbeactual(or virtual) computationengines,etc. In general,an NC subsystemmight be expectedto export its functionsto othersubsystemsor allow direct useraccessto them througha graphicaluser interface (GUI). To accomplishthis in aneffective andefficient fashion,it is usuallya good idea to usesoftware “glue” (middleware) that hasanestablishedand tried performanceand functionality. Effective NC presupposesomecombinationof thefollowing functionalities.

17

Unicastsand multicasts An NC subsystemthat requiresthe servicesor functionsof otherutility pro-cessescanobtainthemby sendingpeer-to-peermessagesrequestingtheservice.For collaborative systems,multicast(or one-to-many) messagesareuseful for collectingstatusinformation,notifying aboutevents,broadcastingcommoninformation,andsoon.

Synchronousand asynchronousmessages Thecommunicationmechanismshouldsupportsynchronousmessagesthat allow client processesto issuerequeststo NC componentsand to wait until they receiverepliesfrom them,andasynchronousmessagesthatallow clientsto issuemessagesandnot wait for repliesfor them.An asynchronousmechanismis importantfor systemsthatusemessagesto triggerfunctionsandto notify events.

Efficient data transfer SomeNC subsystems,suchasvisualizationor data-miningtools, may requiretransfersof largevolumesof databetweenmachines.It is importantthatthecommunicationinfrastructurebeableto do thisefficiently andwithoutnegative impactonNC systemperformance.

Interfacing with external processes NC componentsmayneedto communicatewith otherprocessesandsystemsthatarenot partof theNC infrastructurebut whoseservicesor supportareneededto solve a prob-lem. In general,theseoutsideprocessesmaycommunicateusingaprotocol,messagingandcommunicationsystemthat is not partof theNC environment. For example,a PSEsubsystemmayneedto keeptrackofotherprocesseson a machineto calculatesystemload. Its communicationinfrastructureshouldallow andsupporttheseexternalcommunicationchannels.

Remoteaccessto services Theutility of anNC maybegreatlyenhancedby allowing thefunctionsof theindividual subsystemsto beinvokedfrom otherprocessesor subsystems.For example,suchremoteaccessto NC functionsandmethodsallowsanNC to beusedasacomponentin a largersystemor asanagentin acollaborationfor anotherproblem.

Quality of Service (QoS) Theutility of anNC dependsconsiderablyon thequality of servicethat it canprovideto its users.NC middlewareshouldbeQoSsensitive,andit shouldhavefunctionalitieswhichallow:(1) communicationof applicationlevel QoSneedsto lowerlevels;(2) communicationof infrastructuralQoSconstraintsto theapplication;and(3) ability to negotiate(on behalfof a user)a setof QoSparametersthatmaximizeanapplication-level objective function. For example,for education,antheidealQoSparameterswould maximizeknowledgetransferandretention.For environmentaldecisionsupport,thegeneralobjec-tive wouldbeto minimizetime to make correctdecisions.More specificobjective functionsareneededfordifferentsystemusemodes.

4.2 SystemIntegration

When(heterogeneous)moduleshave to interoperatein asinglesystem,it is advisableto nothave to modifythemodulesthemselves. Similarly, reuseof standardfunctionalitiesfrom librariesof functionsor objectsshouldbe preferredto reimplementation.In general,middleware is the answerto the challengeof reuseand easieruserof lower-level functions. It is basedon the idea that a small amountof “glue” may beinsertedbetweenmismatching,or morebasicor moredifficult to use,componentsin orderto enabletheir

18

interoperation.We restrictourselvesto information-level middleware,althoughmiddlewarecanin generalariseevenat thelower levelsof thesystemarchitecture.

Someexamplesof middlewarearenumericalfunctionsavailablethroughnumericallibraries,graphicalfunctionsavailablethroughgraphicallibrariesandreusableobjectlibraries. Otherexamplesarewrappersor mediators[113]. Wrappersperformsimplelanguageor protocoltranslations.For example,a languagewrappermaymaptheoperatorsin a text keyword searchqueryinto operatorsthatwould berecognizedbytheunderlyingsystem.Anotherlanguagewrappermaymapa structureddatabasequeryinto a lookuponspecificfieldsin anHTML form. A protocolwrappermaymaparemoteprocedurecall into anasynchronousqueryfor which theresponsewill bematchedto thequeryandreturnedto thecalling program.Mediatorsarelike wrappers,only moresophisticated.They canencodelarger varietiesof metadata,e.g.,aboutthereliability of theinformationin thedatabaseor abouthow thevaluesin thedatabasemapto valuesin anotherdatabase.Mediatorsuseencodedknowledgeaboutdatato createinformationfor higher-level applications,providing alogicalview of theunderlyinginformation.Mediatorscan,in principle,learnfrom thedata.Thepopulargenericagent-basedarchitecture,shown in Figure2, incorporatesmediators.

A prominentexampleof NC communicationmiddlewareis ParallelVirtual Machine(PVM). A virtualmachineis anabstractenvironmentwhich is (ideally) platform-independent,andprotectstheprogrammerfrom theidiosyncrasiesof thedistributedcomputingsystemsonwhichtheapplicationwill operate.Anotherexampleis Inferno,a productdevelopedby AT&T. Of course,a popularvirtual machineis offeredby Java[61]. Thegeneraldiscussionsthat follow (includingthaton performanceof middleware)apply to a broadrangeof middlewaresoftware,includingJava.

4.3 Middleware

Of specialinterestto NC aretwo typesof middlewarethatfacilitateexchangeof messagesandinformationobjects,respectively. It is importantthat this middlewarenot imposeanoverheadthatwould translateintofailuresto deliver theQoSexpectedby theusers.

4.3.1 MessagePassing

An importantpartof amodernNC framework is its ability to facilitateeffectiveandefficientcommunicationamongtheNC components(or objects).This is recognizedby bothresearchersandsoftwaremanufactur-ers,and,in recentyears,it hasresultedin a proliferationof communicationbuilding blocksfor distributedcomputing.Thebestknown examplesarePVM andMessagePassingInterface(MPI) [100, 39]. They arespecializedmessagepassinglibrariesfor scientificandothercomputingthat in combinationwith messageandprocessbrokersallow relatively easydistribution of aparallelizedproblemoveranumberof processingunits in orderto increasethesystem’s computationalperformance.Computationplatformsincludeevery-thing from laptopsrunningWindows 95/NTto multiprocessorsupercomputersrunningUnix. Althoughnotoriginally intendedfor this purpose,bothPVM andMPI canbeusedto distributenot only fine-granularitysolutionelements(suchascodesegments)but wholeprogramsandPSEparts.

PVM wasoriginally developedby OakRidgeNationalLaboratoryandUniversityof Tennessee[77, 39].PVM enablesa collectionof heterogeneouscomputersystemsto beviewedasa singleparallelvirtual ma-chine. It transparentlyhandlesall messagerouting,dataconversion,andtaskschedulingacrossa networkof computerswith diversehardwareandoperatingsystems.An applicationis castasa collectionof coop-eratingtasks,which accessPVM resourcesthrougha library of standardinterfaceroutines.Theseroutines

19

OntologyAgent

ApplicationProgram

MediatorAgent

BrokerAgent

Database Resource Agent Database Resource Agent

Query orUpdateIn SQL

Reply

Reg/Unreg(KQML)

Reg/Unreg(KQML)

MediatedQuery (SQL)

Reply

Schemas(CLIPS)

Reply

MediatedQuery (SQL)

OntologyForms

User InterfaceAgent

ReplyReg/Unreg(KQML)

Reg/Unreg(KQML)

Figure2: Perspectivesona Network ComputingArchitecture

20

allow theinitiation andterminationof tasksacrossthenetwork, aswell ascommunicationandsynchroniza-tion amongthem. PVM tasksmay possessarbitrarycontrolanddependency structures.XPVM providesa graphicalinterfaceto the PVM consolecommandsandinformation,alongwith several animatedviewsto monitor the executionof PVM programs.HARNESSis the next generationof this technology. It ex-ploresdynamicvirtual machinecapabilities,suchasvirtual machinescollaboration,merging, or splitting,andplug-in interfacesfor dynamicextensionsto a parallelvirtual machine,aswell asmethodologiesforintelligent parallelapplications,i.e., thosethat discover eachother, dynamicallyattach,collaborate,andcleanlydetach.

MPI is theoutcomeof a communityeffort to definethesyntaxandsemanticsof coremessage-passinglibrary routinesthatarewidely usefulandefficiently implementableonarangeof parallelprocessors[100].MPI is not a completeandself-containedsoftwareinfrastructure.It doesnot includeprocessmanagement,(virtual) machineconfiguration,supportfor input andoutput,andsimilar. MPI is limited to themessage-passing(parallel)programming(MPP)model,which is a distributedmemorymodelwith explicit controlparallelism. The messagepassingmodel is regardedas a viable meansof programmingboth on multi-computersandon heterogeneousnetworks of workstations.This is considereda definiteadvantagewhendevelopingapplicationsthatmaybeportedafterwardsontoamassively parallelmulticomputer. ProcessesinMPPcanonly readandwrite into their respective localmemory. They synchronizewith oneanotherby ex-plicitly calling library procedures.Datais movedbetweenlocal memoriessendingandreceiving messagesvia explicit procedureor subroutinecalls.

Otherexamplesof similarsoftwareareP4,Express,andLinda. P4is alibrary of macrosandsubroutinesdevelopedby ArgonneNationalLaboratoryfor programmingavarietyof parallelmachines,andsupportofboth theshared-memorymodelandthedistributed-memorymodel. Expressis a commercialcollectionofconcurrentcomputationtools.Theideais to startwith a sequentialprogramandfollowing a recommendeddevelopmentlifecycle transformit into aparallelprogramusingtheprovidedtoolset.An alternative to bothsharedmemoryandmessagepassingparallelprogrammingis provided by Linda. Linda is a concurrentmodelthatusesa “tuple-space”abstractionfor communicationamongcooperatingprocesses[19, 20]. It isanabstractionof distributedsharedmemorywith someimportantdifferences,includingassociation,andisavailableasacommercialproduct.

4.3.2 Object Exchange

Anotherflavor of informationexchangemiddlewareis avarietyof, usuallyCORBA-compliant,commercialobjectbrokersthatcanbeusedto constructNC applications.TheCommonObjectRequestBroker Archi-tecture(CORBA) wasproposedby theObjectManagementGroup(OMG) asa standardspecificationfordistributedobjectcomputing[90]. CORBA makespossiblethereuseof softwarethroughdistributedobjectcomputing. The primary componentof CORBA is the ORB corewhich provides transparenttransferofrequestsandrepliesbetweenclientsandobjectservers. CORBA definestwo typesof methodinvocationsthataclientcanuseto invoke anobject’s methods.TheStaticInvocationInterface(SII) is similar to a localmethodcall wherea client caninvoke a methodon anobjectwithout knowledgeof theobject’s locationorimplementation.TheDynamicInvocationInterface(DII) is amoreflexible approachthanSII. Here,aclientdoesnot requirecompiletime knowledgeof themethodssupportedby anobject. It canretrieve informa-tion abouttheobjectmethoddefinitionsfrom a repository, anddynamicallyconstructa methodinvocationrequest.CORBA toolkits developedby differentmanufacturersenablecreationof frameworks composedof cooperatingdistributedobjects.A client caninvoke methodson objectsresidingin any process,on any

21

machine.Thedistribution mechanismis kepthidden.Objectsresidingin a differentprocessaremanagedby a server process,which receivesmethodinvocationsdirectedto theobjectsthat it managesandreturnstheresultsbackto theclient. CORBA implementationsusea daemonprocessto manageserver processesonaparticularmachine.

4.4 Itinerant and Stationary Agents

Therearetwo mainwaysto implementagents:asstationaryor itinerant (alsotermedmobile). Stationaryagentsaregenerallyimplementedusingsomekind of a rule-basedsystem.They includefunctionality toaccesslocal informationresources,e.g.,throughmediators.Most importantly, they communicatewith otheragents,e.g.,to inform, request,or make promises.

Itinerantagents,by contrast,aredesignedto changetheir locationwhile executing. Thereis a lot ofinterestin suchagents,andthey seemto capturethe popularimagination.However, asa consequenceoftheir mobility, suchagentstendto besmallerthanstationaryagents.Thesiteson which they executemustbetrustingor moresecuresothat incomingagentscannotdamagethem. Conversely, they mustguaranteethattheintegrity of anincomingagentwill notbeviolated.

We emphasizethat the key differencebetweenitinerant and stationaryagentsis not conceptualbutimplementational.Onecanachieve thesamefunctionalitywith eitherapproach.Itinerantagentsdemandstrongersecurityfrom a system,but canpotentiallyleadto superiorperformancein settingswherethedatais large andthe customizedprogrammingis small. However, a convincing empiricalcaseremainsto bemade.

4.4.1 Management

Agentmanagementrefersto thesetof functionalitiesthroughwhichagentsystemscanbemanaged.Theseincludeawayfor theagentsto registerandunregisterthemselves,advertisetheirservices,find otheragents,andtransparentlychangetheir locationif necessary. Althoughagentsystemshave long includedsuchfunc-tionality, thereis a recentpushto standardizeit that is beingsupportedby the Foundationfor IntelligentPhysicalAgents(FIPA) [37].

4.4.2 Communication Languages

If separatelydevelopedagentsareto interactintelligently—whetherto cooperateor compete—they mustbeableto communicatewith oneanother. Successfulcommunicationpresupposesa sharedlanguage.Someaspectsof the languagearein the application-specifictermsused—thisrelatesto dataheterogeneity, andoneof thebestwaysof addressingit is throughtheuseof ontologies[73, 50].

The othermajor aspectof communicationis in theactionsthat theagentsperformthroughcommuni-cations.This follows thekey intuition of Austin thatcommunicationis a kind of action[3]. Theseactionsaretermedperformativesandareclassifiedinto a few major categories: assertives(informing), directives(requestingor querying),commissives (promising),prohibitives, and declaratives (causingevents,as inelectinga leaderprocess).

A sharedlanguagemusthaveasharedsyntaxandsemantics.Recently, astandardhasemergedunderthesponsorshipof theFIPA [37], which seeksto includethepreviousDARPA sponsoredwork on theKnowl-edgeQueryandManipulationLanguage[58]. This work reflectsgreatprogress,althoughan objectivelyverifiableor falsifiablesemanticsremainsto bediscovered[96].

22

5 Infrastructur e

5.1 Computersand Operating Systems

The lower layer of infrastructurethat supportsNC includesthe actualnetworks: the wires, light-pipes,wirelessequipment,routers,switches,networking cards,firmwareandsoftwarethat operatestheseunits.It alsoincludesthe physicalcomputersandothernetwork-relateddevicesandappliances(e.g., input andoutputdevices), that areneededfor full operationof an NC application. The computerscanrangefromlaptopsto supercomputers.Operatingsystemscanbe equallyvaried. Two specialgroupsof computingdevicesarenetwork-orientedanddeserve acloserlook.

5.1.1 Network Computers

Network computersareenvisagedasdisklessworkstationsthatdownloadall of their executablecodefromthenetwork. Thepotentialadvantageof suchmachinesis thattheiradministrationmightbesimpler. Manag-ing a largenumberof networkedcomputers,suchasin a largecorporationor university, is amajorproblem,oneof whoseaspectsis upgradingthesoftwareonthevariouscomputers.Thusapotentialsolutionis highlyattractive. Network computerscanbeusefulin restrictedsettingswheretheusermayhave nosayaboutthesoftwarerunningon their machines.For example,all banktellerswould berequiredto usethesamever-sionof theaccountmaintenancesoftware,andpeoplewith dumbterminalsmaybewilling to usewhateverversionsof softwareareinstalledon theservers.

However, thevalueof network computersto assistin thistaskis lessclearif theusershaveany sayaboutwhat softwarethey run, andin what versions. In sucha case,the problemof maintainingthe computingenvironmentwill bemultipliedbackto its presentsize.Having differentsoftwareononesitefrom whereitcanbedownloadedis not anadvantageany more,preciselybecauseof thedevelopmentof otheraspectsofnetwork computing—ifyou canmanageremotecomputers,not muchis lost by letting thesoftwareremainthereaswell.

5.1.2 Mobile Computers

Althoughall computerscanin principlebecarriedalong,mobilecomputersarethosethatareconvenientlyportableby users.Therearethreemainkindsof mobilecomputers:

" Laptopsare the largestand most powerful variety. They can handlealmostall of the tasksof adesktopcomputer. However, whenmobile,they wouldtypically beconstrainedby alowerbandwidth.Althoughlaptopsareideal for certaincomputation-intensive tasks,suchasdocumentpreparationorinterfacingto complex scientificcomputations,they arenot idealfor lighter taskssuchasmessagingor informationaccess.

" PDAs or personaldigital assistantsarethesmallestandlightestvariety, whichcanbeusedfor simpletaskssuchaskeepingone’s schedule,accessingemail,or accessinginformation,suchasmaps,overthe WWW [59]. With increasedcommunicationsfunctionality, thesearebecomingwhat arenowcalledCommunicators.

" Wearablecomputersrefer to a rangeof hardware[64]. Sometimesthey arefairly large computers,comparableto laptopsthatarecarriedaroundin a back-pack.More appropriately, however, they are

23

computersthatcanbecarriedattachedto one’s clothing—onabeltor arm-band.Wearablecomputersrely extensively on specializedinterfacesthehave for hands-freeoperation.Thusthey cantake inputby speechof gesture,andoutputby audioor ondisplaysthatarealsowearable,e.g.,by projectingontheuser’s specialeyeglasses.

Whatmakesmobilecomputersinterestingaretheapplicationsthey enableandthespecialrequirementstheyhave for networking, leadingto specialQoSchallenges.

5.2 Networking Support

In general,a computernetwork is a systemthat connectsend-userworkstationsanddevicesseparatedinspace.A classificationinto local areanetworks (LANs), metropolitanareanetworks (MANs), andWideAreaNetworks (WANs) is conventional. LANs connectcomputersystemsthatareclosetogether, usuallynotmorethanfew kilometersapart.WANs spancountriesandcontinents.MANs areusuallynotseparatelystudiedandareincludedin oneof theothertwo categories.

A numberof underlyingtechnologiesexist. LANs areoftenconnectedvia Ethernet( #�$ Mbps),TokenRing ( % – #�& Mbps), ATM ( '�( , #�$�$ , #�(�( Mbps), FastandGigabit Ethernet( #�$�$ Mbps, # Gbps),or FDDI( #�$�$ Mbps). Thetechnologiesfor WANs tendto beevenmorevaried.They rangefrom T1 ( #*)+(,%�% Mbps),T3 ( %-( Mbps) to ATM over SONET( #�(�( Mbps–#�$ Gbps). Thehardwarethat actuallydirectsandmovesthepacketsandcellsandframesrangesfrom switches,to routersto bridges.

5.2.1 Network Protocols

Wecanview theinfrastructurethatsupportsNC asahierarchyof threelayers:hardwareanddatatransmis-sioninfrastructure(or data-linklayer),networkingandtransport(or OSILayer-3 protocolsandOSILayer-4protocols),andapplications.This is illustratedin Figure3. The first layer varieswidely andcanincludemediaaccessmethodssuchasEthernet,FDDI, ATM, andtokenring.

The middle layer includesthe so calledTCP/IPsuite. The InternetProtocol(IP) standardandits as-sociatedprotocols(e.g, ICMP, ARP, RARP) aredesignedfor delivering informationthroughsystemsofpacket-switchedcomputercommunicationnetworks[76]. Thebasicblocksof dataexchangedbetweenend-to-endIP layersarecalledIP datagrams.Datasourcesanddestinationsarenetwork hostsidentifiedby fixedlengthaddresses.The IP alsoprovidesfor fragmentationandreassemblyof long datagrams,if necessary,for transmissionthroughsmallpacket networks. IP providesa connection-lessandunreliableservice.Anyassociationamongdatagrams,flow-control,andany errorcheckingandreliability functions(beyondabasicself-checkof its headers)needsto beprovidedby higherlayers.Thecurrentversionof IP, IPv4 is reachingthe endof its usefullife, primarily becauseof the limitationsof its 32-bit addressspace.Soon,it will bereplacedby anew protocol,IPv6 [14, 30].

Two examplesof middle-layerprotocolsareTCPandUDP. TCPresidesaboveIP layer. It is connection-oriented,and it assuresreliable, full-duplex byte streamcommunicationbetweenuserprocesses.MostInternetapplicationsuseTCP. UserDatagramProtocol(UDP)is connection-lessandunreliable,but haslowoverhead.For this reason,UDPis employedby anumberof multimediaapplicationsthatprovide theirownreliability andpacingrules.

A recent,but prominent,memberof thetop layeris HTTP. It usesTCP, andit is thefoundationprotocolfor WWW. HTTP is a transaction-oriented client/server protocolandis mostoftenusedbetweena WWWserver anda WWW browser. An exampleof a moreancient,but still active, memberof the top layer is

24

FTPfor transmissionof files betweensystems.Thereis a numberof otherapplicationsat thesamelevel,includingTelnet,andasimplee-mailtransferprotocol(SMTP).

Higherlevel network-basedtoolsneededfor collaborative componentsof theNC includewhite-boards,chat-rooms,telepresencesolutions,etc. All thesearecombinedwith actualend-userapplicationssoftwareto form NC end-to-endsolutions.

5.2.2 Internet and Intranets

TheInternetis a WAN. It is basedon theIP protocoldiscussedabove. An intranetmaybelooselydefinedasa network that is functionally just like the Internet,but restrictedto the computationalenvironmentofanenterprise.Intranetsthuspromisehighersecuritythanthe Internetby blockingof accessfrom outside.However, they supportWWW-like hypertext. Becauseof theiradditionalsecurity, Intranetsareusedwithinenterprisesto manageinternalprocesses.For example,they areusedto definesetsof forms,link them,andexecutethemappropriatelywith respectto theenterprise’s businessmodels.Whentheongoingprocessesintheenterprisearemadeexplicit, theresultingsystemis sometimestermedaprocess-drivenintranet[87].

Intranets,for mostpart,tendto beLANs. However, intranetsof somebiggercompaniesspancounties,statesandevencontinents,andusetechnologythatis moreappropriatefor WANs.

5.2.3 Network Performance

Oneof the commonailmentsof the WAN that todaycomprisethe Internetis that the resourcesareover-subscribedandthatduringpeakloadtimesthis translatesinto loweredqualityof servicethatend-userssee.Figureillustratestheproblem.Theverticalaxisshowsthedelayin receiving thesameWWW pagebetweenEastandWestCoastof theUSduringdifferenttimesof theday. Thehorizontalaxisis in 30minuteintervalsstartingatmidnightonFriday(Saturday0 hours).Weseethatduringweekdaysdelayscanbeunacceptablylong duringpeakhoursof 8 AM to 8 PM. it is obvious that if onewishesto usethe Internetfor adequatesupportof advancedNC applications,suchasdistanceeducationor collaborative interactive work (where250msmaybeexcessive for akeystroke return),weneedaninfrastructurethatwill actively supportqualityof servicefor differentcategoriesof applicationsandusers.Internet2, thenext generationInternetinfras-tructureis expectedto provideadequatemanagementof theresourcesthatwould,for applicationsthatneedit, essentiallyflattenthe Figure4 curvesto an acceptable(andnearlyconstant)responsetime. This willrequirecooperationof not only the networking layersbut alsoof the applicationslayersandapplicationsthemselves. Internet2 is expectto startoperatingin thenearfutureover OC48( .�/�0 Gbps)andOC192( 1�2Gbps)backbonemeshes,andits edgeandcoredeviceswill entertainprotocolsandmechanismsthat willassureadequateuser-level qualityof service.

5.3 Network Functionalities

EffectiveNC reliesonanumberof otherfunctionalitiesbeingavailableessentiallyasstandardizedservices.Thisis soapplicationdevelopersdonothaveto implementthem,andsothey producerepeatableandreliablecomputations.

Onesetof functionalitiesis termedsecurity[22, 80]. It includessupportfor authenticatingthesendersandreceiversof messagesandensuringaccesscontrolto preventunauthorizedusersfromreadingor modify-ing data[70]. Otherservicesincludethosefor digital cash, andfor guaranteeingthatausercannotrepudiatetheironlinecommitments.

25

5.4 Standards

Therearea numberof relevantstandards.Someof thesearecoveredin theabove; for theothers,we deferthediscussionto thecitedmaterials.

6 Research Issues

We have taken a workflow-centeredstancetoward NC. This stanceleadsnaturally to two major classesof researchissues,correspondingto the designandanalysisof workflows, respectively. We discusssomespecificchallengesandemerging approachesbelow. Includedis alsothe issueof how analysistechniquesmight feedinto thedesign.

6.1 Formal Methods

Becauseof theimportanceandcomplexity of NC applications,it is clearthattechniquesarerequiredto con-structthemin a robustmanner. Formalmethodsasstudiedin softwareengineeringandlogicsof programsare,therefore,of greatpotentialvalue.Formalmethodscanapplyin variousways,suchas

3 capturingrequirementsprecisely

3 verifying individualapplicationprograms—thisis nodifferentthanverificationin general

3 verifying protocolsfor theinteractionof differentcomponentsof anNC application

3 constructingsmall,but critical subsystemsin a robustmanner.

Techniquesbasedon variantsof temporallogic appearespeciallyattractive for theabove purposes[25, 36,48].

Althoughformal methodsandtoolshave muchpotential,their presentincarnationscanusuallyhandleonly fairly small systems.NC applicationscould have the advantagein this regard,becausethroughthecarefulapplicationof autonomythedetailsof the interactingmodulesmaybehiddenbehindwell-definedandcompactsysteminterfaces.However, NC applicationsalsorequirea wider rangeof abstractionswithwhich to program.Thesetoohave anobviousconnectionwith formalmethods,andarediscussedbelow.

6.2 Interaction-Oriented Programming

Computingis in themidstof aparadigmshift. After decadesof progresson representationsandalgorithmsgearedtoward individual computations,theemphasisis shifting to what lies amongthecomputations,andbetweenthecomputationsandtheirenvironment.Thisemergingparadigmis thatof interaction. Interactiongoesbeyond traditionalparallelor distributedcomputing,becauseit modelsthecomponentcomputationsasautonomousandableto interfacewith anenvironment[111, 110].

Interactionis preciselythemetaphorwith which to view computationin settingswherenetwork com-puting reigns.Megaprogrammingrefersto programminglarge systemat thecomponentlevel [114]. Thisidea is essentiallya form of softwareengineeringin which large modulesarecomposedto form a largeheterogeneoussystem.This is aninspiringvision,andis addressedby thefollowing discussion.

26

Wesuggestedabove thatmultiagentsystemsaddressmany of thesechallengesquitenaturally. But howmayweconstructmultiagentsystemsefficiently, sothatthegeneratetheflexible andfelicitously interactingworkflows that we desire? If the agentsare constructedmodularly, the main challengeis in specifyingandgeneratingtheright interactions.We termour approachinteraction-oriented programming(IOP), andincludein it abstractionsandtechniquesthatcapturethestructureof thedesiredinteractionsandpreservetheagents’autonomy. Wetentatively identify threelayersof IOP, from lower to upper:

4 coordination, whichenablestheagentsto operatein asharedenvironment

4 commitment, which reflectsthe agents’obligationsto oneanother, capturingthe socialstructureofmultiagentsystemsandthenormsgoverningtheirbehavior

4 collaboration, whichdealswith knowledge-level constraintsoncommunications.

Someinformal concepts,suchascompetition,maybeclassifiedinto differentlayers:biddingin anauctionrequiresno more thancoordination,whereascommerceinvolves commitments,andnegotiation involvessophisticatedprotocols.

Conceptsrelatedto the above have beenstudiedin areasas diverseas distributed computing(DC),databases(DB), anddistributed artificial intelligence(DAI). The DB andDC work focuseson narrowerproblemsof synchronization,and eschews high-level conceptssuchas social commitments. Thus it islessflexible, but morerobust, thanthe DAI work. However, the complexity of NC applicationsdemandsflexibility andtheir importancedemandsrigor. IOP is aboutprogrammingabstractionsthatachieve bothoftheseproperties.

The coordinationlayer of IOP dealswith specifyingskeletonsashigh-level descriptionsof agentbe-havior that arerelevant to the agent’s interactionswith oneanother. The skeletonsdefinewhat eventsofan agentare visible externally, and what propertiesthey have. The agentsinteractwith eachother, butprogramaticallytheinteractionsappearto bethroughadistributedcoordinationservice.

Thepropertiesspecifywhat theotheragentscanexpect: roughly, whetherthey canrequesta taskcor-respondingto an event, ask the agentnot to performa task,or ask the agentto put off doing somethingtill they areready. Examplesof eventsarewhethertheagentwill starta task(which otherscanrequest)ordeclareafailure(whichtheothercannotprevent)or declaresuccess(whichtheotherscanaskthisagentnotto dountil they areready).Basedon theevents,coordinationspecificationscanbestatedthatdeterminetheacceptablebehaviors of themultiagentsystem.Thekey researchchallengesarein definingexpressive suchefficiently processablelanguagesfor specifyingcoordinationrequirements,producingefficient algorithmsfor them,andrelatingthecorrespondingmodelsto methodologiesfor systemdevelopment[93, 94].

Thecommitmentlayer introducesthe logical notionof a “social” commitment,which is a relationshipbetweentwo agents. Oneor both of the agentscould be a multiagentsystem. Agentsenterinto com-mitmentsvoluntarily eitherby sayingso,or by adoptingpredefinedrolesthat requirethosecommitments.Commitmentscanbecanceledor updatedprovidedany additionalmetacommitmentsaresatisfied.Thekeyresearchchallengesarein creatingformalismsin which a usefulrangeof commitmentscanbe expressedandefficiently processed,andin correspondingmethodologiesfor systemdevelopment[92, 95].

6.3 Quality of Service

Traditional,i.e., network-related,QoSis definedusingmeasuressuchaskeystroke delays,probability ofloss of data, jitter, and throughput. Becauseof the increasingfocus on end-userworkflows in NC, we

27

broadentheclassicaldefinitionof QoSto includeend-userqualitycharacteristicssuchassystemreliabilityandavailability, performance,algorithmicscalability, effectiveness,andqualityof user-systeminteractions.For example,usersfind keystroke round-tripdelaysof more than 5�6*7 ms unacceptable[11, 55, 33]. Ineducation,for lessonsof aboutanhour, studiesindicatethatof goodusersatisfactionrequiresa probabilityof error 897�:;7<6 , whereasevenaprobability =>7�:?A@ is unacceptable.

To make NC applicationsappeartruly “appliance-like,” the systemsmustsupportnegotiationof ex-tendedQoSguaranteesfor users,monitorQoS,andadjustresourceallocationdynamically[32]. This is acomplex challenge,becauseof thenatureof applicationsandthefactthattheinfrastructureisdistributedandheterogeneous.Existing techniquesfor applicationlayerQoSmanagementarelimited to staticallocationof resources.Thesearenot suitablefor theabove challenge.Thus,in additionto reactive mechanismsforcontrolof QoSviolations,predictive QoSmanagementis required[69].

For instance,althoughATM solutionsareintendedto provide QoSsupport,only applicationswrittenspeciallyfor ATM cantake full advantageof its QoScapabilities.Someapproachesseekto establishend-to-endconnectionsover existing IP solutions(e.g.,RSVP, AREQUIPA) [1, 116].

Ongoingdiscussionson QoSprovisioninghave oftendebatedwhetherthenetwork canbedimensiondsuchthat traffic requirementsareunlikely to ever exceedthe available resources.However, the “infiniteresources”argumenthasnever beenfoundto betrue.

Dixit arguesthat thereis a considerableneedto monitorandmodelQoSnot only at thenetwork layer,but at theapplicationlayeraswell [32]. While guaranteedboundsareoftenachievableandprovisionedforin datanetworks (e.g.,[72]), they areusuallyintendedfor network-to-network connections(seeFigure3)and do not accountfor QoSviolations resultingform end-userapplications(including server and clientuser-level effects). Further, provisioning for suchboundsis expensive. Tolerantandadaptive clientswillbe unwilling to pay excessive tariffs requiredto suportthesebounds. In addition, reservingbandwidthin advancemay leadto wastedresources.Anothersignificantissueis that the overal stochasticityof theNC systemsis usuallynot accountedfor in mostexisting approaches.The stochasticitywhich resultsindistributedsystemsdueto schedulingmechanisms,resourcedynamics,andso on, may manifestaspoorQoSandmay be taggedasQoSfailuresunlessit is explicitly incorporatedin QoSmodels. Applicationlayermonitoringis neededto provide reliablepredictive estimatesof QoSin thefuture.

Therefore,in emerging networks,QoSshouldbeprovisioneddynamicallyandin a modelusingmoreunifiedapproaches,whichaccountfor thecombinedeffectsof interactingNC componentsandlayers.

6.4 Performanceof NC Applications

Theperformanceon anNC applicationcanbedefinedin userterms(e.g.,availability or reliability [32]) ormorebasicparameters(e.g.,latency andthroughput).Therearemany factorsthatinfluenceperformanceofNC. Theseincludethe performanceof (1) the networking infrastructureandhosthardwareandoperatingsystem[104, 101], (2) the transportandnetworking software [104, 101], and(3) the middleware,whichresidesbetweenthetransportlayerandtheapplication[5]. Theimpactof network congestionon responsedelay is shown in Figure fig-internet-congestion. However, one can elicit an equally poor performancesimply throughinadequatetuningor weakworkstations[83]. It is thecombinationof theabove factorsandtheoperationalprofileof thefieldedapplicationthatdeterminesits performance.

The overheadimposedby the middlewareis relatedto its functionality. Lightweightmiddlewarepro-videsonly a subsetof functions,e.g., for inter-processcommunication,necessaryfor the supportof theimmediateapplicationneeds.Full-function middlewaremakesall operationsandcommunicationmodes

28

available,even if not neededby an application. This typically leadsto greatercommunicationoverheadthanin specializedlightweightlayers.Thus,functionallyequivalentmiddlewareimplementationsmayhavevastlydifferingperformanceprofiles.

Thefollowing resultscomparethedelayin sendinganull-bodyasynchronous(one-way)message,andinsendinganull-bodyrequest-reply(two-way)message.LightweightSoftwareBus(LSB) is acommunicationlayer developedat NCSU [5, 6]. SOMObjects,Orbix, andORBelinearecommercialCORBA-compliantproducts.SII andDII arethestaticanddynamicinvocationinterfacesdefinedin CORBA.

29

Figure3: An illustrationof thepath(andoverhead)betweenanNC clientandanothertop-layercomponent(e.g.,server)

LSB SOMSII SOMDII

One-wayLatency 0.20ms 2.04ms 2.06msTwo-wayLatency 1.83ms 4.32ms 5.26ms

Table2: Latency Measurementsfor LSB andSOMObjects

30

Figure4: Illustrationof InternetCongestionDelays

31

Orbix SII Orbix DII ORBelineSII ORBelineDII

One-wayLatency 0.5ms 0.4ms 0.1ms 0.1msTwo-wayLatency 2.7ms 10.5ms 2.0ms 2.0ms

Table3: Latency Measurementsfor Orbix andORBeline

32

Table2 shows that thedelayincurredby a messagetraversingLSB is muchlessthanfor SOMObjects[5, 6]. Also, for a two-way operation,DII yields a significantlyhigher latency thanSII. Table3 showssimilar comparisonson two otherCORBA products.Theseresultsareextractedfrom thegraphsin [43] forparameter-lessmethodinvocation.Thetablesshow therangesof overheadsthatarepossible.

7 ReadingList

Network computingis a hugeareathat impingesupona numberof subfieldsof computing.We includealist of readingto obtainadditionalinformationaboutthevarioustopicsdiscussedabove.

B Multidatabases:[57, 75, 17, 97,115]

B Traditionalandextendedtransactions:[46, 35, 57]

B Workflow modelingandenactment:[26, 40, 44, 2, 67, 86]

B Agentsandmultiagentsystems:[85, 53, 51,112, 34, 23]

B DistributedobjectsandCORBA: [57, 71, 90]

B Applicationsof network computing:[21, 27, 56, 79]

B Scientificcomputing:[38, 66, 100, 39]

B Softwareandreliability engineering:[47, 12, 62, 63]

B Performanceevaluation:[106, 6, 103]

B Networkingandqualityof service:[101, 74]

B Architectures:[102, 8, 56, 87]

8 CrossReferences

Thesearetermsthatshouldreferto thisarticle.

1. Internetcomputing

2. Openinformationenvironments

3. Problem-solvingenvironments

4. Workflow management

5. Agents

6. Multiagentsystems

7. Middleware

8. Qualityof service

9. InternetandInternet2 applications

33

References

[1] W. Almesberger. AREQUIPA: Designandimplementation.TR 96/213,EPFL,ftp.lrcwww.epfl.ch/pub/arequipa,November1996.

[2] PaulC. Attie, MunindarP. Singh,Amit P. Sheth,andMarekRusinkiewicz. Specifyingandenforcingintertaskdependencies.In Proceedingsof the19thVLDBConference, pages134–145,August1993.

[3] JohnL. Austin. Howto Do Thingswith Words. ClarendonPress,Oxford,1962.

[4] Mark Baker and Geoffrey Fox. Metacomputing:The informal supercomputer. In Proceedingsof the NSF Train the Trainer Workshop, Ithaca, NY, May 1996. Cornell Theory Center. http://renoir.csc.ncsu.edu/RTCPP/HTML/ Workshop2/index.html.

[5] Rajini Balay. A LightweightMiddleware Architecture and Evaluationof Middleware Performance.PhDthesis,NorthCarolinaStateUniversity, Raleigh,1998.

[6] Rajini Balay, MladenA. Vouk, andHarry Perros.Implicationsof middlewareandapplicationlevelcommunicationissueson theperformanceof network-basedproblem-solvingenvironments.In EliasHoustisandJohnR. Rice,editors,ProblemSolvingEnvironments, ComputationalScienceandEngi-neering.IEEEPress,Los Alamitos,CA, 1998.

[7] CarloBatini, StefanoCeri, andShamkantNavathe. ConceptualDatabaseDesign. BenjaminCum-mings,RedwoodCity, CA, 1992.

[8] Miro Benda,editor. SpecialIssueonInternetArchitecture, volume2(2)of IEEEInternetComputing.March1998.Contains6 articles.

[9] T. Berners-Lee,R. Cailliau, J. F. Groff, andB. Pollerman.World-wideweb: The informationuni-verse.Electronic Networking:Research, ApplicationsandPolicy, 1(2):52–58,Spring1992.

[10] Tim Berners-Lee,RobertCailliau, Ari Luotonen,Henrik Frystyk Nielsen,andArthur Secret. Theworld-wideweb. Communicationsof theACM, 37(8):76–82,August1994.

[11] M. D. Bitzer andD. L. Bitzer. Teachingnursingby computer:An evaluationstudy. Computers inBiology andMedicine, 3(3):187–204,1973.

[12] BarryW. Boehm.Software RiskManagement. IEEEComputerSocietyPress,LosAlamitos,1989.

[13] C. Mic Bowman,PeterB. Danzig,Udi Manber, andMichaelF. Schwartz. Scalableinternetresourcediscovery: Researchproblemsandapproaches.Communicationsof theACM, 37(8):98–114,August1994.

[14] S. Bradnerand A. Mankin. Recommendationfor the IP next generationprotocol, January1995.RFC1752.

[15] Alejandro Buchmann,M. TamerOzsu,Mark Hornick, Dimitrios Georgakopoulos,and Frank A.Manola.A transactionmodelfor activedistributedobjectsystems.In [35] , chapter5,pages123–158.1992.

34

[16] OmranA. Bukhres,JiansanChen,Weimin Du, AhmedK. Elmagarmid,andRobertPezzoli. Inter-Base:An executionenvironmentfor heterogeneoussoftwaresystems.IEEEComputer, 26(8):57–69,August1993.

[17] OmranA. BukhresandAhmedK. Elmagarmid,editors.Object-OrientedMultidatabaseSystems:ASolutionfor AdvancedApplications. Prentice-Hall,1996.

[18] ChristophBußlerandStefanJablonski.An approachto integratedworkflow modelingandorganiza-tion modelingin anenterprise.In Workshopon EnablingTechnologies: Infrastructure for Collabo-rativeEnterprises. IEEEComputerSocietyPress,1994.

[19] NicholasCarrieroandDavid Gelernter. Linda in context. Communicationsof theACM, 32(4):444–458,April 1989.

[20] NicholasCarrieroandDavid Gelernter. Coordinationlanguagesandtheir significance.Communica-tionsof theACM, 35(2):97–107,February1992.

[21] BrahimChaib-draa.Industrialapplicationsof distributedartificial intelligence.In [51] , pages31–35.1997.(Reprintedfrom Communicationsof theACM, 1995).

[22] David Chaum. Securitywithout identification: Transactionsystemsto make big brotherobsolete.Communicationsof theACM, 28(10):1030–1044, October1985.Extendedversionwith subtitle“CardComputersto Make Big Brother Obsolete”available at http://digicash.support.nl/publish/bigbro.html.

[23] David Chess,BenjaminGrosof,Colin Harrison,David Levine,Colin Parris,andGeneTsudik. Itin-erantagentsfor mobilecomputing. In [51] , pages267–282.1997. (Reprintedfrom IEEE PersonalCommunications,1995).

[24] PanosChrysanthisandKrithi Ramamritham.ACTA: The SAGA continues. In [35] , chapter10,pages349–397.1992.

[25] E. Clarke,O. Grumberg, andD. Long. Modelchecking.In Proceedingsof theInternationalSummerSchoolonDeductiveProgramDesign, pages428–439,1990.

[26] Bill Curtis,MarcI. Kellner, andJimOver. Processmodeling.Communicationsof theACM, 35(9):75–90,September1992.

[27] Mark R. Cutkosky, RobertS.Englemore,RichardE. Fikes,MichaelR. Genesereth,ThomasR. Gru-ber, William S. Mark, JayM. Tenenbaum,andJayC. Weber. PACT: An experimentin integratingconcurrentengineeringsystems.In [51] , pages46–55.1997.(Reprintedfrom IEEEComputer, 1993).

[28] PeterB. Danzig,Shih-HaoLi, andKatia Obrazacka.Distributed indexing of autonomousinternetservices.ComputingSystems, 5(4):433–459,Fall 1992.

[29] UmeshDayal,HectorGarcia-Molina,Mei Hsu,BenKao, andMing-ChienShan. Third generationTP monitors:A databasechallenge.In Proceedingsof theACM SIGMODInternationalConferenceonManagementof Data, May 1993.Industrialtrackpaper.

35

[30] S. Deering and R. Hinden. Internet protocol, version 6 (IPv6) specification,December1995.RFC1883.

[31] R.L. Dennis,D. W. Byun,J.H. Novak,K. J.Galluppi,C. C. Coats,andM. A. Vouk. Thenext gener-ationof integratedair quality modeling:EPA’s Models-3. AtmosphericEnvironment, 30(12):1925–1938,1996.

[32] ParitoshDixit. Qualityof ServiceModelingfor WideAreaNetworkBasedSystems. PhDthesis,NorthCarolinaStateUniversity, Raleigh,1998.

[33] ParitoshDixit, Mladen A. Vouk, and Donald L. Bitzer. Reliability behavior of a large network-basededucationsystem. In Proceedingsof the International Symposiumon Software ReliabilityEngineering, pages43–56.IEEEComputerSocietyPress,November1997.

[34] EdmundH. Durfee,Daniel L. Kiskis, andWilliam P. Birmingham. The agentarchitectureof theUniversityof Michigandigital library. In [51] , pages98–108.1997.(Reprintedfrom ProceedingsoftheIEE: Software Engineering, 1997).

[35] AhmedK. Elmagarmid,editor. DatabaseTransactionModelsfor AdvancedApplications. MorganKaufmann,SanMateo,1992.

[36] E. Allen Emerson.Temporalandmodallogic. In JanvanLeeuwen,editor, Handbookof TheoreticalComputerScience, volumeB, pages995–1072.North-Holland,Amsterdam,1990.

[37] Foundationfor intelligentphysicalagents(FIPA) 1997specification,1998.http://www.fipa.org.

[38] EfstratiosGallopoulos,EliasHoustis,andJohnR. Rice. Computerasthinker/doer:Problem-solvingenvironmentsfor computationalscience. IEEE ComputationalScienceand Engineering, 1:11–23,Summer1994.

[39] A. Geist,A. Beguelin,J.Dongarra,W. Jiang,R. Mancheck,andV. Sunderam.PVM: Parallel VirtualMachine- A User’s GuideandTutorial for NetworkedParallel Computing. MIT Press,Cambridge,MA, 1994.

[40] Dimitrios Georgakopoulos,Mark Hornick,andAmit Sheth.An overview of workflow management:Fromprocessmodelingto workflow automationinfrastructure.DistributedandParallel Databases,3(2):119–152,April 1995.

[41] Dimitrios Georgakopoulos,Mark F. Hornick, andFrankManola. Customizingtransactionsmodelsandmechanismsin a programmableenvironmentsupportingreliableworkflow automation. IEEETransactionsonKnowledge andDataEngineering, 8(4):630–649,August1996.

[42] CharlesR. Gilman, Manuel Aparicio, J. Barry, Timothy Durniak, HermanLam, and Rajiv Ram-nath.Integrationof designandmanufacturingin avirtual enterpriseusingenterpriserules,intelligentagents,STEP,andwork flow. In SPIEProceedingson Architectures,Networks,andIntelligentSys-temsfor ManufacturingIntegration, pages160–171,1997.

36

[43] AniruddhaGokhaleand DouglasC. Schmidt. EvaluatingCORBA Latency and Scalability OverHigh-SpeedATM Networks. In 17th InternationalConferenceon DistributedSystems, May 27-301997.

[44] Esin Gokkoca,MehmetAltinel, Ibrahim Cingil, E. NesimeTatbul, PinarKoksal,andAsumanDo-gac. Designandimplementationof a distributedworkflow enactmentservice.In Proceedingsof theInternationalConferenceonCooperativeInformationSystems(CoopIS), pages89–98,1997.

[45] Art Goldschmidt,Martin Hardwick,JonJudd,HermanLam,Jeff Pan,JayRamanathan,TomRando,Stanley Su,CraigThompson,andDavid Zenie. NIIIP referencearchitecture:Conceptsandguide-lines. TR NTR95-01,NationalIndustrialInformationInfrastructureProtocols(NIIIP) Consortium,January1995.www.niiip.org/ public-forum/NTR95-01/.

[46] Jim Gray andAndreasReuter. TransactionProcessing:Conceptsand Techniques. MorganKauf-mann,SanMateo,1993.

[47] MauriceH. Halstead.Elementsof Software Science. Elsevier, Amsterdam,1977.

[48] GerardJ. Holzmann. The model checker SPIN. IEEE Transactionson Software Engineering,23(5):279–296,May 1997.

[49] MeichunHsu,editor. SpecialIssueonWorkflowandExtendedTransactionSystems, volume16(2)ofBulletinof theIEEETechnicalCommitteeonDataEngineering. June1993.Contains13articles.

[50] MichaelN. HuhnsandMunindarP. Singh.Ontologiesfor agents.IEEEInternetComputing, 1(6):81–83,December1997.Instanceof thecolumnAgentson theWeb.

[51] Michael N. HuhnsandMunindarP. Singh,editors. Readingsin Agents. MorganKaufmann,SanFrancisco,1997.

[52] AkhtarJameel,MatthiasStuempfle,DanielJiang,andAxel Fuchs.Webonwheels:Towardinternet-enabledcars.IEEEComputer, 31(1):69–76,January1998.

[53] NicholasR. JenningsandMichaelJ.Wooldridge,editors.AgentTechnology: Foundations,Applica-tions,Markets. Springer-Verlag,Berlin, 1997.

[54] MohanKamathandKrithi Ramamritham.Bridging the gapbetweentransactionmanagementandworkflow management.In Proceedingsof theNSFWorkshopon WorkflowandProcessAutomationin InformationSystems:State-of-the-artandFuture Directions, May 1996. http:// optimus.cs.uga.edu:5080/ activities/NSF-workflow/ kamath.html.

[55] P. K. Kauer. An analysisof northcarolinastateuniversity’s network performance.Master’s thesis,Departmentof ComputerScience,NorthCarolinaStateUniversity, Raleigh,1995.

[56] KenKennedy, CharlesF. Bender, JohnW. D. Connolly, JohnL. Hennessy, Mary K. Vernon,andLarrySmarr. A nationwideparallelcomputingenvironment.Communicationsof theACM, 40(11):63–72,November1997.

37

[57] WonKim, editor. ModernDatabaseSystems:TheObjectModel,Interoperability, andBeyond. ACMPressandAddison-Wesley, New York, 1994.Reprintedwith corrections,1995.

[58] YannisLabrouandTim Finin. Semanticsandconversationsfor anagentcommunicationlanguage.In [51] , pages235–242.1997.(Reprintedfrom Proceedingsof theInternationalJoint ConferenceonArtificial Intelligence, 1997).

[59] TedG. Lewis. Informationappliances:Gadgetnetopia.IEEEComputer, 31(1):59–68,January1998.

[60] FrankLeymannandWolfgangAltenhuber. Managingbusinessprocessesasaninformationresource.IBM SystemsJournal, 33(2):326–348,1994.

[61] Tim LindholmandFrankYellin. TheJavaVirtual MachineSpecification. ACM PressandAddison-Wesley, New York, 1996.

[62] MichaelR. Lyu, editor. Software Fault-Tolerance. JohnWiley, New York, 1995.

[63] Michael R. Lyu, editor. Handbookof Software Reliability Engineering. McGraw-Hill and IEEEComputerSociety, New York, 1996.

[64] SteveMann. Wearablecomputing:A first steptowardpersonalimaging. IEEEComputer, 30(2):25–32,February1997.

[65] StevenMcCanneandVanJacobson.VIC: A flexible framework for packet video. In ProceedingsoftheACM MultimediaConference, pages511–522,1995.

[66] Gregory J. McRae. How applicationdomainsdefinerequirementsfor thegrid. CommunicationsoftheACM, 40(11):75–83,November1997.

[67] Raul Medina-MoraandKelly W. Cartron. ActionWorkflow C in use: Clark Countydepartmentofbusinesslicense.In Proceedingsof the12thInternationalConferenceonData Engineering(ICDE),pages288–294,February1996.

[68] J. D. Musa. Operationalprofilesin software-reliabilityengineering.IEEE Software, 10(2):14–32,March1993.

[69] K. Nahrstedt. An Architecture for End-to-EndQuality of Serviceand its ExperimentalValidation.PhDthesis,Universityof Pennsylvania,Philadelphia,1995.

[70] B. C. NeumannandT. Ts’o. Kerberos:An authenticationservicefor computernetworks. IEEECommunications, 32(9),September1994.

[71] M. TamerOzsu,Umeshwar Dayal,andPatrick Valduriez,editors. DistributedObjectManagement.MorganKaufmann,SanMateo,1994.

[72] A. K. Parikh andR. G. Gallager. A generalizedprocessorsharingapproachto flow control in inte-gratedservicesnetwork. IEEETransactionsonNetworking, 2(2):137–150,April 1994.

38

[73] RameshS.Patil, RichardE. Fikes,PeterF. Patel-Schneider, DonMcKay, Tim Finin, ThomasGruber,andRobertNeches.TheDARPA knowledgesharingeffort: Progressreport.In [51] , pages243–254.1997.(ReprintedfromProceedingsof theThird InternationalConferenceonPrinciplesof KnowledgeRepresentationandReasoning, 1992).

[74] CharlesE. Perkins. Mobile networking throughmobile IP. IEEE InternetComputing, 2(1):58–69,January1998.

[75] EvaggeliaPitoura,OmranA. Bukhres,andAhmedK. Elmagarmid.Object-orientedmultidatabasesystems:An overview. In [17] , chapter10.1996.

[76] J.Postel.Internetprotocol,September1981.RFC0791.

[77] Parallelvirtual machine.http://www.netlib.org/pvm3,1997.

[78] Krithi Ramamrithamand PanosK. Chrysanthis. A taxonomyof correctnesscriteria in databaseapplications.TheVLDBJournal, 5(1):85–97,January1996.

[79] DanielA. Reed,RoscoeC. Giles,andCharlesE. Catlett. Distributeddataandimmersive collabora-tion. Communicationsof theACM, 40(11):39–48,November1997.

[80] Michael K. Reiter. Distributing trust with the Ramparttoolkit. In [51] , pages306–309.1997.(Reprintedfrom Communicationsof theACM, 1996).

[81] JohnR. RiceandRonaldF. Boisvert. Fromscientificsoftwarelibrariesto problem-solvingenviron-ments.IEEEComputationalScienceandEngineering, 3:44–53,Fall 1996.

[82] TristanRichardson,QuentinStafford-Fraser, KennethR. Wood,andAndy Hopper. Virtual networkcomputing.IEEEInternetComputing, 2(1):33–38,January1998.

[83] A. J.Rindos,S.Woolet,D. Cosby, L. Hango,andM. Vouk.FactorsinfluencingATM adapterthrough-put. MultimediaToolsandApplications, 2(3):253–272,1996.

[84] Nancy Ross-Flannigan.Thevirtues(andvices)of virtual colleagues.MIT TechnologyReview, March1998.

[85] StuartJ.RussellandPeterNorvig. Artificial Intelligence:A ModernApproach. Prentice-Hall,UpperSaddleRiver, NJ,1995.

[86] SunilK. Sarin.Workflow anddatamanagementin InConcert.In Proceedingsof the12thInternationalConferenceonDataEngineering(ICDE), pages497–499,February1996.

[87] Walt ScacchiandJohnNoll. Process-driven intranets:Life-cycle supportfor processreengineering.IEEEInternetComputing, 1(5):42–49,October1997.

[88] Michael F. Schwartz, Alan Emtage,BrewsterKahle, andB. Clifford Newman. A comparisonofinternetresourcediscovery approaches.ComputingSystems, 5(4):461–493,Fall 1992.

39

[89] HyongSopShim,RobertW. Hall, Atul Prakash,andFarnamJahanian.Providing flexible servicesfor managingsharedstatein collaborative systems.In Proceedingsof theEuropeanConferenceonComputerSupportedCooperativeWork (ECSCW), Lancaster, UK, 1997.

[90] JonSiegel. CORBA: FundamentalsandProgramming. ObjectManagementGroupandWiley, NewYork, 1996.

[91] MunindarP. Singh. Synthesizingdistributedconstrainedeventsfrom transactionalworkflow speci-fications. In Proceedingsof the12th InternationalConferenceon Data Engineering(ICDE), pages616–623,February1996.

[92] MunindarP. Singh. Commitmentsamongautonomousagentsin information-richenvironments.InProceedingsof the8thEuropeanWorkshoponModellingAutonomousAgentsin a Multi-AgentWorld(MAAMAW), pages141–155.Springer-Verlag,May 1997.

[93] MunindarP. Singh. A customizablecoordinationservicefor autonomousagents.In Proceedingsofthe4th InternationalWorkshopon AgentTheories,Architectures,andLanguages(ATAL). Springer-Verlag,July1997.Publicationdate:1998.

[94] Munindar P. Singh. Developing formal specificationsto coordinateheterogeneousautonomousagents.In Proceedingsof the3rd InternationalConferenceon Multiagent Systems(ICMAS). IEEEComputerSocietyPress,July1998.

[95] MunindarP. Singh. An ontologyfor commitmentsin multiagentsystems:Toward a unificationofnormative concepts.Artificial IntelligenceandLaw, 1998.In press.

[96] MunindarP. Singh.Principlesof agentcommunication.IEEEComputer, 1998.To appear.

[97] MunindarP. Singh,Philip E. Cannata,MichaelN. Huhns,Nigel Jacobs,TomaszKsiezyk,KayliangOng, Amit P. Sheth,ChristineTomlinson,andDarrell Woelk. The Carnotheterogeneousdatabaseproject: Implementedapplications.Distributedand Parallel Databases:An InternationalJournal,5(2):207–225,April 1997.

[98] MunindarP. SinghandMichaelN. Huhns.Automatingworkflowsfor serviceprovisioning: Integrat-ing AI anddatabasetechnologies.IEEEExpert, 9(5):19–23,October1994.

[99] Smartdescription.http://smart.npo.org/, 1997.

[100] M. Snir, S. W. Otto, S.Huss-Lederman,D. W. Walker, andJ. Dongarra.MPI: TheCompleteRefer-ence. MIT Press,Cambridge,MA, 1995.

[101] William Stallings.DataandComputerCommunications. Prentice-Hall,UpperSaddleRiver, NJ,5thedition,1997.

[102] Rick Stevens,Paul Woodward, Tom DeFanti, andCharlieCatlett. From the I-way to the nationaltechnologygrid. Communicationsof theACM, 40(11):51–60,November1997.

[103] W. RichardStevens. QueueingNetworkswith Blocking: ExactandApproximateSolutions. OxfordUniversityPress,New York, 1994.

40

[104] W. RichardStevens.TCP/IPIllustrated,Volumes1–3. Addison-Wesley, Reading,MA, 1994.

[105] Stanley Y. W. Su,HermanLam,Tsae-FengYu,Javier A. Arroyo-Figueroa,ZhidongYang,andSoohaLee. NCL: A commonlanguagefor achieving rule-basedinteroperabilityamongheterogeneoussys-tems.Journalof Intelligent InformationSystems(JIIS), 6(2/3):171–198,1996.

[106] Y. Viniotis andH. Perros,editors. SpecialIssueon ATM networksandTheir Performance. Perfor-manceEvaluationJournal.1998.

[107] M. Vouk,J.Hines,A. J.Rindos,S.Woolet,andJ.Lester. ATM technologyenablingeducationalappli-cationsacrosstheNorthCarolinainformationhighway. In Proceedingsof the7thWorld Telecommu-nicationsForum, pages519–522,Geneva,October1995.InternationalTelecommunicationsUnion.

[108] JacquesWainer, MathiasWeske, Gottfried Vossen,and ClaudiaM BauzerMedeiros. Scientificworkflow systems.In Proceedingsof the NSFWorkshopon Workflow and ProcessAutomationinInformation Systems:State-of-the-artand Future Directions, May 1996. http:// optimus.cs.uga.edu:5080/ activities/NSF-workflow/ wainer.html.

[109] Weblecturesystem.http://renoir.csc.ncsu.edu/WLS, 1997.

[110] PeterWegner. Interactive foundationsof computing.Theoretical ComputerScience, May 1997. Inpress.Preprintat www.cs.brown.edu/people/pw/.

[111] PeterWegner. Why interactionis morepowerful thanalgorithms. Communicationsof the ACM,40(5):80–91,May 1997.

[112] GerhardWeiß,editor. Introductionto DistributedArtificial Intelligence. MIT Press,Cambridge,MA,1998.

[113] Gio Wiederhold.Mediatorsin thearchitectureof futureinformationsystems.In [51] , pages185–196.1997.(Reprintedfrom IEEEComputer, 1992).

[114] Gio Wiederhold,PeterWegner, andStefanoCeri. Towardmegaprogramming.CommunicationsoftheACM, 35(11):89–99,November1992.

[115] DarrellWoelk,Philip Cannata,MichaelHuhns,Nigel Jacobs,TomaszKsiezyk,Greg Lavender, GregMeredith,KayliangOng,Wei-Min Shen,MunindarSingh,andChristineTomlinson. Carnotproto-type. In [17] , chapter18,pages621–648.1996.

[116] L. Zhang,S. Deering,D. Estrin, S. Shenker, andD. Zappala. RSVP:A new resourcereservationprotocol. IEEENetwork, 9(5),September1993.

[117] ComputerSelectZiff. Computerselect–softwareproductspecification:Datasourcesreport,Septem-ber1994.Ziff CommunicationsCompany, September1994.

41