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.
Monday, June 09, 2008
SOA 2.0 all over again?
Over two years ago I got frustrated at the announcement of SOA 2.0. Many others were likewise confused and irritated at an attempt to create another hype curve. I'm not going to attribute cause and effect because maybe it would have happened anyway, but SOA 2.0 pretty much bit the dirt subsequently. Well while writing up this article for InfoQ I had a serious case of deja vu.
WTF is WOA? Where did it spring from and more precisely where has it been hiding for the past ten years? At its best it seems to be the same as ROA, i.e., a concrete implementation of REST targeting the Web. (I'm not so keen on ROA either: I prefer REST/HTTP.) At its worst it's an excuse to start generating more terms ('Web-oriented SOA'?! You've got to be joking!) One of the original articles on Web Oriented Architecture (aka WOA) was posted by Dion on April 1st, so maybe that was a Freudian Slip on his part?
But if WOA is not the same as REST (or REST as applied to the Web) then it really needs a different acronym: REST is fundamentally the architecture on which the Web is based and everyone understands that now. Alright you do need to clarify how the concepts are implemented (HTTP, JMS etc.), but that's easy to do without coining a whole new terminology. Independently of Roy's thesis, the W3C has done a good job of defining the Web Architecture. Plus, people have been building RESTful good citizen applications for quite a while. Did they need to coin a new term to make it clear what was happening under the hood? I think not. But then again, maybe the intent is to try to outwit us with an attempt at the Chewbacca Defense? I think it's more a case of The Emperor's New Clothes syndrome and we should just say that WOA is naked and move on!
Look guys, we have REST as a well defined and accepted term. Why do we need yet another acronym to mean the same thing? The answer is that we don't, so let's stop polluting the atmosphere with meaningless or duplicate terms and get on with helping end users and developers figure out the best way in which to deliver business functions and data! I can say 'REST as applied to the Web' in less time than it takes to explain WOA and I can guarantee you that more people will understand what I mean with the first description than the second.
WTF is WOA? Where did it spring from and more precisely where has it been hiding for the past ten years? At its best it seems to be the same as ROA, i.e., a concrete implementation of REST targeting the Web. (I'm not so keen on ROA either: I prefer REST/HTTP.) At its worst it's an excuse to start generating more terms ('Web-oriented SOA'?! You've got to be joking!) One of the original articles on Web Oriented Architecture (aka WOA) was posted by Dion on April 1st, so maybe that was a Freudian Slip on his part?
But if WOA is not the same as REST (or REST as applied to the Web) then it really needs a different acronym: REST is fundamentally the architecture on which the Web is based and everyone understands that now. Alright you do need to clarify how the concepts are implemented (HTTP, JMS etc.), but that's easy to do without coining a whole new terminology. Independently of Roy's thesis, the W3C has done a good job of defining the Web Architecture. Plus, people have been building RESTful good citizen applications for quite a while. Did they need to coin a new term to make it clear what was happening under the hood? I think not. But then again, maybe the intent is to try to outwit us with an attempt at the Chewbacca Defense? I think it's more a case of The Emperor's New Clothes syndrome and we should just say that WOA is naked and move on!
Look guys, we have REST as a well defined and accepted term. Why do we need yet another acronym to mean the same thing? The answer is that we don't, so let's stop polluting the atmosphere with meaningless or duplicate terms and get on with helping end users and developers figure out the best way in which to deliver business functions and data! I can say 'REST as applied to the Web' in less time than it takes to explain WOA and I can guarantee you that more people will understand what I mean with the first description than the second.
Sunday, June 01, 2008
What's it mean to be an architect?
We live in a 19th century station master's house and it's time to either move or add another module (aka extension). We're looking at the latter for a number of reasons. Going this route means we need to have someone come in and draw up plans: the architect. Most people probably think of what an architect does based on the dictionary definition: "One who designs and supervises the construction of buildings or other large structures." But if you think about it more, this person is more than a designer or supervisor: they have to understand a lot about materials and how they fit together in order to assess structural integrity, stress points, resilience to adverse conditions and, of course, the final all-important look. So although they may not get their hands dirty with bricks and mortal (some do), they have to know about the construction as well as the people who will eventually do that work. That doesn't mean they are necessarily as skilled as some others in their team (e.g., I doubt the typical architect would have the skills of a carpenter), but they would need to understand wood, bricks, stone etc.
This requirement for an architect to know how things come together and, if necessary, be able to do some of that development should be common to uses of the term within other sectors and not just building. Whether it be biotechnology, cars or ships, the architect had better be skilled enough to understand how their plans will be affected by the implementation. How they do that may depend upon the industry and the individual (e.g., some building architects have been carpenters in the past).
The software architect needs to be the same. If you've got 'architect' in your title then you need to either be (or have been) a coder. (I think 'be' is better). Whether that means you've coded entire systems, or had to bring together existing modules as well, doesn't really matter as long as you have the understanding of what's possible, practical, reliable and maintainable as a developer. Writing a few XML configuration scripts doesn't cut-it in my opinion, because that does not bring the necessary appreciation for architecture. For instance, how can you understand what it means for a failure to happen in a distributed system if you've never had to implement one (or part of one)? So far I've been in the fortunate position to have only met software architects who fit my definition (I suppose a chicken-and-egg situation could be argued).
However, I know others who have met (suffered) exceptions to this rule. In some companies it appears to be endemic that architects are designers or team managers, with little or no coding experience behind them. Maybe they're just lucky and the development teams pick up the slack, ensuring success of the projects. Or maybe the blame for failed projects just manages to go elsewhere. But I know when we decide to go with an extension on our house I'll be looking for an architect who knows more than how to draw pretty pictures or make sure the work is done on time: I don't want the whole thing collapsing on us months or years later!
This requirement for an architect to know how things come together and, if necessary, be able to do some of that development should be common to uses of the term within other sectors and not just building. Whether it be biotechnology, cars or ships, the architect had better be skilled enough to understand how their plans will be affected by the implementation. How they do that may depend upon the industry and the individual (e.g., some building architects have been carpenters in the past).
The software architect needs to be the same. If you've got 'architect' in your title then you need to either be (or have been) a coder. (I think 'be' is better). Whether that means you've coded entire systems, or had to bring together existing modules as well, doesn't really matter as long as you have the understanding of what's possible, practical, reliable and maintainable as a developer. Writing a few XML configuration scripts doesn't cut-it in my opinion, because that does not bring the necessary appreciation for architecture. For instance, how can you understand what it means for a failure to happen in a distributed system if you've never had to implement one (or part of one)? So far I've been in the fortunate position to have only met software architects who fit my definition (I suppose a chicken-and-egg situation could be argued).
However, I know others who have met (suffered) exceptions to this rule. In some companies it appears to be endemic that architects are designers or team managers, with little or no coding experience behind them. Maybe they're just lucky and the development teams pick up the slack, ensuring success of the projects. Or maybe the blame for failed projects just manages to go elsewhere. But I know when we decide to go with an extension on our house I'll be looking for an architect who knows more than how to draw pretty pictures or make sure the work is done on time: I don't want the whole thing collapsing on us months or years later!
Saturday, May 31, 2008
WSWSA 2008 CFP
ESWSA: Workshop on empirical studies of Web service architectures
(the RESTñSOAP debate in numbers)
in conjunction with OOPSLA 2008
http://eswsa.cs.uiuc.edu
The recent rapid growth in size and capability of distributed computing
systems has heralded new types of software architectures, among them the
messaging paradigm championed by Web Services and the distributed hypermedia
model upheld by the Web. Currently these two competing styles ñ known as
SOAP and RESTful ñ are used, but little is known about the real-world
engineering characteristics of each style, though each has an active camp of
campaigners. The known comparisons focus on sometimes abstract architectural
principles, and there is little empirical information in the public domain
from specific system implementation experience.
Only one piece of empirical data regarding this debate is available to date.
It comes from Amazon. Jeff Barr, quoted by Tim O'Reilly, noted that 85% of
Web services requests at Amazon are HTTP-based, or RESTful. That was in April
2003.
The ongoing conflict between the two groups is often called the ìREST-SOAP
debate.î Yet actual debates, organized for example during conferences, have
not been conclusive, because they typically fail to convince the proponents of
the competing style. Rather than arguing over abstract concepts, this workshop
will address the merits of each style based on empirical experience how
systems work in practice.
GOALS OF THIS WORKSHOP
The workshop will present empirical work on RESTful and SOAP-based Web
Services. We are seeking papers that present empirical engineering evidence
regarding specific aspects of both kinds of services. This evidence will be
the starting point of the discussion during the workshop that aims to:
* Identify what is known empirically about building RESTful and SOAP services;
* Discuss the empirical results to see how widely they apply;
* Confirm or rebuke abstract claims with empirical evidence; and
* Identify questions for further study.
Workshop submissions should focus on one of the following types of empirical
studies.
Firstly, we are soliciting empirical studies or comparisons of SOAP and RESTful
Web services in the context of:
* Publicly accessible services
* Cross-Organization Integration (B2B), or inter-enterprise services
* Enterprise Application Integration (EAI), or intra-enterprise services
* Non-functional requirements of services (e.g. security, reliability, crash
recovery)
Second, studies of the REST architectural style, e.g.
* How closely does the Web follow the principles of REST?
* How many Web services claiming to be RESTful follow the principles of REST?
Good sources of arguments regarding the REST-SOAP debate are
* RESTwiki, http://rest.blueoxen.net
* Paul Prescod's paper, ìRoots of the REST-SOAP debate,î XML 2002.
* "RESTful Web services" book by Leonard Richardson and Sam Ruby
* Web services-related tracks at qCon conferences
SUBMISSIONS
We are seeking short papers (up to 6 pages, 9pt font, in ACM format). A
submission must pose an empirical question related to Web services, present
some data that addresses the question and interpret the results. Submissions
will be judged based on soundness of methods, quality of analysis, as well as
relevance of the empirical results to the REST-SOAP debate. They will be
reviewed by Program Committee members, who are industry and academic experts
in the area of Web services.
Submissions will be accepted through the EasyChair submission system available
from http://eswsa.cs.uiuc.edu.
Authors of accepted papers will be notified by September 2nd (in time to take
advantage of OOPSLA's early registration discount). Authors will have an
opportunity to update their submissions with the reviewers' feedback until
September 20th, 2008. The reviewed submissions will be featured in OOPSLA
Companion 2008 and in the ACM's Digital Library. Note that at least one author
of the submitted paper must be present at the workshop to present it.
IMPORTANT DATES
* ESWSA paper submission deadline: August 3, 2008
* Notification of acceptance/rejection: September 2, 2008
* OOPSLA's early registration deadline: September 11, 2008
* ESWSA Workshop: Oct 19th or 20th, 2008
WORKSHOP PROGRAM
The workshop will run over an entire dayís session at OOPSLA 2008.
Morning session: paper presentations (20 mins per paper + 10 mins for questions)
Afternoon session: more presentations plus a panel discussion of invited experts
WORKSHOP ORGANIZERS
Munawar Hafiz, University of Illinois
Paul Adamczyk, University of Illinois
Jim Webber, ThoughtWorks
PROGRAM COMMITTEE
Mark Baker, Coactus Consulting
Raj Balasubramanian, IBM
Chris Ferris, IBM
Ralph E Johnson, University of Illinois
Mark Little, Redhat
Steve Loughran, HP
Mark Nottingham, Yahoo
Savas Parastatidis, Microsoft
Ian Robinson, ThoughtWorks
Halvard Skogsrud, ThoughtWorks
Stefan Tilkov, innoQ
Paul Watson, Newcastle University
Sanjiva Weerawarana, WSO2
PABELISTS
Jim Webber, ThoughtWorks
Sanjiva Weerawarana, WSO2
Kyle Brown, IBM
Brian Foote, Industrial Logic
Paul Adamczyk, University of Illinois
For more information about the workshop please visit http://eswsa.cs.uiuc.edu
or contact the organizers.
(the RESTñSOAP debate in numbers)
in conjunction with OOPSLA 2008
http://eswsa.cs.uiuc.edu
The recent rapid growth in size and capability of distributed computing
systems has heralded new types of software architectures, among them the
messaging paradigm championed by Web Services and the distributed hypermedia
model upheld by the Web. Currently these two competing styles ñ known as
SOAP and RESTful ñ are used, but little is known about the real-world
engineering characteristics of each style, though each has an active camp of
campaigners. The known comparisons focus on sometimes abstract architectural
principles, and there is little empirical information in the public domain
from specific system implementation experience.
Only one piece of empirical data regarding this debate is available to date.
It comes from Amazon. Jeff Barr, quoted by Tim O'Reilly, noted that 85% of
Web services requests at Amazon are HTTP-based, or RESTful. That was in April
2003.
The ongoing conflict between the two groups is often called the ìREST-SOAP
debate.î Yet actual debates, organized for example during conferences, have
not been conclusive, because they typically fail to convince the proponents of
the competing style. Rather than arguing over abstract concepts, this workshop
will address the merits of each style based on empirical experience how
systems work in practice.
GOALS OF THIS WORKSHOP
The workshop will present empirical work on RESTful and SOAP-based Web
Services. We are seeking papers that present empirical engineering evidence
regarding specific aspects of both kinds of services. This evidence will be
the starting point of the discussion during the workshop that aims to:
* Identify what is known empirically about building RESTful and SOAP services;
* Discuss the empirical results to see how widely they apply;
* Confirm or rebuke abstract claims with empirical evidence; and
* Identify questions for further study.
Workshop submissions should focus on one of the following types of empirical
studies.
Firstly, we are soliciting empirical studies or comparisons of SOAP and RESTful
Web services in the context of:
* Publicly accessible services
* Cross-Organization Integration (B2B), or inter-enterprise services
* Enterprise Application Integration (EAI), or intra-enterprise services
* Non-functional requirements of services (e.g. security, reliability, crash
recovery)
Second, studies of the REST architectural style, e.g.
* How closely does the Web follow the principles of REST?
* How many Web services claiming to be RESTful follow the principles of REST?
Good sources of arguments regarding the REST-SOAP debate are
* RESTwiki, http://rest.blueoxen.net
* Paul Prescod's paper, ìRoots of the REST-SOAP debate,î XML 2002.
* "RESTful Web services" book by Leonard Richardson and Sam Ruby
* Web services-related tracks at qCon conferences
SUBMISSIONS
We are seeking short papers (up to 6 pages, 9pt font, in ACM format). A
submission must pose an empirical question related to Web services, present
some data that addresses the question and interpret the results. Submissions
will be judged based on soundness of methods, quality of analysis, as well as
relevance of the empirical results to the REST-SOAP debate. They will be
reviewed by Program Committee members, who are industry and academic experts
in the area of Web services.
Submissions will be accepted through the EasyChair submission system available
from http://eswsa.cs.uiuc.edu.
Authors of accepted papers will be notified by September 2nd (in time to take
advantage of OOPSLA's early registration discount). Authors will have an
opportunity to update their submissions with the reviewers' feedback until
September 20th, 2008. The reviewed submissions will be featured in OOPSLA
Companion 2008 and in the ACM's Digital Library. Note that at least one author
of the submitted paper must be present at the workshop to present it.
IMPORTANT DATES
* ESWSA paper submission deadline: August 3, 2008
* Notification of acceptance/rejection: September 2, 2008
* OOPSLA's early registration deadline: September 11, 2008
* ESWSA Workshop: Oct 19th or 20th, 2008
WORKSHOP PROGRAM
The workshop will run over an entire dayís session at OOPSLA 2008.
Morning session: paper presentations (20 mins per paper + 10 mins for questions)
Afternoon session: more presentations plus a panel discussion of invited experts
WORKSHOP ORGANIZERS
Munawar Hafiz, University of Illinois
Paul Adamczyk, University of Illinois
Jim Webber, ThoughtWorks
PROGRAM COMMITTEE
Mark Baker, Coactus Consulting
Raj Balasubramanian, IBM
Chris Ferris, IBM
Ralph E Johnson, University of Illinois
Mark Little, Redhat
Steve Loughran, HP
Mark Nottingham, Yahoo
Savas Parastatidis, Microsoft
Ian Robinson, ThoughtWorks
Halvard Skogsrud, ThoughtWorks
Stefan Tilkov, innoQ
Paul Watson, Newcastle University
Sanjiva Weerawarana, WSO2
PABELISTS
Jim Webber, ThoughtWorks
Sanjiva Weerawarana, WSO2
Kyle Brown, IBM
Brian Foote, Industrial Logic
Paul Adamczyk, University of Illinois
For more information about the workshop please visit http://eswsa.cs.uiuc.edu
or contact the organizers.
Subscribe to:
Posts (Atom)