Modeling Web Interactions - Northeastern University
Modeling Web InteractionsPaul Graunke (Northeastern University),Robert Bruce Findler (University of Chicago),Shriram Krishnamurthi (Brown University), andMatthias Felleisen (Northeastern University)Abstract. Programmers confront a minefield when they design interactive Webprograms. Web interactions take place via Web browsers. With browsers, consumers can whimsically navigate among the various stages of a dialog and canthus confuse the most sophisticated corporate Web sites. In turn, Web servicescan fault in frustrating and inexplicable ways. The quickening transition fromWeb scripts to Web services lends these problems immediacy.To address this programming problem, we develop a foundational model of Webinteractions and use it to formally describe two classes of errors. The model suggests techniques for detecting both classes of errors. For one class we present anincrementally checked record type system, which effectively eliminates these errors. For the other class, we introduce a dynamic safety check, which catches themistakes relative to programmers’ simple annotations.1IntroductionOver the past decade, the Web has become an interactive medium. Far more than half ofall Web transactions are interactive [4]. While this rapid growth suggests that Web pagedevelopers and programmers have mastered the mechanics of interactive Web content,consumers still encounter many, and sometimes costly, program errors as they utilizethese new services. In short, designing interactive Web programs poses interesting andcomplex problems.To understand these problems, let us briefly recall how Web programs work. Whena Web browser submits a request whose path points to a Web program, the server invokes the program with the request via any of a number of protocols (CGI [16], Javaservlets [6], or Microsoft’s ASP. NET [15]). It then waits for the program to terminate andturns the program’s output into a response that the browser can display. Put differently,each individual Web program simply consumes an HTTP request and produces a Webpage in response. It is therefore appropriate to call such programs “scripts” consideringthat they only read some inputs and write some output. This very simplicity, however,also makes the design of multi-stage Web dialogs difficult.First, multi-stage interactive Web programs consist of many scripts, each handlingone request. These scripts communicate with each other via external media, because theparticipants in a dialog must remember earlier parts of a conversation. Not surprisingly,forcing the scripts to communicate this way causes many problems, considering thatsuch communications rely on oft-unstated, and therefore easily violated, invariants.Second, the use of a Web browser for the consumer’s side of the dialog introduceseven more complications. The primary purpose of a Web browser is to empower consumers to navigate among a web of hyperlinked nodes in a graph at will. A consumer
naturally wants this same power to explore dialogs on the Web. For example, a consumer may wish to backtrack to an earlier stage in a dialog, clone a page with choicesand explore different possibilities in parallel, bookmark an interaction and come backto it later, and so on. Hence, a programmer must be extremely careful about the invariants that govern the communication among the scripts that make up an interactive Webprogram. What appears to be invariant in a purely sequential dialog context may not beso in a dialog medium that allows whimsical navigation actions.In this paper, we make three contributions to the problem of designing reliable interactive Web programs. First, we develop a simple but formal model of Web interactions.Using this model, we can explain the above problems concisely. Second, we developa type system that solves one of these problems in a provable manner (relative to themodel). Third, because not all the checks can be performed statically, we suggest runtime checks to supplement the type system.2A Sample ProblemLet us illustrate one of the Web programming problems with a commercial example.Figure 1 contains snapshots from an actual interaction with Orbitz,1 which sells travelservices from many vendors. It naturally invites comparison shopping. In particular, acustomer may enter the origin and destination airports to look for some flights betweencities, receive a list of flight choices, and then conduct the following actions:1. Use the “open link in new window” option to study the details of a flight that leavesat 5:50pm. The consumer now has two browser windows open.2. Switching back to the choices window, the consumer can inspect a different option, e.g., a flight leaving at 9:30am. Now the consumer can perform a side-by-sidecomparison of the options in two browser windows.3. After comparing the flight details, the customer decides to take the first flight afterall. The consumer switches back to the window with the 5:50pm flight. Using thiswindow (form), the consumer submits the request for the 5:50pm flight.At this point, the consumer expects the reservation system to respond with a page confirming the 5:50pm flight. Alarmingly, even though the page says a click on some linkwould reserve the 5:50pm flight, Orbitz instead chooses the 9:30am flight. A customerwho doesn’t pay close attention may end up reserving the wrong flight.The Orbitz problem dramatically illustrates our case. Sadly, this is not an isolatederror. Rather it exists in other services (such as hotel reservations) on the Orbitz site.Furthermore, as plain consumers, we have stumbled across this and related problemswhile using several vendor’s sites, including Apple, Continental Airlines, Hertz carrentals, Microsoft, and Register.com. Clearly, an error that occurs repeatedly acrossorganizations suggest not a one-time programming fault but rather a systemic problem.Hence, we believe that it is time to develop a foundational model. Before we do so,however, we review related attempts at overcoming such programming problems.1The screenshots were produced on June 28, 2002, but the problems persist as of October 24.
Choices1CloneandSubmitFlight 1Switch Windows23SubmitFlight 24Problem5Commit toFirst ChoiceLegendClick SubmitSwitch WindowsFig. 1. Orbitz InteractionsSwitch Windows
3Prior WorkThe Bigwig project [2] (a descendant of Bell Lab’s Mawl project [1]) provides a radicalsolution to the problem. The main purpose of the project is to provide a domain-specificlanguage for composing interactive Web sessions. The language’s runtime system enforces the (informal) model of a session as a pair of communicating threads [3]. Forexample, clicking on the back button takes the consumer back to the very beginning ofthe dialog. While such a runtime system prevents damage, it is also overly draconian,especially when compared to other approaches to dealing with Web dialogs.John Hughes [14], Christian Queinnec [18], and Paul Graham [11] independentlyhad the deep insight that a browser’s navigation actions correspond to the use of firstclass continuations in a program. In particular, they show that an interaction with theconsumer corresponds to the manipulation of a continuation. If the underlying languageand server support these manipulations, a program doesn’t have to terminate to interact with a consumer but instead captures a continuation and suspends the evaluation.Every time a consumer submits a response, the computation resumes the proper continuation. Put differently, the communication among scripts is now internalized withinone program and can thus be subjected to the safety mechanisms of the language.Our prior work explored the implications of Queinnec’s in two ways. First, we builta Web server that enables Web programs to interact directly with consumers [13]. Programming in this world eliminates many of the Web design problems in a natural manner. Second, after we realized that this solution doesn’t apply to languages without suchmechanisms, we explored the automatic generation of robust Web programs via functional compilation techniques [12]. While this idea works in principle, we recognizedthat a full-fledged implementation requires a re-engineered library system and runtimeenvironment for the targeted language (say Perl).Thiemann [21] started with Hughes’s ideas and provides a monad-based library forconstructing Web dialogs. In principle, his solution corresponds to our second approach;his monads take care of the “compilation” of Web scripts into a suitable continuationform. Working with Haskell, Thiemann can now use Haskell’s type system to checkthe natural communication invariants between the various portions of a Web program.Haskell, however, is also a problem because Thiemann must accommodate effects (interactions with file systems, data bases, etc) in an unnatural manner. Specifically, foreach interaction, his CGI scripts are re-executed from the beginning to the current pointof interaction. Even though his monad-based approach avoids the re-execution of effects, it is indicative of the problems with Thiemann’s approach. Like our second solution, Thiemann’s approach won’t easily apply to other languages.4Modeling the WebTo study the problems of designing interactive Web programs, we formulate a modelwith four characteristics. First, it consists of a single server and a single client, because we wish to study the problems of simple sequential Web dialogs. Second, it dealsexclusively with dynamically generated Web pages, called forms, to mirror HTML’ssub-language of requests. Third, the model allows the consumer to switch among Web
pages arbitrarily; as we show later, this suffices to represent the “Orbitz problem” andsimilar errors. Finally, the model is abstracted over the programming language so thatwe can experiment with alternatives; here we use a λ calculus for forms and basic data.Our model lacks several properties that are orthogonal to our goals. First, the modelignores client-side storage, a.k.a. “cookies,” which primarily addresses customizationand storage optimizations. Server-side storage suffices for our goals. Second, Web programmers must address concurrency via locking, possibly relying on a server that serializes each session’s requests or relying on a database. Distributing the server software across multiple machines complicates concurrency further. Third, monitoring andrestarting servers improves fault tolerance. The model neither addresses nor introducesany security concerns, so existing solutions for ensuring authentication and privacy apply [7, 9].4.1Server and ClientFigure 2 describes the components of our model. Each Web configuration (W) consistsof a single server (S) and a single client (C). The server consists of storage (Σ) anda dispatcher (see figure 3). The latter contains a table (P) that associates URLs withprograms and an evaluator that applies programs from the table to the submitted form.Programs are closed terms (M ) in a yet to be specified language.WSPM CFV[ S CΣ PU rl 7 M programs F F (form U rl (Id V[ ))Int String{ “”, “x”, “why”, “zee” } String{ x, y, z } Id{ www.drscheme.org, www.plt-scheme.org } UrlFig. 2. The WebThe client consists of the current Web form and a set of all previously visited Webforms. The set of previously visited forms starts as a singleton set: the home page. It thengrows as the consumer visits additional pages. The model assumes that the consumercan freely (non-deterministically) replace the current page with some previously visitedpage. Since the current page is always an element of all previously visited pages, theconsumer can also return to this page. We claim that this model of a consumer representsall interesting browser navigation actions, including those not yet conceived by currentbrowser implementors.The model distills a Web page to a minimal representation. Every page is simply aform (F). It contains the URL to which the form is submitted and a set of form fields. Afield names a value that the consumer may edit at will.Figure 3 illustrates how the pieces of the model interact. The server and client mayrun on different machines, connected by a network. The client sends its current form
Web ServerWeb Client submitDispatcherreadΣ - writeEvaluator Programs FormsCurrent Formswitch submit Fig. 3. The Web Pictureto the server. The server applies a program to the form and then produces a response,possibly accessing the store in the process. Finally, the response replaces the currentform on the client and appears in the client’s set of visited forms.fill-form : W W hs, h(form u (k v0 )), f ii , hs, h(form u (k v1 )), {(form u (k v0 ))} f iiswitch : W W hs, hf0 , f ii , hs, hf1 , f ii wheref1 fsubmit : W W hhσ0 , pi, hf0 , f ii , hhσ1 , pi, hf1 , {f1 } f iiwhere hσ1 , f1 i dp (σ0 , f0 )Fig. 4. TransitionsTo specify behavior, we use rewriting rules to relate Web configurations. Figure 4contains rules that determine the behavior of the client and server as far as Web programs are concerned. The fill-form rule allows the client to edit the values of fields inthe current form. The switch rule brings a different Web form to the foreground. In practice, this happens in a number of ways: switching active browser windows, revisiting acached page2 using the back or forward buttons, or selecting a bookmark. The submitrule dispatches on the current form’s URL to run the program found in table p, resultingin a new current client form and updated server storage. The actual dispatching and theevaluation are specific to the chosen programming language, which we introduce next.4.2Functional Web ProgrammingFigure 5 specifies the WrForm programming language. WrForm extends the call-byvalue λ-calculus with integers, strings, and Web forms, which are records with a reference to a program. The programming language connects to the Web model (figure 2) inthree ways: the syntax for forms, the syntax for terms (M), and the dispatch function dp .2Returning to a non-cached page falls under the submit rule.
The form construct creates Web forms. The M.Id construct extracts the value ofa form field with the name Id. We specify the semantics of WrForm with a reductionsemantics [8]. There are two reductions: βv and select.The bottom half of figure 5 specifies dispatching. It shows how dp processes a submitted form form0 . First, it uses the URL in form0 to extract a program from its table p.Second, it applies the program to the form and reduces this application to a value form1 .The store σ0 remains the same.SyntaxSemanticsM EV(M M)Id (form Url (Id M ))M.Id [] (E M) (V E) (form url (id V ) (id E) (id M )) E.Id(βv )E[((λ (x) body) v)] v E[body[x\v]] (select) E[(form url (ni vi ) (nj vj ) (nk vk )) . nj ] v E[vi ]V V[ (λ (Id) M) FLanguage to Web Connectiondp : Σ F Σ F dp (σ0 , (form url (id v))) hσ0 , form1 i where prog p(url) and (prog (form url (id v))) v form1Fig. 5. Web Programming Language4.3Stateful Web ProgrammingUp to this point, scripts in our model can only communicate with each other throughforms. In practice, however, Web scripts often communicate not only via forms butalso through external storage (files, session objects). To model such stateful communications, we extend WrForm with read and write primitives. Figure 6 presents theselanguage extensions. The two primitives empower programs to read flat values fromand to write flat values to store locations. The reduction relation vσ is the naturalextension of the relation v . The extended relation relates pairs of terms and storesrather than just terms. Consequently the dispatcher starts a reduction with the invokedprogram and the current store. At the end it uses the modified store to form the nextWeb configuration. Thus, the server model remains sequential and does not include anyconcurrency.5Problems with the WebOur model of Web interactions can represent some common Web programming problems concisely. The first problem is that a Web script expects a different kind of form
SyntaxLanguage to Web ConnectionM · · · (read Id) (write Id M)Σ v (Id V[ ) dp (σ0 , (form url (id s))) hσ1 , form1 iwhere prog p(url)e0 v e1 hσ0 , (prog (form url (id s)))ihσ, e0 i vσ hσ, e1 i vσ hσ1 , form1 ihσ, E[(write id v)]i vσ hσ[id\v], E[v]ihσ, E[(read id)]i vσ hσ, E[σ(id )]iwhere id dom(σ)SemanticsFig. 6. Language Extensions for Storagethan is delivered. We dub this problem the “(script) communication problem.” The second problem reveals a weakness of the hypertext transfer protocol. Due to the lack ofan update method, information on client Web pages becomes obsolete and misleadsthe consumer. We dub this problem the “(HTTP) observer problem” indicating that theHTTP protocol does not permit a proper implementation of the Observer pattern [10].5.1The Communication ProblemSince standard Web programs must terminate to interact with a consumer, non-trivialinteractive software consists of many small Web programs. If the software needs to interact N times with the client, it consists of N 1 scripts, and all scripts must communicate properly with their successors.3 Worse, since the client can arbitrarily resubmitpages, the programmer cannot assume anything about the scripts’ execution sequence.Even without the difficulties of unusual execution sequences, splitting Web programs into pieces can introduce errors. Consider the example in figure 7. The server’stable contains two programs: start.ss and next.ss. The start.ss program prompts for theuser’s name and directs this information to next.ss. This second program attempts toverify some properties about the consumer. In doing so, it assumes that the input formcontains both name and phone fields, and attempts to extract both. The attempt to extract the non-existent phone field results in a runtime error. The diagram illustrates theproblem graphically. When programmers mistakenly encode such assumptions into thestore—a mistake that is easily made with Java servlet and ASP. NET session objects—these safety errors concerning form field accesses become even more nefarious.By now, programmers are well-aware of this problem and employ extensive dynamic testing to find these mistakes. In the next section, we present a type system thatdiscovers such problems statically and still allows programmers to develop complexinteractive Web programs in an incremental manner.3A good programmer may recognize opportunities for aggregating some of the programs. It isalso possible to use a “multiplexer” technique that merges all these scripts into one single fileand uses a dispatcher to find the proper subroutine. The problems remain the same.
plt-scheme.org/cgi/start.ss 7 (λ (x)(form plt-scheme.org/cgi/next.ss(name "Your Name")))Σ0 submit(form start.ss)()start?plt-scheme.org/cgi/next.ss 7 (λ (x)(form plt-scheme.org/cgi/done.ss(confirm-name x.name)(confirm-phone x.phone)))Σ1nextphone- (form next.ssresponse(name ""))Ysubmitfill-form?(name)(form next.ss(name "Ed"))Fig. 7. Collaborating Programs5.2The Observer ProblemIn a model-view-controller (MVC) architecture, each change to the model notifies allthe views to update their display. Web programs do not enjoy this privilege, becauseHTTP does not provide for an update (or “push”) method. Once a browser receives apage, it becomes outdated when the model changes on the server, which may be due toadditional form submissions from the consumer.The Observer problem is often, but not always, due to a confusion of environmentsand stores, or form and server-side storage. Clearly, a program that reserves flightsneeds both. Unfortunately, programmers who don’t understand the difference may placeinformation into the store when it really belongs in the Web form.Figure 8 shows a reformulation of Orbitz’s problem (see section 2) in WrForm.The first of these programs, pick-flight, asks the customer for a preferred flight time.The second program, confirm-flight, writes the selected flight time into external storagebefore asking the user to confirm the flight time. The third program, receipt-flight, readsthe selected flight from storage and charges the customer for a ticket.It is easy to see that the WrForm program models the problem in section 2. Submitting two requests for the confirm-flight program results in two pages displaying differentflight times on the client, yet only one flight time resides in the server’s external storage.Submitting the outdated form that no longer matches the storage produces the mistake.6Type Checking CommunicationTrying to extract a field from a form fails in WrForm if the form does not containthe named field. To prevent such errors, languages often employ a type system (and/orsafety checks). Our Web model shows, however, that straightforward type checkingdoesn’t work, because programs consist of many separate scripts loosely connected viaforms and storage. Checking all the scripts together is infeasible. Not only are these
pick-flight 7 (λ (empty-form) (form confirm-flight (departure-time "hh:mm")))confirm-flight 7 (λ (first-form)(write your-flight first-form.departure-time)(form receipt-flight (confirm-time (read your-flight))))receipt-flight 7 (λ (confirmed-form)(buy-flight (read your-flight))(form next-action (itinerary (read your-flight))))Fig. 8. Stateful Web Programsscripts developed and deployed in an incremental manner, they may also reside on different Web servers and/or be written in different programming languages.We, therefore, provide an incremental type system for Web applications. When theserver receives a request for an unknown URL, it installs a program into its table tohandle the request. Before installing the new program, the server type checks the program for “internal consistency.” In addition, the server also derives constraints that thisnew program imposes on other Web programs. We refer to this second step as “externalconsistency” checking. If either step fails, the program is rejected, resulting in an error.In practice, a programmer may register several programs of one application and havethem typed checked before they are deployed.The type system for internal consistency checking heavily borrows from simplytyped λ-calculi with records [5, 17, 19]. Figure 9 defines the type system. In addition tothe usual function type ( ) and primitive types Int and String, the type language alsoincludes types for Web forms. Similar to record types, form types contain the namesand types of the form fields, which—according to their intended usage—must have flat(marshallable) types. We overload the type environment to map both variables and storelocations to types. An initial type environment Γ0 maps locations in the external storageto flat types.4 Typed WrForm differs from WrForm only by requiring types for functionarguments. That is, (λ (x) M) becomes (λ (x : τ ) M) in typed WrForm.The type system also serves as the basis for external consistency checking. As it traverses the program, it generates constraints on external programs. Each type judgment, as shown in figure 9, includes a set of constraints. A constraint url : (form (id τ[ )) in sists that the program associated with url consumes Web forms of type (form (id τ[ )).Most type rules in figure 9 handle constraints in a straightforward manner. Checkingatomic expressions yields the empty set of constraints. Checking most expressions thatcontain subexpressions simply propagates the constraints from checking the subexpressions. The only expressions that generate constraints are form expressions. The expression (form url (id m)) constructs a form value, so its type is similar toa record type. This form expression also indirectly connects the program associatedwith url to the form the consumer will submit later. If the type-checker looked up the4The environment Γ0 is fixed when beginning to check an individual program, but programmersmay add extra locations for new programs.
TypesType T ype[ Type JudgmentsType Type (form (Id T ype[ ))T ype[String IntΓ M : Type, Ξwhere Ξ {url : (form (id τ ))}Type Derivation RulesΓ string : String,{} Γ m : (form (ida τ[a ) (idx τ[x ) (idb τ[b )), ξΓ n : Int,{}Γ m.idx : τ[x , ξ Γ m : τ[ , ξm Γ (form url (id m)) : (form (id τ[ )), {url : (form (id τ[ ))} ξmΓ (x) τΓ x : τ, {}Γ, x : τx m : τ, ξΓ (λ (x : τx ) m) : τx τ, ξΓ (l) τ[Γ (read l) : τ[ , {}Γ m0 : τx τ, ξ0Γ m1 : τx , ξ1Γ (l) τ[Γ (m0 m1 ) : τ, ξ0 ξ1Γ m : τ[ , ξΓ (write l m) : τ[ , ξFig. 9. Internal Types for WrFormprogram associated with url immediately and compared the form type with the function’s argument type, this would suffice. It would not, however, allow for independentdevelopment of connected Web programs. Instead, type checking the form expression generates the constraint url : (form (id τ[ )), which must be checked later.Figure 10 extends the definition of the server state S with a set of constraints Ξ. Thefunction Install-program adds a new program m to the server’s table p at a given url ifthe program is okay. That is, the program must type check and the generated constraintsmust be consistent with the constraints already on the server. A set of constraints isconsistent iff the set is a function from URLs to types.5 The Constrain function ensuresthat the program m is well typed, and it extends the existing set of constraints ξ0 toinclude constraints generated during type checking ξ1 .With type annotations, type checking, constraint generation, and constraint checking in place, the system provides three levels of guarantees. The first theorem shows thatindividual Web scripts respond to appropriately typed requests without getting stuck.Theorem 1. For all m in M, τ in Type, and set of Constraints ξ, if Γ0 m : τ , ξ thenfor some v in V, m v v.The second theorem shows that the server does not apply Web programs to formsof the wrong type, as long as the server starts in a good state. Before we can state thetheorem, though, we need to explain what it means for a server state to be well-typed5Relaxing this restriction could allow forms to contain extra, unanticipated fields.
Server Extension and Additional FunctionsS Σ P ΞInstall-program : URL M W WInstall-program(url, m, hhσ, p, ξi, ci) hhσ, p[url\m], Constrain(ξ, url, m)i, ciwhen Consistent(Constrain(ξ, url, m))Consistent : Ξ booleanConsistent(ξ) (url : (form (id0 τ0 ))) ξ (url : (form (id1 τ1 ))) ξ (id0 τ0 ) (id1 τ1 )Constrain : Ξ url M ΞConstrain(ξ0 , url, m) ξ0 ξ1 {url : (form (idin τin ))}where Γ0 m : (form (idin τin )) (form (idout τout )), ξ1Fig. 10. Constraint Checkingand for a submitted form to be well-typed. A server is well typed when all the programshave function types that map forms to forms and when all the constraints are consistent:server-typechecks(hσ, p, ξi) iff Consistent(ξ) and for each url in dom(p), Γ0 p(url) : (form (id1 τ[1 )) (form (id2 τ[2 )), ξurl and ξurl ξ and url : (form (id τ[1 )) ξA form is well typed with respect to a server if it refers to a program on the server thataccepts that type of form. form-typechecks(hσ, p, ξi, (form url (id v[ ))) iff there are types τ[ such that Γ0 v[ : τ[ , {} and url : (form (id τ[ )) is in ξTheorem 2. If server-typechecks(s0 ) and form-typechecks(s0 , f0 ) then for some hs1 , hf1 , f ii, hs0 , hf0 , f ii , submit hs1 , hf1 , f ii.If the server’s set of constraints is closed, the resulting configuration also guaranteesthe success of the next submission. Theorem 3. If hhσ, p, ξi, hf0 , f ii , submit hs1 , hf1 , f ii,server-typecheck(hσ, p, ξi), form-typechecks(hσ, p, ξi, f0 ), and for each constraint url : (form (id τ )) in ξ, url is in dom(p) thenserver-typecheck(s1 ) and form-typechecks(s1 , f1 ).Alternative Web Programming Languages It is not necessary to instantiate ourmodel with a functional programming language. Instead, we could have used a language such as bigwig , which is the canonical imperative while-loop language overa basic data type of Web documents [20]. Furthermore, the bigwig language already provides an internal type system that derives and checks information about Webdocuments. Its type system is stronger than ours, allowing programmers to use complexmechanisms for composing Web documents.The bigwig project and our analysis differ with respect to the ultimate goal.First, our primary goal is to accommodate the existing Web browser mechanisms. Incontrast, bigwig ’s runtime system disables the back button. Second, we wish to
accommodate an open world, where scripts in ASP. NET, Perl, or Python can collaborate.Our theorems show how type checks in the language and in the server can accommodate just this kind of openness. The bigwig project does not provide a model andtherefore does not provide a foundation for investigating Web interactions in general.Separating constraints on collaborating programs from the type checking of individual programs lends the system flexibility. For WrForm, the set of forms produced couldmore easily be computed by examining the program’s return type. For other languagesthe local type checking and the constraint generation may be less connected. Extending our constraint checking to dynamically typed languages requires a type inferencesystem capable of determining the types of all possible forms a program might produce.7Notifying Outdated ObserversWhen a script creates a form, it reflects the server’s current state. Due to HTTP’s shortcomings, a form can lose currency with the server’s state. Submitting such a form may,from the consumer’s perspective, result in incomprehensible or erroneous behavior.One way to avoid such errors is to reload pages periodically. Since pages are generated with sc
First, multi-stage interactive Web programs consist of many scripts, each handling one request. These scripts communicate with each other via external media, because the . Every time a consumer submits a response, the computation resumes the proper con-tinuation. Put differently, the c
Northeastern University – Silicon Valley Campus Guide Fall 2018 New Student Orientation, photographed by Kindrid Parker Northeastern University Mission Founded in 1898, Northeastern is a global, experiential, research university built on a . lil.ma@northeastern.edu 408.707.3697 College and Program Acronyms
Northeastern University-Seattle Campus Guide Northeastern University Mission Founded in 1898, Northeastern is a global, experiential, research university built on a tradition of engagement with the world, creating a distinctive approach to education and research. The university offers a comprehensive range of undergraduate and graduate
NORTHEASTERN UNIVERSITY Boston Campus Institutional Master Plan Noti cation Form Figure 1. Existing Conditions (2012) Tra c Volumes AM Peak Hours (8:30-9:30 AM) NORTHEASTERN UNIVERSITY Boston Campus Institutional Master Plan Noti cation Form Mitchell L. Fischman CONSULTING LLC 41 Brush Hill Road Newton, Massachusetts 02461 Campus Master Planning
Northeastern Illinois University July 2016 Point of Contact for Designation Process: Kris Pierre Senior Director -Academic & Community Partnerships Northeastern Illinois University Chicago, IL 60625 Email: k-pierre@neiu.edu Phone: 773-442-4607 Northeastern Illinois University's Coalition Campus Team Members:
Northeastern University . 2 Table of Contents TABLE OF CONTENTS . 2 WELCOME TO NORTHEASTERN UNIVERSITY! . 4 PART 1: GETTING AROUND NORTHEASTERN. 5 T HE L AY OF THE L AND .
ing violence prevention, response, and education for Northeastern stu-dents. The major on-campus allies associated with ViSION are University H e a l th nd Cous ig Srv c, O f Resolution, Residential Life, Northeastern University Police Department, Office of Prevention and Education at Northeastern, and Office for G endr Equ ity aCompl c . Th
What is the Accelerated BSN Nursing Program at Northeastern? Northeastern is a school on the move 2013: Forbes ranks Northeastern a "Top College": 236 / 650 on the overall list 167 in Private Colleges 114 in Research Universities 96 in the Northeast 2011: U.S. Army Graduate Program in Anesthesia Nursing
Northeastern University’s extensive academic and athletic facilities on the University’s main campus at 360 Huntington Avenue. The Snell Library is the heart of academic and research work on campus and is part of the Northeastern’s comprehensive library system. Students may also use the University’s outstanding recreation facilities, which
