Obschon ESBs weitestgehend auf Standards setzen, sind die ESB-Service-APIs heute noch proprietär und können nur notdürftig per "Messaging Bridges" oder Web-Services zusammenarbeiten. Ein Service, der auf der Basis eines ESB entwickelt wurde, läuft ohne eine Änderung nicht auf einem anderen Produkt. Hier setzt innerhalb des Java-Lagers die Initiative "Java Business Integration" (JBI) an. Sie beschreibt, wie Integrationskomponenten als Services auf herstellerneutrale und protokollunabhängige Art und Weise interagieren können. Ziel ist, die architektonischen Elemente eines ESB für die Java-Plattform als JBI-Container zu standardisieren. Was JCA heute für Konnektoren ist, könnte JBI morgen für Integrations-Services sein.

Einige kleine ESB-Hersteller haben bereits viele der genannten Features implementiert und bauen ihr Angebot kontinuierlich aus. Umgekehrt haben manche EAI-Anbieter klassischer Integration Broker wie Webmethods und Seebeyond kostengünstigere Einstiegsprodukte auf den Markt gebracht. Es wird bald schwierig werden, Highend-ESBs von Einsteigerversionen ihrer EAI-Plattformen zu unterscheiden. Diese Kategorien von Middleware konvergieren. Zudem wollen Hersteller wie IBM, Oracle, Microsoft und SAP Applikations-Server (J2EE, .NET, Corba) um Integrations-Features erweitern. Dieser zentralistische und schwer skalierbare Ansatz ist problematisch, da es unökonomisch ist, einen kompletten Applikations-Server zu installieren, nur um einen einzigen Integrationsservice darin laufen zu lassen. Letzterer kommt mit einer weit schlankeren (und kostengünstigeren) Ausführungsumgebung aus. Kritisch ist auch, dass beim Ansatz via Appserver die entsprechende Logik entwickelt, kompiliert und später aufwändig gepflegt werden muss. Die ESB-Hersteller versuchen dagegen, ihre Produkte möglichst unabhängig von Programmcode zu halten. Prozessänderungen erfolgen weitgehend per Rekonfiguration (anstatt Rekompilierung).