When people first hear about Space-Based Architecture (SBA) one of their immediate reactions is – “Is it a replacement for J2EE?” Since J2EE is not necessarily only one thing (especially not today with all the recent developments in the likes of Spring, POJO’s etc.) my answer is that SBA is both compatible with as well as independent of J2EE. Let me explain:
The J2EE architecture is fundamentally designed to address the creation of applications that leverage one or more of four tiers:

  • web-front-end
  • business logic
  • data-access/legacy-integration
  • messaging

SBA is more focused and is designed to satisfy the essential purpose of the business , data, and messaging tiers, but with greater scalability and lower overall latency. As SBA does not address the web-front-end, that alone leaves room for cooperation between the platforms.

SBA is a specific development and deployment architecture. Our upcoming 6.0 version is built entirely on top of Spring and utilizes Spaces in a declarative way that hides the direct interaction with the space through various Spring-based abstractions. It is specifically designed to enable a very simple transition of tier-based applications into scalable and high-performance SOA. As such, it fits into the J2EE container model in the same way that Spring does today, i.e., it is compatible but independent.

Now, comes the next question: “Why choose SBA over EJBs?”

My answer: “Increased scalability with greater simplicity and a lower total cost of ownership.” The J2EE stack is constantly evolving and transforming to address performance, scalability and complexity issues. Even so, many J2EE applications have a need to scale beyond the capabilities of the J2EE platform and so are leveraging multiple products to achieve their performance targets.

In the business tier, it is becoming a common practice to use a lightweight container and POJO-based approach, such as Spring, as an alternative to EJBs (BTW, I often see this framework being collocated with the web-tier).

In the data-tier, a common practice is to use an In-Memory-Data-Grid (IMDG) solution as a front-end to the underlying database to reduce the I/O overhead and contention of data access.

Finally, the messaging tier is also often implemented using a separate product produced by a different vendor from the J2EE stack provider.

Because of all this, multiple skill sets and specializations in multiple products are necessary (as well as multiple licenses for these products). As a result, the abstraction away from particular products is sought out often through the adoption of the Spring framework. For the above reasons and for testability, most Spring-based applications are written today in a way that is independent of the J2EE container, i.e., they could run in a Spring-based container during development and only later in the application life-cycle run in a J2EE container. This means the Spring-based application is both compatible with J2EE and independent of it. It also means that the value of J2EE in the business tier is rarely derived from the EJB container as it once was commonly thought.

SBA fits nicely within this new development model. In GigaSpaces 6.0, the lightweight container is built as an extension to the Spring container. As such, users are now free to deploy a Spring-based application on top of our lightweight container, or with a J2EE container, without changing their code. Additionally, our implementation offers interoperability with C++ and C# services, something not found in a J2EE stack. Many high-performance, transactional applications are written today in languages other than Java or with only J2SE in an attempt to meet their high throughput and low latency requirements. The interoperability offered to C++ and C# through our space as well as our lightweight, SLA-driven container directly addresses the needs of those applications without dragging the entire J2EE stack along for the sake of convention. In essence, with GigaSpaces and our Space-Based Architecture you have the outcome you seek achieved with a single platform (aside from the previously described web tier which can as before be collocated thus reducing hops across tiers).

The bottom line is that our Spring-based implementation doesn’t introduce a totally new development environment – it fits very nicely into existing development environments and takes advantage of the Spring-based declarative approach while providing scalability of the business logic, messaging services, and access to associated data. For more information on our spring-based SBA approach, please refer to the following blog entry:


SBA and J2EE Positioning Clarification
Nati Shalom