Editing Enterprise service bus (section)

====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.