Archives / 2004 / February
  • Delivering presentation over Web Services with WSRP

    I recently was asked to talk about the possibilities of implementing a WSRP consumer on the .NET platform. And suprisingly, it has very little to do with Web Services Routing Protocol.

    "Web Services for Remote Portlets" is the OASIS specification name and it's all about delivering presentation instead of data over web services. At first the thought of delivering html over WS sounded weird to me. Isn't this just like screenscraping. And secondly, aren't "Portlets" strictly a Java thing?

    Well, no and no. The specification uses the term portlet, but is completely based on common standards like XML, WSDL, UDDI and Schema. Java did have an advantage though, as the JSR 168 specification was developed in close cooperation with WSRP. So, by now you've probably guessed what it does: WSRP allows you to publish a local portlet remotely with web services. This means that a user in a portal could have a portlet that is running on another portal directly accessible in his view.When delivering data over webservices you are always dependant on some kind of receiving transformation to make it availible for end users. Some services are only meant for presentation and should be delivered this way.

    I have had this post on hold for a while because I felt iffy about the whole concept of doing synchronous calls on web services to deliver presentation. What more does it really do than deliver wrapped html?

    First and foremost the advantage of WSRP is that it delivers presentation in a _standardized_ way. The services can be discovered, and they have metadata. They have standard ways to perform pageflow and they have ways of doing URL-mapping and handle state. If the standard gets broadly adopted in both camps (J2EE/.NET) service providers can deliver functionality to customers portals really quick as each user can implement the service in their portal view without doing any development or deployment at all. Web shops can deliver orderforms and detailed catalogs to resellers, and media can deliver readily formatted, personalized content with interaction functionality directly in an end-users portal view.

    To make this more than a "java thing" it needs Sharepoint support. There are two aspects to this. ASP.NET WebParts (not only for Sharepoint after Whidbey) must be enabeled to act as WSRP producers. In other words, their content will be consumable by any other portal that supports WSRP. Secondly a WebPart must be able to act as a WSRP consumer, it must show the presentation delivered by a WSRP producer. Developing the consumer part for .NET is probably not that hard, but to deliver the seamless "automagic" producer side of the story is quite a challenge. It will be interesting to follow the .NET community on this subject.

    This sounds like it needs Microsoft backing, and Redmond just joined the OASIS WSRP Committee. However there are no trace of an indication from Microsoft on the subject. One might speculate that Microsoft would not want to support this standard because it will allow "heavier" portal services to be hosted on Java, and Sharepoint will remain a presentation/collaboration oriented "lightweight" tool. Also the concept of delivering presentation over ws contradicts (not only) Microsofts strategy on datadriven webservices (BizTalk etc.). I haven't quite decided for myself yet either.


  • New GotDotNet sample posted..

    I've just released a new version of my DataPanel on GotDotNet. Anyone who have ever made a ASP.NET dataentry web form with a lot of textboxes for editing data in a lot of columns know it's a tiresome task. You have to set all the Text properties on load with the column values, and put updated values back on update. Try doing this in 20 fields in 10 dataentry forms.

    Yes, you can use other tools to automate it, but I missed the feel of the Editmode of the datagrid when editing a row, only without the datagrid. If you recognize this scenario, have a look at my sample. Full source is included, and I also took the time to add a ReadMe.doc with several screenshots and a walkthrough.


  • Bridge to asynchronous water

    Kevin W. Hammond points out that programming asynchronous webservices (using SOAP over MSMQ) creates a mindcandy for developers used to the RPC style of SOAP over HTTP:

    If you want request/response semantics when using SOAP over MSMQ, you must keep in mind that the WSE 2.0 channel model actually requires your client to become a server. Â Your client must listen for incoming SOAP messages and understand how to act upon them to correlate them back to the original request, which is distinctly different from the blocking semantics you get with SOAP over HTTP.

    [Kevin W. Hammond]

    In my opinion this is one of the areas withing SOA that needs more attention. When designing services on different layers of applications, and between applications you will at some point find it reasonable to implement a service asynchronously to ensure scalability and reliability, among other things. Most developers that design UIs will say that they need to be synchronous to respond to their users fast enough to not make the users go do something else.

    Kevin also points out that a service invoking an asynchronous method needs, itself, to be a service in order to receive the callback when the message is processed, thus increasing the complexity of the calling service.

    One solution for some use cases is datacaching. User Interface services can work towards a cached set of data optimized to reduce potential conflicts. Updates to the canonical data source can then be done asynchronously in the background, creating the illusion of synchronousity. This approach does however demand some form of conflict handling for the scenarios where the canonical data conflict with the cache upon which the update was made.

    I am thinking about this these days, and hoping for guidelines. According to subtle signals from the Indigo evangelists they will make the programming models (sync/async) more transparent. For now it' really just a matter of good architecture, and we can probably learn a lot from people that have implemented highly scalable (transacted) asynchronous systems for a long time. However, someone with the knowhow would at least get my appreciation and respect for bridging to the asyncronous waters in my SOA implementations.


  • Working with Sharepoint Area Templates

    My last post got too big so I cut it and a small article was the result. I've been working with Area templates the past days and I am sure there are lots left to learn. However, there are no really good resources for this (except a couple of unclear ones on, so I hope it might come in useful for someone.

    I'd love to hear from others that have experience in the area.


  • Working with Sharepoint Portal Server 2003 Area Templates

    There are some documentation out there on Sharepoint Portal Server 2003 (SPS) Area Templates. None however gave me the full overview I needed in order to be able to customize my Areas in the ways I wanted. This article sums up lessons learned in working with Area Templates.

    This article applies to working with Areas. Areas are a feature of SPS, not Windows Sharepoint Services (WSS) that ship with Windows 2003 server.

    The site backbone for SPS is the Area (as described here). The Area concept replaces the "Category" used in Sharepoint 2001, and this term is no longer valid. You will although it encounter the term in some contexts throughout SPS2003 as well. The Area appears in many different shapes and forms. Microsoft have included several templates for Areas out of the box: Topic Area, Community, News Area and more. All of these standard areas are created based on templates defined in CAML and their appearance are also influenced by template ASP.NET Web Forms. To be able to create such Templates for your SPS solution is an extremely powerful feature.

    There are unfortunately no applications available to assist you in this task so it might seem a bit cumbersome at first. Lets have a look at the existing Templates that ship with SPS and are located in this folder: 

    C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\<Your language Code>

    The language code (1033 for english) separates the templates for different localizations. Furthermore you can see a set of directories prefixed with "SPS" and some that are not. The directories contains:

    • STS :  the template for Sharepoint Team Site that ships with WSS
    • MPS : templates for the different workspace sites, also WSS
    • XML : xml files that control the configuration and loading of the templates
    • SPS* : the standard Templates you get to choose from when creating new Areas in SPS

    What is important to note here is that templates for creating WSS teamsites have the same structure as templates for creating SPS Areas. This have implications for what CAML elements in the configurations that actually have effect. Some elements are included in i.e. the SPSCOMMU template that does absolutely nothing. If the template had been applied to a teamsite they would. Of course Microsoft has made sure to hide the possibility of applying a "non-compliant" template to a Team Site or an Area, but it is possible and it looks really bad.

    So, lets cut to the chase. We want to make an area template because our portal is going to take advantage of the features included in SPS and not rely solely on WSS Team Sites. We will start by making a copy of the SPSNEWS folder and renaming it to SPSMYAREATMPL.

    Next we need to let Sharepoint know about the new template. To accomplish this we need to make a new WEBTEMP*.XML file in the XML directory located in the templates root dir (TEMPLATE\<Your language code>\XML). Sharepoint dynamically reads all files in this folder that matches the WEBTEMP*.XML filter so we'll just copy the WEBTEMPSPS.XML file and rename it to WEBTEMPSPSMYAREATMPL.XML, thus matching the directory name. Finally edit the XML file to make it look like this:

    <?xml version="1.0" encoding="utf-8" ?>
    <Templates xmlns:ows="Microsoft SharePoint">
      <Template Name="SPSMYAREATMPL" ID="10000">
       <Configuration ID="0" Title="My area template" Type="0" Hidden="TRUE" ImageUrl="../images/spshome.gif" Description="This template will test news and listings" />

    Note that the Name attribute must match the directory name and be uppercase. The ID is recommended to be above 10000 even though SPS only uses the numbers up to 36. Now my new template is ready to go and as soon as IIS is reset (use IISRESET in cmdline) it will appear in the Sharepoint Portal Server Area Template selection.

    The next step is to adjust and elaborate the template to your requirements. There are two main ways to alter the content:

    • Edit ASP.NET Web Forms in the template directory structure in FrontPage. Changes will affect all new and existing Areas created based on this template.
    • Edit the XML configuration files in the XML subdirectory located within the SPSMYAREATMPL dir. Changes only affects Areas created after IIS Reset.

    To get started creating your template start with opening the default.aspx in FrontPage. Because this is not a Web, FrontPage will be less helpful, and I recommend sticking to editing the tags once you've got the overview of the content. You can also add new webforms for use by your template.

    The second way to change your template is to edit the configuration files. The most important one is  ONET.XML. This file dictates the structure of your Area when it is created. Remember that you have to restart IIS and create a new Area based on your template to see changes in your template. This is the main drawback when working with Area Templates. An important element to check out is the /Modules/Module/File@Url="default.aspx". Here you can set up the webparts, lists and other elements you want to appear on your Area. Read up in the CAML reference to get an understanding for the rest of the elements. Note that the NavBars element have no effect on Area Templates.

    I have showed how to create a custom Area Template for Sharepoint Portal Server 2003. Now you can customize your own Area and create countless instances of it in your portal site. Cool things you can continue with is to create new custom lists , remove elements you don't need, alter the layout and more. Please feel free to contact me if you are doing smart stuff with templates!

    Working with the MySite configuration

    In the template folder you will also find the default template for the MySite configuration. You might think this works in the same matter as the other templates, but no. Editing the default.aspx in the SPSMSITE folder has the same effect, but altering ONET.XML has no effect. This is due to the fact that Sharepoint creates the virtual site that handles all MySite sites on installation, thus only processing the ONET.XML in the SPSMSITE folder once. To alter the MySite template for all users on your portal use FrontPage and navigate to your RootSite/MySite, then perform your changes.

    This inconsistency is kind of hard to spot, and reduces the possibility of preconfiguring the setup of a site before it is rolled out. Not much to do about that though.


    Customizing Templates for Microsoft Windows SharePoint Services
    Introduction to Templates and Definitions
    Overview of Custom Templates in SharePoint Portal Server 2003 and Windows SharePoint Services
    A ppt from (currently unavailible)
    Working with Templates
    Introduction to CAML
    Creating a List Definition
    Server and Site Architecture Overview
    ONET.XML CAML Reference


  • Difference between Sharepoint News & Listing?

    I have embarked on the quest of figuring out all the namespoofing in Sharepoint Portal Server 2003. Microsoft should really have released the document "Developers.. This is what all that Sharepoint stuff it REALLY is".

    Todays experiment was to figure out the difference between the terms

    • "News" used in News Area Template (SPSNEWS directory) and added by clicking "Add news"
    • "Listing" used in, among others, the Community Area Template (SPSCOMMU directory) and added by clicking "Add listing"

    I created a new Area Template as described in my article

    Because I copied this template from the SPSNEWS directory the structure is identical to the News Area Template, so the "Add news" link appears in the left navbar. I wanted to have the "Add listing" aswell. I examined the default.aspx for the SPSCOMMU template, which contains the "Add listing" link. Here is the difference:

    Within the SPSWC:ToolBar element the "Add listing" link looks like:

        <SPSWC:SubmitLinkToolBarButton runat="server"
         RequiredQueryStringParamsToInclude="CatID" />

    Within the SPSWC:ToolBar element the "Add news" link looks like:

        <SPSWC:SubmitLinkToolBarButton runat="server"
         RequiredQueryStringParamsToInclude="CatID" />

    From this it's clear that the two are the same with different labels. The "Mode=News" querystring only opens the possibility to add publishing dates to news items. In order to have them both on the same page I altered the ID (in red) and created a site based on my template. News and Listings appears in the same webparts, both can be directed towards audiences, but news can be time-limited.