On the Mark: 7/25/2002

	Thursday, July 25, 2002

I really like Mark Paschal's Kit tool for Radio. I regularly use the Search feature to find previously written posts. I often do this when I want to copy a link (to a previous posting) into a post I am writing at the moment. Kit renders a permalink to each search result, however the rendered link is relative to the Kit search page (a Radio system page). So it really doesn't point to anything at all. I wrote a little bit of code to fix this up so that the permalink points to something useful. My additions to Mark's code will render a URL by using:

The URL of the first category identified for the posting
The URL for the archived Home Page if there is no category identified.

That means postings to both the Home Page and a category will use the category permalink, but that seems better than nothing. To do it yourself, add the following code to Kit's search.txt file in the bundle labeled "set permalink", immediately following the bundle labeled "build linkurl".

local (base);
if sizeOf(adrpost^.categories) > 0 {
    local(category = nameOf(adrpost^.categories[1]));
    base = wbd^.categories[category].htmlUrl;
    }
else {
    base = radio.weblog.getUrl ();
    };
t.permalink = "<a href=\"" + base + linkurl + "">" + 
  radio.data.strings.itemPermaLinkImg + "</a>"};

Note: I am not on Mark's latest release (1.1.6 I think), but I am fairly certain this code has not yet been changed.
4:01:28 PM

Google It!

Nick likes the idea of early binding web services, from an article that Piotr found. Quoting Nick:

This looks pretty sweet. It looks like you can change the server address/port/url at runtime. As long as the wsdl (type library) doesn't change, this might be the way to go. Piotr is using it for our application and he says it performs a lot better. I guess that makes sense because we wouldn't have to consume/process a wsdl file at runtime.

Some of the benefits here are:

Using a "standard" component model when invoking web services
Gaining some degree of type-safety (immaterial if you are just passing strings, which seems to be the case for all our interfaces)
Gaining Intellisense for web services

I do not see where you can dynamically change the location of the service; I will have to follow up with Nick on that one.

There is one thing that kind of troubles me about the direction this approach is going in (and the direction Microsoft seems to be going in with SOAP). Invoking a web service via SOAP is a pretty simple thing. You build a small XML document and then use an HTTP Post to send it to a web server. There is really no rocket science here if you have a decent toolkit for building HTTP requests. It stays simple so long as we are passing fairly simple data types to the server - integers, strings (not serialized XML docs), and arrays of these types. When you can cruft up the whole call yourself, it is very easy to dynamically alter the service location - it is just part of the HTTP request after all.

However, many useful services require complex types of data. Also, some people want a means for identifying the location of the service and the semantics required for invoking the service. It is for these reasons that Microsoft came forward with WSDL. While WSDL makes it easy to generate code wrappers for a web service, those same wrappers become point-specific - useful only for a specific location of the web service. That means the wrappers must be regenerated when moving from Test to Production.

When I look at it in this light, I have to question the usefulness of WSDL in the first place. Doing SOAP was (is) easy. We started doing WSDL to document the semantics of a web service and justified its complexity by noting that WSDL provided enough detail to generate client wrappers. Now we are right back to SOAP being easy, but with some loss of flexibility. Was it worth it?
2:19:34 PM Google It!