Server architecture for browser based client

pokorra

This is not an urgent issue, but I just want to document the results from my investigations of the last couple of days.

I have looked at http://ext.net, which combines the AJAX framework extjs from Sencha nicely with .net.

The problem I have come across is this: with ASP.net, all clients connect to the same appdomain, and therefore all static (ie. global) variables are shared. This is a problem for us, because we make use of several global variables, for example DBAccess.GDBAccessObj for the connection to the database, UserInfo.GUserInfo for the current user, DomainManager.GSiteKey and DomainManager.GSystemDefaultsCache to name a few.

It would probably be possible to start an appdomain for each user, ie. each session, but it would be quite difficult to call functions inside that appdomain, and to return the results.

So my next idea was to embed the Ict.Petra.Client.App.Core classes into the ASP.net webserver, and to establish a remote connection for each session with the normal OpenPetra server. I would have to work around some global variables too, eg. TRemote, but it would be less complicated. The problem for this was that the call to RemotingConfiguration.Configure is a static call, and you get a RemotingException for the second user, telling that the TCP port is already in use. So it is not possible to have several connections from the ASP server to the OpenPetra server.

Now my next attempt is to change the UserInfo.GUserInfo to a method call, so that it returns the value of the static variable for the usual Client/Server setup, but will return the user information of the current session for the scenario of the ASP server.

I am still thinking if I will not get into trouble using just one Database connection, with transactions overlapping, so I guess I will need to change DB.GDBAccessObj as well.

I hope we can have a simple interface for the ASP pages to access the server functions of OpenPetra.

I will need this for maintaining online the Teenstreet applications for OM Germany and other offices.

christiankatict

Hi Timo,

regarding embedding the Ict.Petra.Client.App.Core Class into the ASP.net server and the Port re-use problem: you could try to use the string '<channel ref="tcp" port="0">' instead of '<channel ref="tcp">' in the Client config file. This should tell .NET Remoting to choose a random, free port. I am not sure whether it will work when hosted inside IIS, but you could at least try.
If it doesn't work (which I almost assume...), then the next option would be to manually configure .NET Remoting inside the Ict.Petra.Client.App.Core Class instead of calling Remoting.Configure. The manual way is more controlled, and you could give the Port property a different value manually for each 'Client' inside an IIS. The manual way ignores any remoting settings in the config file, so if you would want to pick up some settings, but e.g. not the Port setting from the config file then you would need to read them out of the config file yourselves (it's just an XML file anyways) and pass in the values in the individual Method calls that set up .NET Remoting.

In my opinion all ASP.NET Clients should really connect to individual AppDomains in the PetraServer, however we are planning on achieving that. The reasons for that are: security (data can never be shared or leaked across clients), stability (Unhandled Exception in a Client's AppDomain cannot affect other Clients), and similarity of model to the 'normal' PetraClient-PetraServer scenario that we have with non-ASP.net clients (one AppDomain per user, one DB connection per user, only one DB Transaction at any given time per Client).