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
|
« New Survey to Discover the State of SOA Governance | Main | Making SOA Governable » March 16, 2008Will EDA Solve the Issues of Externalized SOA? By now, we're familiar with the promises of loose coupling and flexibility SOA is intended to bring to corporate systems. Now, the move is on to extend SOA beyond the firewall and enable business partners or outsourcers to access and share services. In a new article, Jack van Hoof explains that when a company outsources parts of its processes (and who doesn't these days), standard SOA may nt be appropriate. Instead, the way to go may be Event-Driven Architecture, or EDA. The "synchronous command-and-control nature of SOA is a way of tightly coupling application components which doesn’t allow for this kind of flexibility," he explained. "SOA may be loosely coupled in the technical domain, where common Web services technology is used, but it certainly is not in the functional domain where SOA is associated with ‘calling’ foreign (reusable) services and eliminating data redundancy." The problem with SOA, he says, is "the availability of services and stored data can be vanished after an act of outsourcing, which may lead to costly consequences and high risks. This has all to do with creating dependencies with SOA. The promise of SOA delivering loose coupling, which typically is asynchronous, could at the functional level be stated as a false promise." EDA helps "achieve loose coupling and autonomy" in these multi-enterprise settings, van Hoof writes. "In contrast to SOA, EDA provides a way of loose coupling. EDA is not a synchronous command-and-control type of pattern, but just the contrary: an asynchronous publish-and-subscribe type of pattern. The publisher is completely unaware of the subscriber and vice versa; components are loosely coupled in the sense that they only share the semantics of the message." "If you are seeking to support strong cohesion in the business processes, situations where all process steps are under one control, SOA is the way to go," said van Hoof. "If you are seeking to support independency between business process steps, EDA is the way to go." Since SOA (as we know it today) first came on the scene five years ago, the emphasis has been on employing it as a methodology for integration of disparate enterprise applications. Now, companies are looking to establish clusters of SOAs that extend beyond their enterprises to those of operational partners. This means SOA should no longer be treated as just another IT network. Posted by joemckendrick in Business Process Management • SOA | Digg This | Add to del.icio.us Trackback Pings TrackBack URL for this entry:
|
