Rethinking Traditional Web Interaction: Theory and Implementation
Contents
1. X Leroy D Doligez J Garrigue D R my and J Vouillon The objective caml system release 3 10 documentation and user s manual Inria Tech Rep may 2007 A Frisch The bedouin project http sourceforge net projects bedouin Available http sourceforge net projects bedouin Online O Danvy Functional unparsing Journal of Functional Programming vol 8 no 6 1998 pp 621 625 Online Available citeseer ist psu edu danvy98functional html F Pottier and Y R gis Gianas Stratified type inference for generalized algebraic data types in Proceedings of the 33rd ACM Symposium on Principles of Programming Languages POPL 06 Charleston South Carolina Jan 2006 pp 232 244 Online Available http cristal inria fr fpottier publis pottier regis gianas popl06 ps gz H Xi C Chen and G Chen Guarded recursive datatype construc tors in Proceedings of the 30th ACM SIGPLAN Symposium on Principles of Programming Languages New Orleans January 2003 pp 224 235 S Chong J Liu A C Myers X Qi K Vikram L Zheng and X Zheng Secure web applications via automatic partitioning SIGOPS Oper Syst Rev vol 41 no 6 2007 pp 31 44 P Thiemann Wash cgi Server side Web scripting with sessions and typed compositional forms in Practical Aspects of Declarative Languages PADL 02 2002 Online Available http www informatik uni freiburg de thiemann2. HTTP towards the same site in HTTPS is always absolute This breaks the discipline we have to use only relative links for example to behave correctly behind a reverse proxy We have the same problem with redirections which have to be absolute URLs according to the protocol e There is no means to send POST data through a link and it is difficult to disguise a form into a link Links and forms should probably be unified into one notion that would allow to make a POST or GET request from a click on any part of the page This limitation is not really significant if we have a client side program that does the requests itself when we click on a page element e Having the ability to put several id attributes for one tag would be very useful for automatically generated dynamic pages e Probably one of the main barriers to the evolution of the Web today is the impossibility to run fast code on the browser without plug ins even with recent implementations of Javascript When thinking about a Web application as a complex application distributed between a server and a client we would often like to perform computationally intensive parts of the execution on the client which is not feasible for now We want to make some experiments with Google Native Client 37 C Concluding words and future works This papers presents a new programming style for Web interaction which simplifies a lot the programming work and reduces the possibilities of se
3. If the user comes back later for example after having made a bookmark it will not answer again but another service not hidden will take charge of the request We will speak about bookmarkable services for services that are not hidden Hidden services may induce an URL change Actually we can make exactly the same distinction as for bookmarkable services there are hierarchical hidden services attached to a path hidden attached coservices attached to a path and a special POST parameter and hidden non attached coservices called by a special POST parameter It is important to allow the creation of hidden hierarchi cal services or coservices only if there is a bookmarkable co service registered at the same path This service will act as a fallback when the user comes back to the URL without POST parameters This is done by specifying the fallback instead of the path when creating a hidden service It is a good idea to do the same for bookmarkable coservices Registering a hidden service on top of a bookmarkable service with parameters allows to have both GET and POST parameters for the same service But bear in mind that their roles are very different 5 Client side services Client side service calls have the same status as hidden service calls In a framework that allows to program both the server and client sides using the same language we would like to see local function calls as non attached hidden coservices Hierarchical
4. data He must be very conscientious to think about all these cases It is most likely that the evolutions of the program will break the validity of pages In most cases problems are discovered much later by users In lots of cases such errors will even make the generated output unusable for example for XML data intended to be processed automatically The best means to be sure that this situation will never happen is to use a typing system that will prevent one from putting the service on line if there is the slightest risk for something wrong to be generated For people not accustomed to such strong typing systems this may seem to impose too much of a constraint to pro grammers Indeed it increases a bit the initial implementation time by forcing to take into account all cases But it also saves such a huge amount of debugging time that the use of such typing systems really deserves to be generalized For now these typing systems for XML are used in very few cases of Web services and we are not aware of any major Web programming framework Our experience shows that it is not difficult to use once one get used to the main rules of HTML grammar if error messages are clear enough Validity of Web interaction Static checking and abstraction of concepts can also benefit in many other ways to Web programming and especially to Web interaction Here are a few examples e Ina link do the types and names of parameters match the types e
5. from parameters names We implemented some sophisticated types for service pa rameters like lists or sets In the case of lists the names of parameters are generated automatically by an iterator VII CONCLUSION A Related work A lot of modern Web programming frameworks for exam ple GWT or Jif Sif 32 are trying to propose integrated and high level solutions to make easier the development of Web application They often provide some abstraction of concepts but most of them preserve some historical habits related to technical constraints It is impossible to make a full review of such tools as there are numerous We will concentrate on the main novel features presented here One can try to make a classification of existing Web frameworks with respect to the way they do service identification The old method is what we called page based Web pro gramming where one path corresponds to one file Modern tools are all more flexible and make service identification and selection independent of the physical organization of components in the Web server for example JSP assigns an URL to a service from a configuration file But very few belong to the third group that allows dynamic services Among them Seaside 19 Links 2 and Hop 3 Wash CGI 33 Their service identification models are more basic and they do not have a native notion of coservice Some of them are using an abstraction of forms 33 24 that is fully compatible
6. hidden services and hidden attached coservices correspond to local functions that would change the URL without making any request to the server 6 Non localized parameters One additional notion that is interesting in concrete cases is to enable parameters that are not related to any service at all The server does not take into account their presence to choose the service and services do not have to declare them but can access them if they want This avoids declaring the same optional parameters for each service when you want the whole Web site to be parametrized by the same optional parameters for example the language the user prefers to display the pages D Taxonomy of services 1 Summary of service kinds Figure 1 summarizes the full taxonomy of services we propose This set is obviously complete with respect to technical possibilities as traditional services are part of the table It is powerful enough for describing in very few lines of code lots of features we want for Web sites and does not induce any limitations with respect to the needs of Web developers Current Web program ming frameworks usually implement a small subset of these possibilities For example page based Web programming like PHP or CGI scripts does not allow for non attached coservices at all Even among non page based tools very few allow for dynamic anonymous coservice creation To our knowledge none but Ocsigen is implementing actio
7. in expressiveness we put the focus on reliability This is made necessary by the growing complexity of Web applications The concepts we propose allow for very strong static guarantees like the absence of broken links But more static checks can be done for example the verification of adequacy of links and forms to the service they lead to These static guarantees have not been developed here because of space limitation They are summarized by the following additional principles 7 Static type checking of generated data 8 Static type checking of links and forms This paper does not present an abstract piece of work all the concepts we present have been inspired by our experience in programming concrete Web sites and have been implemented Please refer to Ocsigen s manual 25 and source code for information about the implementation Some implementation details may also be found in 26 describing an old version of Ocsigen that was using a more basic model of services Ocsigen is now used in industry for example BeSport 38 Pumgrana 39 These concrete experiences showed that the programming style we propose is very convenient for Web programmers and reduces a lot the work to be done on Web interaction As we have seen the use of an existing language for the implementation induces some limitations the typing of forms is not perfect there is no type inference of service parameters the need to disconnect creation and registratio
8. language for both sides a solution is to send directly your language values after serialisation This is acceptable and very powerful in the case of hidden POST services but will result in unreadable URLs for bookmarkable services B Forms To be correct relative to the service it leads to a form must respect these conditions e The names of the fields of the form must correspond to the names expected by the service e The types of the fields must correspond to the types expected by the service e All required fields must be present and the right number of times The first item may be solved by taking the parameter names from the data representing the service in memory The static verification of the adequacy of types may be done by putting type information in the type of names instead of using just the string type we use an abstract type with phantom type information 23 on the type of the parameter The third condition is more difficult to encode in types One idea interesting for some particular cases of services is to create dynamically the service that will answer to the form from the form itself as for example in Seaside Links 24 or PLT Scheme V ABSTRACTING SESSIONS Sessions are a way to maintain a state during several interactions with one user The abstraction of sessions is something more common in usual Web programming tools than the abstraction of services It is now standard to have a way to save so
9. papers padl02 ps gz P T Graunke R B Findler S Krishnamurthi and M Felleisen Modeling Web interactions in European Symposium on Programming ESOP April 2003 Online Available http www ccs neu edu scheme pubs esop2003 gfkf ps gz S Krishnamurthi R B Findler P Graunke and M Felleisen Mod eling web interactions and errors in In Interactive Computation The New Paradigm Springer Verlag 2006 J Yu B Benatallah R Saint Paul F Casati F Daniel and M Matera A framework for rapid integration of presentation components in WWW 07 Proceedings of the 16th international conference on World Wide Web New York NY USA ACM 2007 Google native client http code google com p nativeclient Besport http www besport com Pumgrana http www pumgrana com B Canou V Balat and E Chailloux O browser objective caml on browsers in ML 08 Proceedings of the 2008 ACM SIGPLAN workshop on ML New York NY USA ACM 2008 pp 69 78 B Canou V Balat and E Chailloux A declarative friendly api for Web document manipulation in International Symposium on Practi cal Aspects of Declarative Languages PADL 13 Springer Verlag January 2013
10. service through a local function call B Services as first class values The main principle on which is based our work is 1 consider services as first class values exactly as functional languages consider functions as first class values That is we want to manipulate services as abstract data that can for example be given as parameter to a function This has several advantages among which e The programmer does not need to build the syntax of URLs himself He can rely on some function that will create the syntax of the URL if it is a distant call or the function call if it is a client side call Thus it is really easy to switch between a local service and a distant one e All the information about the service is taken automat ically from the data structure representing the service including the path to which the service is attached and parameter names This has a very great consequence if the programmer changes the URL of a service even the name of one of its parameters he does not need to change any link or form towards this service as they are all built automatically This means that links will never be broken and parameter names will always be correct at least for internal services i e services belonging to the Web site and modulo to some restrictions in current implementation as we will see later Some recent frameworks already have an abstraction of the notion of service We will show how to take the full benef
11. services using static typing Then Section V shows how these notions of services interact with sessions Finally some hints on the implementations of these concepts are given in Section VI II ABSTRACTING SERVICES As explained above our goal is to formalize Web interac tion that is the behaviour of a Web application in reaction to the actions of the user What happens when somebody clicks on a link or submits a form A click often means that the user is requesting a new document for example a new page that will replace the current one or one part of it But it can also cause some actions to take place on the server or the client Let us enumerate the different kinds of reactions A click or a key strike from the user may have the following main effects 1 Modifying the application interface That is changing the page displayed by the browser or one part of the page or opening a new window or tab with a new page 2 Changing the URL displayed by the browser protocol server name path parameters etc 3 Doing some other action like the modification of a state for example changing some database values 4 Sending hidden data like form data or files 5 Getting some data to be saved on the user s hard disk Two important things to notice are that each of these items is optional and may either involve a distant server or be processed locally by the browser This decomposition is important as a formalizati
12. two reasons e We need the names of parameters to live both in the world of variable names static and in the world of data dynamic to be used as parameter names for pages e We need dynamic types that is keeping typing informa tion during the execution to enable the server to convert received page parameters into the type expected by the handling function But in any case we must keep in mind that the types of service parameters are not OCaml types and it is difficult to use sophisticated OCaml types for services as mentioned in Section IV A C Links and forms We are using functions to create links and forms Obviously the adequacy of the service to its parameters is checked statically while creating a link To implement non localized parameters we just needed a way to build a new service data structure by combining together a service and non localized parameters We mentioned in Section IV B that performing statically all the verification on the form would require a very sophisticated type system that would be difficult to mix with the already complex typing model we use to check the validity of pages We decided to restrict the static verifications to the names and types of fields To do that we use an abstract type for names as explained in Section IV B and we get parameters names from the service This is done by giving as parameter to our form building function a function that will build the content of the form
13. with our model There have been few attempts to formalize Web interac tion The most closely related work is by Paul T Graunke Robert Bruce Findler Shriram Krishnamurthi and Matthias Felleisen 34 35 Their work is more formal but does not take into account all the practical cases we speak about In particular their service model is much simpler and does not fully take into account the significance of URLs Peter Thiemann 33 uses monads to create HTML pages which makes possible an original and interesting way of handling the typing of forms using Haskell s type system We think our approach is compatible with more data driven approaches 10 component based interfaces 36 or even code generation techniques One interesting work would be to see how they can be mixed together B Evolution of technologies and standards This reflection about Web programming techniques has shown that Web technologies suffer from some limitations that slow down the evolution towards really dynamic applications Here are a few examples e As mentioned above the format of page parameters and the way browsers send them from form data does not allow for sophisticated parameters types e X HTML forms cannot mix GET and POST methods It is possible to send URLs parameters in the action attribute of a form that is using the POST method but it is not possible to take them from the form itself This would open many new possibilities e A link from
14. A session identifier is then generated automatically and a cookie is set and sent back by the browser in the header of each request for the site This is a common feature in current Web programming tools But we propose to add the ability to dynamically register coservices or services in a session table that is for one user One obvious reason for this is to allow the use of certain anonymous coservices only for the user who requested them You probably do not want to give access to these kind of coservices to everybody especially because they may contain private data in the closure We also propose to allow to re register some existing services in a session table When the server is receiving a request it first looks in the session table to see if there is a private version of the service and if not looks in the public table Using this feature it is possible to save all the session data in the closure of services From a theoretical point of view this makes session data tables useless Basically when a user logs in you just need to register in the session service table a new version of each service specialized for this user For the sake of flexibility it is a good idea to allow both session data and session services Thus there is now a new possibility for creating each of our service kinds registering them in the session table This corresponds to a fourth dimension in the table of Figure 1 C Session duration When impleme
15. Renggli Seaside a multiple control flow web application framework in Proceedings of ESUG Research Track 2004 2004 S Krishnamurthi P W Hopkins J Mccarthy P T Graunke G Pet tyjohn and M Felleisen Implementation and use of the plt scheme web server in Higher Order and Symbolic Computation 2007 J Matthews R B Findler P Graunke S Krishnamurthi and M Felleisen Automatically restructuring programs for the web Automated Software Engg vol 11 no 4 2004 pp 337 364 J A McCarthy Automatically restful web applications marking mod ular serializable continuations in ICFP 09 Proceedings of the 14th ACM SIGPLAN international conference on Functional programming New York NY USA ACM 2009 pp 299 310 23 29 30 31 32 D Leijen and E Meijer Domain specific embedded compilers in Domain Specific Languages 1999 pp 109 122 Online Available citeseer ist psu edu leijen99domain html E Cooper S Lindley P Wadler and J Yallop The essence of form abstraction in Sixth Asian Symposium on Programming Languages and Systems 2008 V Balat Eliom programmer s guide Technical report Laboratoire PPS CNRS universit Paris Diderot Tech Rep 2007 Online Available http ocsigen org eliom V Balat Ocsigen Typing web interaction with objective caml in ML 06 Proceedings of the 2006 ACM SIGPLAN workshop on ML
16. Rethinking Traditional Web Interaction Theory and Implementation Vincent Balat Univ Paris Diderot Sorbonne Paris Cit PPS UMR 7126 CNRS Inria Paris France Email vincent balat univ paris diderot fr Abstract In recent years Web sites evolved into ever more complex distributed applications But current Web program ming tools are not fully adapted to this evolution and force programmers to worry about too many inessential details We want to define an alternative programming style better fitted to that kind of applications To do that we propose an analysis of Web interaction in order to break it down into very elementary notions based on semantic criteria instead of technological ones This allows defining a common vernacular language to describe the concepts of current Web programming tools but also some other new concepts We propose to use these new concepts to create new frameworks for programming Web applications This results in a significant gain of expressiveness The understanding and separation of these notions also makes it possible to get strong static guarantees that can help a lot during the development of complex applications for example by making impossible the creation of broken links We show how most of the ideas we pro pose have been implemented in the Ocsigen Web programming framework Ocsigen makes possible to write a client server Web applications as a single program and the interaction model we p
17. aditional Web interaction in International Conference on Internet and Web Applications and Services ICIW Jun 2013 pp 206 211 E Cooper S Lindley P Wadler and J Yallop Links Web pro gramming without tiers in In 5th International Symposium on Formal Methods for Components and Objects FMCO Springer Verlag 2006 p 10 M Serrano E Gallesio and F Loitsch Hop a language for program ming the web 2 0 in Dynamic Languages Symposium Oct 2006 The Ocsigen project http www ocsigen org V Balat J Vouillon and B Yakobowski Experience report ocsigen a web programming framework in ICFP 09 Proceedings of the 14th ACM SIGPLAN international conference on Functional programming Edinburgh Scotland ACM 2009 pp 311 316 V Balat P Chambart and G Henry Client server Web applications with Ocsigen in WWW2012 dev track proceedings Lyon France Apr 2012 p 59 Online Available http hal archives ouvertes fr hal 00691710 V Balat Client server Web applications widgets in Proceedings of the 22nd international conference on World Wide Web WWW 2013 dev track Rio de Janeiro Brazil 2013 pp 19 22 Online Available http dl acm org citation cfm id 2487788 2487795 B Canou E Chailloux and J Vouillon How to Run your Favorite Language in Web Browsers in WWW2012 dev track proceedings Lyon France Apr 2012 pp Online Available htt
18. ath The edit form is just a page registered on a non attached service Our reflexion on services also allows to express clearly a solution to the real estate site described in Section I B Use for example one bookmarkable hierarchical service for displaying one piece of advertisement with additional hidden or not parameters to recall the information about the search 3 Expressiveness The understanding of these notions and their division into very elementary ones induces a significant gain in expressiveness This is particularly true for actions with redisplay They are very particular service return values and seem to be closely related to non attached coservices at first sight But the separation of these two concepts introduces a new symmetry to the table with new cells corresponding to very useful possibilities see the example of the wiki above It is noteworthy that all cells introduced in this table have shown to be useful in concrete cases 4 Priority rules One may wonder what succeeds when one gets apparently conflicting information from the request for example both a hidden coservice name and a URL coservice name In most cases the solution is obvious First hidden services always have priority over URL services Secondly as non attached coservices parameters are added to the URL there may be both attached and non attached coservice parameters in the URL In that case the non attached service must be applied because i
19. ation the path corresponds to the service to be executed and the query to parameters for this service But Web frameworks are sometimes taking a part of the path as parameters On the contrary part of the query or even of the host may be used to determine the service to call This will be discussed later in more detail The fragment part of the URL only concerns the browser and is not sent to the server The item Changing the URL is then to be decomposed semantically into these sub tasks 1 Changing the protocol to use 2 Changing the server and port to which the request must be made 3 Choosing a hierarchical position path in the Web site structure and specifying non hierarchical information query about the page 4 And optionally telling who the user is credentials and the fragment of the page he wants to display 2 URL change and service calls There are two methods to send form data using a browser either in the URL GET method or in the body of the HTTP request POST method Even if they are technical variants of the same concept a function call their semantics are very different with respect to Web interaction Having parameters in the URL allows to turn back to the same document later whereas putting them in the request allows to send one shot data to a service for example because they will cause an action to occur We propose to focus on this semantical difference rather than on the way it is i
20. ce Web application through a browser interface Web applications communicate with one or several servers and sometimes need the ability to make part of the computation in the browser A few similar Web interaction systems have already been described before for example Links 2 or Hop 3 The goal of this paper is to improve the way we program Web interaction using one feature that has been very rarely addressed before namely service identification That is how the service to handle a request is chosen We will show that a good service identification mechanism can help programmers a lot and that the concepts we present here allow to take into account very concrete needs of Web developpers that are usually not addressed by more theoretical works Through an analysis of existing programming frameworks and Web sites we will give a semantic description of the diverse behaviours we want to have This language will lead to the definition of a vernacular language for describing Web interaction This will allow to understand the concepts and to propose new ones to increase the expressiveness of Web frameworks Our second goal is the safety of programming By using well defined concepts and static checking it is possible to eliminate a lot of programmer s errors and make the application much more reliable thus simplifying by a lot the maintenance work and evolutions of the site The concepts we present here have been implemented in the Ocs
21. created and not registered which can lead to broken links We were forced to do so because services are usually highly mutually recursive every page may contain links towards any other one and it is not easy in OCaml to have mutually recursive data in several different modules The solution that is currently implemented consists in a dynamic check of the registration of services when the server starts This solves the problem for static services but not for dynamic ones A solution we consider is to use a syntax extension to the language to put back together creation and registration But the concrete realization of that idea is not straightforward 2 Types of parameters One important thing to check statically when registering a function on a service is that the type of this function corresponds to the type expected by the service This makes the type of the registration function dependent on the value of one of its parameters the service This requires very sophisticated type systems As explained in 26 it can be done either using functional unparsing 29 or using generalized algebraic data types 30 31 Ideally one would expect to declare page parameters only once when defining both the service and its handling function As we separate definition and registration it is not possible to do so But even without this separation it is probably not possible to avoid this duplication without a syntax extension for the language for
22. d a large set of libraries We made this choice with the goal in mind to write not only a research prototype but a full framework usable for real applications We benefited greatly from the free software development model which enabled us to have a powerful framework very quickly thanks to the growing community of users Our implementation takes the form of a module for the Oc sigen 4 Web server called Eliom 25 More implementation details may be found in 26 but for an old version of Eliom that was using a more basic model of services A Static type checking of pages As the return value of services is completely independent of services it is important to make the creation of new kinds of output types easy This is realized through the use of OCaml s module language which allows parametrized modules called functors To create a new output module you apply a functor that will create the registration functions for your output type Eliom does not impose one way to write the output but proposes several predefined modules One allows text output as in usual Web programming if you do not want any type checking of pages Another one is using an extension of OCaml called OCaml duce 11 that adds XML types This is really powerful as the typing is very strict and corresponds exactly to what you need to take into account all features of DTDs It also has the advantage of allowing to easily create new output modules for o
23. duce a new kind of output called actions Basically sending an action means no output at all But the service may perform some action as side effect like modifying a database or connecting a user opening a new session From a technical point of view actions implemented server side are usually sending a 204 No content HTTP status code Client side actions are just procedures We will see some examples of use of actions and how to refine the concept in Section II D2 B Dynamic services or continuation based Web program ming 1 Dynamic services Modern Web frameworks propose various solutions to get rid of the lack of flexibility induced by a one to one mapping between one URL and one service But very few take the full benefit of this as most of them do not allow to dynamically create new services For example if we want to add a feature to a Web site or even if we occasionally want to create a service depending on previous interaction with one user For example if one user wants to book a plane ticket the system will look in a database for available planes and dynamically create the services corresponding to booking each of them Then it displays the list of tickets with on each of them a link towards one of these dynamic services Thus we will be sure that the user will book the ticket he expects even if he duplicates his browser window or uses the back button This behaviour is really simple to implement with dynamic ser
24. eate notions of group data and group services E Session scopes In Ocsigen session data are saved in some kind of persistent references whose value depends on the browser that is perfomring the request This makes very easy to access the data in a way that is very well integrated in language features It is possible to make the concept even more powerful by making possible to choose the scope of these references Session The default scope is session and correspond to the usual use of sessions implemented with regular browser cookies The data recorded in references with session scope are specific to a browser Session group If you create a reference with scope session group the value will be available from all browser sharing the same session group For example you can implement a shoping basket just by setting this kind of reference It will be shared by all your sessions Client process Ocsigen makes possible to write both sides of a Web application server and browser as a single program Client side parts are extracted and compiled into Javascript Among many other things this makes possible to create server side references with scope client process These reference values are specific to one tab of the browser Think for example of several instances of the same game running in several tabs We are also using this to record the communication channels that are specific to one tab To implement that we added a cookie mechan
25. elegate to the server the task of decoding and verifying parameters which is traditionally done by the service itself This has the obvious advantage of reducing a lot the work of the service programmer Another benefit is that the choice of the service to be called can depend on parameters Let us first speak about distant server side bookmarkable services i e services called by sending a GET request to a server We will speak later about client side services and hidden services 1 Hierarchical services One obvious way to associate a service to an URL is by looking at the path or one part of it We will call these services hierarchical services These kinds of services are usually the main entry points of a Web site They may take parameters in the query part of the URL or in the path One way to distinguish between several hierarchical services registered on the same path is to look at parameters For example the first registered service whose expected parameters exactly match the URL will answer 2 Coservices Most of the time one probably wants dy namic services to share their path with a hierarchical service at least those which last for only a short time result of a search for example Also one may want two services to share the same hierarchical position on the Web site We will call coservices services that are not directly asso ciated to a path but to a special parameter This is one of the main original features of o
26. ement this with current technology when possible and how it would be interesting to make technologies evolve We place ourselves at a semantic level rather than at a tech nical one Moving away from technical details will allow to increase the expressiveness of Web programming frameworks In the domain of programming languages high level concepts have been introduced over the years for example genericity inductive types late binding closures They make easier the implementation of some complex behaviours We want to do the same for the Web For example the notion of sending a cookie benefits from being abstracted to a more semantic notion like opening a session which is already often the case today Also it is not really important for the programmer to know how URLs are formed What matters is the service we want to speak about and optionally the parameters we want to send it This abstraction from technology allows two things e First it increases the expressiveness of the language by introducing specific concepts closer to the behaviours we want to describe and irrespective of the way they are implemented From a practical point of view this allows to implement complex behaviours in very few lines of code e Having well designed dedicated concepts also allows to avoid wrong behaviours We forbid unsafe technical possibilities either by making them inexpressible or by static checking B Improving the reliabilit
27. erarchical and non hierarchical parts of the URL and hidden parameters II A TAXONOMY OF SERVICES A Values returned by services A first classification of services may be made according to the results they send In almost all Web programming tools services send HTML data written as a string of characters But as we have seen before it is much more interesting to build the output as a tree to enable static type checking To keep full generality we will consider that a service constructs a result of any type that is then sent possibly after some kind of serialization to the browser which requested it It is important to give to the programmer the choice of the kind of service he wants A reflection on return types of services will provide once again a gain of expressiveness Besides plain text or typed HTML trees a service may create for example a redirection One can also consider using a service to send a file It is also important to give the possibility to services to choose themselves what they want to send For example some service may send a file if it exists or an HTML page with an error message on the other case The document is sent together with its content type telling the browser how to display it it is a dynamic type But in other cases for example when a service implements a function to be called from the client side part of the program one probably want the type of the result to be known statically We also intro
28. igen Web programming framework 4 5 6 7 Eliom project It allows to program fully in OCaml both the server and client parts of a Web application with a consistent abstraction of concepts A compiler to Javascript is used to run the client parts in the browser 8 9 A A common vernacular language for Web interaction Web development is highly constrained by technologies First it relies on the HTTP protocol which is non connected and mainly stateless on the applicative layer even if many solutions have been proposed to circumvent this Then Web applications must be executable in various browsers that implement more or less accurately common standards and recommendations One of our goals is to remove these constraints and focus on the programming of Web interaction Obviously this is also a question of taste But rather than proposing yet another programming model from scratch we start by analyzing com mon Web programming practices in order to understand the notions they use Then we decompose them in very elementary notions that can be used to describe the features of Web programming tools from PHP to JSP or Miscrosoft NET Web Forms etc Some frameworks impose some artificial restrictions like the shape of URLs Ideally we would like to give a generic language flexible enough to describe all possible behaviours without imposing any artificial restriction due to one technology We will then see how to impl
29. ing because he may have pressed the back button of his browser or he may have duplicated the page Christian Queinnec solves this problem by using the Scheme control operator call cc that allows to name the current point of execution of the program called continuation and to go back to this continuation when needed The second solution is the one we propose It is symmetric to the first one as it consists in viewing a click on a link or a form as a remote function call Each link or form of the page corresponds to a continuation and the user chooses the continuation he wants by clicking on the page This corresponds to a Continuation Passing programming Style CPS and has the advantage that it no longer needs control operators no saving of the stack is required Strangely this style of programming usually considered unnatural is closer to what we are used to doing in traditional Web programming The use of dynamic services is a huge step in the understanding of Web interaction and an huge gain of expressiveness Until now very few tools have used these ideas None of the most widely used Web programming frameworks implement them but they are used for example in Seaside 19 PLT Scheme 20 Hop 3 Links 2 and obviously Ocsigen 3 Implementation of dynamic services The implementation of dynamic services in CPS is usually done by registering closures in a table on the server It associates to an automat ically generated
30. int and float is not enough We need more complex types Just think about variable length forms for example a page displaying a list of people with just a checkbox for each of them The implementation of this is a tedious work with traditional Web programming tools because you need to give different names to each parameter for example by using numbers to be able to find back on server side the person associated to the checkbox Obviously you do not want to worry about such details when programming a Web application Your service just wants to get an association table from a name to a boolean value however they are encoded in parameters Another example is when you want to send an unordered set of values to a service or optional values Unfortunately most of this is sometimes difficult to imple ment due to the way parameters are encoded in the URL and the way browsers send them One example of this is the way browsers handle unchecked boxes they send no parameter at all instead of sending a false value Thus there is no way to distinguish between an unchecked box and no parameter at all Sets of base types data may be implemented using the same parameter name for each member of the set But an implementation of sets of more complex data requires more thinking In conclusion the types of parameters for Web pages is highly constrained by current technology In the case your Web program has a client side and you are using the same
31. ism very similar to the usual one but at the level of a client process Site References with scope site have the same value for everyone They have the same semantics of regular references but may be persistent across server restarts References with scope request are a simple way to store some data for a single request that is for one thread of the server Request VI IMPLEMENTATION To implement the features presented above we had two possible solutions either we created our own language which would have given us the full freedom in implementation Or we needed to choose a language expressive enough to encode most of the features presented here We chose the second solution for two reasons e We think that Web programming is not a task for a domain specific language We need the full power of a general purpose language because we do not want only to speak about Web interaction and typing of pages but also for example about database interaction We also want code structuring and separation and we need programming environments and libraries The cost of creating our own new language would have been much too high e We knew one language namely OCaml that has almost all features we want to implement the concepts of this paper most notably a powerful typing system able to encode most of the properties we wanted to check statically Moreover this language now has a strong basis of users in academia and industry an
32. it of it Our notion of service must be powerful enough to take into account all the possibilities described above but without relying on their technical implementation A service is some function taking parameters and returning some data with possibly some side effects remote function calls The server is a provider of services Client side function calls can also be seen as calls to certain services The place where services take place is not so significant This allows to consider a Web site with two versions of some services one on server side the other on client side depending on the availability of some resources network connection or browser plug ins for example The model we strongly advocate for building Web ap plications is a compiled language with static type checking and dynamic generation of URLs from abstract services The language must provide some way to define these services either using a specific keyword or just through a function call Once we have this notion we can completely forget the old page based view of the Web where one URL was supposed to be associated to one file on the hard disk Thus it is possible to gain a lot of freedom in the organization and modularity of the code and also as we will see later in the way services are associated to URLs One of the goals of next section is precisely to discuss service identification and selection that is how services are chosen by the server from the hi
33. key a function and its environment which contains all the data needed by the service The cost in terms of memory or disk space consumption is about the same as with usual Web programming no copy of the stack one instance of the data plus one pointer to the code of the function An alternative approach 2 21 22 is to serialize the closures and send them to the client Either we serialize the environment and a pointer to the function or even the environment and the full code of the function This has the advantage that no space is required on the server to save the closures But serializing functions is not easy and this solution may require sending large amounts of data to the client with potentially several copies of some state information Obviously security issues must be considered as the server is executing code sent by the client C Finding the right service The very few experimental frameworks which are proposing some kind of dynamic services impose usually too much rigidity in the way they handle URLs This section is devoted to showing how it is possible to define a notion of service identification that keeps all the possibilities described in Sec tion II The important thing to take care of is how to do the association between a request and a service For example if the service is associated to an URL where in this URL is the service to be called encoded To make this as powerful as possible we propose to d
34. mantical errors and bad practices The principles we advocate are summarized here 1 Services as first class values 2 Decoding and verification of parameters done by the server 3 Dynamic creation of services 4 Full taxonomy of services for precise service identifi cation 5 Same language on server and client sides 6 Symmetry between local and distant services One of the main novel feature is the powerful service iden tification mechanism performed automatically by the server It introduces the notion of coservice which make the program ming of sophisticated Web interaction very easy Beyond just presenting a new Web programming model this paper defines a new vocabulary for describing the behaviour of Web sites on a semantic basis It is a first step towards a formalization of Web interaction We started from an analysis of existing Web sites and we extracted from this observation the underlying concepts trying to move away as much as possible from non essential technical details This allowed a better understanding of the important notions but above all to bring to light some new concepts that were hidden by technical details or historical habits The main feature that allowed this is the introduction of dynamic services and also forgetting the traditional page based Web programming There exist very few frameworks with these features and none is going as far as we do especially in the management of URLs Besides the gain
35. me data for one user and recover it each time the user comes back A Technical remainder From a technical point of view sessions are not so easy to implement due to the fact that the HTTP protocol is stateless on the applicative layer once a request is fulfilled the connexion is usually closed There are several ways to get around this limitation One possibility is to send all the data to the user But this does not have exactly the semantics we expect for sessions Indeed several browser tabs opened on the same site will have different versions of the state which is not what we want The nature of a state being to be unique it is supposed to be kept in one place and the only simple solution is to keep it server side Therefore there must be one way to identify the user to get back her data This is done by asking the browser to send one session identifier at each request Two techniques are used for that either you put the session identifier in each link and form of the site or you ask the browser to send it at each request using cookies But only the second solution has exactly the semantics we expect for sessions Using the first solution leads to incompatibilities between tabs for example if you log in from one tab and return to another tab opened on the same site B Session data and session services Opening a session on server side may be done transparently when the Web site decides to register some data for one user
36. mplemented Instead of speaking about POST or GET parameters we prefer the orthogonal notions of service calls and URL change It is particularly important to forget the technical details if we want to keep the symmetry between server and client side services Calling a local javascript for example function is similar to sending POST data to a server if it does not explicitly change the URL displayed by the browser Semantically speaking in modern Web programming tools changing the URL has no relation with calling a service It is possible to call a service without changing the URL because it is a local service or because the call uses POST parameters On the contrary changing the URL may be done without calling a service There is only one reason to change the URL give the user a new entry point to the Web site to which he can come back when he wants to ask the same service once again for example by saving it in a bookmark To keep the full generality that is necessary for program ming it is important to understand that the notions of URL change and service call are completely disconnected It is possible to change the URL by a call to a javascript DOM function without calling a service This changes the entry point of the Web site just the page one will turn back to if a bookmark is registered On the contrary it is possible to all a service without changing the URL either a distant service through POST parameters or a local
37. n of services But despite these limitations our implementation is very close to the model we presented in the paper and it is a huge step forwards in the implementation of robust Web applications This paper is not a full presentation of Ocsigen Many aspects have been hidden and especially how we program the client side part of the application 8 9 40 using the same language and with the same strong static guarantees As we have seen our notions of services also apply to client side functions Obviously we are using the same typing system for services but also for HTML It is not easy to guarantee that a page will remain valid if it can evolve over time 41 We did not show how the server can send data to the client at any time or even call a function on client side We are currently working on extending our service model to multi tiers architecture when more than two pairs are interacting On a more theoretical point of view we are working on a formal description of our services ACKNOWLEDGMENT Many acknowledgements are due to Jean Vincent Loddo J r me Vouillon and all the people who took part in Ocsi gen development I also want to thank Russ Harmer Boris Yakobowski and Yann R gis Gianas for their helpful remarks about this paper and Dario Teixeira for the idea of session groups 1 8 10 11 12 13 14 15 16 17 18 19 20 21 22 REFERENCES V Balat Rethinking tr
38. ns on non attached services as primary notions even if all the notions can obviously be simulated 2 Example cases We have already seen some examples of dynamic service creation if a user creates a blog in a subdirectory of his or her personal site one possibility is to add dynamically a hierarchical service to the right path and it must be recreated every time the serser is relaunched If we want to display the result of a search for example plane ticket booking we will create dynamically a new anonymous coservice hidden or not probably with a timeout Without dynamic services we would need to save manually the search keyword or the result list in a table Coservices are not always dynamic Suppose we want a link towards the main page of the site that will close the session We will use a named hidden attached coservice named so that the coservice key is always the same We will now give an example where non attached hidden coservices allow to reduce significantly the number of lines of code Consider a site with several pages Each page has a connected version and a non connected version and we want a connection box on each non connected page But we do not want the connection box to change the URL We just want to log in and stay on the same URL in connected version Without non attached services and thus with almost all Web programming tools we need to create a version with POST parameters of each of our hierarchical ser
39. nting such kinds of session one must be very careful about the duration of sessions and timeout for services If you want your sessions to survive a restarting of the server you need a way to serialize data for session data and closures for session services D Session names and session groups To make the session system more powerful we may want to add two more notions namely session names and session groups Naming sessions allows to use several sessions in the same site Think for example about one site that allows some features for non connected users which requires some private coservices to be created If the user logs in this opens a new session but must not close the previous one To avoid that we use another session by specifying another session name Technically speaking session naming can be implemented by recording the name of the session in the cookie name The idea of session groups is complementary to that of the session name While session naming allows for a single session to have multiple buckets of data associated with it session grouping allows multiple sessions to be referenced together For most uses the session group is the user name It allows to implement features like close all sessions for one user even those opened on other browsers or to limit the number of sessions one user may open at the same time for security reasons As we have session data end session services it is possible to cr
40. on of Web interaction should not omit any of these items in order not to restrict the freedom of the programmer All these items are described semantically not technically A The role of URLs The item Changing the URL above is a really significant one and is one key to understand the behaviour of Web applications This section is devoted to the understanding of that notion URLs are entry points to the Web site Changing the URL semantically means giving the possibility to the user to turn back to this point of interaction later for example through bookmarks Note that unlike many Web sites a good practice is to keep the URL as readable as possible because it is an information visible to users that may be typed manually 1 Forgetting technical details about URLs The syntax of URLs is described by the Internet standard STD 66 and RFC 3986 and is summarized a bit simplified here scheme user pwd host port path query fragment The path traditionally describes a file in the tree structure of a file system But this view is too restrictive Actually the path describes the hierarchical part of the URL This is a way to divide a Web site into several sections and subsections The query string syntax is commonly organized as a se quence of key value pairs separated by a semicolon or an am persand e g keyl valuel amp key2 value2 amp key3 value3 This is the part of the URL that is not hierarchical To a first approxim
41. p hal archives ouvertes fr hal 0069403 1 J Vouillon and V Balat From bytecode to javascript the js_of_ocaml compiler Journal of Software Practice and Experience 2013 Ruby on rails http www rubyonrails com A Frisch Ocaml xduce in Proceedings of the international confer ence on Functional programming ICFP ACM 2006 pp 192 200 V Benzaken G Castagna and A Frisch CDuce An XML centric general purpose language in Proceedings of the International Confer ence on Functional Programming ICFP 2003 pp 51 63 H Hosoya and B C Pierce XDuce A statically typed XML process ing language ACM Transactions on Internet Technology vol 3 no 2 May 2003 pp 117 148 C Queinnec The influence of browsers on evaluators or continuations to program web servers in International conference on Functional programming ICFP 2000 C Queinnec Continuations and web servers Higher Order and Sym bolic Computation Dec 2004 C Queinnec Inverting back the inversion of control or continuations versus page centric programming ACM SIGPLAN Notices vol 38 no 2 Feb 2003 J Hughes Generalising monads to arrows Science of Computer Programming vol 37 no 1 3 2000 pp 67 111 Online Available citeseer ist psu edu hughes98 generalising html P Graham Beating the averages http www paulgraham com avg html S Ducasse A Lienhard and L
42. ropose is fully compatible with this kind of applications Keywords Typing Web interaction Functional Web program ming Continuations I INTRODUCTION Nowadays Web sites behave more and more like real applications with a high level of interactivity on both the server and client sides For this reason they deserve well designed programming tools with features like high level code structuring and static typing These tools must take into account the specificities of that kind of application One of these specificities is the division of the interface into pages connected to each other by links These pages are usually associated to URLs which one can bookmark It is also possible to turn back to one page using the back button This makes the dynamics of the interface completely different from a regular application Another specificity is that this kind of applications is highly dependent on standards as they will be executed on various platforms Web programming covers a wide range of fields from database to networking The ambition of this paper is not to address them all nor to deal with the full generality of service oriented computing We concentrate on what we will call Web interaction that is the interaction between a user and a Work partially supported by the French national research agency ANR PWD project grant ANR 09 EMER 009 01 and performed at the IRILL center for Free Software Research and Innovation in Paris Fran
43. ther XML types just from a DTD Furthermore it allows to parse and transform easily incoming XML data The drawback is that is not part of the standard OCaml compiler As an alternative we are using a second typing method based on OCaml s polymorphic variants see 27 used as phantom types 23 This technique is not new as we use an implementation due to Thorsten Ohl which is also distributed as a distinct library We are aware of another very similar implementation used by Alain Frisch for the Bedouin project 28 It is less strict than OCamlduce for the validation of pages as it only checks the correct nesting of XML tags for example it is not possible to put a lt div gt tag inside a lt em gt tag There also a way to check the presence of mandatory tags See 26 for more information about that technique Both typing techniques have shown to be very helpful and relieves the programmer from thinking about validation of her pages B Defining services 1 Creation and registration of services Creating a new service means two things first filling a data structure with all the information about the service that will be used to create forms and links towards this service and registering in a table the handling function implementing the service In Eliom these two operations have been disconnected You first create the service then register a function on it This may be considered dangerous as some services may be
44. ts parameters have necessarily been added later The last ambiguous case is when we want to use a hidden non attached coservice when we already have non attached parameters in the URL We may want to keep them or not The programmer must choose the behaviour he wants himself when defining the service IV TYPING WEB INTERACTION A Typing service parameters Another advantage to our way of building Web sites is that it becomes possible to perform more static checking on the site and thus avoid lots of mistakes We have already seen that some very strong guarantees no broken links are ensured just by the abstraction of the notion of services and links But static types can help us to make things even safer When defining a service it is easy to add type information to each parameter This has three advantages e The server will be able to dynamically convert the data it receives into the type expected by the service and also check that the data corresponds to what is expected which saves a lot of time while writing the service e It is possible to check statically the types of parameters given to the links we create towards the services e It is also possible to do some static verification of forms see next section It should also be possible to use type inference to avoid declaring manually the types of parameters On first sight the type system for services parameters seems rather poor But declaring basic types like string
45. ur service identification mechanism and this has a huge impact on expressiveness as we will see on example in Section III D2 From a semantic point of view the difference is that hierarchical services are the entry points of the site They must last forever whereas coservices may have a timeout and one probably want to use the associated main service as fallback when the coservice has expired We will distinguish between named coservices and anony mous coservices the difference being the value of the special parameter Named coservices have a fixed parameter value the name of the coservice whereas this value is generated automatically for anonymous coservice Like all other services coservices may take parameters that will be added to the URL There must be a way to distinguish between parameters for this coservice and parameters of the original service This can be done by adding automatically a prefix to coservice parameters 3 Attached and non attached coservices We will also distinguish between coservices attached to a path and non attached coservices The key for finding an attached coservice is the path completed by a special parameter whereas non attached coservices are associated to a parameter whatever the path in the URL This feature is not so common and we will see in Section IN D2 how powerful it is 4 Distant hidden services A distant service is said to be hidden when it depends on POST data sent by the browser
46. vices and rather tricky with traditional Web programming Witness the huge number of Web sites which do not implement this correctly If we want to implement such behaviour without dynamic services we will need to save somewhere all the data the service depends on One possibility is to put all this data in the link as parameters or in hidden form data Another possibility for example if the amount of data is prohibitive is to save it on the server for example in a database table and send only the key in the link With dynamic service creation all this contextual data is recorded automatically in the environment of the closure implementing the service This closure is created dynamically according to some dynamic data recording the past of the interaction with the user It requires a functional language to be implemented easily 2 Continuations This feature is equivalent to what is known as continuation based Web programming This technique was first described independently by Christian Queinnec 14 15 16 John Hughes 17 and Paul Graham 18 There are basically two ways to implement dynamic ser vices The first described as continuation based Web program ming consists of viewing the sending of a Web page by the server as a function call a question asked of the user that will return for example the values of a form or a link pressed The problem is that we never know in advance to which question the user is answer
47. vices to take into account the fact that each URL may be called with user credentials as POST parameters Using our set of services we just need to define only one non attached hidden coservice for the connection At first sight that service only performs an action as defined in Section III A saving user information in a session table But we probably want to return a new page connected version of the same page This can be done easily by returning a redirection to the same URL Another solution if we do not want to pay the cost of a redirection is to define a new kind of output action with redisplay that will perform the action then make an internal server side request as if the browser had done the redirection The solution with redirection has one advantage the browser would not try to resend POST data if the user reloads the page Now say for example that we want to implement a wiki where each editable box may occur on several pages Clicking on the edit button goes to a page with an edit form and submitting the form must turn back to the original page One dirty solution would be to send the original URL as hidden parameter in the edit link But there is now a simpler solution Hierarchical Services attached non attached k ve o5 f 5 named anonymous J named anonymous SS es SS ee es ey Action with redisplay Act itl display Coservices Figure 1 Full taxonomy of services just do not change the p
48. xpected by the service it points to e Does a form match the service it points to e Do we have broken links It is not so difficult to have these guarantees even if almost no Web programming framework are doing so now All what is needed is a programming language expressive enough in the sense we explained above Improving the ergonomics of Web sites Lots of Web devel opers are doing implementation errors resulting in reduced ease of use wrong use of sessions or GET and POST parameters etc Take as example a famous real estate Web site that allows to browse through the results of a search but if someone sets a bookmark on one of the result pages he never goes back to the same page because the URL does not refer to the advertisement itself but to the rank in the search We will see that a good understanding of concepts can avoid such common errors C Overview of the paper Sections II and II are devoted to the definition of our vernacular language for describing the services provided by a Web application Section II explains the advantage of using an abstract notion of service instead of old fashioned page based programming and string URLs Section III presents a new service identification and selection method It shows how powerful this notion of service can be made by separating it into several kinds This results in a very new programming style for Web interaction Section IV explains how to ensure correct use of these
49. y of Web applications As Web sites are currently evolving very quickly into com plex distributed applications the use of strongly and statically typed programming languages for the Web becomes more and more helpful Using scripting languages was acceptable when there was very little dynamic behaviour in Web pages but current Web sites written with such languages are proving to be very difficult to evolve and maintain Some frameworks are counterbalancing their weaknesses by doing a lot of automatic code generation for example 10 In the current state of knowledge we are able to do much better and Web programming must benefit from this Static validation of pages One example where static typing revolutionizes Web programming concerns the validation of pages Respecting W3C recommendations is the best way to ensure portability and accessibility of Web sites The novelty is that there now exist typing systems sophisticated enough to statically ensure a page s validity 11 12 13 Whereas the usual practice is to check the validity of pages once generated such typing systems make it possible to be sure that the program that builds the XML data will always generate something valid even in the most particular cases For example even if a programmer has checked all the pages of his site in a validator is he sure that the HTML table he creates dynamically will never be empty which is forbidden What if for some reason there is no
Download Pdf Manuals
Related Search