Identifying resources

After a chat with Owen Rees at HP Labs in Bristol, which originally started off about URIs and whether they should be dereferenceable or not (that old chestnut), it would seem that one way to generate a unique identifier for a file is to create an MD5 checksum for it. Each instance of the resource, that is identical, will have the same checksum, a revision would have a different checksome. Of course, if you start embedding some form of date stamp metadata into a file, it's checksum will be different every time. Quite a cute idea I thought. Maybe even add mix it with the Tag URI scheme too?

Exception handling, a general strategy...

It will be important to build a generalized strategy for exception handling throught the SOA-R development process. This applies to both the capture and the reporting of exceptions. In my previous posting regarding slogs (service logs) I indicated that generating log feeds (RSS) provides a more accessible interface to the service logs and allows value added features like built-in links for reporting exceptions.

Modeling message packages

There will be a hierarchy in the structure of message packages. An abstract Package class will provide a means by which all package sub-classes like XMLTransform, Render and maybe even sub-classes of Render like RIBRender or YafrayRender can inherit the basic properties and methods required to construct and manipulate a SOA-R message package. An alternative might be to use an Interface instead, but if I change the interface existing code may break. So I'll have to make sure I'm happy with it before I enshrine it in an interface. I have decided to call the class (or interface) a 'JobBag'. It would seem fit for the purpose. Now, do you suppose that by passing a load of metadata in the JobBag, that the message would derive any advantage from being expressed in RDF/XML rather than just plain XML? If I create my own WSDL then I'd be free to define the schema as I see fit. But am I just gilding the Lilly - so to speak?

Web Service logging, or is that slogging?

When generating logs, primarily error logs but could also be used for activity logging, the format of SOA-R logs will be RSS. More specifically, RSS 1.0 (RDF). This will allow for easier access to web service logs via RSS readers, as well as providing either CSS or XSLT stylesheet PIs to provide default styling/transformations respectively. In addition, the error log items will have as their link a means of posting the error/exception info to the administrator. Other nice features could include in the activity log, a thumbnail of each transform and a link to, for example, the client (mailto or website). The additional metadata will use Dublin Core plus whatever else seems appropriate to classify the contents of any particular item. You could call them 'Service Logs', or 'slogs' for short!

And so it begins...

This blog will cronical my journey towards establishing a distributed CGI rendering architecture using Web Services. The initial development will be under the Mono .net framework but in time will include a Java implementation too.