Java EE is one of the most successful application model and rightfully so. It greatly simplifies the development of stand alone, scalable, available, secure and transacted web applications. Everything in its application model is designed to process an arbitrary number of simultaneous requests and create a response synchronously as fast as possible. JSPs/Servlets, Session beans, Entity beans (as an in memory data cache), the security model, the transaction model, ... are all assisting the developer in creating these responses, in the richest and fastest possible way.

In fact, JEE has been so successful it has imposed itself as the main and preferred way of accessing back-end data, not just as a way to write new and cool stand alone web applications. Back-end integration is not easy, technologies are varied and often rustic to say the least, and most back-end systems were not designed  with the requirements of web applications in mind. There are three approaches to develop back-end integration solutions: invocation, mediation and activation.

Invocation has been the most commonly used approach used to date through technologies such as JCA, JAX-WS or WS-IF which are well aligned to support the request/response model but fail to support complex long running integration scenarios associated to particular application states. This is precisely one of the problems in JEE today because back-end integration does not always fit well the synchronous request/response model.

Mediation, is not new, and has been applied through proprietary products and frameworks for a decade. Last summer the JCP published an API to build standardized mediation infrastructure: the JBI specification. JBI is based on the "mediated message exchange" pattern: when a component sends a message to another component, this interchange is mediated by the JBI infrastructure, namely the NMR or Normalized Message Router. The NMR functionality can be augmented by Service Engines (such as transformation or orchestration engines) to facilitate the mediation with back-end systems. However, centrally coordinated architectures, such as JBI, have historically always struggled with the problem of "who manages the central infrastructure". The problem is most acute in B2B scenarios where most companies don't want to incur the cost of "mediating" message interchanges unless there is some value add. Actually, the JBI specification explicitly excludes from its scope the normalization of the interactions between two JBI instances. These type of interactions happen behind binding components in a completely proprietary way. This restriction greatly compromises the composition capabilities of JBI instances. Hence, JBI is well suited to solve small and local integration problems.

Activation is a relatively new approach to the problem. It consists of producing components which can be accessed via different middleware, synchronously or asynchronously. Activation maximizes the autonomy of the components themselves and their ability to be composed with other components. In particular, this means that the business logic implemented by a component cannot depend or rely on any specific middleware facilities. This is the component model proposed by SCA. In SCA, activation applies either at the component level or at the module level. A module is an assembly of components running in the same process. 

SCA enables arbitrary topologies of systems, supporting synchronous and asynchronous, client/server, peer-to-peer, long running or short lived interactions. SCA does not make any assumption about company boundaries and enables exposing a system as a component participating in another system, each of which having different managing authorities, i.e. company boundaries may be defined or shifted arbitrarily across an SCA system. SCA is well suited to solve any integration problem in particular the most complex ones, including the ones solved by mediation and invocation infrastructures. In many ways, SCA can be viewed as a decentralized mediation infrastructure where mediation happens either at the provider or the consumer side, without necessarily involving an intermediary.

To further understand the differences between the 3 approaches, let's look at how a "connected system" is assembled, i.e. how the wiring is defined and enacted in each approach. In an invocation based infrastructure, the wiring is usually defined via a "connection string containing the end point reference and some credential. In a mediation based infrastructure, the connected system is defined via a configuration file that contains the specification of a particular assembly of components, routing rules, ... This specification is consumed by the JBI infrastructure (NMR, Binding Components and Service Components). However each binding component retains its own proprietary mechanism to specify wiring to the service provider or consumer behind the binding component. In SCA, there is no central coordinator and an assembly of components is deployed to each component type, which activate components (instances of component types) for each unit of work being performed.

I do not want to end this note just by saying that SCA offers a new integration model because, SCA is also and above all a new application model, i.e a new way to build applications as an assembly of autonomous software agents, exposing service interfaces. SCA is innovative because it offers a unified application and integration model.

We can expect that Java EE and SCA will coexist offering a complementary application model while JBI will be used in traditional Enterprise Application Integration scenario.