So, uh, duh 2.0
Joe McKendrick of ZDNet picked up on my so, uh, duh… blog entry regarding the new SOA 2.0 moniker. My previous post merely pointed to the petition to stop the madness. Something that is unfortunate in all of this is the actual reasoning behind the new moniker. Oracle and Gartner are trying to encourage the incorporation of events into SOA efforts. This, outside of the name, is actually a good thing. Bloggers like Brenda Michelson (eBizQ, elemental links) and Mike Herrick have posted on the importance of event driven architecture and its relation to SOA, as have I. Others out there clearly feel that EDA is a subset of SOA, and therefore there is no need to call it out. Personally, I think there is a risk that the need for events can get lost. A service is something that is available for the public good. It has to be requested. An event does not necessarily represent a request. It is merely a statement of something that has happened. What makes events so great is that anyone who is interested can choose to take action. The source of the event is not required to have any expectations of actions that will take place. It certainly can, but it doesn’t have to, unlike a service request. If we come back to the goals of SOA, a key one is agility. I don’t see how we can be agile without events. They bring exposure to happenings to a wider audience than the silo in which the action happened. That’s what it is all about. If we don’t break down the silos, we can’t be successful. Stop the madness. Ensure your architecture fully embraces services AND events. Just don’t call it SOA 2.0.
7 Responses to “So, uh, duh 2.0”
Leave a Reply
Todd – good to see Joe reading your blog.
As you mention, I’m all for the blended use of services and events. I do see SOA and EDA as complementary and peer architectural strategies.
The worst thing about the Gartner/Oracle SOA 2.0 moniker is “SOA 2.0â€? as presented has nothing to do with the underlying architectures, or the resulting business value. It evolved as marketing, to create a product category for Oracle to land their new offering in. The whole ‘no one was thinking of events in SOA 1.0’ – from the early announcements – really meant ‘no one had an all in one product’. Well… as those of us with practitioner backgrounds know, you can’t buy architecture in a box…
I presented SOA and EDA to the OMG earlier this week. I’ll be writing about it soon. But first, I need to answer your community project questions.
-brenda
Todd, I think that with or without “2.0” and Oracle, organizations are buying into RSS as their default ‘event mechanism’. So yeah, why not drop the “2.0”.
As MS incorporates RSS producers and reader into its Sharepoint offering, becoming core to Vista, and every other enterprise (and not) software vendor does the same we already have a ready event mechanism available, tried and trusted by bloggers and syndication services worldwide.
It doesn’t need much to see that it takes pressure off IT for surfacing a range of information on a portal. Now they’ll have time to concentrate on something other than working out how to present access to their corporate content systems. Maybe someone will work out that this mechanism (with the occasional ping) could easily be extended to a range of event driven tasks for automated systems as well.
If I read this in my sleep and this was the concept that Oracle is pushing, its so obvious that it seems to hardly need the hype!
Phil
I’d love to see someone really run with a discuss about using RSS as a system-to-system communication mechanism. I’ll be the first one to admit that my experience with RSS is limited to my usage of NetNewsWire (my reader of choice). The issue I have with it is that when I think of subscribe, I think of a push model. My RSS reader doesn’t get stories pushed to it, instead, it polls on some configurable basis. To enable what I envision with regards to events, a push model via some MOM is the way to go.
I’m with you Todd – I have a pretty hard time seeing RSS being a real Event Driven protocol.
Frankly, I don’t see how it can happen with HTTP w/o a major overhaul.
I’d love to see take off. Can you imagine the things we could do if there was a wire protocol standard as ubiquotous as HTTP/SMTP for real messaging?
Todd, Mike –
Good point – subscribe in the newsfeed RSS world is really a polling action. Even when paired with the ‘RPC’ pings that a blog sends to syndication services this does not really cut the mustard. Though in a low volume world I could see that a subscription service to a ping that tells a system when content has been updated could work – but is probably beyond the intended, or sensible use.
Still, at least as an integration mechanism, with RSS we now get no-coding content integration that even I can work!
Time for the smart guys to start really using the RedHat AMQ that Mike talks about!
Cheers
Phil
[…] If this wasn’t enough, you also have to consider how to represent identity on processes that are kicked off by system events. I’ve previously blogged a bit about events, but in a nutshell, I believe there is a fundamental difference between events and service requests. Events are purely information. Service requests represent an explicit requests to have action taken. Events do not. Events can trigger action, and often do, but in and of themselves, they’re just information. This now poses a problem for identity. If a user performs some action that results in a business event, and some subscriber on that event performs some action as a result, what identity should be carried on that action? While the implementation may result in events and implied action, to the business side, the actions the end user took that kicked off the event may represent an explicit request for that action. In other scenarios, it might not. It is safe to say that identity should be carried on both service requests and events allowing the flexibility to choose appropriately in particular scenarios. […]
[…] Joe McKendrick brought the subject of event driven architecture again on his SOA in Action blog. I’ve previously commented on this subject, most recently here, here, and here. This is a subject that I like to comment on, because I feel that appropriate use of events are a key to the agility that we strive to achieve. It’s very simple. Services execute actions. Processes orchestrate actions. Events trigger the transitions within the process. You need all of them. A solid messaging infrastructure is critical to event processing, so it’s very surprising to me that the MOM EAI ESB vendors aren’t all over this. Tibco has their complex event processing product, but they really haven’t pushed the event message very hard. What about the registry/repository vendors? Lots of talk about services, but not very much about events. The fact is, just as an enterprise can’t leverage SOA without services, they can’t leverage EDA without events. The two are complimentary, and I encourage the EA’s out there to start doing the work to identify the events that drive the business. […]