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!
Wednesday, July 21, 2004
Friday, July 16, 2004
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
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
Tuesday, July 13, 2004
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.
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.
Friday, July 02, 2004
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
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
Thursday, July 01, 2004
Friday, June 25, 2004
I don't like breaking code that works....
Okay, so that's probably a pretty obvious thing to say, but I think it's turning into a debilitating disease. You see there's a new feature that I've got to add into the client code, I know that it's going to be a complete pain in the arse to add as it is a very special case. So basically I know that it's going to break things for a while till I've managed to get it working properly.
Obviously this code isn't going to go anywhere until it's working, I know that. I know that I'm the only person that is going to have to suffer an application that doesn't work properly, yet somehow this does not help me. I still don't want to start this work.
I think this stems from a general fear I had of breaking things when I started in this company, back in the dreaded old days when the didn't have version control! Yes I know! So we were constantly breaking things, obviously. A team of three working on the same code without version control, what else is going to happen.
I was chatting about these good old days with a friend who worked here back then. He's since run off back to acedemia (it was that scary at the time), but it's nice to chat about it with him. Gives me some perspective on how much better things are now.
Well I suppose writing this is just another way to put off the enevitable....maybe a quick coffee break first... ;)
Okay, so that's probably a pretty obvious thing to say, but I think it's turning into a debilitating disease. You see there's a new feature that I've got to add into the client code, I know that it's going to be a complete pain in the arse to add as it is a very special case. So basically I know that it's going to break things for a while till I've managed to get it working properly.
Obviously this code isn't going to go anywhere until it's working, I know that. I know that I'm the only person that is going to have to suffer an application that doesn't work properly, yet somehow this does not help me. I still don't want to start this work.
I think this stems from a general fear I had of breaking things when I started in this company, back in the dreaded old days when the didn't have version control! Yes I know! So we were constantly breaking things, obviously. A team of three working on the same code without version control, what else is going to happen.
I was chatting about these good old days with a friend who worked here back then. He's since run off back to acedemia (it was that scary at the time), but it's nice to chat about it with him. Gives me some perspective on how much better things are now.
Well I suppose writing this is just another way to put off the enevitable....maybe a quick coffee break first... ;)
Thursday, June 24, 2004
Self-publishing.
Some time ago I read this article on Java.net.
My adventure in Self-Publishing [June 24, 2004]
I was interested in these experiences, perhapse thinking about the future. The reason I bring this up now is that a friend of mine is trying self-publishing for comics.
The Variance Anthology
They are using the Cafepress.com system, which is publising on demand. There are no up front costs. There are currently only 8 books in their programming section so there might be a gap in the market for the entrepreneurially minded.
Some time ago I read this article on Java.net.
My adventure in Self-Publishing [June 24, 2004]
I was interested in these experiences, perhapse thinking about the future. The reason I bring this up now is that a friend of mine is trying self-publishing for comics.
The Variance Anthology
They are using the Cafepress.com system, which is publising on demand. There are no up front costs. There are currently only 8 books in their programming section so there might be a gap in the market for the entrepreneurially minded.
Wednesday, June 16, 2004
XSLT sorting on dates
Roll on XSLT v2 is all I can say. First off, I've not blogged for the last few days due to a sudden and rather large amount of work, which was not Java or XML related, so I didn't have that much to post about. However today we got a query from a licensee of our technology. I'm not going to go into masses of detail about our technology (mostly because it's not that interesting) but needless to say at the end of hte pipeline it produces output (HTML, TEXT, XML, PDF etc) by passing the output XML through XSLT.
This licensee was asking (read moaning!) about that fact that data information came out in the XML as either "YYYY-MM-DD G" or similar with a time on the end. For those of you who may not recognise it the "G" is the Era, i.e. "AD" or "BC". He said he couldn't do any sorting on it in the XSLT.
One of my biggest issue with people is when they ask for help without even trying to find the answer themselves, I judge this by how long it takes me to find the answer....
...10 minutes with the excellent Zvon XSLT Reference and Stylus Studio and I had all dates ordering correctly with only 9 lines of XSLT. You can imagine the curt yet polite response to the licensee.
Still, all of this sort (no pun intended) of thing will be a lot easier when XSLT v2 is available, however I do think that will be a long time coming. After talking to Michael Kay, creator of Saxon and Jacek R. Ambroziak creator of XSLTC at Sun and now the Gregor/XSLT compiler at XML Europe last year, XSLT v2 sounds like it will be much harder to implement and more importantly optimise in XSLT processors.
Roll on XSLT v2 is all I can say. First off, I've not blogged for the last few days due to a sudden and rather large amount of work, which was not Java or XML related, so I didn't have that much to post about. However today we got a query from a licensee of our technology. I'm not going to go into masses of detail about our technology (mostly because it's not that interesting) but needless to say at the end of hte pipeline it produces output (HTML, TEXT, XML, PDF etc) by passing the output XML through XSLT.
This licensee was asking (read moaning!) about that fact that data information came out in the XML as either "YYYY-MM-DD G" or similar with a time on the end. For those of you who may not recognise it the "G" is the Era, i.e. "AD" or "BC". He said he couldn't do any sorting on it in the XSLT.
One of my biggest issue with people is when they ask for help without even trying to find the answer themselves, I judge this by how long it takes me to find the answer....
...10 minutes with the excellent Zvon XSLT Reference and Stylus Studio and I had all dates ordering correctly with only 9 lines of XSLT. You can imagine the curt yet polite response to the licensee.
Still, all of this sort (no pun intended) of thing will be a lot easier when XSLT v2 is available, however I do think that will be a long time coming. After talking to Michael Kay, creator of Saxon and Jacek R. Ambroziak creator of XSLTC at Sun and now the Gregor/XSLT compiler at XML Europe last year, XSLT v2 sounds like it will be much harder to implement and more importantly optimise in XSLT processors.
Thursday, June 10, 2004
Web services stacks
I've been following the Apache Web Services mailing lists of late and there is interesting talk of them release a Web Services Pack, as an alternative to Sun's.
This is great news, I think. However what we need is some nice independant group to do interoperability testing for these. Which I think should be part of the WS-I remit. Surely it would be easy for them to set up their Basic and Security profile tests using each of the stacks and cross-test them.
Personally for completness sake I would like this to extend to other languages, such as PHP, C/++ etc. As a developer I want to know which specifications I can use without cutting off people using other languages, for example which languages and implementation stacks have WS-ReliableMessaging implementations and are they compatible.
I'd really like to see a set of flexed aggregations of Web Service implementation stacks pulled together that implemented as much of the standards stack as they could across all implementations. This should be cross-tested, WS-I tested and offered in two variants, server and minimal client (so for example the server Reliable Messaging layer would use a RDBMS and the client would have an in-memory embedded db) to keep client application distributions small.
Well this is the web service nirvana that I dream of, what do you think.
I've been following the Apache Web Services mailing lists of late and there is interesting talk of them release a Web Services Pack, as an alternative to Sun's.
This is great news, I think. However what we need is some nice independant group to do interoperability testing for these. Which I think should be part of the WS-I remit. Surely it would be easy for them to set up their Basic and Security profile tests using each of the stacks and cross-test them.
Personally for completness sake I would like this to extend to other languages, such as PHP, C/++ etc. As a developer I want to know which specifications I can use without cutting off people using other languages, for example which languages and implementation stacks have WS-ReliableMessaging implementations and are they compatible.
I'd really like to see a set of flexed aggregations of Web Service implementation stacks pulled together that implemented as much of the standards stack as they could across all implementations. This should be cross-tested, WS-I tested and offered in two variants, server and minimal client (so for example the server Reliable Messaging layer would use a RDBMS and the client would have an in-memory embedded db) to keep client application distributions small.
Well this is the web service nirvana that I dream of, what do you think.
Subscribe to:
Posts (Atom)