Joe McKendrick, ebizQ's SOA in Action Blogger, is a nationally published author and consultant
with deep knowledge and insights regarding trends and developments in
the technology industry. He is a contributing editor to a number of
national and international publications and Websites including
Database Trends & Applications, ZDNet, and Webservices.Org. He also
serves as analyst for Evans Data Corp., and is lead analyst for Evans'
Web services and enterprise development management issues surveys.
SOA in Action Blog
|
« 'An Enterprise Service is Not Any Old Web Service' | Main | 2007: A Year of Convergence for SOA and Business Process Management » December 14, 2006Why ESBs are Made for Event-Driven Architecture "In my travels around the world talking with people about SOA and ESB, I have noticed a shift in people's thinking and witnessed a trend of enlightenment over the past two years." Dave Chappell of Progress Software, who literally wrote the book on ESBs, has contributed a two-part series to th ebizQ site. In Part 1, he discusses why ESBs may be just what the doctor ordered (or make that what the CIO ordered) to broker the emerging event-driven architectures which are the next phase of SOA. "The real sweet spot where an ESB has shown its power and flexibility is in process-oriented, event driven architectures," Dave writes. In enterprise integration projects, "the key to success is to have an architecture that allows for each application to be decoupled from the rest of the SOA by using the ESB as a form of mediation." Dave adds that "the event-driven interaction style is a major advantage of keeping applications decoupled from one another. When plugged into an ESB, each application does not need to understand the intimate details of how to interact with all the other applications. The ESB handles all the protocols, data formats and different interaction styles." However, he cautions, its important that the ESB implementation have "reliable asynchronous messaging and high availability capabilities" to avoid errors in the transaction chain. In addition, he adds, the applications themselves often "need to be written or adapted to this event driven style of interaction." In Part 2, Dave discusses the various jobs ESBs must do, including Web Services Management and SOA governance, Advanced Web Services (WS-*), complex event processing, and semantic data integration. Interestingly, Dave dove into the role ESBs can play in complex event processing (CEP), sometimes known as event stream processing, which is a relatively new field in the area of Event Driven Architectures. CEP is about capturing and analyzing high-volume data streams coming out of algorithmic trading, fraud detection in financial services and supply chain management with Radio Frequency Identification (RFID) processing and filtering. "Typically, a CEP engine that is plugged into the ESB as a service will perform these tasks," Dave explains. "The stream of events may come through the ESB or may be another source such as an external stock ticker feed or an RFID reader. The course of action taken when a complex pattern of events is identified may vary, but can range from alerting a business user in a Business Activity Monitoring (BAM) dashboard or to invoke a service or a business process via the ESB." Posted by joemckendrick in SOA | Digg This | Add to del.icio.us Trackback Pings TrackBack URL for this entry:
|
