Simon Fell > Its just code > February 2002

Earlier in the week I wrote a subscriber interface for weblogs.com. This allows you to register the URL's of your favorite weblogs, and the subscriber service will call you back when one of your weblogs changes.

Weblogs watcher is a Radio based client to the subscriber service. It does the following

• It regularly subscribes your list of favorites [from Radio's existing weblogs.com tool]
• It listens for the service callbacks, and keeps a log of recent changes.
• It provides a small regularly updated window with the summary of recent changes.
• It provides a couple of functions that can render the summary list in other parts of your radio site [i have it in the home desktop page]

Here's a view of the top of my home desktop page

Clicking the little [watch] link pops up the mini watcher

Installation

If I understand the tools stuff properly, the install should just be a matter of dropping weblogsNotify.root into your tools directory. Radio will spot the new tool and install it. Once installed open Radio goto the Tools menu and select Weblog Watcher -> Send Subscription to force the initial subscription call [it will do it itself, but not until the top of the hour]. At this point, the Weblogs Watcher will appear in the status center on right hand side of the desktop home page. If you want the full recent summary somewhere else, then edit the Desktop Website template and add this in the relevant place

<p><% weblogsNotifyCode.renderLauncher() %>
<% weblogsNotifyCode.renderSummary() %></p>

I have mine just before this chunk of code, the exact place to put it will depend on what template you're using

<p><%bodytext%></p>
<p><%radio.macros.weblogEditBox ()%></p>
<p><%radio.macros.weblogRecentPosts ()%></p>

Configuration

This works by the subscriber service making SOAP calls to your Radio installation, this means that if you're behind a firewall and/or NAT you'll need to allow incoming traffic on 5335 from soap.4s4c.com. You'll also need to make sure that Radio is configured to enable the SOAP interface, and to allow SOAP traffic from soap.4s4c.com [67.113.138.114], see XML-RPC and SOAP in Radio

Todo

The main thing that's lacking at this point is a pref's page, there's not much to twiddle with, but there should be a prefs page for it.

As a fully fledged weblogs.com adict, i find the hourly update in Radio to be too long a wait, so i constantly have www.weblogs.com open, and keep hitting refresh, looking for blogs that i follow.

So, to help build a better tool for this, i started by building a subscriber interface to the weblogs.com data. You register the URL(s) of the weblogs you want to subscribe to, and the port & path of where your callback handler is [it must be at the same address as the subscribe call]. Then when the service sees a change in any of the URL's you subscribed to, it'll call you back with a SOAP message saying its updated.

This is just the ground work, more interesting scenarios can be built on top of this. Radio would be an obvious client, as it already has something to manage a list of favorites, just need some code to subscribe to all your favourites, and a callback listener that tracks the callsbacks, and displays them somewhere obvious.

There's also scope for a small stand alone app that does something similar.

In addition other notification layers can be built on top, such as IM messages, .NET Alerts, email, SMS etc.

The WSDL that describes the subscription interface is here. Here's a sample subscribe request generated by PocketSOAP

POST http://soap.4s4c.com/weblogs/subscribe.asmx HTTP/1.0
Content-Type: text/xml; charset=UTF-8
User-Agent: pocketSOAP/1.3.beta.2
Accept-Charset: UTF-8, UTF-16
Host: soap.4s4c.com
Content-Length: 701
SOAPAction: "http://soap.pocketsoap.com/weblogs.com/Subscribe"

<S:Envelope
 S:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/'
 xmlns:Enc='http://schemas.xmlsoap.org/soap/encoding/'
 xmlns:S='http://schemas.xmlsoap.org/soap/envelope/'
 xmlns:a='http://soap.pocketsoap.com/weblogs.com/'
 xmlns:XS='http://www.w3.org/2001/XMLSchema'
 xmlns:XI='http://www.w3.org/2001/XMLSchema-instance'>
<S:Body><a:Subscribe><urls XI:type='Enc:Array' Enc:arrayType='XS:anyType[2]'><i XI:type='XS:string'>http://www.pocketsoap.com/weblog/</i>
<i XI:type='XS:string'>http://www.razorsoft.net/weblog/</i>
</urls>
<callback_port XI:type='XS:int'>80</callback_port>
<callback_path XI:type='XS:string'>/dummy.asp</callback_path>
</a:Subscribe>
</S:Body></S:Envelope>

When the service sees a change in a weblog you are subscribed to, it'll call you back with a message like

<sp:Envelope
  sp:EncodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
    xmlns:sp="http://schemas.xmlsoap.org/soap/envelope/">
  <sp:Body xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/">
    <m:updated xmlns:m="http://soap.pocketsoap.com/weblogs.com/">
      <weblogs enc:arrayType="m:weblog[1]"
          xsi:type="enc:Array">
        <weblog xsi:type="m:weblog">
          <url xsi:type="xsd:anyURI">http://www.pocketsoap.com/weblog/</url>
          <name xsi:type="xsd:string">its just code</name>
          <timestamp xsi:type="xsd:dateTime">2002-02-15T07:29:26Z</timestamp>
        </weblog>
      </weblogs>
    </m:updated>
  </sp:Body>
</sp:Envelope>

Subscriptions are valid for 48 hours, you need to call subscribe again before the 48 hours expires to renew the subscription.

Changes are polled from weblogs.com, so there can be upto a 5 minute delay before you'll get a notification callback

Although there's no standard interop tests for either SwA or DIME, everyone so far, has some sort of SwA enabled test, its a pain, but I'm coding up specific tests for each different endpoint, to see what the interop landscape looks like.

Here are the current results, I'll keep this updated as I find new endpoints to test against

SwA / MIME

Apache Axis beta 1 : Attachments of size 344 or 345 bytes fail [I beleive this is an Axis problem]

SOAP::Lite 0.5.2 : No Known Issues

XMLBus : No Known Issues

Spheon JSOAP : No Known Issues

Apache SOAP 2.2+ : Sometime it will send MIME parts with a Content-Transfer-Encoding of base64, pocketSOAP will fail this as it doesn't support mutating CTE's

GLUE 2.3.1 : Fails, GLUE has a dependency on the optional Content-Length header

ZSI : Fails, cause unknown at this point

WASP : Fails, PocketSOAP has a dependency on the optional Start attribute

DIME [June 17, 2002 version with PocketSOAP 1.3.5+]

White Mesa DIME enabled Server : No Issues

MS SOAP Toolkit 3.0 : No Issues

Spheon JSOAP : No Known Issues

Microsoft WSDK : No Known Issues

DIME [Feb 01, 2002 version with PocketSOAP 1.3.0]

Simon's .NET Test DIME server : No Issues

White Mesa DIME enabled Server : No Issues

MS SOAP Toolkit 3.0 [pre release version] : No Issues

ASP.NET DIME Sample from WS DevCon [also available on MSDN] : No Issues

Spheon JSOAP : No Known Issues

WSDL FM ( aka Radio WSDL )

In Sam's article Axis/Radio interop, actual and potential, he describes calling Radio hosted services from Axis, and calling Axis hosted services from Radio, then goes on to describe how WSDL can remove some of the grungyness of making the SOAP call. Finally he leaves us with a teaser of what could be.

There's a middle ground not mentioned, which is to generate the macro files from WSDL and drop them in the Macros directory, not quite as easy to use as Sam's teaser, but pretty close. A quick test reveals that you can create a directory structure under the Macros tree, and reference them will the . notation, e.g. create a directory foo under macro's, and drop bar.txt in there, can you can call <% foo.bar() %>. Looks promising :)

So, inspired by Sam's teaser, I set out to write a tool that generates Radio macro's from WSDL. Now correctly parsing and processing WSDL is a PIA, however our friends up in the north have conviently done most of the work, there's a pretty good WSDL parser built into the .NET Framework, thanks Keith !. 

With most of the WSDL gunging out of the way, its a pretty straightforward task to walk around the WSDL and spit out text files for each operation. The tool generates the macros into a sub directory, named after the Port, so in the case of the 4s4c Interop service, you get a interopTestPort directory, with files for each method, echoString, echoInteger, echoDate etc. Simply copy the directory under the Macros directory, and off you go, making calls is now as simpe as <% interopTestPort.echoString("Hello Dave !") %>

You can download the source code and executable from here. Run the tool with radio_wsdl http://some/wsdl/document

You can see the results of a little test with the macro's generated from 4s4c and the Delphi servers.

Issues:

There's a known issue with the .NET WSDL parser, in that it needs the WSDL and/or XSD documents to be served with a text/xml content-type, however many WSDL docs that are served as static content typically get a application/ocectstream content type. And unfortuantly, the interop docs on whitemesa.com fall into this category, so i couldn't test with the Axis WSDL doc :(