The answer to this question depends the great deal on what ESB is. When I checked just qbizQ on 'ESB', the results came from 43 Articles, 19 Webinars, 42 News Stories, 21 White Papers, 5 Vendor Listings and many pages of BLOG titles. There is a strong opinion in the industry that currently the term is not defined or, more accurately, no definition is commonly accepted.
A few years ago, a Forrester Research Inc. report called ESBs "the leading entry point for SOA".Is this a buzz or not? Let us see.
Webopedia defines ESB as : "Short for Enterprise Service Bus, also referred to as a message broker. ESB is an open standards-based distributed synchronous or asynchronous messaging middleware that provides secure interoperability between enterprise applications via XML, Web services interfaces and standardized rules-based routing of documents. In practice, this means that data files are passed to and from their destinations based on pre-established guidelines that are common to all parties sharing the information to ensure that the data maintains its integrity as it is routed". Do you see SOA anywhere? If you do not, let's continue the search. Wikipedia shares the same opinion about messaging middleware foundation of ESB and goes a bit further: "...an enterprise service bus (ESB) consists of a software architecture construct which provides fundamental services for complex architectures via an event-driven and standards-based messaging-engine (the bus)." It is interesting what "fundamental services" are meant? "... An ESB generally provides an abstraction layer on top of an implementation of an enterprise messaging system, which allows integration architects to exploit the value of messaging without writing code. ..An ESB does not itself implement a service-oriented architecture (SOA) but provides the features with which one may implement such" Well, this is a bit confusing discovery: from one hand ESB provides fundamental services, i.e. realisation of SOA as I assume, from another hand, it does not implement SOA. Then what does it do; holds the word 'SOA' on a leash? Probably, the essence of ESB in provided features: "...ESBs attempt to isolate the coupling between the service called and the transport medium. "
Besides transport medium decoupling, there are a few other features that are claimed in many ESB products according to Wikipedia's observation:
1) message routing - static/deterministic routing, content-based routing, rules-based routing, policy-based routing
2) mediation - adapters, protocol transformation
3) message processing - message transformation and message enhancement
4) service invocation orchestration
5) security (encryption and signing), reliable delivery, transaction management
6) monitoring, audit, logging, metering
7) event processing - interpretation, correlation, pattern-matching
Additionally, some vendors claim they provide 'service mapping', which is, probably, a foreign terminology for the SOA realm. Others host 'service choreography' as an 'implementation of complex business processes'. Since service choreography is an internal feature of participating services, it is difficult to me to imagine how an intermediary may be a service internal at the same time.
As the ebizQ author David A. Kelly wrote, "The ESB has become a viable and practical integration alternative for many organizations". There is no doubt that ESB - a message broker - is a very valuable intermediary for application integration. The question is only about what service orientation is in the application integration? A usage of Web Services as an integration technology is nothing more than a standardised integration, which is good but an integration itself does not implement SOA. This is why I do not see why ESB becomes an "entry point for SOA": integration has existed and without SOA as well as SOA, as an architectural paradigm, not a technology, does not require any integration.
Five out of seven listed ESB features are purely infrastructure features. The only message processing and claimed 'service invocation orchestration' might relay to SOA and this depends on the types of SOA services. If we are talking about utility or infrastructure services, ESB may be useful (analysis of this type of the service with regard to ESB is the subject of another post). If we talk about business services, I think that an ESB creates more 'bads' than 'goods' if it is extended beyond the routing and abstraction of the transport layer. Here is why I think so.
First, service invocation orchestration being delegated to an ESB breaks integrity between architectural/design principles and concepts in SOA and its implementation. From service-oriented architecture perspective, there are basic self-contained stand-alone services and their combinations called aggregate or composite business services. The former do not use assistance of other business services, the latter, by definition, do. The essence of the composite business service is the orchestration of other service invocations, which also is called a process. If an ESB does not belong to such composite business services but performs service orchestration, the SOA eco-system looses the composite business services, which is not acceptable to SOA. At the same time, from the implementation perspective, there is no logical difference between a composite business service-process and an implementation of it in the form of a script on an ESB.
The problem here is not in technology but in the relationship management. If architected composite business service is the ESB, who owns this service, who is responsible for its behaviour and results to the consumers, who signs the Service Contract with consumers? Is it a Business Service Owner or a Technical ESB Owner? Remember, we are talking not about abstract services but about the ones that implement elements of business functionality, i.e. the ones that directly used in the business activities and, thus, carry business, not technical, responsibilities.
Since majority of the ESB's features are supposed to be shared, the Business Service Owner will get a problem of technical dependency on other and, possibly, unrelated business services. The Principle of Service Separation of Concerns requires that for the business service, its technical implementation, whatever it might be, may not create ties with other business services other than via official service interfaces. Shared transport/network layers, like the ones provided by the ESB, are external to the business service (it belongs to the execution context) and do not create undesirable ties. However, the directly combination of the service composition (application OSI layer) with shared transport/network layers results in potential mess and problems.
My educated guess is that no Business that seriously rely on Technology would allow loosely controlled ESB (because it is a technical infrastructure element) to be the crucial element of the composition of business functionality; this is the business matter. In my mind, there should be either an Application Server with such capability or a 'BPM-like' technical entity dedicated to the deployment of composite business service implementations. This, however, does not mean that all services used in the compositions must be deployed on the same entity; I suggest such co-location is rather unlikely.
Finally, regarding message processing, I would say that message transformation (for purposes of one of the interacting parties) or message enhancement performed by an intermediary is unacceptable for the business services unless this intermediary belongs/controlled by the business service. Assume we have a business service and a consumer of that business services. They tied by the Service Contract, which defines service interfaces available to the consumer. What would it mean if a consumer submits a message that is not understood by the service without undefined intermediary transformation (I said 'undefined' because the transforming intermediary is not a part of the Service Contract)? The same relates to opposite interaction from the service to the consumer. This is the case of violation of the Service Contract (which does not include the situation where an intermediary transforms the message into its internal format for its own convenience during the transmission).
Moreover, if an intermediary/ESB has its own internal processing policies that may be changed independently from the services/consumers and affect SLA, who should be responsible to the consumer for service misbehaviour - service or ESB? For the business services, the relationship with the consumers is the business matter, i.e. the message changes in between the interacting interfaces are the business matter as well. In particular, if a message carries a data structure that has to be modified to fit with the format accepted by the consumer, the business service would rather engage another business service (that knows and maintains all business rules for data transformation for all consumers) and release already transformed message in accordance to the Service Contract. If the message should be enhanced by, e.g., additional data-field, this 'intelligence' certainly belongs to the business domain and cannot be left without close business supervision, i.e. without another business service that performs business service collaboration and data composition.
You can ask a simple question: 'Why wouldn't we include the ESB into the Service Contract and define its role in the data transformation?". Well, there are some of my thoughts why this might be not a good idea. A Service Contract can contain an agreement among several parties but it recognises two roles only - Service Consumer and Service Provider. Assume, we have a Service Contract between one provider of a business service and two consumers. That is, the ESB has to be in the Service Consumer role. But in this case, the consumers in the Service Contract are not in the serving relationship to each other, i.e. ESB cannot serve consumer other than via the business service provider. Also, ESB cannot serve the provider because it is in the reversed serving relationship with it. If the Service Contract is among one consumer and two providers, we have a mirrored picture - the ESB in the role of Service Provider cannot serve another service, i.e. business service in this case, because of inappropriate serving relationships.
Thus, the only chance for ESB to perform data transformation in the scope of business consumer-service interaction is to become a service by itself. Fine, now we have an ESB Data Transformation Service. From the consumer perspectives, it would be reckless to hope that a transformation service will communicate with the business service on behalf of the consumer upon performing data transformation because there is not agreement about such 'favour'. So, the consumer will utilise the ESB Data Transformation Service and then send properly transformed message to the business service. From the business service perspective, it is unclear why it has to delegate its relationship with its consumers to the ESB Data Transformation Service (to interact with them on behalf of the business service) instead of simply engaging the ESB Data Transformation Service and only then responding to the consumer with well transformed message.
We have these problems with inserting ESB into the interaction between business service and consumer because the ESB does not appear as a business entity in the business transaction but tries to interfere with the business interaction in hidden, which is not acceptable in the Business. If the ESB starts to act in clear, as a business entity, it must play the roles of Service Consumer and/or Service Provider. This means, the consumers would sign the Service Contracts with the ESB and it would sign the Service Contracts with providers of the business services in turn. Is anybody aware of such business ESB ? Maybe this is the future...
As we've seen, not all ESB capabilities may be used for all types of services. I hope this conclusion does not come as a surprise - we have the same example with cars. In the USA, majority of cars have engines capable to run faster than 100 miles per hour. How many roads we see there that permit such speed?