WCSF falling short on composing web applications?

I’m right now looking for options on composing web applications. I recently took part of an interesting project with the composite application block framework (CAB) developed by the patterns and practices team and am certainly looking for the web equivalent. That been said I should add I have a great deal of frustration now.

I had been subscribed to several discussion threads at Codeplex for the web composite application block and WCSF. At the moment of writing this post codeplex.com is down (it has been down for about 2 hours now at 4.18 PM EST) and southworks.net is down too.

SouthWorks.net is the company that has more developers maintaining these application blocks, afaik, and they also moderate most of the codeplex threads.

After reading about the road map of the Composite Web Applications I tried out the QuickStarts for the WCSF hoping to find the web equivalent of CAB or Prism.

My team has a couple of “legacy” web asp.net applications that were migrated to asp.net 2.0 two years ago.

We were looking for a framework that would serve as a skeleton for composing web solutions.

IoC containers such as Spring.NET allow composability at object level, but it’s cumbersome to have all the objects that you’ll inject into your main application defined in a main configuration file. *this is as far as what i’ve seen* And we wanted to be able to use existing applications with a minimum of re-write (maybe some style changes).

That’s why modules might be a better choice of dividing and composing applications. Each module could have it’s own set of configurable objects, it’s own configuration file and it’s own UI and would communicate with other modules through an event broker mechanism and would consume information presented by the services registered or published by the shell…

WSCF appeared to be the answer, until after we tried the QuickStarts.

The modules do not have a UI at all, the UI is defined in the main web application (web project) where the web.config file resides. The modules are merely a group of business objects and presenters. I don’t think the modules are loosely coupled at all, as the view is defined in the main application (web project) and the name of the view or web form is also declared in the sub module.

I might be very biased by the architectural design of Facebook, but composability in that case means, you can host *any* application on your main *shell* and this application will consume services to communicate with the main shell, using encryption with a key provided at the time the application is registered.

…they surely share session…

Why WSCF falls so short on this?

My real world problem: I would like to integrate the existing web applications into a new shell with minimum changes. These legacy applications are now on different virtual directory and run on different appdomains. They do share a single sign on implemented as shown here:
http://forums.asp.net/p/1023838/1390821.aspx
but there is no shared session.

These web applications although might be considered legacy, are fully functional and have been tested. Rewriting them would cause more pain that help the business.

It seems that if the team goes for WCSF we will have to end up rewriting these application into WCSF modules and moving all the webforms and user controls to the web project as oppose to do small modifications to integrate them into a true composable shell. This would be extremely painful.

I’m still looking and to be honest, I’m kind of lost, it must be it is Friday afternoon. Any comments or suggestions would be more than welcome…

Thanks!