From Layers to Bus
The Way from Classical Middleware Applications to SOA
The Layered Scenario
A classical layered middleware application landscape might look like this:
A few frontend applications connected to a middleware application that connects to the backend systems. Frontend application means anything an end user interacts with. This includes web applications, interactive voice response systems as well as special devices like ATMs. The middleware applications expose business services to the frontends using a unified data model and hiding the backend calls from the frontends. Additional business logic that is missing in the backend systems is also implemented in the middleware. Finally backend applications do the central data processing, implement compliance requirements and provide a single point of truth regarding the business data. While the middleware layer is often developed inhouse, the backend applications are mainly (customized) products.
Communication takes place according to the layered structure of the landscape. Frontends talk to the middleware and the middleware talks to the backends. There are no direct calls of frontends to the backends, all backend services are wrapped (and mapped) by middleware services. Backends do not consume enhanced services of the middleware, communication between backend systems is usally implemented by batch jobs.
The Bus Scenario
On the way to SOA the connectivity and mapping features of classical middleware applications are moved into an off-the-shelf Infrastructue: the Service Bus. The goal is to replace implementation by configuration. So the backend and frontend adapter layers of the old landscape are no longer needed. The Service Bus takes over and is able to communicate with the frotend and backend applications while still ensuring appropiate encapsulation by mapping to a common vocabulary.
The Service Bus itself does not add any new services like the old middleware applications did. Therefore we will need a place for these added-value services. As you can see in the above picture the place for these features is a new Custom Services box at the level of the backend systems, now referred to as Service Producers.
As the bus architecture does not by itself enforce a caller-callee relationship Custom Services can use the backends and can be used by the frontends. In addition Custom Services now can also be used by the backends as they see fit. Finally there is no longer a need to wrap backend services by self-built services as the frontends are now able to talk "directly" to the backends while still maintaining encapsulation through the use of the mapping features of the bus infrastructure.
Consequences
The most obvious consequence is that you have to remove the frontend and backend adapters from the middleware application block. Transport Adapters are now either part of the service bus itself or the service bus provides a common transports that your applications must be enabled to connect to.
Besides transport adapters you will also need a common Enterprise Vocabulary, i.e. a data model that is understood by your services. To make the services understand this vocabulary you can either add mapping to the service bus so that (legacy) applications can still use their own vocabulary or you enable the applications to provide their services using the new vocabulary natively. Depending on the applications you have in place the one or the other option is more compelling. Often you will use a mixed approach.
Finally an important concequence is the need for more explicit Governance. While the layered scenario inherently restricts allowed dependencies the bus scenario offers much more freedom. You may want to prohibit cyclic dependencies between service blocks and make sure that service level agreements can be met (i.e. higher quality services do not depend on lower quality services). Governance is also required to define responsibilites of the now mostly equal service blocks and to evolve the common enterprise vocabulary.