Author Description

Enterprise Service Bus (ESB) is a hot topic today. Many vendors are either building new products in this category or dressing up their existing products to pitch them as an ESB. H- ever, there is no clearly accepted definition of what an ESB is, or what its architecture or programming paradigm should be. Definitions range from saying that ESB is wholly unneeded to saying it has all the capabilities of a full integration suite with built-in BPM, data aggre- tion, and WSM capabilities. Architectures range from being embedded in the clients and endpoints to being a central intermediary. Programming paradigms for the ESB range from writing Java to being completely configuration driven and pliable with graphical interfaces. BEA did not dress up one of their existing products and pitch it as an ESB but built an ESB from scratch. First introduced in summer 2005, BEA’s ESB has a razor sharp focus on where it is positioned as a component in an end-to-end SOA architecture. It complements a BPM service or a data aggregation service but serves a different and distinct role. Much of SOA is about componentization, interconnectivity, and reuse, and the ESB component serves as an intermediary with the clear and distinct role of providing loose coupling between clients and services, a routing fabric, connectivity, and a central point of security enforcement that c- tribute to the manageability of your SOA network.