Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Enterprise service bus
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
===ESB as software=== {{more citations|date=October 2014|reason=reads like a bunch of short essays}} The ESB is implemented in software that operates between the business applications, and enables communication among them. Ideally, the ESB should be able to replace all direct contact with the applications on the bus, so that all communication takes place via the ESB. To achieve this objective, the ESB must [[information hiding|encapsulate]] the functionality offered by its component applications in a meaningful way. This typically occurs through the use of an [[Enterprise messaging system|enterprise message model]]. The message model defines a standard set of messages that the ESB transmits and receives. When the ESB receives a message, it routes the message to the appropriate application. Often, because that application evolved without the same message model, the ESB has to transform the message into a format that the application can interpret. A software adapter fulfills the task of effecting these transformations, analogously to a physical [[adapter]].<ref>{{Cite web|url=http://shop.oreilly.com/product/9780596006754.do|title=Enterprise Service Bus [Book]}}</ref> ESBs rely on accurately constructing the enterprise message model and properly designing the functionality offered by applications. If the message model does not completely [[Encapsulation (computer science)|encapsulate]] the application functionality, then other applications that desire that functionality may have to bypass the bus, and [[Invocational media|invoke]] the mismatched applications directly. Doing so violates the principles of the ESB model, and negates many of the advantages of using this architecture.{{citation needed|date=May 2025}} The beauty of the ESB lies in its platform-agnostic nature and the ability to integrate with anything at any condition. It is important that [[Application Lifecycle Management]] vendors truly apply all the ESB capabilities in their integration products while adopting [[Service-oriented architecture|SOA]]. Therefore, the challenges and opportunities for [[Enterprise application integration|EAI]] vendors are to provide an integration solution that is low-cost, easily configurable, intuitive, user-friendly, and open to any tools customers choose.{{citation needed|date=May 2025}} [[File:ESB Component Hive.png|thumb|ESB hive of commodity components]] ====Characteristics==== {| class="wikitable" |- ! Category ! Functions |- | Invocation | support for synchronous and asynchronous transport protocols, service mapping (locating and binding) |- | Routing | addressability, static/deterministic routing, content-based routing, rules-based routing, policy-based routing |- | [[data mediation|Mediation]] | adapters, protocol transformation, service mapping |- | Messaging | message-processing, message transformation and message enhancement |- | [[Process choreography]]¹ | implementation of complex business processes |- | [[Orchestration (computers)|Service orchestration]]² | coordination of multiple implementation services exposed as a single, aggregate service |- | [[Complex event processing]] | event-interpretation, correlation, pattern-matching |- | Other [[quality of service]] | security (encryption and signing), reliable delivery, transaction management |- | [[systems management|Management]] | monitoring, audit, logging, metering, admin console, [[Business Activity Monitoring|BAM]] (BAM is not a management capability in other words the ESB doesn't react to a specific threshold. It is a business service capability surfaced to end users.) |- | [[Agnostic (data)|Agnosticism]] | general agnosticism to operating-systems and programming-languages; for example, it should enable interoperability between [[Java (programming language)|Java]] and [[Microsoft .NET|.NET]] applications |- | [[Protocol Conversion]] | comprehensive support for topical communication protocols service standards |- | [[Message Exchange Pattern]]s | support for various MEPs ([[Message Exchange Pattern]]s) (for example: synchronous request/response, asynchronous request/response, send-and-forget, publish/subscribe) |- | Adapters | adapters for supporting integration with legacy systems, possibly based on standards such as [[J2EE Connector Architecture|JCA]] |- | Security | a standardized security-model to authorize, authenticate and audit use of the ESB |- | Transformation | [[Middleware Analysts|facilitation of the transformation]] of data formats and values, including transformation services (often via [[XSL Transformations|XSLT]] or [[XQuery]]) between the formats of the sending application and the receiving application |- | Validation | validation against schemas for sending and receiving messages |- | [[SOA Governance|Governance]] | the ability to apply business rules uniformly |- | Enrichment | [[Event-driven SOA|enriching messages]] from other sources |- | Split and Merge | the splitting and combining of multiple messages and the handling of exceptions |- | Abstraction | the provision of a unified abstraction across multiple layers |- | Routing and Transformation | routing or transforming messages conditionally, based on a non-centralized policy (without the need for a central rules-engine) |- | Commodity Services | provisioning of commonly used functionality as shared services depending on context |} ¹ ''Some do not regard process choreography as an ESB function. For example, see M.Richards.<ref>{{cite web | last = Richards | first = Mark | title = The Role of the Enterprise Service Bus (presentation) | url=http://www.infoq.com/presentations/Enterprise-Service-Bus | access-date = 2009-06-04 | quote = I do not consider process choreography part of an ESB, if we consider an ESB as a high-speed messaging middleware. However, I do consider process choreography part of the ESB *platform*. Fortunately most ESB vendors separate out these major components into different products, but package them under a consolidated ESB offering. So, in the strictest sense of the word, no, I would not consider it as part of an ESB. It is a related capability.}}</ref> ² ''While process choreography supports implementation of complex business processes that require coordination of multiple [[business]] services (usually using [[BPEL]]), [[service orchestration]] enables coordination of multiple implementation services (most suitably exposed as an aggregate service) to serve individual requests.'' These solutions often focus on low-level ESB functions, such as connectivity, routing and transformation, and require coding or scripting to implement orchestration.<ref>{{cite web|last=Feraga|first=Matthias|title=How to: choosing between lightweight and traditional ESBs|url=http://blog.octo.com/en/choosing-between-lightweight-and-traditional-esbs/|publisher=Octo|access-date=23 April 2014|date=6 Jun 2011}}</ref> Developers operating at a project or tactical level, e.g., just trying to fix a problem, often gravitate toward lightweight service bus technologies, but there is often ongoing tension between these initiatives and an enterprise architecture whose goal it is to optimize infrastructure across multiple projects.<ref>{{cite web|last=Fulton|first=Larry|title=Learn How to Embrace Lightweight ESBs|url=http://www.forrester.com/Learn+How+To+Embrace+Lightweight+ESBs/fulltext/-/E-RES43339|publisher=Fo2014|date=12 Sep 2007|access-date=23 April 2014|archive-date=27 January 2022|archive-url=https://web.archive.org/web/20220127014928/https://www.forrester.com/Learn+How+To+Embrace+Lightweight+ESBs/fulltext/-/E-RES43339|url-status=dead}}</ref> If the message broker, the ESB software, translates a message from one format to another, then as with any translation, there is the issue of semantics of the message. For example, a record can be translated from [[JSON]] to [[XML]], but the same set of fields can be interpreted differently by different applications, specifically in the case of the various corner cases that are usually known only to developers that have extensive experience with the application that is connected to the ESB. For the known corner cases the number of tests that cover all corner cases increases exponentially with every application that is connected to the ESB, because every ESB-connected application must be tested against every other application that is connected to the ESB.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)