One of the biggest
investment with the new GigaSpaces XAP release is our Spring support through a
new development framework named OpenSpaces. While many vendors are declaring
support for Spring these days, not everyone is doing the same level of
integration. Many are using Spring just for simplifying the configuration,
others like many of the J2EE vendors enable the deployment of Spring into their
containers, other initiative provides different Add-ons to
Spring.
Adrian
Colyer from interface21 summarized nicely in his blog post what
does it mean to support Spring:
He outlined
specifically the areas in Spring which should be utilized to support the "Spring
spirit" and pointed specifically the areas GigaSpaces release that support those
items:
• Allow
configuration to be managed by Spring. At the most basic
level this means having a set of configuration metadata classes that can be
wired up as Spring beans in an application context. Avoid creating your own
custom configuration files and formats if at all possible. To further simplify
things for your users, you might consider adding support for a Spring namespace
that makes it easier to configure things. Gigaspace provide a "gigaspaces"
namespace for example allowing elements such as <gigaspaces:config> and
<gigaspaces:caching> to be used directly in a Spring configuration file.
• Use
the Spring abstractions and design idioms in your
API. For example, the notion of a
"Template" is very familiar to Spring users. GigaSpaces provide a
"GigaSpacesTemplate".
• Support unit and
integration testing. Design your API in such a way that
it is easy to unit test and integration test business logic in a Spring
application that uses your product.
• Integrate with
the infrastructure services abstractions used by
Spring. For example, GigaSpaces' JMS and
JDBC abstraction can be used directly with Spring. GigaSpaces also provides
several implementations of Spring's PlatformTransactionManager to allow the
Spring framework to demarcate space-based transactions
When we designed
OpenSpaces we also thought on area's in which we could extend the Spring
framework under that same "Spring Spirit" that Adrian mentioned:
• OpenSpaces utilizes Spring as the
POJO development infrastructure and adds runtime and development components for
developing POJO-driven EDA/SOA applications and scale them out across a pool of
machines in a simple way – without dependency on JEE
container.
– Processing
Unit: The core unit of work, which
encapsulates the middleware as well as the business logic as a single unit of
scale and fail-over.
– SLA-Driven
Container: A lightweight container that
enables dynamic deployment of Processing Units over a pool of machines based on
machine availability, CPU utilization, capabilities and other criteria.
– In-Memory Data
Grid: Provides in-memory distributed data
storage.
– Declarative Event
Containers: For triggering events from the
Space into POJOs in either pull or push mode.
– Remoting: Utilizes
the Space as the underlying transport for invoking remote methods on POJO
services that "live" within a Processing Unit. With this approach a client can
invoke a method on a POJO service even if it changes its physical location. It
can re-route requests to available services in case of fail-over etc.
– Declarative
transaction support for the GigaSpaces In-Memory Data
Grid.
– OSGI-Like
Deployment Model: To enable simple packaging of
application bundles and manage their lifecycle independent of the Processing
Unit.
What does that
mean for a Spring user?
Spring users can use
the openspaces framework for high-availability and scalability of their
application – without being dependent on a J2EE container – using a lightweight
SLA-driven container. They can thus benefit from the simplicity of Spring
throughout the entire application and deployment environment. Having said that
It is important to note that this framework kept compatible with J2EE and can be
easily deployed within J2EE containers – so it is compatible but independent
with J2EE.