Today, I discovered Robert J. Seymour's page in my referers.  He has an article that's a few weeks old entitled "On REST, SOAP, and Web Service Architectures", where he makes a pretty good summation of issues.  The second paragraph in particular grabbed me:

Mostly you're just trading off interface and parsing simplicity for structural specificity and extensibility/negotiation (i.e. URI for WSDL, HTTP methods for SOAP headers). Its not clear to me that either are better in general, but if you're going to go through the bother of creating nicely formatted XML services (as opposed to simplistic RSS feeds, HTML pages, etc.) the service extensibility seems likely to be useful. Wrapper libs and a good dev tools should take the grunt work out of WSDL and headers and you end up with a more natural looking interface for programmable service interaction.

Social networking in Radiospace.  [Jon's Radio]

This is a really interesting article. On the one hand, this article itself points to a really important reason to have referers: I found this article through my referrers.

The strongest correlation connects Sam Ruby, Peter Drayton, and Gordon Weakliem... I'm sure none of those three would find this result surprising.

Doesn't surprise me that my channelroll would correlate me with Sam & Peter, they're 2 of the first sites I look at each day. Interestingly, I was at Chris Sells' Web Services DevCon where Peter was a presenter and Sam was in attendance. Maybe that's just when I started paying attention, but there seems to have been a huge burst of interest in blogging around WSDC. Sam Gentile, Jim Murphy, and Justin Rudd were also at the conference and have since started blogs (Jim's is a little sparse. Jim? You still there?). I'd never heard of Sam Ruby or Peter Drayton before the conference, but their sites gave me the impetus to write a little. Most interestingly to me, Chris Sells has even converted his homepage over to a /. like forum, which is kind of ironic, considering that his last post before DevCon was This is Not a Blog

For example, in a team situation, I might want to allow you not only to read my subscriptions, but also to subscribe me to sources that you know are relevant to our joint effort.

Interesting point, I think this has a lot of merit.  We've been working with Sharepoint Team Services at work trying to improve group communications.  I'm not sure it's working all that well, but one thing that we did is subscribe the email alias for the group to changes to certain key document libraries and discussion groups, so that people would get an email reminder to look at the site.  It's not nearly as nice as an RSS feed, but we're working on getting people to break the email/hallway conference habit, so email's more of a utilitarian solution. 

And yet we need to respect the uniqueness and power of this new mode, in which groups are defined fuzzily and coupled loosely.

To me, the great thing about the medium is the loose coupling.  I'm not sure about the more explicit mechanisms for clustering & grouping.  As my interests shift and I discover new sites, I think you'll see my subscription list change a great deal.  One other final point that others (Brad Wilson comes to mind) have brought up recently is the crying need for RSS as the glue for this coupling.  David Mc Cusker is about the only person without an RSS feed who I remember to read regularly, and clearly, RSS is the enabling technology for Jon's entire experiment.

John Lam has been trying to open up a discussion on enforcing development policies using Aspect Oriented Programming.  It seems like aspects work well in enforcing drudge work that's ancillary to the actual function of some code, i.e. logging. 

One thing that I've looked at is implementing billing for a web service using .NET attributes, which from the tiny bit that I understand about AOP, can be used to implement aspects statically.  While this is a specialization of the logging use case, it's a significant one.  The idea is that you can write some C# code (for example) like this:

[WebMethod,BillableMethod] public String HelloWorld() { return "Hello, World"; } 

The WebMethodAttribute is the standard .NET way of flagging a method to be exposed via SOAP, and the BillableMethod is my invention for flagging that a caller should be billed for calling this method.  (Clearly, many people would gladly pay for access to the HelloWorld method :-)  The .NET mechanism behind this is the System.Web.Services.Protocols.SoapExtensionAttribute and System.Web.Services.Protocols.SoapExtension classes.  You write a subclass for SoapExtension and then write a subclass for SoapExtensionAttribute, which has a method named ExtensionType where you return the SoapExtension subclass.  SoapExtension has a ProcessMessage method which takes a System.Web.Services.Protocols.SoapMessage object.  Generally, you inspect the Stage property of the SoapMessage object and do processing at one of the four stages: before and after serialization and deserialization.  In the billing example, you might log in the billing log that a particular user called the method in the BeforeDeserialize stage and log the result of the call in the AfterSerialize stage; this could be useful if you want to distinguish whether the call succeeded or failed; maybe you wouldn't charge for failed calls.

However, this doesn't address the issue that I think John is trying to get at, namely, how do you get around a code review to ensure that the aspects are applied correctly.  He talks about applying compile-time aspects that throw a compile time error if a policy was violated; in his example, if someone tried to bypass a factory pattern when instantiating an object.  I simply don't know if any of the .NET compilers support this type of extension, and it almost seems to me that the C# language, at least, gives you enough control to prevent this unless the programmer went to extremes, such as the reflection API, to circumvent it.

Congratulations to Sam Ruby on his election to the Apache Board of Directors.  Next stop, here?

Tommy Williams and Sam Ruby have been following their progress on Google. Somehow, having a name like Gordon Weakliem takes the fun out of this sort of research :-)  However, it is interesting to note that Google seems to have a strong bias for Radio results, probably because I update Radio much more than my other site.