Tuesday, February 10, 2009
The ultimate Christmas dinner
OK it's a little late but then I didn't realise this video was online! I watched it for the first time over Christmas 2007 and then again last year. Heston Blumenthal has quickly become a favourite to watch and someday I hope to be able to get to his restaurant. Until then I'll sit and watch in awe!
Zakim paper
I've been using Zakim for a few years through various W3C standards committees. Nice paper.
Wednesday, February 04, 2009
Arjuna and the OTS
A couple of comments on my last reminiscence post got me thinking again. One of the things we use to go on about a lot in the early days of the company was the influence we'd had on standards and particularly the Object Transaction Service from the OMG. If you ever compare the two you'll see that by the time the OTS started Graeme, who co-created the Arjuna project (upon which he also got his PhD), was working for Transarc and involved in the standards definition. I remember visiting him in Pittsburgh a few times during that period and hearing a few horror stories about this brain-dead approach being pushed by vendor X and that dumb idea from vendor Y. But I'm sure it was all fun; it was definitely influential on the industry and me personally. When I came to start pushing the OTS in the OMG I did understand what Graeme had been on about with standards processes!
Tuesday, February 03, 2009
OMG where did the time go?
While writing the previous entry concerning building transactional applications I came across that HP paper by Nigel Edwards. That sent shivers down my spine because I can recall Nigel sharing the office with Stuart and I for months while he got to grips with Arjuna. We were both still doing our PhDs and also in the throws of making the first code release of Arjuna to the world. Here's the announcement for Release 2 (it would appear that our first release predates the web!):
The work we did with Nigel still seems so fresh in my mind and yet it is so long ago.
Then I also remembered the work on Stabilis that some of our Brazilian PhD students did a few years later. We'd always talked about how the programming model we had in Arjuna was good for building complex applications (and Nigel's work agreed with that), but it took us all by surprise when they presented Stabilis: here was the largest and most complex system (a full relational database) built entirely on Arjuna! This was an impressive demonstration of what was possible with what we'd spent the last 6 years working on.
Definitely a time to reminisce!
Arjuna (Distr Prog System)
What: Release 2 of Arjuna Distributed Programming System
From: arjuna@newcastle.ac.uk (Arjuna Project)
Date: Mon, 17 May 1993 12:37:34 GMT
We are pleased to announce the availability of a new version
of Arjuna: a programming system for reliable distributed computing,
and the Arjuna mailing list.
The software and the manual for the Arjuna system can be
obtained by anonymous ftp: arjuna.ncl.ac.uk (128.240.150.1)
Arjuna System
This beta release of ArjunaPR2.0 fixes all known bugs present
in ArjunaPR1.2B that have been reported to us or that we have found,
and contains only minimal information about how to use the new features
provided. This release should be compilable with the following
compilers:
AT&T Cfront Release 2.1, on SunOS 4.1.x,
(using Sun supplied lex and yacc).
AT&T Cfront Release 3.0.1, on SunOS 4.1.x and Solaris 2.1,
(using Sun supplied lex and yacc).
GCC versions 2.1, 2.2.2, on SunOS 4.1.x,
(using flex(v2.3.x) and bison).
Patched GCC version 2.3.3 on SunOS 4.1.x and Solaris 2.1,
(using flex(v2.3.x) and bison).
Sun C++ 2.1, on SunOs 4.1.x,
(using Sun's lex++ and yacc++).
HP C++ (B2402 A.02.34), HP-UX 8.07,
(using HP supplied lex and yacc or lex++ and yacc++).
The major new features are:
- Faster object store.
- Support for replicated objects.
- Memory resident object store.
- Support for ANSAware (not available via ftp)
Arjuna supports nested atomic actions (atomic transactions) for
controlling operations on objects (instances of C++ classes), which can
potentially be persistent. Arjuna has been implemented in C++ to run on
stock platforms (Unix on SUNs, HPs etc). The software available
includes a C++ stub generator which hides much of the details of
client-server based programming, plus a system programmer's manual
containing details of how to install Arjuna and use it to build
fault-tolerant distributed applications. The software and the manual
can be obtained by anonymous ftp: arjuna.ncl.ac.uk (128.240.150.1)
Several enhancements and ports on various distributed
computing platforms are in progress. We would be pleased to hear from
researchers and teachers interested in using Arjuna. The programmer's
manual contains the e-mail addresses for sending your comments and
problem reports.
ANSAware version of Arjuna
The ANSAware version of Arjuna is available from:
Architecture Projects Management Limited
Poseidon House
Castle Park Phone +44 223 323010
Cambridge Fax +44 223 359779
CB3 0RD Internet apm@ansa.co.uk
United Kingdom UUCP ...uknet!ansa!apm
Arjuna Mailing List
To enable us to help people using Arjuna, an electronic mail list has
been setup. You can join the Arjuna mailing list by sending an e-mail
message to "mailbase@mailbase.ac.uk" containing:
join arjuna
For example : join arjuna John Smith
Mail messages can then be sent to "arjuna@mailbase.ac.uk", for
distribution.
Arjuna Project Team
The Department of Computing Science,
The University,
Newcastle upon Tyne.
NE1 7RU, UK.
The work we did with Nigel still seems so fresh in my mind and yet it is so long ago.
Then I also remembered the work on Stabilis that some of our Brazilian PhD students did a few years later. We'd always talked about how the programming model we had in Arjuna was good for building complex applications (and Nigel's work agreed with that), but it took us all by surprise when they presented Stabilis: here was the largest and most complex system (a full relational database) built entirely on Arjuna! This was an impressive demonstration of what was possible with what we'd spent the last 6 years working on.
Definitely a time to reminisce!
Transactions and AIT/TOJ
Jonathan pointed me to a recent discussion on TSS concerning writing transactional resources for non-transactional objects. It expanded into the more general topic of how to write XAResources, which it topical at the moment within Red Hat. Anyway it got me thinking that many of these requests aren't necessarily for "How do I write an XAResource?" but more for "How do I make my data transactional?" These are two different questions: the former infers the latter, but the latter doesn't infer the former. Yes believe it or not but transactions existed before XA came on the scene.
So it got me thinking and I realised that what many of them they really want is something akin to what we did in the original Arjuna system. It didn't have a name back then, since it was the whole reason for doing the Arjuna research, but eventually it became known as Arjuna Integrated Transactions (AIT), or Transactional Objects for Java (TOJ). The use of "it" has not been pushed much (at all) over the past few years, which is a shame because I still think it's a great model. So it may be time to dust it off and bring it back into the light.
So it got me thinking and I realised that what many of them they really want is something akin to what we did in the original Arjuna system. It didn't have a name back then, since it was the whole reason for doing the Arjuna research, but eventually it became known as Arjuna Integrated Transactions (AIT), or Transactional Objects for Java (TOJ). The use of "it" has not been pushed much (at all) over the past few years, which is a shame because I still think it's a great model. So it may be time to dust it off and bring it back into the light.
Sunday, February 01, 2009
Sock and Anti-Sock Pairs
Back when I was hard at work doing my Physics undergraduate degree (a quarter of a century ago!) I remember a few of us finding creative ways to spend the time during the 4 hour practical sessions we had twice a week. Well there are only so many times you can do Millikan's experiment or kill a cat in an enclosed box with a stray beta particle. (OK that last one is something we planned but never quite did for obvious reasons and it still scores high on the "what if?" discussions at reunions.) So what we often did was end up spending hours reading New Scientist.
The one article that has stuck in my mind for that length of time was a brief description of why you end up with odd socks in the wash and usually a piece of fluff. From what I can recall, it talked about spontaneous creation of anti-socks and sock/anti-sock annihilation. To us physics students it appealed on at least two levels: the obvious physics analogies concerning matter and anti-matter, but also the fact that for most of us this was the first time we'd been away from home and having to worry about doing our own washing, much of which was full of fluff and stray socks that we were sure weren't our own! Many times over the years I wish I'd kept that article. I had hoped that the wonder of the digital age would help, but this is the closest I've found.
The one article that has stuck in my mind for that length of time was a brief description of why you end up with odd socks in the wash and usually a piece of fluff. From what I can recall, it talked about spontaneous creation of anti-socks and sock/anti-sock annihilation. To us physics students it appealed on at least two levels: the obvious physics analogies concerning matter and anti-matter, but also the fact that for most of us this was the first time we'd been away from home and having to worry about doing our own washing, much of which was full of fluff and stray socks that we were sure weren't our own! Many times over the years I wish I'd kept that article. I had hoped that the wonder of the digital age would help, but this is the closest I've found.
DOA Program Committee and Topics
I'm chairing DOA 2009 and my co-chairs (Jean-Jacques Dubray and Fabio Panzieri) and I have been finalizing the program committee. Fortunately most of last year's PC have agreed to stay on so we've only had to add a couple of new people. Next step is to figure out the Call for Papers. If you've any thoughts on things you'd like to see at DOA 2009 that maybe weren't covered in the DOA 2008 CfP, let me know. After that we'll have to determine the invited speakers and keynotes. Fun fun fun!
Tuesday, January 27, 2009
Sunday, January 18, 2009
SOA Design Patterns released
I've been writing a book on SOA and ESB for a while with a couple of friends. It's due to be part of Thomas Erl's SOA series later this year. While writing it Thomas asked us to produce some patterns for his book on SOA. Well the finished book, SOA Design Patterns, is now out and it's well worth a read. A number of people throughout the industry have helped to contribute some of the patterns within it so this is definitely a cross-industry collaborative effort. Thomas also wants it to be a live-work in as much as new patterns can be contributed by anyone. So take a look at the book and if you see something missing consider contributing it.
Saturday, January 17, 2009
Star Trek interlude
Anyone who's known me for long enough knows that I'm a Star Trek fan. (Not the variety that dresses up as Andorians or learns Klingon!) Being born in the late sixties sci-fi was fairly influential to me in one way or another, with my fondest TV memories coming from shows like Star Trek, Space 1999, Dr Who, The Six Million Dollar Man and Blakes 7.
I still say that the first couple of seasons of The Original Series were better than much of what was created in recent years. So it's with some apprehension that I look ahead to the new movie. I'm definitely not going to prejudge, but I had hoped they would retain some of the look-and-feel of the original.
On thing that has stayed with me over the past few years is a quote from Kirk to Picard from Star Trek Generations (watch the film if you want to understand the context):
"Don't let them transfer you... don't let anything take you off the bridge of that ship... Because while you're there, you can make a difference."
I've found that it applies to more than just starship captains!
I still say that the first couple of seasons of The Original Series were better than much of what was created in recent years. So it's with some apprehension that I look ahead to the new movie. I'm definitely not going to prejudge, but I had hoped they would retain some of the look-and-feel of the original.
On thing that has stayed with me over the past few years is a quote from Kirk to Picard from Star Trek Generations (watch the film if you want to understand the context):
"Don't let them transfer you... don't let anything take you off the bridge of that ship... Because while you're there, you can make a difference."
I've found that it applies to more than just starship captains!
Monday, January 12, 2009
Virtual conference
We're doing a virtual conference next month. I'm recording some sessions at the moment. Very strange, but I think it'll be fun to attend. Maybe this will encourage me to look into SecondLife.
Wednesday, January 07, 2009
SOA is dead (again?)
For the umpteenth time SOA is dead apparently. It's been shot so many times over the past year or so that you'd think it had a role in a Sam Peckinpah movie! However, maybe it's got 9 lives or you need to use a silver bullet, because each time it dies it keeps coming back.
This time it's my friend Anne who is reporting the demise of SOA. I've known Anne for many years and respect her, so unlike a few other obituaries I take note of this one. However, like Duane I have to disagree that SOA is dead. OK, the term may have been overloaded over the past few years almost to the point of being meaningless (analysts are as much at fault as anyone in the industry) but the concepts behind it are still very much alive and relevant (more so in today's economy.) Where we have lost our way is perhaps in having an agreed architectural definition for SOA: it is the 'A' after all, so surely we can agree on what that means (REST doesn't suffer this problem) as well as pushing the mantra that "SOA is not just a technology" (though given the number of people who have been saying this over the years I suspect that this is more a case of individuals simply not listening, certain vendors muddying the waters or it being lost in the noise.)
There is no global panacea for IT woes. There never has been and I doubt there ever will be one. For the most part software engineering practices evolve over time (Darwin would be proud). There are a few evolutionary dead ends on the way. I doubt we'll see any extinction-level events though (not unless they're associated with human extinction.) But these things take time (I'm sure the dinosaurs laughed at the evolutionary path that created the Coelacanth, but who's laughing now?)
We can't afford to keep jumping from one lifeboat to another just because some use cases don't match, or someone didn't quite understand that you need to think about how to use SOA before coding. The underlying requirements of loose coupling, security, federation, reliability etc. date back decades. The term SOA should have been good enough. It still is as far as I'm concerned. If it's not SOA then are we in for yet another round of acronym generation, like SOA 2.0, WOA etc? None of which really add much to help the people at the sharp end of IT problems!
I think in Anne's recent SOA obituary she is trying to indicate that the principles are fine but it's the term that needs to go. In the first case we can agree. In the second I don't think it's worth the industry wasting another 4 years to disagree on yet another acronym (if we do, I'd like to nominate XYZZY.) As I said above, for people actually using these principles and associated technologies it won't make a difference to them. (It may be good for analysts though.) So let's just stop this madness and start concentrating on where it really matters.
In this case I think it's definitely more a case of what Mark Twain once said, "The reports of my death have been greatly exaggerated".
This time it's my friend Anne who is reporting the demise of SOA. I've known Anne for many years and respect her, so unlike a few other obituaries I take note of this one. However, like Duane I have to disagree that SOA is dead. OK, the term may have been overloaded over the past few years almost to the point of being meaningless (analysts are as much at fault as anyone in the industry) but the concepts behind it are still very much alive and relevant (more so in today's economy.) Where we have lost our way is perhaps in having an agreed architectural definition for SOA: it is the 'A' after all, so surely we can agree on what that means (REST doesn't suffer this problem) as well as pushing the mantra that "SOA is not just a technology" (though given the number of people who have been saying this over the years I suspect that this is more a case of individuals simply not listening, certain vendors muddying the waters or it being lost in the noise.)
There is no global panacea for IT woes. There never has been and I doubt there ever will be one. For the most part software engineering practices evolve over time (Darwin would be proud). There are a few evolutionary dead ends on the way. I doubt we'll see any extinction-level events though (not unless they're associated with human extinction.) But these things take time (I'm sure the dinosaurs laughed at the evolutionary path that created the Coelacanth, but who's laughing now?)
We can't afford to keep jumping from one lifeboat to another just because some use cases don't match, or someone didn't quite understand that you need to think about how to use SOA before coding. The underlying requirements of loose coupling, security, federation, reliability etc. date back decades. The term SOA should have been good enough. It still is as far as I'm concerned. If it's not SOA then are we in for yet another round of acronym generation, like SOA 2.0, WOA etc? None of which really add much to help the people at the sharp end of IT problems!
I think in Anne's recent SOA obituary she is trying to indicate that the principles are fine but it's the term that needs to go. In the first case we can agree. In the second I don't think it's worth the industry wasting another 4 years to disagree on yet another acronym (if we do, I'd like to nominate XYZZY.) As I said above, for people actually using these principles and associated technologies it won't make a difference to them. (It may be good for analysts though.) So let's just stop this madness and start concentrating on where it really matters.
In this case I think it's definitely more a case of what Mark Twain once said, "The reports of my death have been greatly exaggerated".
Thursday, January 01, 2009
Scala
My friend Mic and I have discussed a few languages I've been playing with over the past year or so, which include D and Erlang. I think I managed to persuade Mic that there is some benefit to Erlang, but maybe the jury's still out on D. Well a few weeks back Mic mentioned that he was looking at Scala, so I decided to take a look. I didn't find the time until I took a break from work for the festive season and have just spent a few days giving it a go. My first impressions are pretty positive (I've mentioned a few times in the past that I'm a fan of functional programming languages and particularly lisp which I've used for over 20 years). I'm trying to use it through Eclipse but am finding the plugin a bit clunky, so I may go back to the command-line and emacs (I'm a shell/emacs person at heart!)
So far I haven't got into any really complicated projects or applications so there may be problems with the language that I don't know about yet. But at the moment I like it and will persevere with some pet projects that I've been thinking about for a while. Even if it doesn't lead to anything ultimately, it's another language to learn and experience gained. But I have a suspicion it'll be more than a passing fad for me. Thanks Mic.
So far I haven't got into any really complicated projects or applications so there may be problems with the language that I don't know about yet. But at the moment I like it and will persevere with some pet projects that I've been thinking about for a while. Even if it doesn't lead to anything ultimately, it's another language to learn and experience gained. But I have a suspicion it'll be more than a passing fad for me. Thanks Mic.
Monday, December 29, 2008
Eventual Consistency and XTP
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 ;-)
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 ;-)
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.
Subscribe to:
Posts (Atom)