There are SOA evangelists and there are EDA evangelists. Some SOA evangelists are starting to discover EDA and some EDA evangelists are starting to discover SOA. Most EDA evangelists concentrate on complex event processing (CEP: recognizing patterns in events) and event stream processing (ESP: take time related actions on patterns in fast streaming event-flows), with David Luckham as their Godfather. Most SOA evangelists struggle with the idea of decoupled one-way communications; "what the heck is an event?" and "don't I loose control?".
But I don't see a focus on the big advantages of using simple events, yet. Forget for a while about explicit correlations between events and pattern recognitions. After you are familiar with events, you can always add complexity to do more sophisticated and exciting things. You don't always need to recognize patterns in event-flows or to process huge numbers of events in very short time-frames. The contrary is true. In most cases simple events will already give a lot of opportunities and above all: ease.
Let me tell you a story
We implemented an ESB infrastructure as a platform to start building SOAs. We are creating roadmaps to implement SOAs. We are looking for pilot projects. We are evangelizing the concepts. But we don't have an SOA yet.
We are also implementing an employee-portal. And the portal uses an enterprise directory to control access, among other things. We also have an SAP-system in which we maintain employee data. And it seemed to us that it would be a good idea to feed the enterprise directory with employee data from SAP when a new employee is employed or when an employee gets retired. What we do now - using our common sense - is publishing the new employee data as a one-way SOAP-message in our ESB. And we also publish a one-way SOAP-message in the ESB when an employee retires. Not a big deal, is it? But guess what... Other departments in our company are starting to ask: "Wow, can we use these published employee data as well? It would save us a lot of work if we didn't need to handle and check all those FTP-files every week. And our database would always be up-to-date." Another department (maintaining work-schedules) asked us if it could be possible to publish the employees that are sick and to publish when they recover. Well, of course, at your service.
You see what happens? We don't have an SOA, but we see arise an EDA without even mentioning the acronym. Isn't that wonderful?
And I have another interesting story
We would like to know the occupation of our trains. These figures are interesting for several reasons. For instance to optimize material planning, but also to recognize trends which may trigger new business opportunities. We designed sensors in the trains to count the number of passengers boarding and leaving the train. These data are parameters to a piece of software that calculates the occupation of the train. The data is planned to be stored in a data warehouse.
But... in stead of collecting records to a file to be loaded into the data warehouse, we designed to publish the calculated occupations directly in real-time as one-way SOAP-messages in an ESB. The data warehouse will be wrapped to collect and store the published data. (You must know that we are working on a mobile infrastructure which gets ESB-components onto the train, which makes it possible to have the software on the trains participating in our global application-infrastructure.)
What is the big deal now? Well, of course I explained that the transport of data using this generic application-infrastructure in place would be much cheaper than any other form of transport. But when I explained that the messages floating in the ESB can be captured by any other application wherever in the organization, for instance by an easy to program little tool to display the occupation of every train in real-time, it became quiet. "So, when there is an obstruction on the railroad, we can see how many passengers will strand at the station... in advance?" Yes sir, you can! It's a free spin off.
"Wow..."
This is all about EDA with simple events. It just happens and it will continue...
Wednesday, September 06, 2006
Why not start with simple events?
Subscribe to:
Post Comments (Atom)
3 comments:
I agree with you Jack!
It's a strange thing. People seem to be looking in the distance, where sexy solutions are glowing in the dark, while there are very powerful mechanisms in bright daylight.
It's a pity many people have been focussing so much lately on these complex event- things, however beautiful. There are events for grasp, even before implementing an SOA!
Maybe this opportunity is so strongly overlooked because it's not so much a technology-thing as it is a conceptual one. We see this phenomenon everyday.
Here's my advice: Start thinking and talking in eventy terms, business people and IT- people. The rest will probably be there before you know it.
Let there be events!
Agreed Jack!!
SOA is way overhyped. Events are the future.
Ref: http://eventprocessing.worldpress.com
Link should have been:
http://eventprocessing.wordpress.com
(please correct, thanks!)
Post a Comment