SOA is all about a set of architectural patterns, principles, and best practices to implement software components in such a way that we overcome much of the deficiencies identified in traditional programming paradigms. SOA speaks about services implemented based on abstract interfaces where only the abstract interface is exposed to the outside world. Hence the consumers are unaware of any implementation details. Moreover, the abstract model is neutral of any platform or technology. This means, components or services implemented in any platform or technology can interoperate. We will list out few more features of SOA here:
Standards-based (WS-* Specifications)
Services are autonomous and coarse grained
Providers and consumers are loosely coupled
The list is not exhaustive, but we have many number of literature available speaking on SOA.
ESB is an architectural pattern different from traditional integration architectures, which support standards-based services for integration. As is true with SOA, ESB-based integration has been increasingly using web services standards and technologies for service description, hosting, and accessing. The advantage is that we not only reap all the benefits of ESB architecture (explained in Chapter 1), but also make sure that the services exposed at the bus are complying with industry standards. This means consumers and providers makes use of existing toolsets and frameworks to interact with the ESB.
If the services are as per the web service standards, ESB can provide the mediation services which will help to interconnect these services. Externalizing mediation logic out of services to an ESB will remove in-code coupling between services. To sum up, our current SOA infrastructure still exists which hosts services and takes care of service management and governance. Also an ESB provides SOI (Service Oriented Integration) in the form of mediation (and other services), which provides communication (along with other features) between services.
So, ESB or JBI are not an end by themselves, but a means towards an end (which is SOA). An ESB is not required to build an SOA, nor is JBI required for ESB or SOA. However, all of them have something in common using JBI � we can build standard components to be deployed into ESB architectures. Thus, JBI by itself is one of the ways by which we can attain SOA. There is also a caveat to this � just following JBI or ESB will not guarantee that you attain SOA. You need to consider the whole IT landscape in your enterprise, and then build and integrate things in the 'SOA way', and the below book is a guide and tutorial with this aim in mind.