ESB and API are really different entities. If you read about a kind of competition between both products, there is a misunderstanding.
API is used to expose your services, checks the access rights, security, invoicing, etc.
ESB on the other side, provide new services by aggregating existing applications and resources.
Mixing roles creates great difficulties since API are not made to create new processes and ESB is weak when managing accesses.
Another point, API products are often linked to HTTP and don't manage service access through FTP, message which is useful when you do integration projects.
In the bank, ESB puts together, new and legacy resources such As the mainframe, to create new business processes. The API is a convenient way to access to that service.
I hope it is useful.
Feel free to contact me for more detail
Search for a product comparison in Enterprise Service Bus (ESB)
Today I would like to come back to this question about mixing ESB and API management.
First, I'd like to clarify that I mainly understand APIs based on the REST protocol when I hear or read APIs. Even if REST and API are not linked in their theoretical definitions, today, a large majority of the APIs is defined using REST.
As I have often said in other media, using REST as a protocol impoverishes the integration capabilities. When you see the success of REST APIs in many projects of all kinds, you often come across as a comical or a nostalgist of the past, SOAP/XML and Comma Separated Values exchanges.
This second answer would take too long to explain why REST pollutes and impoverishes exchanges between partners in the same business process. But to give you more details in a few words, the main reason for this affirmation comes from the indefectible link between REST and HTTP. Using only GET, PUT, POST... in asynchronous mode restrains integration platforms capabilities and is toxic for the definition of coherent exchanges.
Back to our question, it is clear that any ESB like OpenESB, WSO2 or WebMethod, today can handle REST APIs more or less quickly. REST is used as an entry point to the company's business services. So many IT managers mix ESB and API and ask the ESB administrator to become an API manager.
Today, REST's influence on integration technologies is decreasing. For 2-3 years, we see that more and more software editors, service companies, and analysts expressing reservations about REST use as an entry point for business services. (the light is at the end of the tunnel)
Event Oriented Architecture users are at the forefront of this new movement. The recent EDA 2021 summit (edasummit.io/) demonstrated that the future is not in REST APIs.
Also, the IoT (Internet of Things) wave with its billions of devices will be much more influential on our future architecture and integration platform design than the web and its HTTP protocol itself.
Other IoT protocols such as MQTT (Asynchronous and message-oriented protocols) will soon play a significant role in our future architectures where GET, PUT, and POST operations will no longer be used in exchanges between partners.
Best ESBs will be perfectly capable of using IoT protocols (or any other protocols) as entry points to business services.
In conclusion:
REST APIs are just a part of an integration platform. This part will decrease in the following years, replaced by IoT protocols and event-oriented designs. The ESB administrator must understand that even if IT Gurus and user pressure force him to focus on REST APIs, this is a small part of his/her tasks. Reliable and easy access to scalable and available business services is the essential part of his job and the criteria on which he will be evaluated.
The ESB manager must not be focused on API only. Still, he must employ all the protocols existing on the market to design a powerful integration platform and provide easy access to business services. Consequently, asking him/her to be (or become) an API manager seems to be a mistake and even a long term fault for the company evolution.
Financial Technology Solution Consultant at Intellect Design Arena Ltd
Consultant
Dec 7, 2020
The industry framework has changed rapidly. Instead of a strong core and multiple interfaces mostly hardcoded with channels, banks are moving to a light and flexible product processor with APIs that can be consumed by various partners in the fintech echo systems. API managers are going to be an integral part of next-gen banking as they will own revenue generation and building a network of opportunities for the banks through integrations and partnerships to help the bank become a lifestyle bank rather than a traditional bank which will loose to the competition to the challenger banks.
@Rohit SAHNI Hi Rohit,
You are right when saying that fintech companies need to publish their services and API is the current good solution. API Managers are in Fact very efficient in managing API access.
But unfortunately, it is not a response to the question. The question was: how we see the ESB and API role in Digital Banking environment.
I did not see the word ESB in your answer.
As you explain, API is a standard way to communicate between partners but it is certainly not a way to manage complex business processes. I think that you don't see the hidden part of the iceberg in integration. When you receive a service consumer request, you must control and receive it through APIs. But the response you must build can be easily created through an ESB when multiple partners are involved in a new business process.
If you suggest other easy and flexible solutions with just API please let us know.
Good evening
Paul
In my viewpoint, ESB (now we have an even more mature toolset like iPaaS) and API Management are very different w.r.t. the roles they perform in a Digital Banking World.
In big banks, we still have core banking systems running on protocols that in the modern world are native and from integration pattern perspective are corrupted for Open Integration enablement. This is where ESB or iPaaS play a major role. They help you create an Anti-Corruption Layer.
However, API Management is used to securely expose the APIs for outside-in consumption by digital frontends like Mobile, Web, etc.
So in a typical bank, you need both complementing each other.
In a digital banking environment, the role of ESB/API Managers becomes increasingly crucial. They serve as the bridge between various systems, ensuring smooth communication and data exchange while maintaining security and scalability. If you're interested in exploring more about digital banking and the importance of ESB/API Managers, Cleveroad's webpage on banking (https://www.cleveroad.com/industries/banking/) provides valuable insights into how technology is transforming the banking sector.
Presales Solution Architect at a tech services company with 10,001+ employees
Consultant
May 31, 2021
i think their role is about desgn, development, testing, and operational issues all of it. ensure that the vision of integration is implemented and maintained by being part of implementation and governance team.
Enterprise Service Bus (ESB) acts as a central component in application integration, offering a scalable architecture for seamless communication between disparate systems without requiring modifications to existing applications.ESB is essential for streamlining the interaction between multiple applications in an organization, acting as a middleware to connect and manage data exchanges effectively. Its architecture decouples systems, allowing integration across platforms, technologies, and...
ESB and API are really different entities. If you read about a kind of competition between both products, there is a misunderstanding.
API is used to expose your services, checks the access rights, security, invoicing, etc.
ESB on the other side, provide new services by aggregating existing applications and resources.
Mixing roles creates great difficulties since API are not made to create new processes and ESB is weak when managing accesses.
Another point, API products are often linked to HTTP and don't manage service access through FTP, message which is useful when you do integration projects.
In the bank, ESB puts together, new and legacy resources such As the mainframe, to create new business processes. The API is a convenient way to access to that service.
I hope it is useful.
Feel free to contact me for more detail
Hello to all,
Today I would like to come back to this question about mixing ESB and API management.
First, I'd like to clarify that I mainly understand APIs based on the REST protocol when I hear or read APIs. Even if REST and API are not linked in their theoretical definitions, today, a large majority of the APIs is defined using REST.
As I have often said in other media, using REST as a protocol impoverishes the integration capabilities. When you see the success of REST APIs in many projects of all kinds, you often come across as a comical or a nostalgist of the past, SOAP/XML and Comma Separated Values exchanges.
This second answer would take too long to explain why REST pollutes and impoverishes exchanges between partners in the same business process. But to give you more details in a few words, the main reason for this affirmation comes from the indefectible link between REST and HTTP. Using only GET, PUT, POST... in asynchronous mode restrains integration platforms capabilities and is toxic for the definition of coherent exchanges.
Back to our question, it is clear that any ESB like OpenESB, WSO2 or WebMethod, today can handle REST APIs more or less quickly. REST is used as an entry point to the company's business services. So many IT managers mix ESB and API and ask the ESB administrator to become an API manager.
Today, REST's influence on integration technologies is decreasing. For 2-3 years, we see that more and more software editors, service companies, and analysts expressing reservations about REST use as an entry point for business services. (the light is at the end of the tunnel)
Event Oriented Architecture users are at the forefront of this new movement. The recent EDA 2021 summit (edasummit.io/) demonstrated that the future is not in REST APIs.
Also, the IoT (Internet of Things) wave with its billions of devices will be much more influential on our future architecture and integration platform design than the web and its HTTP protocol itself.
Other IoT protocols such as MQTT (Asynchronous and message-oriented protocols) will soon play a significant role in our future architectures where GET, PUT, and POST operations will no longer be used in exchanges between partners.
Best ESBs will be perfectly capable of using IoT protocols (or any other protocols) as entry points to business services.
In conclusion:
REST APIs are just a part of an integration platform. This part will decrease in the following years, replaced by IoT protocols and event-oriented designs. The ESB administrator must understand that even if IT Gurus and user pressure force him to focus on REST APIs, this is a small part of his/her tasks. Reliable and easy access to scalable and available business services is the essential part of his job and the criteria on which he will be evaluated.
The ESB manager must not be focused on API only. Still, he must employ all the protocols existing on the market to design a powerful integration platform and provide easy access to business services. Consequently, asking him/her to be (or become) an API manager seems to be a mistake and even a long term fault for the company evolution.
The industry framework has changed rapidly. Instead of a strong core and multiple interfaces mostly hardcoded with channels, banks are moving to a light and flexible product processor with APIs that can be consumed by various partners in the fintech echo systems. API managers are going to be an integral part of next-gen banking as they will own revenue generation and building a network of opportunities for the banks through integrations and partnerships to help the bank become a lifestyle bank rather than a traditional bank which will loose to the competition to the challenger banks.
@Rohit SAHNI
Hi Rohit,
You are right when saying that fintech companies need to publish their services and API is the current good solution. API Managers are in Fact very efficient in managing API access.
But unfortunately, it is not a response to the question. The question was: how we see the ESB and API role in Digital Banking environment.
I did not see the word ESB in your answer.
As you explain, API is a standard way to communicate between partners but it is certainly not a way to manage complex business processes. I think that you don't see the hidden part of the iceberg in integration. When you receive a service consumer request, you must control and receive it through APIs. But the response you must build can be easily created through an ESB when multiple partners are involved in a new business process.
If you suggest other easy and flexible solutions with just API please let us know.
Good evening
Paul
In my viewpoint, ESB (now we have an even more mature toolset like iPaaS) and API Management are very different w.r.t. the roles they perform in a Digital Banking World.
In big banks, we still have core banking systems running on protocols that in the modern world are native and from integration pattern perspective are corrupted for Open Integration enablement. This is where ESB or iPaaS play a major role. They help you create an Anti-Corruption Layer.
However, API Management is used to securely expose the APIs for outside-in consumption by digital frontends like Mobile, Web, etc.
So in a typical bank, you need both complementing each other.
In a digital banking environment, the role of ESB/API Managers becomes increasingly crucial. They serve as the bridge between various systems, ensuring smooth communication and data exchange while maintaining security and scalability. If you're interested in exploring more about digital banking and the importance of ESB/API Managers, Cleveroad's webpage on banking (https://www.cleveroad.com/industries/banking/) provides valuable insights into how technology is transforming the banking sector.
API Gateways and ESBs: an Enterprise Comparison (apifriends.com)
i think their role is about desgn, development, testing, and operational issues all of it. ensure that the vision of integration is implemented and maintained by being part of implementation and governance team.