WS-Reliability specification released
Wow, no sooner do I start to moan about how WS-* stack specification are not taking WSDL into account than this is released from OASIS.
Cover Pages: OASIS WSRM TC Releases Web Services Reliable Messaging (WS-Reliability) Version 1.1.
I haven't had time to go over the specification in detail yet, but it does appear to deal with the implications for WSDL. I will let you know.
Tuesday, September 14, 2004
Monday, September 13, 2004
Why you cannot describe a Web Service ... or how I bullied an Oracle product manager.
I am embarking on a new pet project at home, to do with Web Services. I won't go into too much detail in this posting as I am sure I'll be going on and on about it in the coming months. Basically though it is to do with generating dynamic proxies for SOAP Web Services and doing this from service descriptions such as WSDL and UDDI.
For this project I would like to be able to support a more fully WS-* stack, including WS-Security, WS-ReliableMessaging and WS-Addressing. The problem I am having can be seen with WS-Security.
There is no where in the WS-Security specification that advises on how you declare this requirement in WSDL documents. Therefore from a WSDL there is no way to know that you need to apply WS-Security.
WSDL is meant to desribe the interfact to the service, the clues in the name, however if the service is any more complex than basic SOAP this is not possible. This seems to me to be a glaring ommision.
The WS-Security Specification states that "Advertisement and exchange of security policy." is a "Non-goal", but surely is cannot be the responsibility of the WSDL group to deal with this.
You may have read my previous post Our WebDAV love affair? where I have a bit of a go at the WebDAV specifications, however there is one place where they have done amazing work which is understanding how to build a stack of specifications. In any of the extending specifications there are clear statements on how these effect the other specifications.
My major concern is that I cannot find any work going on in this, the the WSDL 2.0 Feature element might be something for this, but if the extension specifications continue to see this as something for other people to deal with then who will come up with the vocabulary for this to work.
The second part of the title for this posting is about me bullying an Oracle product manager. On Friday I went to the London Java Special Interest Group meeting where there was a presentation from RSA on Identity and Federation and then one from Oracle on the new WS-Security features in their App Server and JDeveloper 10g.
Part of this was a demo of building a WS-Security enabled SOAP Service in JDeveloper, which I have to admit looked to be an extremely easy process. The simple service was exposed, including building the WSDL, and then WS-Security was added to it.
I asked if the WSDL file had in anyway been changed when adding the WS-Security, and as I expected it hadn't. A couple of other people then commented on this, obviously not have come up against this problem before. Unfortunately someone then asked to see the building of a client stub for that service, which was also a completely painless process.
My bullying then came in the form of pointing out that the client blatently would not work as it had been built from the WSDL which did not advertise the fact that encryption and digital signatures where required. I feel I should publicly appologise to this guy and state that aside from this, which is not the fault of JDeveloper or anyone at Oracle, the demo was really good and their next generation product line does seem to be very good.
As for the problems with WSDL and the WS-* stack, well I guess we are all going to have to wait for this, and perhapse try to get the WS-I to expand their remit to look at this kind of thing.
I am embarking on a new pet project at home, to do with Web Services. I won't go into too much detail in this posting as I am sure I'll be going on and on about it in the coming months. Basically though it is to do with generating dynamic proxies for SOAP Web Services and doing this from service descriptions such as WSDL and UDDI.
For this project I would like to be able to support a more fully WS-* stack, including WS-Security, WS-ReliableMessaging and WS-Addressing. The problem I am having can be seen with WS-Security.
There is no where in the WS-Security specification that advises on how you declare this requirement in WSDL documents. Therefore from a WSDL there is no way to know that you need to apply WS-Security.
WSDL is meant to desribe the interfact to the service, the clues in the name, however if the service is any more complex than basic SOAP this is not possible. This seems to me to be a glaring ommision.
The WS-Security Specification states that "Advertisement and exchange of security policy." is a "Non-goal", but surely is cannot be the responsibility of the WSDL group to deal with this.
You may have read my previous post Our WebDAV love affair? where I have a bit of a go at the WebDAV specifications, however there is one place where they have done amazing work which is understanding how to build a stack of specifications. In any of the extending specifications there are clear statements on how these effect the other specifications.
My major concern is that I cannot find any work going on in this, the the WSDL 2.0 Feature element might be something for this, but if the extension specifications continue to see this as something for other people to deal with then who will come up with the vocabulary for this to work.
The second part of the title for this posting is about me bullying an Oracle product manager. On Friday I went to the London Java Special Interest Group meeting where there was a presentation from RSA on Identity and Federation and then one from Oracle on the new WS-Security features in their App Server and JDeveloper 10g.
Part of this was a demo of building a WS-Security enabled SOAP Service in JDeveloper, which I have to admit looked to be an extremely easy process. The simple service was exposed, including building the WSDL, and then WS-Security was added to it.
I asked if the WSDL file had in anyway been changed when adding the WS-Security, and as I expected it hadn't. A couple of other people then commented on this, obviously not have come up against this problem before. Unfortunately someone then asked to see the building of a client stub for that service, which was also a completely painless process.
My bullying then came in the form of pointing out that the client blatently would not work as it had been built from the WSDL which did not advertise the fact that encryption and digital signatures where required. I feel I should publicly appologise to this guy and state that aside from this, which is not the fault of JDeveloper or anyone at Oracle, the demo was really good and their next generation product line does seem to be very good.
As for the problems with WSDL and the WS-* stack, well I guess we are all going to have to wait for this, and perhapse try to get the WS-I to expand their remit to look at this kind of thing.
Back after a long break.....
So this is my first post in a while, mostly because I've been away from the office for the best part of seven weeks. This has been due to take-it-or-loose it holiday and training that my company has sent me on.
The holiday time was great, with some of it spent back home with the folks attending a family wedding and some of it spent in Rome.
Last weekend also saw the third annual 24x24, 24 hours watching the third season of 24 in sync, so starting at 1:00pm. Always much fun, this year was a little different as I'd not seen the season before this.
The training I went on was, hmmmm shall we say "interesting". It was a week long Business Analysis course and three days of Introduction to Consultancy Skills. Most of the company went on both of these, as they are seen as key skills, even for developers. Certainly opened my eyes to a different way of working.
As part of the Consultancy Skills course I took the Belbin test to discover my preferred team working roles. A little worryingly I got zero for the co-ordinator role, however I scored highly on the specialist and completer-finisher roles which does seems to make sense.
Anyway, more technical postings to come, just thought I'd get a hello post in there first.
So this is my first post in a while, mostly because I've been away from the office for the best part of seven weeks. This has been due to take-it-or-loose it holiday and training that my company has sent me on.
The holiday time was great, with some of it spent back home with the folks attending a family wedding and some of it spent in Rome.
Last weekend also saw the third annual 24x24, 24 hours watching the third season of 24 in sync, so starting at 1:00pm. Always much fun, this year was a little different as I'd not seen the season before this.
The training I went on was, hmmmm shall we say "interesting". It was a week long Business Analysis course and three days of Introduction to Consultancy Skills. Most of the company went on both of these, as they are seen as key skills, even for developers. Certainly opened my eyes to a different way of working.
As part of the Consultancy Skills course I took the Belbin test to discover my preferred team working roles. A little worryingly I got zero for the co-ordinator role, however I scored highly on the specialist and completer-finisher roles which does seems to make sense.
Anyway, more technical postings to come, just thought I'd get a hello post in there first.
Wednesday, July 21, 2004
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!
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!
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... ;)
Subscribe to:
Posts (Atom)