Cut-and-paste from the formal W3C announcement:
"W3C is pleased to announce the advancement of "Web Services Addressing 1.0 - Core" and "Web Services Addressing 1.0 - SOAP Binding"
to Proposed Recommendations:
http://www.w3.org/TR/2006/PR-ws-addr-core-20060321/
http://www.w3.org/TR/2006/PR-ws-addr-soap-20060321/
Please review these specifications and indicate whether you endorse them as W3C Recommendations or object to their advancement by completing the following questionnaire:
http://www.w3.org/2002/09/wbs/33280/wsaddr-cs-pr/
There were no new Formal Objections since the transition to Candidate
Recommendation. Additional details about the transition are available in the questionnaire.
The deadline for responses is 23:59, Boston time on 2006-04-18.
For more information about the Web Services Addressing Working Group:
http://www.w3.org/2002/ws/addr/"
Good news!
I work for Red Hat, where I lead JBoss technical direction and research/development. Prior to this I was SOA Technical Development Manager and Director of Standards. I was Chief Architect and co-founder at Arjuna Technologies, an HP spin-off (where I was a Distinguished Engineer). I've been working in the area of reliable distributed systems since the mid-80's. My PhD was on fault-tolerant distributed systems, replication and transactions. I'm also a Professor at Newcastle University and Lyon.
Tuesday, March 21, 2006
Laugh? I nearly cried!
Ever wondered what if some of our luminaries had tried to publish today? Well I encourage you to go and see!
Thursday, March 16, 2006
WS-Eventing, WS-Transfer and WS-Enumeration to W3C
Whilst it is good to see WS-Eventing, WS-Transfer and WS-Enumeration finally go to a standards body, it not necessarily a good thing. As Paul points out on Savas' blog, these specifications have been used in yet another political game of chess, in the same way as WS-ReliableMessaging/WS-ReliableExchange or WS-CAF/WS-TX. One good thing is that this time IBM are on the receiving end, despite what they may say.
Ignoring the technical merits (or lack thereof) of these specifications, one thing that simply cannot be ignored is the fact that this will now cause more fractures within the WS-* architecture, and not less. Two competing specifications, within two different (and often competing) standards bodies, will mean yet more FUD and delay as far as vendors and customers are concerned. At least when these current specifications were purely vendor specific, customers who wanted a standard approach to events (for example), had only one choice. Now they don't have any: they've got to wait until something is sorted out.
Now don't get me wrong: I'm not disagreeing that these things shouldn't be in a standards body. Quite the contrary: I believe strongly that they should be. I just wish that the likes of IBM and Microsoft could have gotten together 2 years ago and sorted this out, so we had a single standard now! I think that the world of Web Services can learn a lot from the OMG in terms of how to work collaboratively. It's not perfect by any means, but it's inclusive, which the world of Web Services standards simply is not. There's a lot of rubberstamping going on.
Ignoring the technical merits (or lack thereof) of these specifications, one thing that simply cannot be ignored is the fact that this will now cause more fractures within the WS-* architecture, and not less. Two competing specifications, within two different (and often competing) standards bodies, will mean yet more FUD and delay as far as vendors and customers are concerned. At least when these current specifications were purely vendor specific, customers who wanted a standard approach to events (for example), had only one choice. Now they don't have any: they've got to wait until something is sorted out.
Now don't get me wrong: I'm not disagreeing that these things shouldn't be in a standards body. Quite the contrary: I believe strongly that they should be. I just wish that the likes of IBM and Microsoft could have gotten together 2 years ago and sorted this out, so we had a single standard now! I think that the world of Web Services can learn a lot from the OMG in terms of how to work collaboratively. It's not perfect by any means, but it's inclusive, which the world of Web Services standards simply is not. There's a lot of rubberstamping going on.
Wednesday, March 15, 2006
RFID and security
We used to collaborate with Andy Tanenbaum and his group a lot back in the late 1980's and early 1990's, so it's nice to get an update on what they're doing these days. Very interesting.
Tuesday, March 14, 2006
Somethings just don't make sense
There are many things in life that just don't make sense. For example, how can you have South Park without Chef? Whatever happened to Cold Fusion? Or the entire "plot" of Highlander II! But probably the one that gets to me at the moment (because it's related to my job) is how on earth can there be such a thing as a legacy ESB?!
Since it sprang to life, the ESB term has been used to mean different things to different people. For example, to some it's JMS with a few extra bells and whistles, to others it's Web Services, and to yet others it's the saviour of EAI. However, over the past couple of years, one thing that almost everyone can agree on is that it should be an infrastructure for SOA applications. Now we all know that one of the things SOA is good for is leveraging existing infrastructural investments: letting you use your old stuff in new and interesting ways.
So it always seemed to me that a product that helps you implement SOA applications (quick note, SOA is not something you can get out of a shrink-wrapped box), shouldn't be part of the legacy problem! And yet when I was with Arjuna, I came across a number of large and small companies that were already being forced to work with legacy ESBs! These were products (names removed to protect the guilty parties) that, once integrated into the user's infrastructure, couldn't cope with changes in user requirements a matter of mere months or years later; plus they were so intertwined with that infrastructure that they simply couldn't be removed (or it wasn't worth the effort). So these companies then had to rely on yet more ESB implementations to talk to their legacy ESBs! And the vicious circle went on. Not exactly a good return on your investment!!
Now I'm not saying that we're going to reverse that trend, but I'd like to think we'll try not to fall into the same holes that others have. However, it's still an interesting contradiction, sort of like military intelligence.
Since it sprang to life, the ESB term has been used to mean different things to different people. For example, to some it's JMS with a few extra bells and whistles, to others it's Web Services, and to yet others it's the saviour of EAI. However, over the past couple of years, one thing that almost everyone can agree on is that it should be an infrastructure for SOA applications. Now we all know that one of the things SOA is good for is leveraging existing infrastructural investments: letting you use your old stuff in new and interesting ways.
So it always seemed to me that a product that helps you implement SOA applications (quick note, SOA is not something you can get out of a shrink-wrapped box), shouldn't be part of the legacy problem! And yet when I was with Arjuna, I came across a number of large and small companies that were already being forced to work with legacy ESBs! These were products (names removed to protect the guilty parties) that, once integrated into the user's infrastructure, couldn't cope with changes in user requirements a matter of mere months or years later; plus they were so intertwined with that infrastructure that they simply couldn't be removed (or it wasn't worth the effort). So these companies then had to rely on yet more ESB implementations to talk to their legacy ESBs! And the vicious circle went on. Not exactly a good return on your investment!!
Now I'm not saying that we're going to reverse that trend, but I'd like to think we'll try not to fall into the same holes that others have. However, it's still an interesting contradiction, sort of like military intelligence.
Friday, March 10, 2006
WS-Policy re-release
The next (and simplified) version of WS-Policy is out. My spider-sense tells me a push for standardisation may come next.
Thursday, March 09, 2006
Spotlight and Google Desktop
I've been using a Mac OS X machine at home for over a year and one of the features I really love about Tiger is spotlight. It's really easy to use and before I knew it, I'd become dependant upon it: any search for text, images etc, would drag me first and foremost to spotlight. No more using the clunky Thunderbird email search, or grep (yes, I also use emacs). It's great.
That's great for my Mac, but my main work machine is a Windows box. So I've been putting off installing Google Desktop for ages because I'd heard some bad things about it. But after checking with a few people who have actually been using it, I decided to give it a whirl. It's not as good as spotlight (indexing seems to take an age!), but it's good nonetheless. I think I'll stick with it for a while.
That's great for my Mac, but my main work machine is a Windows box. So I've been putting off installing Google Desktop for ages because I'd heard some bad things about it. But after checking with a few people who have actually been using it, I decided to give it a whirl. It's not as good as spotlight (indexing seems to take an age!), but it's good nonetheless. I think I'll stick with it for a while.
Saturday, March 04, 2006
WS-Addressing interoperability fest
We've been taking part in the WS-Addressing interoperability work during the W3C Plenary in Cannes. (We did it remotely, so no nice trips to the South of France for us.)
I produced our first WS-Addressing implementation as part of the Web Services transactions implementation, which we then tested as part of the WS-TX interoperability workshop. But that was the August 2004 version of the specification and things have moved on since then, both with WS-Addressing and our product. So this interoperability event was around the latest Candidate Recommendation from the working group, which required us to change our addressing implementation. Unlike with the Raleigh event, where we shared the effort, this time Kevin had the lion's share of the work to do. It was touch-and-go at times, but it eventually paid off and we demonstrated interoperability with IBM, Microsoft, Sun and WSO2/Apache. There's still a bit more work to do over the next week or so, but it looks like we'll have a pretty good story on the interoperability of the specification, as well as our implementation.
Thanks to everyone who participated from the various companies (within the working group and in testing), and particularly to Kevin!
I produced our first WS-Addressing implementation as part of the Web Services transactions implementation, which we then tested as part of the WS-TX interoperability workshop. But that was the August 2004 version of the specification and things have moved on since then, both with WS-Addressing and our product. So this interoperability event was around the latest Candidate Recommendation from the working group, which required us to change our addressing implementation. Unlike with the Raleigh event, where we shared the effort, this time Kevin had the lion's share of the work to do. It was touch-and-go at times, but it eventually paid off and we demonstrated interoperability with IBM, Microsoft, Sun and WSO2/Apache. There's still a bit more work to do over the next week or so, but it looks like we'll have a pretty good story on the interoperability of the specification, as well as our implementation.
Thanks to everyone who participated from the various companies (within the working group and in testing), and particularly to Kevin!