Fitz has a post about WSRP (Web Services for Remote Portlets, e.g. Web Parts).
Clippings of Fitz quick Tablet PC sketches
Wikipedia definition of WSRP
In the last month I've actively discussed WSRP concepts with at least two customers. The first has a non-SharePoint portal and was motivated by the quick reuse of IFRAME-ing an ASPX page (both UI and code-behind/beside) in both portal products. They have many ASPX developers, feel comfortable with this infrastructure, like the fact that the solution (page) can be tested apart from SharePoint, and will likely pursue this option. The other customer was keenly interested to understand what WSRP was all about.
Also recently, I have been coding AJAX “shell” Web Parts using out-of-band AJAX-like (or eventually ATLAS) calls to a self-contained Web Services layer (I'll blog about it here in Q2/2006). I like this because I don’t have the postback and state management required in a traditional Web Part which is critical to the success of my application. Also, everything the Web Part is dependant upon is entirely contained within the Web Part’s deployment CAB (wppackage).
However, one of the reasons the aforementioned customer wanted to use ASPX pages rather than Web Services (ASMX) had to do with the location of the UI code. Traditionally this customer generates their UI in an ASPX page containing server controls or user controls (ASCX) calling business logic in a component (code-behind/beside, ASMX, COM+, etc.). In Web Parts, we traditionally generate the UI from within a WebPart class using server controls or user controls (ASCX) and call business logic in a component (Web Part assembly, ASMX, COM+, etc.)
But in the WSRP model Fitz describes and in AJAX “shell” Web Parts I'm creating, the UI can often come directly from the Web Service (ASMX) itself. The Web Part effectively becomes a placeholder (DIV) that the user can position on any Web Part page. It knows how to load the UI it receives from the Web Service into its innerHTML attribute. This way, each portal need not have UI logic to consistently recreate that UI. Fitz mentioned consuming the XML from within the DVWP so I realize that isn’t necessarily an accurate depiction of his post but humor me...
My question is this, “Which is inherently better design?“
1) Using an IFRAME within a Web Part to host an ASPX page.
2) Using the Web Part’s own DIV as the placeholder for HTML returned from a Web Service (ASMX) call.
For the sake of argument, let’s assume that either could be dynamically changed without a full Page postback and that the hosted UI (ASPX and ASMX) are provided in another Web Site, excluded managed path, or embedded as a Web Part class resource (my preference).
These two approaches achieve the same goal but are architecturally very different. I’m certain that the pros and cons go much deeper than the points I’ve made in this post. I wonder which approach WSRP would favor. Let me know your thoughts.
At any rate, we’ve got a whole new breed of .NET Framework 1.1 SharePoint Web Parts running on our SPPT 2003 platform to contend with.
<Todd />