Ray Ozzie proposed his concept of Simple Sharing Extensions back in 2005, and then more or less went silent. Until now!

Another Live Labs technology preview release arrived this week. It's called FeedSync and it is the current incarnation of the concept Ozzie developed to allow data sharing over web protocols like RSS.

The initial specification is available as version 1.0 at the time of this writing. It extends both the Atom and RSS specifications to incorporate item sharing which Microsoft defines as "bi-directional, asynchronous synchronization of new and changed items amongst two or more cross-subscribed feeds".

(Hmmm, calendar sharing anyone?)

The samples in the specification deal with a fictional task list example. Here is the code (emphasis added) for the sample RSS feed.

<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:sx="http://feedsync.org/2007/feedsync">
 <channel>
  <title>To Do List</title>
  <description>A list of items to do</description>
  <link> http://example.com/partial.xml </link>
  <sx:sharing since="2005-02-13T18:30:02Z"
    until="2005-05-23T18:30:02Z" >
   <sx:related link="http://example.com/all.xml" type="complete" />
   <sx:related link="http://example.com/B.xml" type="aggregated" 
    title="To Do List (Jacks Copy)" />
  </sx:sharing>
  <item>
   <title>Buy groceries</title>
   <description>Get milk, eggs, butter and bread</description>
   <sx:sync id="item_1_myapp_2005-05-21T11:43:33Z" updates="3">
    <sx:history sequence="3" when="2005-05-21T11:43:33Z" by="JEO2000"/>
    <sx:history sequence="2" when="2005-05-21T10:43:33Z" by="REO1750"/>
    <sx:history sequence="1" when="2005-05-21T09:43:33Z" by="REO1750"/>
   </sx:sync>
  </item>
 </channel>
</rss>

Notice the namespace reference sx=http://feedsync.org/2007/feedsync the "sx" prefix is the one designated in the spec.

FeedSync supports multi-master topologies which means it can be used to send and receive data to multiple clients. An example topology is shown below, (image from Microsoft's web site.), as you can see clients can be bi-directional or pull only.

The possibilities are many, I am already thinking about using this technology to allow calendar syncing between Google Calendar, and Outlook. Another thought that jumped to mind would be to allow sharing appointment data for a centralized calendar among a group of subscribers on a project I am working on.

Best of all, the technology has been released and licensed under a Creative Commons license which means the technology is likely to be extended.

The best place to start looking for developers is the FeedSync For Developers page.

Have fun! Share with me your observations and ideas!

Cheers,

Robert Porter

Microsoft has released a Live Lab's (Microsoft Research and Live Services) preview technology package called Volta.

Volta is a framework that allows a developer to potentially build a multi tier application initially as an client application, and then use a technique called "declarative tier-splitting" to identify which pieces of the application run on a server and which pieces run on the client.

This is accomplished by using and XML like declarative markup within the code. With this approach a developer can focus on getting the application designed and functional and then let Volta split the tiers and create the communications "glue" that lets the applications tiers work together.

How this is accomplished is rather interesting, Microsoft decided to go with an MSIL based approach, mostly accomplished in the post compilation area. MSIL code is rewritten to run in Javascript for the client, and ASP.NET for the server side, typically as a web service.

Since Volta works it's magic at the MSIL level, any CLR targeted language is supported, C#, VB.NET, IronPython and others. Visual Studio 2008 is required at this stage, 2005 is not supported and it is unclear if it will ever be.

So show me some code already!

The code shown below is from the Volta Recipe's page. It shows the [RunAtOrigin] custom attribute in use.

namespace VEMashup.Weather
{
    [RunAtOrigin]
    public class WeatherSvcProxy
    {
        public string GetJsonWeatherInfoFor(double lat, double lng)
        {
            var baseUri = @"http://ws.geonames.org/weatherIcaoJSON";
            var uri = baseUri + "?lat=" + lat.ToString() + "&lng=" + lng.ToString();
            var xhr = new Microsoft.LiveLabs.Volta.Xml.XMLHttpRequest();
            xhr.Open("GET", uri);
            xhr.Send();
            if (xhr.Status == 200)
                return xhr.ResponseText;
            else
                return null;
        }  
    }
}

This is an example of "tier splitting" via markup. This tells the Volta framework that this code is destined to run on the server. Code not marked will continue to run on the client. This means that as a developer you can postpone deciding how and where to partition your application until the last minute.

The agile developer in me seriously enjoys this particular aspect! Volta technology is seriously early in the life cycle however, so bear in mind that this will change before it gets released.

There is a handy list of known issues you should review before you start playing with the framework.

You could think of Volta as architecture refactoring on steroids. As shown below Microsoft has designed it explicitly with that in mind. (Image from Volta Web Site.)

Bear in mind that you are not limited to 2 tiers, you can retarget portions of your application to as many tiers as you want!

All in all I think this bears some watching!

Cheers,

Robert Porter

In the last (and first) post of this series we discussed how to create a typed dataset. Now that we have our dataset we need to see how to use it.

But before we go into the details, I want to explain something that I stumbled upon in my research. There is a serious bug in the implementation of the dataset generator. It effects retrieving and manipulating childrows when you are dealing with related tables.

After a great deal of hair pulling, self doubt, and serious coffee consumption, I finally found a series of blog posts that ended up leading me here. The bug has been confirmed and will be released: “thanks again for reporting this. We fixed this problem and the fix will be available in the next Visual Studio release.”

Description

When you create a typed DataSet using the class-designer of VS.NET with a parent- and a child-table, a method is generated on the parentrow-class which should return the childrows. This method uses DataRow.GetChilds with the name of the relationship. This method returns a parentrow-array instead of a childrow-array. The generated method casts it to a childrow-array and thus causes a InvalidCastException.

The first thing we need to do is to create the actual dataset. There are a number of ways to accomplish this, however I have found that the most straightforward way is to right click your solution, select Add… then select Dataset from the list.

Datasets can contain many tables or queries or both, I tend to create a dataset per table unless I need to work with joins or multiple tables at once.

There are also a number of options involved in creating a dataset, we are going to explore several of them in this series. The most significant decision you will need to make is whether or not to base your dataset on Stored Procedures or Queries.

In this first example we will be using Queries. But first we need to create the dataset. Once you have selected Dataset you should give it a name, I typically use the table name it is going to be based on, in this example, Employees.xsd

The Dataset Designer will appear, a mostly blank screen that we will drag objects from Server Explorer onto. Go to the Server Explorer window, if it is not visible you can pull down the View menu and select Server Explorer. You should see something like Figure 1:

The Data Connections node is what we are going to work with, right-click it and select the Add Connection… option. Fill in the resulting dialog to connect to your instance of SQL Server and make sure the database selected is “pubs”.

Expand your connection and you will see a listing like Figure 2:

As you can see we now have access to a number of items within the database itself, most importantly for this example, the Tables node.

Expand the Tables node and drag the ‘employee’ table onto the dataset designer surface. By default you will get an ‘employee’ dataset and an ‘employeeTableAdapter’ with two methods, Fill and GetData().

Behind the scenes a great deal of code has been generated for you, or will be once you press Save. But we don’t want to accept the defaults, so we are going to make some adjustments.

The first thing you should know is that the process of dropping the table onto the designer surface persisted the connection you created in you applications app.config file. It will have created the app.config file if one did not already exist.

In a production application you would want to alter this connection string to match the production servers connection parameters as well as probably encrypt it. For this example I would suggest that you open your app.config file and rename the connection to “pubs”. My ConnectionStrings section contains the following:

    <connectionStrings>

        <add name="pubs" connectionString="Data Source=DELLXPS;Initial Catalog=pubs;Integrated Security=True"

            providerName="System.Data.SqlClient" />

    </connectionStrings>

I will show you later how to use this renamed connection string as opposed to the one the dataset will be expecting, and explain why I do that.

Next, we need to tweak some of the defaults created for us by the designer. Right-click the employee Dataset and select Configure from the context menu.

You will see a TableAdapter Configuration Wizard pop up. It will show you the query it is using to build and populate the dataset. Click the “Advanced Options…” button and make sure all 3 checkboxes are checked. They usually are by default. The first option tells the designer to create Insert, Update and Delete statements that match the Select statement used.

The second option tells the designer to Use optimistic concurrency which adds intelligence to the Update and Delete statements to allow them to detect if the record(s) they are about to Update or Delete have been modified since they were populated.

The final option, “Refresh the data table” fires a Select after every Insert and Update statement in order to retrieve calculated fields, default values and identity values that are generated by the database.

Once you have done that, return to the Wizard and select Next, you will get the Choose Methods to Generate screen. You will see 3 options, the first two are what we are concerned with for now.

All 3 should again be checked, modify the names of the methods to better reflect what they are doing, in this case returning all employees. See Figure 3 below for an example:

Press next once more and you will get Wizard Results screen that shows that the designer has generated all the code, queries and methods we asked it to.

Review the results, then press Finish to return to the designer. Your dataset should now look something like this in the designer:

Notice the highlighted section, this shows that the method names have changed like we wanted.

Thats it! You have now created your first strongly typed dataset.

Next up, we will discuss what exactly this does for you, and how you would use it in code and what advantages you gain from using this construct.

Stay tuned!

Bob Porter

This post is my first attempt to share some of my own experience. Specifically with ADO.NET and Typed Datasets. Scott Guthrie published an excellent series of tutorials on creating a DAL using Typed Datasets.

This is not an attempt to duplicate that series, but it is inspired by it. And I also wanted to do this from a Winforms perspective rather than an ASP.NET view, since I still work in both worlds.

For my first effort, I created a fairly simple application that allows the user to perform simple, Select, Update, Delete and Insert operations against the SQL Server sample pubs database employee table.

SQL Server 2005 does not ship with the pubs or Northwind databases any longer. If you want the scripts to create them you can download them here. These scripts while designed for SQL Server 2000 worked just fine in SQL Server 2005 and created the databases and populated them with data. (They also include pre built databases in the form of MDF and LDF files that you can attach but I prefer to build them from the scripts.)

If you want to download the sample application that goes along with this series of tutorial posts you can do so here. File Attachment: MasterDetail001.zip (71 KB)

I am going to begin this series in earnest tomorrow with the first of the “meat” posts. And let me clearly state, the code in the sample app is very basic, little or no error handling, and not necessarily even the correct way of doing things. I am looking for constructive feedback myself. This application, as it grows, and the tutorials that accompany it are as much a learning exercise for me as anything else.

Cheers,

Bob Porter

Hmmm