The UDDI OPMLlist is now being cached in memory and refreshed every three minutes on a background thread. Unless the AppDomain recycles, the responses should be instantaneous now,unless you are doing a query on categories, because that needs to happen live because I don't want to cache each and every request combination on our server here and have it take up too much memory for this demo.

I looked at IBM's UDDI service yesterday and at least the web interface is by several magnitudes quicker (from here). I should probably play with their service a little to improve response times. ( ... just did, IBM and SAP aren't any faster)

Andrew asked for per-UDDI-category queries for the OPML lists my little tool creates and here it is:

Optional query parameters:

scheme=<<name of one of the pre-registered categorization schemes in the Microsoft UDDI registry>>
key=<<a key from a category>> (required parameter if scheme is provided)

For the following categorization entry for a service in UDDI (one of the RSS tModels is required in addition to that):

Categorization Scheme: ntis-gov:naics:1997
Key Name: Information Services and Data Processing Services
Key Value: 514

the proper query is therefore

http://staff.newtelligence.net/playground/clemensv/rssinuddi/rss_in_uddi.aspx?scheme=ntis-gov:naics:1997&key=514

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) 

RSS in UDDI as OPML

Related to this here, I wrote a little OPML renderer that shows all RSS feeds registered in UDDI using the RSS tModels by Karsten. The htmlUrl only shows if there is a second binding for the service that uses the uddi-org:homepage tModel. The access point of that binding is emitted for the htmlUrl.

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

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