What are we talking about when we talk about event-driven architecture and how is it related to SOA? In real life,...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
most of the time we are event-driven beings. If you look at your body, your eyes, your ears, your skin these are all event processors that are getting information and sending it to your central unit, which is your brain, which is figuring out whether I should listen to this guy or do something else. SOA is like your hands and feet. After the event has come in you send some message to your hands saying, "You've touched something hot. Move your hand from there." And you move your hand away. In the IT world, what kinds of events are the equivalent of putting your hand in the fire? There's the call center example where constantly calls are coming in and people are responding to those calls. Call center employees are logging in and logging out. Call volume is going up. Response time is going up. In that scenario the event processing system is monitoring a complex set of events and looking at it to see the call center response time is going up the SLA (service level agreement) is going bad. You may not get paid so someone has to do something about it quickly. So the event processing system alerts a supervisor? The process information is sent to the dashboard that someone is watching. Or if it has violated certain conditions, it will be sent as an alert, which could be an e-mail or a phone message to someone who could take care of it. You also could start a workflow to handle the situation. How is this event monitoring processed? It's the same SOA kind of framework we add events as the complimentary part of the enterprise. Not everything is requested and handled by services. Things that are event driven are addressed by the event infrastructure. There's an action framework. After the event is detected and processed, you could trigger an action either by sending it to some other system, which you think of it as a subscriber of the event. Or it could kick off a business process. Or it could kick of a message to a system providing additional information to someone else.
The composition of the event infrastructure is the generation of the event in the ESB (enterprise service bus) layer and propagation of the event, the complex event processing, the triggering of a business process and the processing of the event for monitoring purposes. SOA and EDA, how are they similar and how are they different?
There's a lot of overlap between SOA and EDA, but at the same time there are certain things that are different. It's about how you think about solving a problem. In the service-oriented world you have a request that you send out and you control what happens. In the case of the event world, you are reacting to things as they happen.
The infrastructure is similar. Both need underlying infrastructure which can talk to systems. Both need some kind of a bus to carry the request or information from one place to another. They need the capability to transform the messages that are flowing through. Both need business rules and business rules processing.
The things that are different in terms of EDA, for example, RFID falls more into the event driven side of the business. No one is asking for that event – a palette arriving on a loading dock – to be read. It is read as it is passing through and that event just automatically comes out. The event processing systems sense things that are going on and trying to make sense out of the data. Are there cases where SOA and EDA work together?
In most cases it's a hybrid. Like in the case of the guy sitting in front of a Web browser and trying to do something, he's doing a request/reply to the server: I want this information send it back to me. In the backend typically there will be some kind of a process that handles that request. But at the same time, that request, say on Amazon, could have triggered an event saying this guy came in and he's looking for a book on Tuscany. That event went out and is distributed onto the bus and maybe there are multiple processors that are looking at this event and saying this guy's looking at Tuscany maybe he's interested in plane ticket or finding a hotel there. It could be all the asynchronous activities that go on that come back with response to your request. You didn't ask for these things. Are IT departments aware of EDA?
Customers don't always know they are already doing EDA. They're trying to solve a problem that's a combination of events and services. One of the reasons for highlighting EDA is to educate people about different ways of thinking about problem solving. To make them aware that for certain problems the event-driven paradigm may be more practical that a service-oriented/process-oriented paradigm. So this isn't exactly new to them, other than maybe the acronym?
Event-driven processing has been around for a long time. In health care there are many things that are event-driven. The stock market trading is another example. So the concepts and the applications have been around for a long time. The same thing is true of service-oriented architecture, too. These patterns have been around for a long time. I've worked in this business for 24 years. Even 24 years ago, people were doing these patterns for these problems. What is different now is standards have come in – XML and Web services standards. People are more aware of these standards and are thinking of it in those terms. What standards are specific or key to EDA?
We are trying to leverage most of the standards that are there in the Web services world – XML, WSDL. The new one that is coming in is the event definition itself, WS-Eventing.
Also, event processing used to be an area that was very proprietary, we are working with the larger vendors (including Oracle, IBM and Microsoft) to come up with a standard for how you express an event process rule. There are complex event processing rules. We call it CQL internally, complex query language. CQL is being worked on by vendors now but will eventually move to a standards body. So the goal is to have EDA with open standards?
We would like to build applications with artifacts that can be interchanges amongst vendors. So if I create a business process definition, you can take my business process definition and run it on IBM. Or if you are running it today on IBM's engine or Microsoft's engine, you can take that definition and run it on Oracle. If someone has defined some event processing logic, I should be able take it from one engine from one vendor and run it on someone else's engine later. It's important from the vendor standpoint because I don't want to be excluded from a customer who has got some Microsoft or IBM infrastructure. I want to play in that customer's environment, too.