Our WebDAV love affair?

A while ago my company met WebDAV, we spied it across a crowded room and knew instantly that it was the technology that we want to be with, forever. Thus followed a whirlwind romance and a very quick marriage.

Now we have been together for 2 years and the honeymoon is definitely over, but unfortunately we've had kids and now divorce seems as problematic as trying to work around our issues. We have a mistress on the side, SOAP Web Services, to provide what is missing from our relationship with WebDAV. What is to be done.

At this point I should make sure that you understand that I am in no way having a go at the people who have worked tirelessly to bring the WebDAV family of specifications to the point that they are at now. The work they have done is great, on a standard that doesn't have anywhere near the support that it should and one that has been implemented in a bad way many times.

The IETF WebDAV group began officially on March 20th 1997, there is now the core WebDAV specification, DeltaV versioning extensions specification, Ordered Collections, Access Control Extensions and the in progress DASL Searching specification. Pulled together these form, on the surface at least, a well rounded set of specifications, however 2 years is a long time to get to know something.

We started working with WebDAV because our company had instituted research days, once a month, for all the developers. We each got to try out new and interesting things as long as they were something to do with what we do, which is build online information systems with a heavy focus on use of metadata. One of our developers was exploring the idea of layer new interfaces onto the CMS aspect of our server software. He got FTP working, then Telnet and finally tried out WebDAV.

It was a good fit, we have resources to which we allow people to attach metadata, which is exactly what WebDAV gives you. Straight away we ran into 2 problems, the first was that there is no way in WebDAV to supply to the client application the definitions for each of the properties. Secondly there is no agreed way to pass around multiple values for a property. A property can simply contain <xs:any/> element.

So we designed extensions to WebDAV for this, which worked well, and completed the implementation of the core specification. We skirted around having to implement the immature versioning specification by simplifying the view over our versioning and relating these through metadata. We used the HTML <ol/> and <li/> constructs for the multiple values, which was a work around proposed by the Dublin Core group. This was the basis for our first release.

Since then we have gone on to expand on the metadata definitions extension, we've move the multiple values constructs over to using the SOAP specification array concepts and implemented DeltaV versioning, Ordered Collections and DASL searching.

To a degree all of this has worked. I say to a degree because there are problems with these specifications. You need only look at the changes in the recent revision to the core specification to begin to understand how much needed clarification. There is not enough integration across the specifications, our implementation of the DeltaV specification had to skirt the lines across 2 of the different implementations flavours to be able to lay on top of our versioning system, which isn't that unusual.

There are missed opportunities, such as the lack of a definition of what a Principal is. In the LOCK specification the lock owner is a URI to information about this user. In the versioning specification there is also talk about users and URIs to information about them and finally in the Access control extension there are Principals, with WebDAV paths to them. However these Principals, and the WebDAV path/URIs, are in no way specified as being the same as the other user URIs. We have assumed this, and gained so much more out of it.

User handling is perhaps the area of greatest weakness, there are others mostly stemming from the specifications not quite explaining things enough (could of course just be me being thick). But yes, user handling is the worst, again not really WebDAV's fault, mostly from the awful way in which HTTP authentication works. We have ended up plugging these gaps with Web Services.

So I guess my advice is that WebDAV worked well for us, it got us up and running fairly quickly without having to design a comms protocol ourselves, but we have spent a long time tailoring and extending it to meet our exact needs, generic though it is you just cannot use it as the sole protocol for an entire system even though it might look like you can at first.

WebDAV and us will not be getting a divorce anytime soon, but I will definitely think twice the next time my eyes meet those of such a lovely technology across a crowded room!

Went to a LemonJelly gig last night...

First gig in a while and the second time I've seen LemonJelly live. Had a really great time, hope eveyone else that was there (Somerset House in London) did too.

Lemon Jelly

The return of the DateField...again!

So the date field has a fatal flaw. You might remember my description of the component that I create including a restriction that for each date block, year or month etc, the intended input must match the length of the format. For example for months the format should be MM and it will expect 2 digits.

The unexpected problem is that in a project we are doing for a museum we have dates going back to 50,000 BC....bugger.

Do you UDDI?

Ther have been many articles over the last few months about people not using UDDI, in fact apparently (according to most of these articles) people are not even thinking about using UDDI.

I find this most interesting. I for one agree with those people that believe any moves towards a Service Oriented Architecture must include the implementation and use of UDDI. If I were dictating terms for an SLA to go to consumers of a service that my company provided I would insist that part of that agreement forced them to do dynamic UDDI look ups for finding the endpoint to bind to.

Doing this gives the provider much more freedom in provisioning the service and the consumer can be much more certain that a service is not going to be interrupted for a silly reason such as moving location.

I've worked on large web service implementations for Government projects and have been astounded that UDDI is not being used at a project level at least. I am even more astounded that there appears to be no plan at all for Government to implement a centralised UDDI server.

A lot of extremely good work is being done on web services, and use of XML and metadata etc, generally within the UK Government so I am amazed at that this does not appear to have been raised at all.

Now I should point out that I don't have direct access to the powers that be within eGov over here, so I may be missing something. Perhapse this has been looked at and discounted, maybe it is in the works (although I would have thought it would be here now or that I would have heard if this was the case)>

Perhapse the fault should lie with the UDDI vendors themselves? I don't know I've never tried to purchase a solution, because none of our clients have asked for one. I have a sneaky suspition that some of the blame should lie with the API people, as there is nothing I can see in the Web Service APIs I've used which actively encourages this practice. I just don't know.

Perhapse there is too much bad association with the UBR, which I really believe was doomed to failure from the moment the concept was started.

I would be very interested in others thoughts on this matter, so please post away.

Dynamic Discovery and Invocation of Web services

Been ill...

Actually I've been off of work for the last couple of days due to a mix of tube strike and feeling ill. Will be back online next week.