Semantic slogging!

The whole point of using RSS 1.0 for the service logs was to ensure that the data captured in the slog(s) carried some semantic meaning. Therefore, it will be necessary to create an RDF schema for classifying slog entries. The most important area will be error logs. It will be useful to classify errors so that an administrator can query a set of logs and obtain statistics on the types and frequencies of errors that are occurring in services, be they local or distributed. Usage patterns and the like can be inferred from the entries in activity slogs. Through an administrators interface, it should be possible to interrogate a slog and attach additional/new classifications to slog entries.

Should slogging be provided by a web service?

There is the danger of getting a bit 'web service happy', but if service logging was provided by a web service then you could either centralize or distribute service logging as you see fit and the whole logging system could become a self contained entity. I guess it would lead to a lot of unnecessary traffic as requests are made to 'slog this for me please'. But then again the service making the request could get on with it's work while another gets on with the tedious job of writing log stuff out to a file system.

Administering slogs

An administrator's interface for managing, reviewing an maintaining the service logs would be a useful tool. The administrator would be able to view all logs (slog aggregator) and in the case of distributed services there could be many, and from the one interface manually archive, clear, interrogate, and configure the service logs.

Need service calls to archive/clear logs

It is very important that there are service calls available to archive and clear log files remotely. It would then be possible to have cron jobs running that archived the logs at regular (daily, weekly depending upon usage I guess) intervals.

Where do log entry links lead?

When a log is presented as an RSS feed, by definition the feed is a summary, and therefore each entry should be a summary of the activity and/or error. Therefore, the item's link should point to the full log entry. In the case of an activity log entry, the link's target will be a full description of the activity and include all metadata available. For an error log you will have access to the exception stack trace and a link (mailto: or similar) that can be used to submit the details of the exception (plus comments) to the service provider.

The furtherance of slogging

I have been 'slowly' adding to the service log by building up the parts of the log feed. I originally chose RSS 1.0 because I wanted the RDFishness but I wonder whether the overhead is really worth it. I mean I could use RSS 2.0 which is cleaner and still have the namespaced metadata components that I want. But, then again I think I'll stick with it because this is my project, my work, my time and therefore it's my call :)

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.