I meant to post something about this article a while ago but only found the time due to the Christmas vacation.
It's a nice article and what Werner's talking about is part of what I consider real extreme transaction processing (not the hype term). As I've said elsewhere several times before, a few of us in the transaction community have been working on this type of problem dating back to at least the work we did in early SOA/Web Services standards. Even longer if you consider the work on extended transaction models. It's nice to see practical implementations of some of the theory behind these models actually being used outside of academia.
I'm hoping that in the next year we'll see some fruit coming from research and development we've been doing on real XTP, including the REST approach I've mentioned before as well as general approaches to large scale (extended) transactions. This should further illustrate what's possible with relaxation of the ACID properties we know and love, particularly when combined with high performance messaging and replication techniques. Sometimes it's hard to believe that this has been going on for so long.
Since this article started with a reference to Werner, it's worth ending with him too: congratulations my friend for your latest award. Well done! I think I could have predicated it ;-)
Monday, December 29, 2008
Tuesday, December 09, 2008
Sad day
I just read that Oliver Postgate has died. It's sad because I grew up in an age when Bagpuss and the Clangers were the high points of television. Those were some of my fondest memories.
Saturday, December 06, 2008
SOA Symposium follow up
I seem to have forgotten to mention that I presented a couple of times at this year's first ever SOA Symposium a couple of months ago.
Friday, November 28, 2008
The Eternal Golden Braid
I first read An Eternal Golden Braid about 14 years ago and thought it was a great book. I still do. If you haven't read it then I would encourage you to do so: it is a wonderful journey through mathematics, computer science, philosophy, art and so much more. (I notice that there's a 20th anniversary edition, so that may be going on my present list to Santa since my original copy is a bit dog-eared.) So it was with some surprise that I noticed a translation of Godel's original work available! However, the reviews indicate that it may not be a good translation. But it may be worth a try anyway!
Sunday, November 16, 2008
EDA followup
JJ commented on my earlier posting. Unfortunately he doesn't seem to have comments enabled, or I'd have responded there. (JJ, if you do have comments on that entry, let me know and I'll cross link).
Anyway, he talks about "the main failure of distributed computing is precisely the prevalent monotheism of traditional distributed computing approaches". Ignoring the fact that I don't believe distributed computing has failed, I think JJ read more into my posting than was intended. I didn't mean to suggest that any approach to distributed computing (e.g., RPC or message based) should be used to the exclusion of all others. I think I made that clear elsewhere too: you should use the best approach to hand. After all, isn't that what being a good engineer or architect is all about? I'm very fond of saying that one-size doesn't fit all, and by that I mean what I've just said. Of course systems exist that are entirely based on the concept of resources, services, events, RPC or message exchange, as examples. But there are examples of implementations that combine these different approaches very successfully too.
So in a way I disagree when JJ says "It is not being about fence sitting, or applying the right solution to a given problem." At this stage in computer science that is precisely what it is all about. However, I know what he's after and I've said elsewhere that in many ways computer science is a soft science and more of an art at the moment.
So looking forward, would I like to see a formal approach that combines all of the different approaches I've discussed to distributed computing, and which JJ mentions? Yes, I would. But would everyone use it in its entirety? No, of course they wouldn't: they would use the right aspect of it for the task at hand. Does that invalidate it? No. Does it offer an improvement over today? Yes. Is it going to happen soon? I doubt it, and I'm fairly sure JJ knows the reasons for that too (and the majority of them aren't technical). In fact I could probably write an entire article on that very subject because it relates to how close to a hard science computing science is and can come, with analogies between Galileo/religion and vendor values. But it's way too dark a subject to cover today.
Anyway, he talks about "the main failure of distributed computing is precisely the prevalent monotheism of traditional distributed computing approaches". Ignoring the fact that I don't believe distributed computing has failed, I think JJ read more into my posting than was intended. I didn't mean to suggest that any approach to distributed computing (e.g., RPC or message based) should be used to the exclusion of all others. I think I made that clear elsewhere too: you should use the best approach to hand. After all, isn't that what being a good engineer or architect is all about? I'm very fond of saying that one-size doesn't fit all, and by that I mean what I've just said. Of course systems exist that are entirely based on the concept of resources, services, events, RPC or message exchange, as examples. But there are examples of implementations that combine these different approaches very successfully too.
So in a way I disagree when JJ says "It is not being about fence sitting, or applying the right solution to a given problem." At this stage in computer science that is precisely what it is all about. However, I know what he's after and I've said elsewhere that in many ways computer science is a soft science and more of an art at the moment.
So looking forward, would I like to see a formal approach that combines all of the different approaches I've discussed to distributed computing, and which JJ mentions? Yes, I would. But would everyone use it in its entirety? No, of course they wouldn't: they would use the right aspect of it for the task at hand. Does that invalidate it? No. Does it offer an improvement over today? Yes. Is it going to happen soon? I doubt it, and I'm fairly sure JJ knows the reasons for that too (and the majority of them aren't technical). In fact I could probably write an entire article on that very subject because it relates to how close to a hard science computing science is and can come, with analogies between Galileo/religion and vendor values. But it's way too dark a subject to cover today.
Tuesday, November 11, 2008
DOA 2008 is over
I just finished chairing the last session for DOA 2008. It's been a good conference with some excellent presentations and invited speakers. Now for the long trip home.
Sunday, November 09, 2008
Thoughts on EDA and CEP
Over the past year or so I've been seeing more and more discussions on Event Driven Architecture (EDA). I suppose the thing that really made me take notice was when Gartner tried to push SOA 2.0 and mentioned EDA in there. For me, event driven architectures (notice the case) have been around for as long as I can recall. I've used the concept of events and triggers in many systems I've been involved with without thinking it was somehow novel. The reason for this? Well as I say every time I'm asked about event driven architectures (still notice the case), I believe that they are all around us and have been since the very first computer system: they are a useful abstraction for building certain types of systems (not necessarily just distributed systems).
It's possible to model everything in terms of events when you think about it. For example, in a distributed object system that is based on RPC and uses client and server stubs to make the distribution opaque, the ultimate server object (the one that does the real work) is essentially registered with the server stub to be called (triggered) by it upon the receipt of the right message (i.e., the right opcode in the recipient message). Likewise, the client application (or thread of control) can be considered to register itself with the client stub to be triggered (woken, since we're working in a synchronous environment in this example) when the response message comes back. Pub/sub based messaging systems, such as JMS, support the concept of events as well. When you subscribe to a blog you're essentially registering to be triggered when an event (a new blog entry) becomes available. Anyone remember the CORBA Event Service or the DCE Event Management Service?
Back when I was starting my PhD one of the first things I did (for fun, as it really had nothing to do with any of the various subjects I was considering for my PhD at the time) was to write a hardware bus simulator in C++. It had the concept of components being connected to the various buses and registering to be triggered when specific events occurred. In the real world, hardware is event based, with IRQs as the events and the bus as the delivery mechanism. A very good example of an asynchronous system that is often ignored by the software community these days. Maybe we should be looking at calling the next wave Interrupt Driven Architectures instead?
I've written applications on a number of windowing systems over the past 20 years. Probably the best one was InterViews, but they all share a very common pattern: components (e.g., windows, scroll bars, minimisers, etc.) register for events (e.g., left mouse click, mouse move, etc.)
Over the past 5 years or so we've also seen a move away from the synchronous request/response approach to one-way messages with various Web Services standards and SOAP implementations. Services register their interest in specific events (receipt messages) and clients register their interest in specific events (response messages). But it's still very similar to the stub approach I mentioned earlier. But what we're seeing in this approach is making the concept of events and triggers more explicit than it was before (at least in the Web Services world). This is definitely a good thing for loose coupling when you look at asynchronous environments. But is is a good thing for developers and users? Maybe.
So why have we not seen more event based frameworks pushing events as first class entities up to the developer, which seems to be what the current discussions around EDA are about? I think the reason for this is abstractions: we typically try to hide things like events because most of the time we don't think in terms of them. When a sound wave hits my ear drum and is converted into electrical impulses that trigger a response in me, I don't normally equate the sound wave or the electrical impulses as events. When I receive a letter through my post box telling me I've won the lottery (I wish!) I don't think about the steps it took to be delivered as a series of events (though they clearly are). If you look back at what I said earlier concerning how event driven architectures have been with us for many years, you'll see that what's really happened is that we've tended to hide events with abstractions like stubs and message exchanges.
I've said before that I think an event driven approach to SOA (or pretty much anything) is good if it helps you to better reason about the system in question. If it gets in the way, though, there are alternatives that could be better. As with anything, you use the right abstraction for the job. Is this going to be like RPC, where we realise that hiding distribution is a bad thing (we knew all along really)? Is hiding events bad? Well as I just said, that will depend upon what you're doing. But just because you start thinking in terms of events doesn't solve all of your problems immediately. There may be benefit to exposing some business events to the higher level, but we shouldn't think that rewriting everything we currently use in an event-explicit manner will be a global panacea - it may even be a step backwards. As an industry we need to stop pushing point solutions as global solutions and remember that one-size doesn't fit all.
And what about Complex Event Processing (CEP)? In a nutshell CEP gives you the ability to correlate events from different streams over time (time should really be modeled as an event too) to determine patterns, manage and predict other events (such as failure conditions) etc. The data streams can contain messages at various levels of a system architecture, so it's possible to use CEP at the low level (e.g., allowing a system administrator to predict when machines a more likely to fail given daily usage patterns) as well as the higher level (e.g., allowing a business analyst to determine the buying habits of specific individuals given the market trends elsewhere in the world).
So if you've got CEP do you have an EDA? Well you obviously have something that is generating the event (data) streams that are input to the CEP implementation, but that doesn't mean the entire system is (or should be) architected using an event abstraction.
If you've got an EDA do you need CEP? This is more clear-cut: of course you don't need CEP if you've got events. There are more examples of event driven architectures that don't use (and don't need to use) CEP than those that do. But in some cases, it can make things easier to use CEP.
It's possible to model everything in terms of events when you think about it. For example, in a distributed object system that is based on RPC and uses client and server stubs to make the distribution opaque, the ultimate server object (the one that does the real work) is essentially registered with the server stub to be called (triggered) by it upon the receipt of the right message (i.e., the right opcode in the recipient message). Likewise, the client application (or thread of control) can be considered to register itself with the client stub to be triggered (woken, since we're working in a synchronous environment in this example) when the response message comes back. Pub/sub based messaging systems, such as JMS, support the concept of events as well. When you subscribe to a blog you're essentially registering to be triggered when an event (a new blog entry) becomes available. Anyone remember the CORBA Event Service or the DCE Event Management Service?
Back when I was starting my PhD one of the first things I did (for fun, as it really had nothing to do with any of the various subjects I was considering for my PhD at the time) was to write a hardware bus simulator in C++. It had the concept of components being connected to the various buses and registering to be triggered when specific events occurred. In the real world, hardware is event based, with IRQs as the events and the bus as the delivery mechanism. A very good example of an asynchronous system that is often ignored by the software community these days. Maybe we should be looking at calling the next wave Interrupt Driven Architectures instead?
I've written applications on a number of windowing systems over the past 20 years. Probably the best one was InterViews, but they all share a very common pattern: components (e.g., windows, scroll bars, minimisers, etc.) register for events (e.g., left mouse click, mouse move, etc.)
Over the past 5 years or so we've also seen a move away from the synchronous request/response approach to one-way messages with various Web Services standards and SOAP implementations. Services register their interest in specific events (receipt messages) and clients register their interest in specific events (response messages). But it's still very similar to the stub approach I mentioned earlier. But what we're seeing in this approach is making the concept of events and triggers more explicit than it was before (at least in the Web Services world). This is definitely a good thing for loose coupling when you look at asynchronous environments. But is is a good thing for developers and users? Maybe.
So why have we not seen more event based frameworks pushing events as first class entities up to the developer, which seems to be what the current discussions around EDA are about? I think the reason for this is abstractions: we typically try to hide things like events because most of the time we don't think in terms of them. When a sound wave hits my ear drum and is converted into electrical impulses that trigger a response in me, I don't normally equate the sound wave or the electrical impulses as events. When I receive a letter through my post box telling me I've won the lottery (I wish!) I don't think about the steps it took to be delivered as a series of events (though they clearly are). If you look back at what I said earlier concerning how event driven architectures have been with us for many years, you'll see that what's really happened is that we've tended to hide events with abstractions like stubs and message exchanges.
I've said before that I think an event driven approach to SOA (or pretty much anything) is good if it helps you to better reason about the system in question. If it gets in the way, though, there are alternatives that could be better. As with anything, you use the right abstraction for the job. Is this going to be like RPC, where we realise that hiding distribution is a bad thing (we knew all along really)? Is hiding events bad? Well as I just said, that will depend upon what you're doing. But just because you start thinking in terms of events doesn't solve all of your problems immediately. There may be benefit to exposing some business events to the higher level, but we shouldn't think that rewriting everything we currently use in an event-explicit manner will be a global panacea - it may even be a step backwards. As an industry we need to stop pushing point solutions as global solutions and remember that one-size doesn't fit all.
And what about Complex Event Processing (CEP)? In a nutshell CEP gives you the ability to correlate events from different streams over time (time should really be modeled as an event too) to determine patterns, manage and predict other events (such as failure conditions) etc. The data streams can contain messages at various levels of a system architecture, so it's possible to use CEP at the low level (e.g., allowing a system administrator to predict when machines a more likely to fail given daily usage patterns) as well as the higher level (e.g., allowing a business analyst to determine the buying habits of specific individuals given the market trends elsewhere in the world).
So if you've got CEP do you have an EDA? Well you obviously have something that is generating the event (data) streams that are input to the CEP implementation, but that doesn't mean the entire system is (or should be) architected using an event abstraction.
If you've got an EDA do you need CEP? This is more clear-cut: of course you don't need CEP if you've got events. There are more examples of event driven architectures that don't use (and don't need to use) CEP than those that do. But in some cases, it can make things easier to use CEP.
DOA 2008
I wasn't going to be able to come to DOA 2008, which was a shame because I enjoyed DOA 2007. However, neither of my co-chairs could attend either, so it fell to me to come. It's in Monterrey, Mexico this year and the trip here wasn't something I would like to repeat very often. But I'm here now and looking forward the conference. It'll also give me a chance to catchup on some work that I haven't been able to do (because of work) and blog entries that have been filling up my to-do queue. So one way or another the next few days should be interesting.
Wednesday, November 05, 2008
MAX sounds like it'll be fun
Friday, October 17, 2008
New Macs
I've been a Mac user for a few years (keep promising myself that I'll return to Linux one day), so I was looking forward to the announcement of new Macs. But I obviously missed something because I'm not really impressed with what I've seen. No button on the track-pad? No 1900x1200 resolution? Slightly improved performance. But gone is the metal screen surround, to be replaced by black plastic?! I'm not sure what I expected from Apple, but it wasn't this. Plus, maybe the thing will look better when viewed up close rather than through a web page. If the new design does get around the erosion problem then it'll be worth an upgrade eventually.
Thursday, October 16, 2008
Transactive Memory
I've been doing some research on Software Transactional Memory recently and as a result started to read about Transactive Memory. Now it quickly became apparent that the two things are unrelated, but I found transactive memory to be very interesting (not to indicate that STM isn't interesting!) Put simply, transactive memory is the name for the process whereby people selectively remember things and rely on their relationships with other people, or other things, to remember everything else. So for example, you don't remember every single phone number for everyone you know: you're selective (because that's how the brain works) and remember the "top" 6 or 7, but will probably rely on a telephone book or a PDA for the others. In the home, you may not remember how all of your friends are related to one another, maybe relying on your partner to do that. If you are a technophobe then you may rely on someone in your family to program the DVD player so you don't have to remember how to do it. If you've got kids then you may rely on your partner to do the bulk of their welfare. And the list goes on.
So what has this to do with STM? Well as I said at the start, absolutely nothing. But it does have relevancy to something else I've been interested in for the past few years: repositories. I've always believed that systems such as repositories are better implemented in a federated manner: they scale much better. This means that although you may have a logical notion of a repository, each physical instance is responsible for some different aspect(s) of the whole "mind". This is important because, for example, how you store and index service binaries is different to how you would store and index service contracts, or workflow definitions etc. In this kind of set up if you ask one repository instance "do you know about X" it should say either "no, but I know a man who does" or "no, but hold on and I'll get the answer for you". I'd never been able to put a name to the approach (beyond federation), but it seems to me that this is precisely transitive memory from a software system. DNS works in the same way.
So what has this to do with STM? Well as I said at the start, absolutely nothing. But it does have relevancy to something else I've been interested in for the past few years: repositories. I've always believed that systems such as repositories are better implemented in a federated manner: they scale much better. This means that although you may have a logical notion of a repository, each physical instance is responsible for some different aspect(s) of the whole "mind". This is important because, for example, how you store and index service binaries is different to how you would store and index service contracts, or workflow definitions etc. In this kind of set up if you ask one repository instance "do you know about X" it should say either "no, but I know a man who does" or "no, but hold on and I'll get the answer for you". I'd never been able to put a name to the approach (beyond federation), but it seems to me that this is precisely transitive memory from a software system. DNS works in the same way.
Wednesday, October 08, 2008
CSP book available for free
I'll never know how I missed this announcement from 4 years ago, but the original CSP book is one of the most dog-eared in my library. If you don't have a copy, then I encourage you to download this and read it: it's as applicable today as it was 20 years ago (if not more so!)
To Twitter or not to Twitter?
A number of friends are "on" Twitter and apparently I should be too. I'm not quite sure why though. If blogging is anything to go by, it'll probably take me a couple of years to get round to it.
Nice article on REST
I haven't blogged much recently because I really haven't had the time. The same is true at the moment, since I'm sitting in yet another airport lounge, this time coming back from the first SOA Symposium (hopefully there'll be a blog entry or two from me on that subject later). But I wanted to say that I really enjoyed the latest article from Jim, Savas and Ian. It's been a few years since Jim and Savas worked for me and blogs/articles are often the only regular way we keep in touch. Nice work guys!
Friday, September 26, 2008
Farewell John Warne
I just heard that a friend of mine, John Warne, died this morning. The immediate cause was pneumonia, after he had been diagnosed with liver cancer five weeks ago.
I first met John Warne back in 1987 when I was doing my PhD and he was working at ANSA on behalf of Nortel. He was a great guy, always very passionate about his work but also very down to earth. Over the years our paths crossed time and time again, and no matter how long it had been between meetings it was always like it has only been a few days. He was a great guy to listen to, with some wonderful stories about things he'd seen and done over the years. I remember him telling the story about how he'd been sent by Nortel to work on the Hong Kong Race Course and that they (the Race Course) had so much money they would fly him first class, best hotels etc. He was a good mentor and always willing to spend time to understand problems or share his knowledge openly. In short, John was one of those rare people in our industry: a really nice and intelligent person, someone you looked forward to seeing.
It's a very sad day. I'm not sure what else I can say. Farewell John, it was an honour and a pleasure to know you.
I first met John Warne back in 1987 when I was doing my PhD and he was working at ANSA on behalf of Nortel. He was a great guy, always very passionate about his work but also very down to earth. Over the years our paths crossed time and time again, and no matter how long it had been between meetings it was always like it has only been a few days. He was a great guy to listen to, with some wonderful stories about things he'd seen and done over the years. I remember him telling the story about how he'd been sent by Nortel to work on the Hong Kong Race Course and that they (the Race Course) had so much money they would fly him first class, best hotels etc. He was a good mentor and always willing to spend time to understand problems or share his knowledge openly. In short, John was one of those rare people in our industry: a really nice and intelligent person, someone you looked forward to seeing.
It's a very sad day. I'm not sure what else I can say. Farewell John, it was an honour and a pleasure to know you.
Thursday, September 11, 2008
Saturday, August 30, 2008
A gift interlude
For Christmas 2007 my wife got me an Aqua Sphereing experience. The local centre is also only 5 miles from our house. Given that she was also the one who got me into SCUBA diving, I figured this would be fun. Unfortunately the weather in the UK this summer hasn't been that good, but eventually I managed to find the time and the weather held. Although the whole thing lasted only a minute or so, I had a fantastic time and now know what it feels like to be inside a giant washing machine. My friend Duane did something similar at JavaOne earlier this year, but I don't think there was water involved. If you get the chance, I'd definitely recommend the experience!
For our anniversary this year, my wife got me an EcoSphere (hmmm, there's definitely a spherical theme going on here!). It turned up the other day and it's fantastic. I love this sort of thing: mini-worlds, whether they're real or virtual, have always fascinated me. Maybe it's a god-complex or something, but I can spend hours just watching these worlds evolve.
For our anniversary this year, my wife got me an EcoSphere (hmmm, there's definitely a spherical theme going on here!). It turned up the other day and it's fantastic. I love this sort of thing: mini-worlds, whether they're real or virtual, have always fascinated me. Maybe it's a god-complex or something, but I can spend hours just watching these worlds evolve.
Friday, August 15, 2008
Erlang and Mac OS 10
Wednesday, June 25, 2008
WS-CDL literature surveys
I've been on the program committees for too many conferences and workshops to keep count. You almost always see the expected bell-curve of paper submissions (5% are really bad, 90% are ok, and 5% are extremely good). But irrespective of the quality and content of a paper, the one thing that always annoys me is bad citations and references. I think this goes back to when we were doing the initial work around Arjuna and looking at how to leverage object-oriented techniques for fault tolerance. These days it'd be very passe, but back then it was the start of OO and the work we did was cutting edge. We weren't the only ones doing work in that area: there was Camelot/Avalon (later went on to become Encina from Transarc) and Argus (ISIS wasn't really about exploiting OO approaches). Whenever we ran into papers by those teams it was very rare to see them reference us, whereas the inverse was almost never the case (timing permitting). Frustrating to say the least. So I always try to ensure that accepted papers have appropriate references. It benefits the author's work as well as the reader (there's nothing more infuriating than reading a paper, asking yourself "OK, but how does this compare with XYZ?" and then finding that the author's don't mention it.)
What has this to do with WS-CDL? Well I'm on another PC (I won't mention which, though I have posted the CFP on the blog already) and recently received a swathe of papers on orchestration and choreography. All of them mentioned BPMN. Several of them mentioned BPEL. A couple of them mentioned Pi-calculus. None of them mentioned WS-CDL (or its predecessors)! Of those that mentioned Pi-calculus, they all duplicated the effort that has gone into CDL. Plus every single paper mentioned the importance of being "standards compliant". It's not as if it's hard to find a mention of CDL via google (try googling for 'choreography web services'): in the "good 'ol days" we used to wonder if the lack of references to Arjuna was down to the complexity of tracking journal and conference papers - this was before the WWW and in the relative infancy of the internet (oh cr*p, doesn't that make me sound old?!)
Why is it that these papers didn't even mention CDL once? I think it's a combination of factors including: poor research on the part of the authors', excellent publicity on the part of major vendors that CDL is a dead standard, and confusion around the relationship of CDL to BPEL. This does a disservice to the people who have worked on CDL over the years: it's an excellent body of work and brings value to the choreography arena both from a static (development) perspective as well as dynamic (runtime). Of course it's in the vendor's best interests to ignore WS-CDL when they've adopted WS-BPEL heavily, but these things are complimentary (in fact CDL compliments any orchestration implementation, so don't get hung up over the WS part of the name.) But for a researcher, it's not acceptable.
So if you're doing research into choreography (and/or orchestration) and are thinking of writing a paper, you need to look at WS-CDL. Even if it's only to compare and contrast with what you're going to do, it's important. (A cogent argument against it in favour of your own work is fine, as long as the literature survey is complete.) Otherwise you could be disappointed when your paper is rejected.
What has this to do with WS-CDL? Well I'm on another PC (I won't mention which, though I have posted the CFP on the blog already) and recently received a swathe of papers on orchestration and choreography. All of them mentioned BPMN. Several of them mentioned BPEL. A couple of them mentioned Pi-calculus. None of them mentioned WS-CDL (or its predecessors)! Of those that mentioned Pi-calculus, they all duplicated the effort that has gone into CDL. Plus every single paper mentioned the importance of being "standards compliant". It's not as if it's hard to find a mention of CDL via google (try googling for 'choreography web services'): in the "good 'ol days" we used to wonder if the lack of references to Arjuna was down to the complexity of tracking journal and conference papers - this was before the WWW and in the relative infancy of the internet (oh cr*p, doesn't that make me sound old?!)
Why is it that these papers didn't even mention CDL once? I think it's a combination of factors including: poor research on the part of the authors', excellent publicity on the part of major vendors that CDL is a dead standard, and confusion around the relationship of CDL to BPEL. This does a disservice to the people who have worked on CDL over the years: it's an excellent body of work and brings value to the choreography arena both from a static (development) perspective as well as dynamic (runtime). Of course it's in the vendor's best interests to ignore WS-CDL when they've adopted WS-BPEL heavily, but these things are complimentary (in fact CDL compliments any orchestration implementation, so don't get hung up over the WS part of the name.) But for a researcher, it's not acceptable.
So if you're doing research into choreography (and/or orchestration) and are thinking of writing a paper, you need to look at WS-CDL. Even if it's only to compare and contrast with what you're going to do, it's important. (A cogent argument against it in favour of your own work is fine, as long as the literature survey is complete.) Otherwise you could be disappointed when your paper is rejected.
Sunday, June 15, 2008
What's the point?
I've had the pleasure of working with some very smart people over the years in the area of fault tolerant distributed systems. As a result I've performed research and development in a number of different techniques, including replication (for high availability) and transactions (for consistency). In all that time I've been conscious of the fact that a lot of time and effort has been spent proving that whatever was done worked in the case of failures (whatever the specific definition may be for the particular environment): after all, that's the point of the whole exercise. Yes I know that failures don't happen that often (try selling a transaction manager to people who haven't used one for years and explaining why they really really need to buy one!) But they do happen and that's why fault tolerance techniques (and testing they work in the presence of failures) are so important.
Now why do I bother mentioning this? Well it's come to my attention over the past few years that some purveyors of fault tolerance solutions either don't bother to test the "edge cases" (which are not really edge cases, but the reason for their product's existence) or don't care (and hence publicize) that their solutions won't work in the case of some (all?) possible failure modes. I'm not going to name-and-shame them (primarily because I haven't been able to confirm those reports myself), but if you are a user of something that purports to offer high availability or data consistency in the presence of failures, you really need to check that that vendor means and how they go about confirming that their product works as they say it should.
Now why do I bother mentioning this? Well it's come to my attention over the past few years that some purveyors of fault tolerance solutions either don't bother to test the "edge cases" (which are not really edge cases, but the reason for their product's existence) or don't care (and hence publicize) that their solutions won't work in the case of some (all?) possible failure modes. I'm not going to name-and-shame them (primarily because I haven't been able to confirm those reports myself), but if you are a user of something that purports to offer high availability or data consistency in the presence of failures, you really need to check that that vendor means and how they go about confirming that their product works as they say it should.
Subscribe to:
Posts (Atom)