I must confess that the lack of posts on my blog are mainly due to a very silly reason, I started playing FarmVille on Facebook with my friends and it reminded me of my favorite game SimCity.
What I like most about the game is how it runs on an iframe, is able to send requests to all the FB friends and keeps the FB session alive even though I haven’t clicked outside of the FarmVille iframe in a long time. It’s not as sophisticated as SimCity, but lets’ wait till it evolves…
A few months ago I was evaluating web frameworks with several criteria. The main one was the ability to extend the web application without the need to recompile and deploy the existing modules.
There are two main concepts for applications in general that save up a great deal of time in testing and deploying (in maintenance in general)
Composite: Composition strategies determine how you manage
component dependencies and the interactions between
components.
Modularity: is designing a system that is divided into a set of functional units (named modules) that can be composed into a larger application. A module represents a set of related concerns. It can include components, such as views or business logic, and pieces of infrastructure, such as services for logging or authenticating users. Modules are independent of one another but can communicate with each other in a loosely coupled fashion.
The following are specific guidelines for developing a modular system:
- Modules should be opaque to the rest of the system and initialized through a well-known interface.
- Modules should not directly reference one another or the application that loaded them.
- Modules should use services to communicate with the application or with other modules.
- Modules should not be responsible for managing their dependencies. These dependencies should be provided externally, for example, through dependency injection.
- Modules should not rely on static methods that can inhibit testability.
- Modules should support being added and removed from the system in a pluggable fashion.
In an old post I was complaining about how in two of the ASP.NET frameworks that I was evaluating I couldn’t separate the modules that had an UI component and deploy them independently of the main application. I was mainly talking of WCSF and Spring.NET.
In WCSF, even though modules can be groups of MVP triads, the main web project still has to be modified each time a new module is added to the application as it contains the shared UI elements (aspx pages or ascx controls). When I tried the WCSF Modularity QuickStart I realized all of the web pages (aspx) are kept into the main web project and the rest of the projects are dlls without any visual part, only the interfaces to the views that are stored on the main web project (IViews.cs). To me, that couples the main web project with each module… It is not true modularity. See the description of the QuickStart here.
For Spring.NET the framework, as any DI framework, allows you to replace your BLL or DAL objects using configuration files as long as the implement the same contract (have the same interface), but there is no concept of module and no way to “plug in” a module containing aspx pages.
I spent some time looking into the Facebook API, after all, they do have a production implementation that complies with all the bullet points under Modularity (see above) During this “read and research” I came across two very good articles on cross browser communication:
Secure Cross-Domain Communication in the Browser by Danny Thorpe
and
Cross Domain Communication with IFrames on this blog.
Why jumping into Cross Browser Communication? Well, if I want to compose an application of different applications running on iframes I better read about Cross Browser Communication…
I decided to expose my ignorance and ask Danny Thorpe for advice, what the hell, he worked on the VCL, Windows Live, CoolIris <... and keep inserting cool projects here...>
I emailed him on FB:
…
I do like the idea of FB where an application hosted on a different domain can interact with the facebook user, facebook sends the auth key, session key and signature and the application calls the facebook servers to perform actions on that user, whether getting the list of friends, send notifications, upload pictures etc. All these actions take place in the application’s servers doing requests to the FB servers and updating the application page on the iFrame running on facebook.
I’ve been trying to move away from the idea, mostly based on the fact that an enterprise application would need to share context (session) between its different modules and that transactions involving several modules might be too difficult.
I’m basing my devil’s advocate argument on your article and trying to state that facebook applications can indeed leave the user’s data on facebook servers on an inconsistent state, due to the different sessions that are not shared.
…
and Danny Thorpe was kind enough to reply:
…
Facebook does offer server to server data sharing as you describe, but most Facebook applications actually use client-side cross domain communications using an independent implementation of the iframe cross-domain channel I described in the article. I haven’t studied the Facebook api closely, but I have been informed by folks who have that there is some client-side cross domain communications going on in there.
I agree that sharing user context between modules in different domains in an enterprise application is a scary prospect. I don’t think the issue is with maintaining consistent state as with simple security and privacy issues.
There are other ways to allow multiple applications/domains to access a shared user resource. Delegated authorization is one technique sprouting up from several vendors, including Microsoft. The idea is that app A can be granted access to the user data on server B by the end user without disclosing the user’s login credentials. Server B issues a unique opaque token to App A representing the permissions granted by the end user. The token is unique to the user and application but does not disclose the user’s identity. App A stores the token and can then make requests of server B with that token attached, and server B will look up the token to see what permissions it grants and to see if it has been revoked by the user. The user can revoke the token independently of App A at any time.
Delegated authorization gives the appearance of single-sign-on even across disparate services with incompatible authorization domains. The user has control of granting and revoking access to their information. Multiple applications can connect to the shared resource to monitor state changes, avoiding the issue of inconsistent state.
…
In order to keep the look and feel of the different applications that compose a portal, I would have to share a site map, the ability to create a unique profile of the user and the look and feel or CSS of the different applications.
Now I’m facing the fork on the path:
- iFrames with cross domain communication to compose a portal with modules
- SSO and shared SiteMap and Profile API along with consistent design and CSS to glue the different modules.
more ramblings to follow…
L.