There’s a generally held belief in theoretical and applied physics that nothing is continuous and everything comes in discrete packets (quanta). Light, atomic particles, even time, have their own quantum behaviour and their own sizes for a quanta. Furthermore, these entities possess both wave and particle natures. My old physics teacher used to call these wavicles. Now this discrete nature of things is only really "observable" at the microscopic level; where we live, on the macroscopic level, our eyes, senses and most machines simply can’t discern the individual quanta and we perceive them as continuous.
So where’s all this leading, you might ask? Well I’m in New York at the moment at the Web Services on Wall Street conference. I just flew into Kennedy and while waiting for a taxi at the airport I realised that every single time I’ve been here before it always goes the same way: you get off the plane, spend 50 minutes going through customs and then spend another 50 minutes waiting for a taxi; when they do arrive, they always turn up in fours. So, the size of an airport taxi-quanta is 4. My question is: why? Is there some physical process that does that, or is it some fundamental law of the universe? Whatever the reason, after travelling for over 12 hours, as Eric Cartman would put it, that extra wait p*sses me off! And let's not forget that there's always some taxi-rank "conductor" (sorry, can't think of the right term at the moment) who seems to think that blowing a whistle really loud will make things better. No, all it does it deafen the people standing in the queue!!
BTW, taxi’s also exhibit other quantum behaviour, specifically Heisenberg’s Uncertainty Principle, which in one of its incarnations says that you can’t measure position and momentum precisely. For taxis, if you need a taxi you can never find one though there are always plenty of empty ones speeding around; when you don’t want one, there are plenty parked in the road!
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.
Sunday, January 30, 2005
Friday, January 28, 2005
A real world example of context over object key
While writing this entry I got to thinking about what was a good real world example of the benefits of a context-based approach to sessions and state management. The one I came up with is fairly obvious (particularly with 20-20 hindsight): snail mail.
So how is this a good example of referencing via context? Well let's look at how we might model this architecture using two different approaches. In both cases, obviously the goal is to get some information (the content of the letter) to an entity that can deal with it (the person/organisation on the front of the envelope).
In the first approach (WS-RF) the address on the envelope is a hard reference to the ultimate receiver and therefore I would be required to deliver the message directly to that house. If the individual moved, then I'd need to figure out where he'd gone (maybe he would stick a redirect message on the front-door, but there are obvious limits to how much effort I'm going to go to there).
Now let's go back to the way the snail-mail post really works. I'm fairly sure mail delivery works pretty much the same throughout the world, but here in the UK when you've addressed and stamped a letter you stick it into a postbox - you never deliver it by hand. Now that letter doesn't go directly to the individual on the address; it is routed via a sorting office, which may then pass it to other offices in this country or even abroad. Ultimately it'll end up in a sorting office that is local to the final destination and a postman will be given the job of delivering the letter (probably at 1pm in the afternoon if my post is anything to go by!)
So, implicit with every address I put on a letter is the address of the local sorting office. They know where the ultimate receiver is and I don't need to (which is good because I'd hate to have to run something like MultiMap each time I wanted to find out where someone lived). If he's moved, he can arrange to have mail diverted to a new location simply by telling them. Obviously this can't go on forever and eventually becomes a matter of diminishing returns, but that's up to the householder.
In this case, the initial destination (service) for my letter is the post office (as I said, implicitly addressed in the physical world) and the context associated with the message is what I stick on the front of the envelope: it's my session information and is the same for all letters I write to that individual. How the post office "service" gets the content of my letter to the recipient is a backend implementation choice. They can (and have) changed that implementation many times over the years, but the way I write my envelopes (the context) never changes.
If the ultimate receiver does eventually move, I may get a new context from them (setting up a new session) or the equivalent of a 404 (Not Found) message.
Trying to be even handed, I suppose another way of approaching this would be to say that the binding of SOAP-to-PostOffice implicitly does all of this routing/redirecting for me, but that then relies on a specific medium. I'd like this to work no matter what carrier medium I use.
You could also argue that the post office (or actually the sorting office) that is implicitly addressed in the physical world suffers from the same static address problem. But it doesn't - as far as my letter is concerned it is stateless; the letter could just as easily be dealt with by any sorting office in the country (hey, the model allows me to post my letter anywhere after all). So this is an example of where any "service" that offers the same functionality (dealing with post in this case) can be used: I'm not tied to a specific instance.
Of course another way of looking at this is that it's all just
hierarchical naming again. However, I think it just shows that abstracting the *what* (my ultimate receiver) out of the *how* (the post office in this case), makes for a scalable system. (Except at Christmas, where they almost never guarantee delivery dates for postcards!)
So how is this a good example of referencing via context? Well let's look at how we might model this architecture using two different approaches. In both cases, obviously the goal is to get some information (the content of the letter) to an entity that can deal with it (the person/organisation on the front of the envelope).
In the first approach (WS-RF) the address on the envelope is a hard reference to the ultimate receiver and therefore I would be required to deliver the message directly to that house. If the individual moved, then I'd need to figure out where he'd gone (maybe he would stick a redirect message on the front-door, but there are obvious limits to how much effort I'm going to go to there).
Now let's go back to the way the snail-mail post really works. I'm fairly sure mail delivery works pretty much the same throughout the world, but here in the UK when you've addressed and stamped a letter you stick it into a postbox - you never deliver it by hand. Now that letter doesn't go directly to the individual on the address; it is routed via a sorting office, which may then pass it to other offices in this country or even abroad. Ultimately it'll end up in a sorting office that is local to the final destination and a postman will be given the job of delivering the letter (probably at 1pm in the afternoon if my post is anything to go by!)
So, implicit with every address I put on a letter is the address of the local sorting office. They know where the ultimate receiver is and I don't need to (which is good because I'd hate to have to run something like MultiMap each time I wanted to find out where someone lived). If he's moved, he can arrange to have mail diverted to a new location simply by telling them. Obviously this can't go on forever and eventually becomes a matter of diminishing returns, but that's up to the householder.
In this case, the initial destination (service) for my letter is the post office (as I said, implicitly addressed in the physical world) and the context associated with the message is what I stick on the front of the envelope: it's my session information and is the same for all letters I write to that individual. How the post office "service" gets the content of my letter to the recipient is a backend implementation choice. They can (and have) changed that implementation many times over the years, but the way I write my envelopes (the context) never changes.
If the ultimate receiver does eventually move, I may get a new context from them (setting up a new session) or the equivalent of a 404 (Not Found) message.
Trying to be even handed, I suppose another way of approaching this would be to say that the binding of SOAP-to-PostOffice implicitly does all of this routing/redirecting for me, but that then relies on a specific medium. I'd like this to work no matter what carrier medium I use.
You could also argue that the post office (or actually the sorting office) that is implicitly addressed in the physical world suffers from the same static address problem. But it doesn't - as far as my letter is concerned it is stateless; the letter could just as easily be dealt with by any sorting office in the country (hey, the model allows me to post my letter anywhere after all). So this is an example of where any "service" that offers the same functionality (dealing with post in this case) can be used: I'm not tied to a specific instance.
Of course another way of looking at this is that it's all just
hierarchical naming again. However, I think it just shows that abstracting the *what* (my ultimate receiver) out of the *how* (the post office in this case), makes for a scalable system. (Except at Christmas, where they almost never guarantee delivery dates for postcards!)
Thursday, January 27, 2005
Long running sessions
I've been talking to some friends who are proponents of WS-RF and
embedding ReferenceProperties/ReferenceParameters into an EPR. By now we all know that RefProps have gone from the latest version of WS-Addressing, but the principle that they want is the same: an EPR points to a specific (stateful) resource instance of "within" a service.
I've mentioned before why I think this is a bad idea for SOA and so have others. However, the arguments I'm hearing now are based on the supposition that regardless of the merits of context and sessions via that route, you always need a way to refer to some specific instance of a service/state outside of a session. Hence the "object key" approach that WS-Addressing epitomises (and WS-RF uses).
However, I'm still not convinced. Afterall sessions are time dependant
entities: the information that you manipulate within a session is
inherently temporal in nature, even if the period associated with it
is arbitrarily large. So why not just say that there are such things
as sessions that have a lifetime as long as the age of the universe?
Seems to me that you then keep a single uniform model for accessing
and manipulating *back-end implementation specific information* that
is in line with the loosely-coupled nature of SOA we want to
maintain. Or am I missing something?
Here's an easy real-world example, based on the ubiquitous bank
account. I've had an account with my friendly bank since 1984 (nothing
ominous in that date!) and I've kept the same account number
throughout. When I go into any branch in the country I just give them
my account number and Hey Presto, I've got access to my
account. (Imagine if the account number was hard-coded into the branch
address, so I could only got to a specific branch!) If you think about
it, that's a pretty long running session, which we could model
trivially with WS-Context.
embedding ReferenceProperties/ReferenceParameters into an EPR. By now we all know that RefProps have gone from the latest version of WS-Addressing, but the principle that they want is the same: an EPR points to a specific (stateful) resource instance of "within" a service.
I've mentioned before why I think this is a bad idea for SOA and so have others. However, the arguments I'm hearing now are based on the supposition that regardless of the merits of context and sessions via that route, you always need a way to refer to some specific instance of a service/state outside of a session. Hence the "object key" approach that WS-Addressing epitomises (and WS-RF uses).
However, I'm still not convinced. Afterall sessions are time dependant
entities: the information that you manipulate within a session is
inherently temporal in nature, even if the period associated with it
is arbitrarily large. So why not just say that there are such things
as sessions that have a lifetime as long as the age of the universe?
Seems to me that you then keep a single uniform model for accessing
and manipulating *back-end implementation specific information* that
is in line with the loosely-coupled nature of SOA we want to
maintain. Or am I missing something?
Here's an easy real-world example, based on the ubiquitous bank
account. I've had an account with my friendly bank since 1984 (nothing
ominous in that date!) and I've kept the same account number
throughout. When I go into any branch in the country I just give them
my account number and Hey Presto, I've got access to my
account. (Imagine if the account number was hard-coded into the branch
address, so I could only got to a specific branch!) If you think about
it, that's a pretty long running session, which we could model
trivially with WS-Context.
Tuesday, January 25, 2005
Saturday, January 22, 2005
Welcome Arnaud
Thursday, January 20, 2005
Amazon's new CTO
OK, I'm a little late on this, but I've been busy! Amazon have just made my friend Werner Vogels their new CTO. Way to go Werner!
Werner and I have known each other for many years, going back to when I was a PhD student and he was working with Ken on the Isis project. I think Amazon have made a great choice: Werner's a nice guy who's got a good breadth of understanding and can usually hold his own when we have a few drinks together!
Werner and I have known each other for many years, going back to when I was a PhD student and he was working with Ken on the Isis project. I think Amazon have made a great choice: Werner's a nice guy who's got a good breadth of understanding and can usually hold his own when we have a few drinks together!
Wednesday, January 19, 2005
Interoperability of Web Services transactions
I mentioned the other day that I'm at the Web Services Transaction interoperability workshop here in Raleigh. We were at the first of these workshops back in April when we went over the various specifications to try to enhance them to improve interoperability. 9 months later, we're actually trying to make our product work with other implementations. Pretty cool, but also a very intense few days.
Unfortunately in order to attend we had to sign a fairly restrictive agreement that basically says we can't give much information about what happened. So I'm not even sure whether I can even say who was there beyond the usual suspects. But with that restriction in mind, I'll try to give an overview of what happened.
First of all, I had intended to post something before and during the actual event. However, it turned out to be way too busy. There were almost a half dozen different companies represented with nearly two dozen test scenarios! I talked to my friend Jorgen who was there with the Microsoft contingent and he said this was the most scenarios of any interoperability workshop: he should know, as it's his job to attend them all! Then each scenario has two possible actors: the initiator (basically who is the transaction coordinator) and the participant (who's being driven by the coordinator according to the specific protocol). So you can imagine the test matrix was pretty big - at a minimum we had to take part in nearly 300 tests!
Whoever thought that we could do this in two days needs their head examining. No individual specification, whether it's Web Services, CORBA, IETF or whatever, is ever going to be so carefully written that there's no scope for confusion or misinterpretation. Throw into that the fact that the transactions specifications build on the WS-Coordination specification and they all use WS-Addressing and that transaction protocols are inherently complex things to understand let alone implement, and you've got a potential state explosion for getting things wrong. So I'm actually pretty impressed by all the attendees that it worked out so well. Of course there were some hiccups, but everyone seemed to go into it with an open mind to just "get the job done" and I think we did. In fact, now that it's over and I look back, I'm really surprised by the lack of significant implementation and/or specification problems.
As I've said before, Web Services are as much about interoperability as they are about building internet-scale applications. However, that doesn't mean that a Web Services specification is inherently interoperable. So, something like these workshops, or the ones we did for WS-Context are necessary. I think other standards bodies such as the OMG could benefit from this approach.
So we spent two intensive days going round each scenario testing and being tested, updating and forcing updates and ultimately clarifying the specifications and agreeing on what interpretations made sense. I had some great help from back in our office, despite the timezone difference. A collective pat on the back!
The place this all happened was really nice. It has food of one sort or another constantly available, with drinks throughout the corridors. The perfect finishing touch came at about 2pm when they opened a sweet (candy for the Americans amongst you) "bar": a long table with different types of sweet-stuff. My dentist isn't going to be happy when I see him next, but when the going got tough, it was the gummi-bears and coke that kept me going!
Well I've been up at 4am every day since I got here (and 4am when I travelled here), so it's time to catch up on some sleep. Then it's a flight back home, assuming I don't get snowed in!
Unfortunately in order to attend we had to sign a fairly restrictive agreement that basically says we can't give much information about what happened. So I'm not even sure whether I can even say who was there beyond the usual suspects. But with that restriction in mind, I'll try to give an overview of what happened.
First of all, I had intended to post something before and during the actual event. However, it turned out to be way too busy. There were almost a half dozen different companies represented with nearly two dozen test scenarios! I talked to my friend Jorgen who was there with the Microsoft contingent and he said this was the most scenarios of any interoperability workshop: he should know, as it's his job to attend them all! Then each scenario has two possible actors: the initiator (basically who is the transaction coordinator) and the participant (who's being driven by the coordinator according to the specific protocol). So you can imagine the test matrix was pretty big - at a minimum we had to take part in nearly 300 tests!
Whoever thought that we could do this in two days needs their head examining. No individual specification, whether it's Web Services, CORBA, IETF or whatever, is ever going to be so carefully written that there's no scope for confusion or misinterpretation. Throw into that the fact that the transactions specifications build on the WS-Coordination specification and they all use WS-Addressing and that transaction protocols are inherently complex things to understand let alone implement, and you've got a potential state explosion for getting things wrong. So I'm actually pretty impressed by all the attendees that it worked out so well. Of course there were some hiccups, but everyone seemed to go into it with an open mind to just "get the job done" and I think we did. In fact, now that it's over and I look back, I'm really surprised by the lack of significant implementation and/or specification problems.
As I've said before, Web Services are as much about interoperability as they are about building internet-scale applications. However, that doesn't mean that a Web Services specification is inherently interoperable. So, something like these workshops, or the ones we did for WS-Context are necessary. I think other standards bodies such as the OMG could benefit from this approach.
So we spent two intensive days going round each scenario testing and being tested, updating and forcing updates and ultimately clarifying the specifications and agreeing on what interpretations made sense. I had some great help from back in our office, despite the timezone difference. A collective pat on the back!
The place this all happened was really nice. It has food of one sort or another constantly available, with drinks throughout the corridors. The perfect finishing touch came at about 2pm when they opened a sweet (candy for the Americans amongst you) "bar": a long table with different types of sweet-stuff. My dentist isn't going to be happy when I see him next, but when the going got tough, it was the gummi-bears and coke that kept me going!
Well I've been up at 4am every day since I got here (and 4am when I travelled here), so it's time to catch up on some sleep. Then it's a flight back home, assuming I don't get snowed in!
Tuesday, January 18, 2005
Busy busy busy
I can hardly believe it's only mid-January! Since the start of the year it just seems to have been one thing or another that's taken up so much time. Over the Christmas and New Year period I've been working on severalJavaOne proposals with colleagues here and Oracle. Still not finalised any of them, so we'll have to do that before the deadline.
Then there's been all the work on WWW 2005. As I've already mentioned, I'm co-chair on the Web Services and XML Track and we had a lot of papers to go through. Thanks to the many reviewers who helped. The quality of the papers was OK (maybe the bell-curve was shifted towards to origin a bit) and it was difficult to make the final selection (still not finalised at the time of writing this). I have been a little disappointed with the quality of the Web Services papers: in my book taking a paper on traditional Web *Servers* and changing Servers to Services doesn't cut it, and Semantic Web isn't Web Services either. In the end the papers submitted concentrated more on the XML side of things that the Web Services.
Now does that mean that there's no interesting R&D going on in Web Services, or that people don't see the WWW conferences as the most appropriate place to publish them? I've published several times in the earlier WWW conferences and they've always been good places to attend. OK, in the early days they were about Web Servers, caching, optimizations of HTTP interactions etc, but that's because there were no such things as Web Services. But as the Web has evolved, so has the conference (not a bad example of Darwinian theory in practice). Let's hope that in the future people see the conference as a much more inclusive venue.
Another area that's taken up time is the Web Services transactions interoperability workshop, which is where I am at the moment. More on that in a separate entry though.
Oh, and let's not forget the work we've been doing with customers of our products. Sometimes that can be frustrating, but more often than not it's interesting and informative to get feedback (positive as well as negative). Someday it would be interesting to produce a timeline of all of the products and show how they've evolved over the years and (where possible/allowed) indicate why they evolved in the way they did. We started to do this with the original Arjuna System, which went on to become the Arjuna Transaction Service, but even that paper is now out-of-date. (Santosh and I have been working on an update for a while, so this just reminds me that he has the token.)
Then there's been all the work on WWW 2005. As I've already mentioned, I'm co-chair on the Web Services and XML Track and we had a lot of papers to go through. Thanks to the many reviewers who helped. The quality of the papers was OK (maybe the bell-curve was shifted towards to origin a bit) and it was difficult to make the final selection (still not finalised at the time of writing this). I have been a little disappointed with the quality of the Web Services papers: in my book taking a paper on traditional Web *Servers* and changing Servers to Services doesn't cut it, and Semantic Web isn't Web Services either. In the end the papers submitted concentrated more on the XML side of things that the Web Services.
Now does that mean that there's no interesting R&D going on in Web Services, or that people don't see the WWW conferences as the most appropriate place to publish them? I've published several times in the earlier WWW conferences and they've always been good places to attend. OK, in the early days they were about Web Servers, caching, optimizations of HTTP interactions etc, but that's because there were no such things as Web Services. But as the Web has evolved, so has the conference (not a bad example of Darwinian theory in practice). Let's hope that in the future people see the conference as a much more inclusive venue.
Another area that's taken up time is the Web Services transactions interoperability workshop, which is where I am at the moment. More on that in a separate entry though.
Oh, and let's not forget the work we've been doing with customers of our products. Sometimes that can be frustrating, but more often than not it's interesting and informative to get feedback (positive as well as negative). Someday it would be interesting to produce a timeline of all of the products and show how they've evolved over the years and (where possible/allowed) indicate why they evolved in the way they did. We started to do this with the original Arjuna System, which went on to become the Arjuna Transaction Service, but even that paper is now out-of-date. (Santosh and I have been working on an update for a while, so this just reminds me that he has the token.)
Tuesday, January 11, 2005
Apologies for inconvenience
There've been a few spurious comments entered today by anonymous individuals. I've deleted the ones I've spotted and have decided to only allow comments from people who have an account on blogger.com (hopefully that'll help cut down on this sort of thing). Sorry for any inconvenience, but creating an account is free and simple.
Tuesday, January 04, 2005
Happy new year
Well, it's 2005 and not a lot to report at the moment. However, there's an interesting article on blogging here. Worth a look.