User: Developer


- not applicable


Explanation of caching for websites and webservices



When Futurama runs in WebSite or WebService mode it is possible to declare settings for the caching of information in the futuramaSettings part of the configuration-file (web.config). In this page the use and impact of caching is explained in detail for both websites as well as webservices.

Caching: Websites

What happens when someone opens a Futurama website?

When a website is opened a so-called session is opened. A session can be considered as a dialogue between the user and the website and normally lasts until the user either closes the website or if a time-out occurs. Every action the user makes (e.g. clicking a button) or input he enters during the session is stored for the duration of the session. For every session that is opened the Futurama Engine has to load the Futurama Document for this session into the memory of the server. Depending on the size of the document this takes up to a second. To avoid delays when dealing with large numbers of users that open the website at the same time, Futurama is able to store a number of documents in the memory of the server (the cache) to make sure these are readily available when new sessions are opened. The 'enabled' attribute of the cache element in the web.config determines how many documents can be loaded into the cache. Note however that for every document in the cache memory is needed on the server. How much ultimately depends on the size of the document.

The above implies there is a trade-off between the desired speed it takes to open a session (the more documents in the cache the faster this is) and the amount of memory that is required to store the documents (the more documents the more memory is needed).

How does Futurama handle multiple users opening the same website?

When multiple users open the same website around the same time, it is important that the actions of one user do not affect the session of another. To make sure this doesn’t happen, Futurama can make use of either sessionIDs or cookies.  When making use of cookies the session information is stored in a cookie, whereas if not it is encrypted in the URL. See for an example of the latter the intriguing code between 'futurama' and 'default' in the following URL: http://localhost/futurama/(S(hhgvn45t2w4f53tzxeyhl2d1))/default.aspx?Folder=planner. Whether sessionIDs or cookies are used is defined in the setting 'SessionState' in the web.config. See this page for more information about the difference between cookies and sessions. 

The use of sessionIDs and cookies makes every session unique and therefore the state of every session can be stored and the actions of the user remembered.

Caching: Webservices

Webservices work in quite a different way than websites. When a request to a webservice is done, a number of parameters will be given in this request to the webservice. The value of these parameters will be used to make calculations, execute actions or perform some other operation(s). The result is then given back to the source that initiated the call and that’s basically it. The webservice 'forgets' what it just did and does not store any information about the parameters or the results. In other words, webservices are stateless. Therefore when the webservice is requested again, the webservice treats it like a new request and will therefore need to load the document again and perform all operations, actions, calculations etc. even when the parameters are exactly the same.

Obviously this takes a lot of time. It is, however, possible to use caching. This will significantly improve the speed with which the webservice will return an answer. Caching for webservices is different from caching for websites, as described above. If caching is used the input of the webservice and the Futurama-document that was loaded into memory by the webservice are being stored into the memory. When the next call takes place, only the differences in the input will be processed. When the differences are small, this can mean a huge saving in time because many calculations, actions and operations do not have to be executed again. Note: pay attention to the situation where the value of UserVariables are set by the webservice call. Make sure that all the Uservariables that potentially can be set will be reset after each webservice call. This to prevent that a UserVariable that is set in a previous webservice request still has his value in the request after. 

Whether or not to use caching for webservices can be stated in the enabled attribute of the cache element which is located in the web.config. Furthermore, the expirationInMinutes attribute of the cache element is then used as well. This setting determines after how many minutes after the last call the caching has to be terminated. The latest stored Futurama document is then removed.


To show what happens when more than one user request the same webservice, an example project is created. This project contains a webservice to which a parameter is passed after which it writes a number of pdfs to a directory. The value of the parameter determines to which directory the pdfs are written and the value is also included in the name of every pdf.


  • A working installation of Futurama Webservice Version or later. Here we assume this directory is called "FuturamaWebservice".
  • An installation of SOAPUI to test webservices. This can be downloaded for free here. This example will not cover how to work with SOAPUI. For more information about it's features and tutorials we refer to the SOAPUI website.

Installing the project

  • Download the zip-file containing the project here. This zip-file contains a directory "WSDocConverter" and a web.config file.
  • Copy the directory "WSDocConverter" and the web.config to the Futurama Webservice directory "FuturamaWebservice".
  • Make sure the application has write-rights on the subdirectory "test" in "WSDocConverter". This is necessary because the webservice will write documents to file.
  • Open the web.config and check the key "BaseDir". This represents the path to the directory we just copied. Alter it according to your local situation if necessary.
  • Open a webbrowser and type in the address-bar the URL to the file service.svc which is located in "FuturamaWebservice". For example http://localhost/futuramawebservice/service.svc. A screen will appear stating that you have created a service. Leave this screen open.
  • Open SOAPUI.
  • Click on File | Import Project. Open the project TestWebservices-soapui-project.xml which is located in the subdirectory "test" in "WSDocConverter".
  • Select BasicHttpBinding_IService and do a rightclick. Select Update Definition.
  • In the field Definition URL we need to specify the correct URL. Open the screen from step 5 and copy the URL that appears in the top green box.
  • Paste the URL in the field Definition URL and select the checkboxes Create New Requests and Recreate Requests. Click OK.
  • A dialoguebox will pop up asking if you want to update existing requests with new endpoint. Click Yes.
  • Select TestSuite | TestDocumentVersion | Test Steps (1) | Test Request and do a rightclick. Select Open Editor.
  • Make sure the URL strokes with the one we copied and pasted earlier.
  • Make a call to the webservice by pressing the green triangular "play"-button in the toolbar. The response appears after a short while in the screen to the right. It should give the answer 1.

Testing with cache turned off.

By default in the web.config the attribute 'enabled' of the cache element is set to False. This implies no caching is used. This we will test first.

  • Select TestSuite | TestDocConverterWS | Test Steps (2) | Test Request1 and open the Editor.
  • Open also the Editor for Test Request2.
  • Open two Windows Explorers. Set one to show the contents of “…\WSDocConverter\test\Destination V1\” and one to show the contents of “…\WSDocConverter\test\Destination V2\”.
  • Run Test Request1 and after 5 seconds Test Request2.
  • In the Windows Explorer it can be seen that the directories “Destination V1” en “Destination V2” are being filled with documents. It can also be seen that documents with V1 in the name are placed in directory “Destination V1” and documents with V2 in the name are placed in directory “Destination V2”.
  • When Test Request1 is finished it can be seen that 31 documents are created. SOAPUI will show a result message in the Editor stating “Version: 1 and returnvalue: 1 and number of generated pdfs: 31”. The Version returns the value of the parameter that was used in input, so the value of ‘1’ is correct indeed. The returnvalue is a variable in the webservice that is raised by one on the moment the session starts. The value of 1 implies that we started with a ‘clean’ session in which the initial value was 0. Furthermore the number of generated documents is returned which is, unsurprisingly, 31. Analogous for Test Request2 the resulting message states “Version: 2 and returnvalue: 1 and number of generated pdfs: 31”.

We can therefore see that with the cache turned off, every call gets it’s own ‘clean’ session and both sessions run completely independant of each other. The actions done in one session do not interfere with the other.

Testing with cache turned on.

We will now show what happens if caching is turned on when asynchronous calls are made.

  • Open the web.config and change the value of the attribute 'enabled' of the cache element to True. Save the file.
  • Empty the directories “…\WSDocConverter\test\Destination V1\” and “…\WSDocConverter\test\Destination V2\”.
  • Open “…\WSDocConverter\test\Destination V1\” and run Test Request1. The documents are seen being created.
  • After 5 seconds start Test Request2. It can be seen that no documents are created in “Destination V1” any longer. In “Destination V2” however all 31 documents are created.
  • In the result messages of both requests can be read “Version: 2”, indicating that the original parameter of Test Request1 was overwritten by the one of Test Request2.
  • Furthermore it can be seen that the session of Test Request2 was not a new one, but the session started by Test Request1. This can be seen from the returnvalue which is 2 meaning that the session of Test Request1 raised it to 1, after which the session of Test Request2 took over and raised it to 2.
  • The same conclusion can finally be drawn from the number of generated PDFs which are above 31 indicating that the second session took over the session from the first request.

We can therefore see that at the moment Test Request2 is started, it overwrites the parameter of the session started by Test Request1. This session does not stop however, but continues using the new parameter. This can seen from the result messages, which both return Version: 2.


If you have any questions about this subject or if you want to provide us feedback please send us an e-mail.

Updated: 2014-07-22