Shared Csla DataPortal Servers

razorkai posted on Wednesday, May 17, 2006

Hi folks.

If you have multiple applications (web & winforms) that share a common set of business objects then how do you deal with changes & bug fixes? Each website and winforms app will have its own copy of the businessobjects.dll, and the application server (remote dataportal) will also have a copy of the same dll. Now if I were to change one of the objects within the dll, e.g. change change some of the logic, would I then have to recompile each of the applications that share the remote dataportal or would the clients that have not been recompiled yet still be able to communicate ok with the server even if it has a newer revised copy of the businessobjects.dll? Hope that is clear. This is something we need a clear answer on as we often release small updates to our applications and it would be a real pain to have to release/update everything out of hours due to tight coupling between client and server.

TIA.

John.

Bayu replied on Wednesday, May 17, 2006

Hi,

This sounds like the often faced deployment challenges .... Smile [:)]

- to avoid recompilation of ALL your stuff, you could employ a plugin-like architecture like CAB supports, or have a look at one of these:
    - http://msdn.microsoft.com/library/?url=/library/en-us/dnaspp/html/pluginframework.asp?frame=true
- http://msdn.microsoft.com/msdnmag/issues/03/10/Plug-Ins/default.aspx
    - http://www.codeproject.com/csharp/RazorPt1.asp

I use CAB, which merely enforces a particular design to your winforms app as a whole, the plugin stuff is just one the issues solved by it. So I guess it's overkill for you, but for more info on CAB go to: http://www.gotdotnet.com/codegallery/codegallery.aspx?id=22f72167-af95-44ce-a6ca-f2eafbf2653c.

- using plugins avoids having to recompile and hence redeploy all your stuff, the modified assemblies will still need to be redeployed of course. Several solutions have been discussed at length at this (and the old) forum.
    - Click-once deployment was mentioned frequently, I have no experience with it myself, but do check out this show on dnrTV: http://www.dnrtv.com/default.aspx?showID=8.
    - The App Updater AB is one I have used to great satisfaction in several projects: http://www.gotdotnet.com/codegallery/codegallery.aspx?id=83c68646-befb-4586-ba9f-fdf1301902f5 , many tutorials on how to integrate this with your particular app are just one Google-search away

- one of the questions you asked was about having different versions of a dll on the client and server. I recall that this can work under some circumstances. I don't know the details, but I believe at least all object and member names should have stayed the same for reflection to succeed. With strong naming it is also possible to host multiple versions of a dll on the server at the same time so you can support different client versions from the same server ...... we didn't really like this idea though and felt this would turn messy. We simply update the server with the new dll and require all our clients to update their stuff before they are allowed access to the server again. When they boot the (older versioned) client app, it will recieve a message and an automatic download of the new assemblies is started. Part of this is custom-built, but it is quite similar in fashion to the App Updater AB.

This may sound a little 'enforcing' on the clients, but it does keep our stuff cleanly in sync. Actually, you see this scheme in many software, just think of MSN Messenger for example, the clients are forced to keep their software up-to-date .....

Hope to have answered some questions or at least have provided links to some additional information. Wink [;)]

Bayu

RockfordLhotka replied on Thursday, May 18, 2006

Security is (I think) the only valid reason for having an app server in a web application, and that sounds like what you are driving at.

However, you may want to consider Microsoft's recommendation instead, which is to use ISA Server as a reverse proxy between your web server and the outside world. This way your web server can run in a trusted environment, with ISA acting as the shield. In that scenario you may not need to have a physical application server at all - which is really nice.

Magenic has clients that are doing both: either using ISA server this way, or using a physical app server behind a second firewall. Both appear to be quite secure, but there's no doubt that using the app server has higher costs in terms of performance and complexity.

I've never thought that keeping code in sync across the web servers and app server was a very big deal - at least not in ASP.NET. There are many techniques for deployment of code out to a set of controlled servers.

Even if you want to avoid having to do a synchronized update (which might require taking the site offline momentarily), you can do a rolling update. This is true even with a remote data portal. To do this, you need to make sure your update scheme allows for you to change the data portal URL over time.

Consider that you are running a version, V1, on all servers, and your data portal URL is then http://appserver/V1/DataPortal.rem

Then you want to update to version V2, so you first create a new data portal URL: http://appserver/V2/DataPortal.rem

Now you can do a rolling update across your web server cluster/farm - updating each server to V2 in turn. As part of the update you not only update the business assemblies, but also web.config so the data portal knows to use the newly updated data portal

When the update is complete, you can remove the old data portal virtual root from the app server.

This entire process can (and should) be automated so it just ripples across your server farm by itself. Even minor updates become a non-issue if the process is automated.

Rocky

razorkai replied on Thursday, May 18, 2006

Rocky.

Security is exactly the reason why we are planning to implement the DMZ. Unfortuantely I have little say in this as our systems team decide on infrastructure. I believe ISA has already been investigated but I will check this with them. As for the suggested update strategy, I had a similar idea but wasn't sure how practical it was. Good to know it is workable. The only issue I can think of is the users currently using the websites. We are going to be using a SQL state database that our websites will use to track their state and store objects in temporarily. If an object gets persisted to state and then an upgrade to the server roles out then won't the user hit problems when their object gets recalled from state and is of an object type that gets tweaked by the upgrade?

John.

JCardina replied on Thursday, May 18, 2006

razorkai:

This is something we need a clear answer on as we often release small updates to our applications and it would be a real pain to have to release/update everything out of hours due to tight coupling between client and server.

For what it's worth we have 12 different applications that use the same business object library we built with CSLA and users may or may not be running any of the 12 together. 1 main one and 11 different utilties and add on programs.

What we do to avoid re-releasing everything when there is a small change to the business object library is we cheat. We don't change the version number of the business object library. Instead we have a "subversion" static property that we set in it so that users can check the version from within the apps in the about screen.

A *lot* of times in reality you will find that you need to make a very minor change to the business object which doesn't at all impact the other applications that rely on it, just an internal change to fix somehting it does on the inside. To change the version number for this would either break the ability of all the other apps to work with it without recompiling them or would require a lot of complex .net mumbo jumbo to be set to allow them to work with it.

It's not technically correct, what we do, but it's very practical when you have users all over the world with very little technical knowledge who just want it to work. You release a new business object library .dll, they install it overtop of the existing one and mission accomplished.

Of course as a project matures and changes are less and less frequent you can have the luxury of moving to the more accepted practices.