It's a fairly high level concept of abstraction. The central concept is that the ESB provides the middleware and interfaces that allow businesses to connect their applications without writing code.
This could include mediation to reconcile incompatible protocols, data, and interaction.
The idea of a central bus on which everything passes gives opportunity for additional layers of abstraction. Using industry standards to "plug" other applications, clients, and such into this bus makes it so that connecting new services, data sources, clients with disparate needs is relatively easy.
Actual implementations
As far as actual implementations, that's the domain of very large enterprise support businesses. While it's very buzzwordy, the goal is an ideal that on some small level can be understood through comparison with the internet:
Similarity to Internet
One big communications bus with widely different uses and data, but all running standardize protocols.
One can, in fact, write an HTTP to FTP connector that would allow browsers to access FTP sites without invoking an FTP client (usually built into the browser now).
Mashups
Mashups demonstrate an interesting implementation - take some bus route data from the San Francisco authority, map from google, and sushi bar locations from yahoo with ratings and run a simple query that gives you the closest sushi bar, weighting it so that you'd be willing to travel a little further for a better bar.
All completely different services, incompatible by themselves, but using standard connectors (yahoo pipes, for instance) they can be pulled together into a cohesive and useful whole.
-Adam
An API Gateway is a proxy provided for the client. The Gateway gives the client a consistent interface regardless of any changes within the internal system. It allows the internal system to change without affecting the client. The API Gateway can also provide consistent cross-cutting concerns such as security logging, reporting and API analytics.
An ESB (Enterprise Service Bus) provides a means for service-to-service communication. With this technique, services do not need to communicate with each other, reducing coupling. ESBs often use guaranteed messaging for inter-service communication.
Today, the Service Mesh pattern has become popular for microservices. A Service Mesh implementation can provide both an API Gateway and service-to-service communication, along with load balancing, security and many other features.
There are a lot of variations and implementation details, but this is the high-level difference.
Best Answer
SOA
isservice oriented architecture
. In SOAservices are decoupled
and can interact with each other irrespective of the service type. Meaning a particular service can be platform or protocol specific but SOA enables such services to interact and exchange data. This data is essentially exchanged viaESB
(Enterprise service bus
) which forms the backbone of any SOA architecture.Let me go ahead and give specific example to help understand this better. One way ESB could be implemented us by using
JMS servers
and usingXML/XSD
as means of transferring data between various services. So various service will register or connect to these JMS servers and exchange data using XML format. Generally SOA suite comes bundles with so calledadapters
that help transforming messages to and from format understood by service and XML.For example consider shares trading system. Messages from stock exchange come in
FIX
protocol. You may have build an application that expectsJSON
. To make these both systems work you will use SOA - FIX Adapter will convert FIX message to XML, then this xml will be transferred to JSON Adapter over ESB which will then convert to JSON as required by your system endpoint.Finally hoping following picture makes it very clear.