can Layer 7 replace an ESB and to which extent?
Any paper on this topic you can point me out to?
Message was edited by: Leif Bildoy
Removed Categories for OAuth and MAG
This very much depends on what backend architecture/systems your existing ESB is connecting to. We support a variety of protocols and connectors, and our product is a lightweight ESB in a sense.
If you provide more context to what systems the API Gateway would need to connect to, then we can provide the answer in terms of if it's possible.
If you want to know if the CA API Gateway can receive a request, do many call outs to other systems via several protocols and respond with a cumulated or transformed message, the answer is yes. If you want to know if it ships with a queuing solution, the answer is no. Nevertheless it can leverage queuing systems.
For general Gateway vs ESB information I suggest checking out Gartner. They have a webinar that reviews their noESB research paper here: Time to Get Off the Enterprise Service Bus? | Gartner Webinars . I think you need to register (for free) to view this.
A PDF of the presentation is also available: http://public.brighttalk.com/resource/core/52967/november_19_time_to_get_off_gollife_78141.pdf .
The actual Gartner research paper is here: http://www.gartner.com/document/2752017 . You need Gartner client access to download this however.
My usual short answer is no: the Gateway works as an API Management solution,
it can connect to the queues of an ESB because it has the possibility to listen and drop messages into queues but it does not have an onboarded bus, queue/topic management and other such aspects that are inherent of an ESB. Of course some people have tried to FrankeinBox a gateway into an ESB but I would not recommend it at all. You can use a tanker as a cruise ship (there is space and you can add seats and containers for rooms) and the novelty might attract business at the beginning but will still lack features that are inherent of the cruise ship and the user experience will not be the same (including the smell),
I am sorry if it is not the answer you were looking for
Office: +31611025636/ 20374 | Maurizio.Garzelli@ca.com<mailto:Maurizio.Garzelli@ca.com>
The key is your requirements. If you're replacing an existing ESB, how are you currently using it? How would you like to use it?
We, and other gateway vendors, have long and successfully positioned our gateways as special purposed ESBs (or ESB gateways, or NoESBs to use the term recently coined by Gartner; see above). By that, we mean we focus on the 20% of ESB capabilities that give most customers 80% of what they want/need from an ESB. That 20% is what ESB vendors largely agree is the core capability of an ESB, service virtualization. We support service virtualization of identity via routing, protocol via bridging, and interface via transformation; and we often do these things quicker, easier, and better with better security, performance, scalability, reliability and a lower total cost of ownership over time.
For service virtualization of identity via routing, we provide simple and sophisticated, accelerated and dynamic, runtime routing based on context and content.
For service virtualization of protocol via bridging, we provide support for and bridging between different combinations of inbound/outbound HTTP(S), FTP(S), SFTP, SCP, JMS, MQ, AMQP, Web Sockets, XMPP, APN, SSH, Raw TCP; inbound IMAP, POP; outbound SMTP, SNMP, JDBC, Cassandra and custom Java protocols.
For service virtualization of interface via transformation, we provide accelerated XML-to-any transformation with XSL; JSON to/from XML transformation with an out-of-the-box assertion; and any-to-any transformation with custom Java, Contivo and Data Direct assertions.
If your requirements fall within what we do well, you will realize a lot of value using our gateway as a special purposed ESB.
That said, we don't usually try to replace a customer's existing ESB (unless they ask us to, and they're using their existing ESB only for requirements that fall within what we do well, and they like our value proposition more). There are things that most broadly capable ESBs have/do that we don't. For example, they tend to have many adapters to handle esoteric protocols that we don't (though we support the most common ones). They tend to include queuing systems, and we don't (though we can connect to queuing systems when they're provided). They tend to support transactionality, and we don't (though we can support composite transactionality in policy). They tend to layer on higher level capabilities that some would argue go beyond the ESB itself, like long running orchestration, and we don't (though you can perform some orchestration in policy).
More often, customers with existing ESBs will also get our gateway for the things it does well, which let's them avoid their complex and expensive ESB more of the time, while they keep it around for the few things they use it for that only it can do.
We are trying to use gateway to orchestre rest service. We have heavy service API with 20 basic rest Backend service and light also. Every API could be to orchestre until 18 basic esb rest services or could be to proxy or route a single service . In total we have around 1000 service API. We don't manage the transactionality or the queues in the gateway but we have serious problems anyway.
We have service policy until 16000 rows of XML (exported service API) and we have serious problems with stability.
The architecture of the gateway uses different threads pool. In particular it uses tomcat Executor ( it has an old Jboss 4 inside) and instance one thread for each service API. If the service have tons of policies/assertions/... the context thread process seems to make unpredictable behavior: the gateway became very slow (also without traffic) and the only way to continue is the restarting.
After 1 month of investigations and analysis with CA support the issue is still present.
If you have expert developers / it architects my suggestion is to choose an open source gateway, if you didn't experts use CA gateway just to securize and publish service orchestrated by others components.
Sorry for typo
Retrieving data ...