Should we use ESB in any case of online integration?

When you are developing integration architecture principles in your company, the best current approaches is use ESB as target approach to online integration and services implementation. But do we need to use ESB in any case of online integration? Is it correct to fix it as principle? Or are there any cases when point-to-point integration is preferred.

The answer depends on vision and expected complexity of future services. Good ESB or different integration middleware can help to define integration architecture well. But on the other side it is new quite expensive component in infrastructure with indirect return on investment which is visible after longer time period.

You can focus on finding additional benefits. For instance, if you have in your company some specialized applications, you can choose ESB with adapters for them which rapid creation of first level of services which will represent functionalities within them. Integration middleware also can bring performance benefits via support of some high performance messaging (EMS, MQ and so on) which can be used as internal communication channel. Of course if you are considering future use of some repository during runtime (dynamic routing and changing of endpoints), implementation of features like these will be easier with ESB/integration middleware.

If you want to have a service oriented architecture, with all the benefits then your first thought would be use the ESB whenever you expose business services or APIs. However, as in most IT situations, there are no absolutes. While rarely right in a good, well-designed SOA, there may be occasions where point to point interaction without the ESB as an intermediary is the best answer. For example, if there is only one application using a service, and the expectation is that will not ever change, or at least not for a long time, then that interaction is probably best point to point.

In a good SOA, one does not implement services with an ESB, but only exposes services. By that I mean that the ESB presents a well-defined interface to presumably many consumers of that service. The ESB deals with issue such as security, message translation, and other things that fall under the category of syntactic mismatches between the consumers of the service and the provider(s) of the actual implementation of the service.


‘nogotofail’ Network Traffic Security Testing Tool

Google introduced a new security tool testing for common SSL certificate verification issues, HTTPS and TLS/SSL library vulnerabilities and misconfigurations, SSL and STARTTLS stripping issues, and clear text traffic issues, and more. Tool will help developers to detect bugs and security glitches in the network traffic security that may leave passwords and other sensitive information open to snooping.
The open source tool, dubbed as Nogotofail, has been launched by the technology giant in sake of a number of vulnerabilities discovered in the implementation of the transport layer security, from the most criticalHeartbleed bug in OpenSSL to the Apple’s gotofail bug to the recent POODLE bug in SSL version 3.
The company has made the Nogotofail tool available on GitHub, so that so anyone can test their applications, contribute new features to the project, provide support for more platforms, and help improve the security of the internet. It written by Android engineers Chad Brubaker, Alex Klyubin and Geremy Condra, works on devices running Android, iOS, Linux, Windows, Chrome OS, OS X, and “in fact any device you use to connect to the Internet.” The tool can be deployed on a router, a Linux machine, or a VPN server.