Skip to Content

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. 

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

    1. Peter Peshev
      Hi Brian,

      One interesting possibility is to have a SCA  Java EE integration running inside the application server allowing Java EE applications enriched with SCA concepts to communicate with non Java EE  concepts (BPEL, etc). The runtime for communication with other systems could be  JBI / ESB based. I would personally love to see a common roadmap between JBI 2.0 and SCA.

      We have presented demo at the latest JavaOne about our SCAJava EE approach, you may check as well the following blogs for more /details :
      Service Component Architecture Meets Java EE: A Work in Progress (Part 1 of 2)
      Service Component Architecture Meets Java EE: A Work In Progress (Part 2 of 2)

      Best Regards

  1. Gerald KLESER
    “JEE has been so successful”

    I would rather put ot like this:

    It has sucessfully created a huge counter moveme, because of its design flaws: spring, POJO, Hibernate. And the deficiencies were so that they changed it in EJB 3.0 towards POJO (JPA is basically the Hibernate api)


Leave a Reply