Event Description Language?
A colleague of mine was showing me an RSS feed that the USGS is now publishing. Within each item, in addition to the normal title, description, and link elements, it also contains latitude and longitude values, among other things. This spun its way into a conversation around subscribing to events, and whether we need an EDL (Event Description Language) that would be analagous to WSDL. Essentially, at the time a subscription is established, the EDL could be pulled in, allowing the subscriber to integrate the data from those events in a much simpler fashion. XML Firewalls could also use that to perform schema validation (among other things), ensuring that incoming event feeds don’t do bad things to the subscribers. The question is, does this exist? Does WS-Notifications handle this? If we had an EDL, we could have standard Web Services for querying the EDL and subscribing to the event feed. In the case of the USGS, I could have an application that queries the EDL, and sets up a subscription to earthquake events that occur within some range of lat/lon values of the user’s current location.
It’s suprising to me how EDA has not received anywhere near the press that SOA and BPM have. To me, they represent the triumverate that must exist. Services are the processing logic that get work done. Business processes control the sequencing of that logic, with events triggering the transitions.
[…] 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. […]