Category-based UDDI RSS search. Done.

Matevz Gacnik got it and put himself on the list 

(Note: I set the output cache to expire every 180 seconds and therefore it mostly takes a little while to rebuild by getting the fresh data from UDDI) 

I wrote a little OPML renderer that grabs all RSS feeds that are registered in Microsoft's UDDI registry

A quick overview about my changes to BlogX and why it just isn't BlogX anymore. And, yes, you'll get it.

Philip Rieck makes a great point about the obsession with "revolutionary innovation" quite a few people have. Little steps count too, he says, and there's good stuff in old things and I absolutely agree. At TechEd in Barcelona I said in one of my talks that people should read less computer books published in 2003 and more of those published in 1973.

Stephen Forte is a big fan of Munich, except for their Linux strategy; and I do agree on the latter -- for some obvious and some not so obvious reasons.

BloggerAPI, MT API, MetaWeblog API, Comment API, Pingback API, Trackback  ...  are you nuts?

I must admit that until last week I didn't really pay much close attention to all the blogging related APIs and specs beyond "keeping myself informed". Today I copied my weekend's work over to this server and now I have all of them implemented as client and server versions. Sam's and Mark's validator is happy with my RSS 2.0 feed and the experimental Atom (Pie/Echo) feed.

I have to say ... the state of affairs in this space is absolutely scary. Most of the specs, especially for the APIs are lacking proper information detail, are often too informal with too much room for ambiguities and you need to be lucky to find a reasonably recent one. Sam laments that people don't read specs carefully and I agree, but I would argue that the specs need to be written carefully, too. It also seems that because the documentation on expected behavior is so thin, everybody implements their own flavor and extensions and not only do the APIs have huge overlap, but it seems like any random selection of offline blogging tools will use its own arbitrary selection of these APIs in any random order. Since my implementation didn't "grow" over time, but I implemented it all in one shot essentially only since last Thursday and had to look at this all at once and what I found was just saddening. All of this has to be consolidated and it will be.

I am all for the Atom project and creating a consolidated, SOAP-based API for all blogging functions that the aforementioned APIs offer. XML-RPC was a good thing to start with but its time is up.  I am also for replacing RSS x.x with a spec that's open and under the umbrella of a recognized standards body and not of a law school, that's XML as of ca. 2003 and not as of ca. 1998, and that's formally documented (with a proper schema). What's there right now smells all like "let's hack something up" and not very much like serious software engineering. Ok, it's proven that it all works, but how about dumping the prototypes now?

 

This morning I got up early (I going to be picked to play Paintball in an hour or so) and implemented image and attachment uploads for the blogging site. This is the test for the live site.

[Here's a copy of the SoapExtension Wizard for Visual Studio.NET: ASPNETSoapExtensionWizard.zip (53.82 KB)]

 

I will be speaking at TechEd Malaysia 2003

Productivity and ASP.NET

It took me less than an hour to implement, test and deploy pingback support for this blog here using ASP.NET and XML-RPC.NET (and that includes reading the spec). Yesterday and today, it took me less than 2hrs total (including addressing two comments/suggestions/corrections from Sam Ruby) to get (n)echo/pie/atom support working so that it can be validated.

A little IHttpModule implementation for ASP.NET that maps between URLs using regular expressions. In use here.

On-the-fly template-based blog rendering

If you want to get a feeling for what the rendering engine here can do (which may not be so impressive looking at other tools, but a lot better than than rev20 of BlogX which I started from), check out the "Pick a theme" bar down at the bottom of the page.

The default theme for this page is currently "newtelligence Blue". You can always go back to the default by clicking "Reset". When you select any of the other themes, you'll get a cookie set and the rendering engine will use the template whenever you come and look at the site.

[As of this moment there are two little bugs in the logic which will (1) have that cookie span the whole site and (2) will render the page inaccessible for you if the cookie goes bad. Both should be fixed today.]

This here is not Radio.

Quake II on .NET. Scott Stanfield and his team at Vertigo Software show yet another nice trick: Quake II in managed code.

I couldn't find one, so I made a WS-PolicyAttachment UDDI bootstrap file for import into Windows UDDI Services.

When I put that together, I ran into a bug in the spec. Point 5.1 shows the tModel for the remote policy reference. The tModelKey shown there is

<tModel tModelKey="uuid:0b1b5a47-bebf-3b7d-9802-f2dd80a91adebd3966a8-faa5-416e-9772-128554343571">

which is a bit long for a uuid, isn't it? Correct is the following (as the spec later explains):

<tModel tModelKey="uuid:0b1b5a47-bebf-3b7d-9802-f2dd80a91ade">

The bug even survived the revision from 1.0 to 1.1, which makes me wonder whether anyone ever reads these specs in any depth

This bit of news retires one of my talks ;)

Current output of this is that:

---------------
Feed Name: Clemens Vasters: Enterprise Development & Alien Abductions
Access Point: http://radio.weblogs.com/0108971/rss.xml
RSS Version: 2.0
Description: Clemens Vasters' Weblog, Language: en
Press any key to continue

Getting serious about UDDI, Step 1

If you search uddi.microsoft.com for "Services" by the "RSS - Version 2.0" tModel, there's exactly one entry at this time. Mine. Fix that.

Using the UDDI SDK 2.0 (part of the Platform SDK), the following snippet is a simple console app that lists all weblogs registered with the RSS 2.0 tModel in the Microsoft UDDI registry [thanks to Karsten Januszewski for his doc, tModel bootstrap and code]. The advantage? If aggregators were able to remember my service key instead or in addition to my absolute access point (right now http://radio.weblogs.com/0108971/rss.xml), I could move the RSS feed around to any arbitrary locations without any pain and clients would still be able to find it using a simple lookup into the registry. And the infrastructure is all there. No future thing.

using System;
using Microsoft.Uddi;
using Microsoft.Uddi.TModels;
using Microsoft.Uddi.Services;

namespace ListRSS20Feeds
{
    class MainApp
    {
        static void Main(string[] args)
        {
            UddiConnection uddiConnection = new UddiConnection();
            /* RSS 2.0 tModel key from config */
            string RSS20TModelKey = "uuid:bacbe300-4b2b-11d7-bc51-000629dc0a53";
            /* setup the UDDI parameters on the connection */
            uddiConnection.InquireUrl = "http://uddi.microsoft.com/inquire";


            /* create a UDDI FindService and ServiceList objects */

            FindService fs = new FindService();
            ServiceList sl = new ServiceList();
            /* add the rss tModel key */
            fs.TModelBag.Add( RSS20TModelKey );


            try
            {
                /* send to uddi */
                sl = fs.Send(uddiConnection);
            }
            catch ( Exception ex )
            {
                Console.WriteLine( ex.Message );
                return;
            }

            /* create FindBinding and BindingDetail objects */
            FindBinding fb = new FindBinding();
            BindingDetail bd = new BindingDetail();
            fb.TModelBag.Add( RSS20TModelKey );

            /* get the bindings */
            foreach ( ServiceInfo si in sl.ServiceInfos  )
            {
                /* set the serviceKey */
                fb.ServiceKey = si.ServiceKey;
                try
                {
                    /* send to UDDI */
                    bd = fb.Send(uddiConnection);
                }
                catch ( Exception ex )
                {
                    Console.WriteLine( ex.Message );
                    return;
                }
                foreach ( BindingTemplate bt in bd.BindingTemplates )
                {
                    Console.WriteLine(

                        "---------------\n"+
                        "Feed Name: {0}\n"+
                        "Access Point: {1}", 
                        si.Names[0].Text, 
                        bt.AccessPoint.Text);

                    /* get out the tModelInstanceInfo for the tModelKey 
                        that represents RSS 2.0 and get the version info */
                    foreach ( TModelInstanceInfo tmii in bt.TModelInstanceInfos )
                    {
                        if ( tmii.TModelKey == RSS20TModelKey ) 
                        {
                            if ( tmii.InstanceDetails.InstanceParameters != null )
                                Console.WriteLine("RSS Version: {0}", 
                                  tmii.InstanceDetails.InstanceParameters);
                            else
                                Console.WriteLine("RSS Version: n/a");
                        }
                    }
                    
                    if ( bt.Descriptions.Count > 0 )
                    {
                        Console.WriteLine( "Description: {0}, Language: {1}", 
                           bt.Descriptions[0].Text, 
                           bt.Descriptions[0].IsoLanguageCode);
                    }
                }
            }
        }
    }
}

H2/2003, moving up one notch on the WS stack.

Yesterday, all the travel madness of H1/2003 which begun in January has officially ended. I have a couple of weeks at the office ahead of me and that's, even if it may sound odd, a fantastic thing. The first half of the year and quite a bit of last year too, I spent most of my research time working deep down in the public and not-so-public extensibility points of Enterprise Services and Web Services, trying to understand the exact details of how they work, figuring out how to inject more and tweak existing functionality and whether certain development patterns such as AOP could enhance the development experience and productivity of my clients (and all of you out there who are reading my blog). I've been in 21 countries in this first half of the year alone and at about 40 different events, talking about what I found working with these technologies on some more and some less serious projects and doing that and speaking to people I learned a lot and I also think that I helped to inspire quite a few people's thinking.

Now it's time to move on and focus on the bigger picture. Starting with version 2.0 of Microsoft Web Service Enhancements that's due out by end of this summer, Web Services will finally become less Web and more Services. The WSE 2.0 stack will break the tie between HTTP and SOAP by enabling other transports and they'll add support for some of the most important WS-* specs such as WS-Policy, WS-Addressing and related specs. The now released UDDI services in Windows Server 2003 put a serious local UDDI registry at my fingertips. BizTalk Server 2004's new orchestration engine looks awesome. There's a lot of talk about Service Oriented Architectures, but too less to see and touch for everyone to believe that this stuff is real. I think that's a good job description for H2/2003. My UDDI provider key: 7f0baedf-3f0d-4de1-b5e7-c35f668964d5