4 Tier Deployment with Silverlight and XBAPs

Anthony posted on Monday, October 12, 2009

We are currently working on an application built primarily on Csla Light with a 4 tier deployement where we have a need to also have some XBAPs for portions of the application. Given the security scenarios we are going to encounter on deployement it is our expectation that there will be no avoiding the 4-tier deployment however the XBAP applications do not work with that model. I have the entire structure set up and working fine for all silverlight requests, however if I point the XBAP to the web server data portal it does not attempt to forward the request to the second application server like the silverlight data portal does. I have looked at the Csla code and it would appear that silverlight data portal has code which performs this task by reading the config file to check for the proxy that should be used much like Csla does on the original client, however the .NET version of Csla does not have the code to access a proxy and instead just attempts to operate directly on the web tier, which will not work. I have searched the forums and the only comments I have found about this set-up are several years old at this point so I am wondering if I have missed something where Csla.NET does support this proxy scenario or if I will have to write the support myself. It surprised me to find that this support was there for the silverlight side and not for the .NET side. Is there an easier way than writing a new server side data portal with proxying support to do this?

RockfordLhotka replied on Monday, October 12, 2009

There is no pre-built data portal router for CSLA .NET for Windows. Interestingly, you are the second person to bring this up in about a week - after no one bringing up such a requirement for a couple years. It just isn't that common to want a 4-tier model with a Windows-based smart client I guess.

The answer I'll give you is the same one I gave a few years ago the last time this came up - just create your own data portal host that delegates each inbound call to the data portal (which will follow normal routing rules). This is all the Silverlight data portal does - though it uses a different endpoint contract from the standard WcfHost because the Silverlight data messages are not in the same format.

If you are using WCF this is pretty darn easy, because all your host needs to do is implement the pre-defined IWcfPortal contract and it will be compatible with existing WcfProxy code. If you are not using WCF, now might be a great time to upgrade :)

Anthony replied on Monday, October 12, 2009

Thanks for the confirmation. We are already using WCF so this won't be an issue I just wanted to make sure I wasn't missing something before going ahead and adding the extra router.

I can certainly see how it would be uncommon to use the smart client apps across a 4-tier deployment, so as an FYI the reason we are doing it is because 99% of the application is a web app with the intended host platform being sharepoint. The other 1% of the app requires system level access for sockets etc. that would not be possible to do through standard web applications, so in order to provide the "illusion" that it is still in the web app these portions of the application are in a full trust XBAP. The net result is that we don't know where the user may be accessing the smart client features from due to the nature of the web and therefore have to provide for the possibility of access from outside the corporate network.

ctiu replied on Tuesday, February 08, 2011

Thank you very much for this tip Rocky! 

I have a 4-tier model (Database <-> AppServer <-> [Firewall] <-> External-Facing WebApp <-> WinApp).

In deed, the solution was easy enough to implement a custom data portal host using the IWcfPortal interface.

Why WinApp, you might ask?  Because I have a deadline and I am much more comfortable using the Windows third-party controls than what's available for Silverlight.  Eventually, though, the goal is to deploy a Silverlight UI.