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
|
« Gartner's Schulte: How to Grow Your SOA | Main | BPM Without SOA: 'Like One Hand Tied Behind Your Back' » November 21, 2006Are ESBs the New Application Servers? There's been no shortage of confusion in the industry about the role and makeup of the enterprise service bus, or ESB. Just about every vendor has a product they call an ESB, but there are questions around their scalability and interoperability. In this panel discussion at ebizQ's recent SOA in Action online conference, Progress Software's Dave Chappell and Cape Clear's David Clarke sought to clear up some of the confusion around ESBs. (Replay is available here.) "Unfortunately it's the IT departments who are trying understand and evaluate ESBs that suffer the most from the current lack of clarity of a definition of ESB in the marketplace," said Chappell, who defines an ESB as a platform "used to connect mediate and control the interactions between a diverse set of applications that are exposed through the bus using service level interfaces." ESBs should be light and rapidly deployable, Chappell added. Ideally, an ESB "shouldn't require the heavy footprint of monolithic integration brokers or application servers deployed repeatedly in order to provide the proper infrastructure support," he said. "Capable of being deployed broadly across the extended enterprise with minimal intrusion without requiring a large staff to install and manage over time." Clark noted that ESBs are an evolving technology, and that it currently is "the best way to implement SOA." In addition, he added, "we consider ESB the principal container for business logic. This is the next generation application server." ESBs will continue to change as approaches to SOA change, he added. "As the level of capability and sophistication and understanding of how you can implement SOA increases or evolves, the definition of ESB and how it should rightly behave will also evolve." Both Clarke and Chappell emphasize, however, that ESBs are not mandatory for SOA development -- but it really helps to have one. "What we're finding is that organizations are approaching SOA through a variety of ways today," Chappell said. "Some are using ESBs, some are using Web services capabilities that came with their application servers, or with their ERP systems, some are using Web services toolkits." However, effective SOAs are difficult to build, and attempting to manage a jumble of point-to-point Web services can become unwieldy. "An ESB provides a common backbone upon which you build your SOA," Chappell continued. ESBs "provide a layer of abstraction between SOA objects.. This common backbone can provide a unified, enterprise-wide approach to ensuring quality of service issues, such as guarantee of service requests, and a common means of applying common security and solution for fault tolerance and high availability within a service infrastructure." "Using an ESB prevents you from having to spend time in low-level plumbing details directly into your services," Chappell said. Posted by joemckendrick in SOA | Digg This | Add to del.icio.us Trackback Pings TrackBack URL for this entry:
|
