A service bus is generally used to enable the connection between different parts of a SOA. Hence, its main purpose is to provide interoperability between services [PAP07]. Therefore, it has to be as flexible as possible to allow connectivity between different communication protocols, programming languages, runtime environments, and operating systems. Many concepts of a service bus also provide security, auditing, and logging services. If a service bus also provides these technical infrastructure services, it is more related to an execution container (i.e. CORBA). Whereas, if it does not provide technical infrastructure services but only facilitates communication, (i.e. remote method invocation) it can be seen as related to a communication framework [KRA07].  

 

For a service bus it is fundamental that each part of the functionality provided is implemented as a service [MAS07]. This allows implementing the functionality independently from each other and hence supports the concepts of loose coupling and distribution. A service bus also includes a service providing means to centrally manage the distributed SOA in order to enhance governability. 

 

 

When using a SOA within an enterprise a new model using a service bus (enterprise service bus) often replaces the ‘publish – find – bind model’. Since this concept is not entirely identical to a usual SOA concept it is often referred to as enterprise SOA [MAS07]. [1] shows such an enterprise SOA where the enterprise service bus acts as an intermediary between diverse, loosely coupled services.