Robert Baumann's Blog

I got an e-mail from John Hancock, the author of the article in May '07's MSDN magazine about interfacing with Groove 2007.  It turns out that there's a Codeplex project that provides a managed wrapper API to Groove so that you don't need to use the wsdl files, registry access, etc.  It's probably a good thing that you know what tricks have to be pulled to interface w/ Groove's web services API, but overall it's better to use a wrapper and hide all of that rather than having Registry key lookups, time conversion logic, etc. permeate through your applications.

Windows Vista and Longhorn include the ability to perform File I/O in a transaction.  In order to have your File I/O enlist in a transaction, you need to call a separate set of new APIs.  This makes sense for a couple of reasons:

 

1) If you have a log file, then you don't want changes to the log file rolled back in a transaction

2) Transactions incur a locking cost on their resources.  Access to files/folders is not shared - if you try to access a NTFS transacted resource that's currently held by another thread, you'll get an error.

 

The moral?  Use transactions wisely, but this is a powerful tool, especially since NTFS transactions can also participate in distributed transactions (DTC), allowing you to span one or more databases, plus the file system. 

 

For example, we have a function in Gfx that allows customers to move tax returns from one account to another.  In order to do this, we use COM+ objects with TransactionOption.Required, and first run some stored procedures to move the metadata in the database.  If all that succeeds, we start moving files.  In our existing system, we had to write logic to implement a compensating resource manager that moved files back to where they belonged if there was a failure in the process.  Longhorn would have done this for us by using CopyFileTransacted(), and passing it the handle from the current transaction context.  Awesome stuff, wish it had been there a few years ago!

 

All this is brought to you by the Kernel Transaction Manager (KTM), which is a light-weight transaction manager that supports attaching to another transaction manager (like DTC).

 

I don't see that C# wrapper classes that are transaction-aware are in Orcas, so unfortunately we'll all have to Interop.  It might be a good article to post a full set of TxF-aware classes that check the OSVersion.

With MIX today, Silverlight 1.1 alpha add-ons were released for Orcas beta 1.  You can get them at:

 

 

Silverlight 1.1 alpha includes .NET runtime support, so you can actually develop interactive applications that run within the browser.

 

They have also announced Silverlight streaming services, which offers a free hosting service for building your own silverlight applications and videos.  Check them out at:

 

 

 

In the May 2007 issue of MSDN magazine, John Hancock laid out the steps that it takes to work with the Groove web services interface.  In those steps, there are two key problems:

1) Service location must be done by the client by looking in the windows registry under HKLM\Software\Microsoft\Office\12.0\Groove

2) Time format passed back from the web service is UTC, not local time

 

Let's take on these issues:

1) Service location must be done by the client

If the client must perform registry access directly to a datastore managed by your product, then you're not abstracting that datastore.  This means that Office 14 (they're skipping version 13), in order to support older interfaces, needs to support this registry entry.  Furthermore, LocalRequestKey and LocalResponseKey are dependent upon the caller to determine what they mean.  Rather, the best practice is to develop according to interface specifications, not a particular data storage implementation.  Service location should be via COM.  By exposing LocalRequestKey/LocalResponseKey, the Groove implementation is assuming that the client knows exactly what the behavior is.  Behavior requirements should be specified by interface, not assumptions.

 

2) Time format passed back from the web service is UTC, not local time - The assumption here is that developers will know what to do with UTC times.  Most developers work with LocalTime, which is the default (and is in fact the default for Datasets)...

 

Both of these issues are caused by the fact that Groove does not have an SDK that wraps access to the web services.  As the author infers, this is code that will be written once and used many times over - why not implement in an SDK rather than publishing the SDK as web services?

 

Overall, John did a nice job of covering the steps in communicating with Groove.  Bravo!

Beta 3 of Longhorn is available for download on the Microsoft website.  You can get it here: