|
|
 | Summary: New features in GigaSpaces 5.1.
|
GigaSpaces 5.1 New Features
 | For links to the new features documentation, see below. |
| For the GigaSpaces 5.1 fixed bugs and known issues, click here |
- Full POJO Support
- POJO based services – you can encapsulate your business logic as a POJO, and deploy it as a distributed service on a dynamic pool of machines. To ensure that your distributed application requirements are met (CPU, memory, type of machines, availability, etc.), you need to simply provide them via the SLA deployment descriptor.
- Space – there is no need to implement any special interface or to extend your classes from a base class. POJO-based services can have the space started transparently, and have the space proxy injected into them. With 5.1, building SBA applications is easy, fast, and only requires a simple design phase. Most of the building blocks are ready to use.
- POJO data object – enables you to define your domain model using a POJO-based approach, eliminating the need for any special interfaces such as the JavaSpaces Entry. This feature also allows you to declaratively define your object's space meta mapping attributes such as indexes, FIFO behavior, replication behavior, etc. Using this method, mapping to the space Entry is done implicitly.
- Distributed dependency injection – this reference injection mechanism of services availability handles partial-failure scenarios, and enables application's continuous availability, simplifying the application development in a distributed environment.
- Spring Framework Integration – the Spring integration provides abstraction to the underlying GigaSpaces middleware components. This enables developers to seamlessly migrate from the existing tier-based model to a scalable Space-Based Architecture, while enjoying the simplicity of Spring, and avoiding vendor- locking. Space Based Architecture includes Data Grid abstraction through DAO support, declarative cache, JDBC template, declarative transactions, and Messaging Grid abstraction through remoting JMS template and a common JavaSpaces template. Finally, distributed Spring applications can leverage the POJO service support (see above) to enable dynamic service deployment.
- Seamless integration with external data sources – to fully benefit from the IMDG's performance and reliability with existing applications, this feature enables reliable asynchronous and synchronous integration with external data sources, e.g. databases. Applications can interact with the IMDG as high-performance front-end to data, which resides in an external data source. A special interface, CacheBulk, was introduced as an enhancement to the CacheStore/CacheLoader interfaces, to reduce I/O and network overhead while interacting with data sources. Special handling was added to ensure that no data is lost during this interaction, even in asynchronous mode and in partial failure scenarios. An out of the box Hibernate CacheStore implementation enables seamless integration without additional development. This allows users to persist their POJO objects into the database tables, using Hibernate mapping files or class annotations, and reusing the existing investment with Hibernate ORM, without additional code.
- The Mirror Service as its name suggests, provides the ability to capture all changes made to the entire IMDG cluster from a single point of access, even after an event of a failure. Combined with the Hibernate CacheBulk implementation, this feature provides simple and high-performance synchronization with external databases. Performance overhead is reduced significantly, using reliable asynchronous communication; and collocating of the mirror service with the database, leveraging the fast communication channel to the database.
- Performance – with this release, users can reduce the serialization overhead of their data objects significantly, by using the standard Externalizable Interface with the JavaSpaces API. A special optimization in the GigaSpaces communication layer takes advantage of such cases and bypasses some of the marshaling/unmarhaling layers. According to our tests, this optimization can improve space operations with Entry classes performance in remote spaces up to a factor of 5-10, compared to similar classes not using the Externalizable interface. The improvement factor is relative to the object's complexity.
- Out of the box .Net/CPP support with implicit handling of native data objects and improved performance. The PONO (Plain Old .Net Object) and the POCO (Plain Old CPP Object) introduce a new model for marshalling native data types in the .Net and CPP environment, similar to the POJO in the JavaSpaces environment. This allows .Net/CPP users to store their existing domain models in the IMDG. There is no need to write your own marshalling and unmarshalling code, and furthermore, from the developer's point of view, the implementation looks and behaves as a native implementation in the .Net or CPP environment. The design behind this model provides an efficient interoperability between all languages, through a portable binary representation. This release also includes significant performance optimization for the CPP and .Net environment. With this support, users have been able to reach up to a few thousands of messages/sec when writing complex market data events to a remote space, and to leverage linear scalability executing more than 100k transactions msg/sec, by using a partitioned IMDG.
- End-to-end application and middleware management tools – GigaSpaces management environment provides new capabilities to manage deployment, lifecycle, failure, and scaling of the business logic through a single point of access. These capabilities provide a consistent control of the entire application stack, as if it was running on a single server. The management interface is provided in two forms: CLI, which is essentially a distributed command line shell, and a rich-client management application, which provides different views of the entire cluster. The next release will include a JMX-enabled interface, which will enable users to view all of the managed entities through a single cluster. In addition, all middleware logging now uses the standard Java Logging API, to enable consistent logging across the application and middleware stack. A special handling inside the Service Grid enables dynamic control over the logging setup per service at deployment time.
- Network cable failure detection – the standard TCP stack could not reliably detect whether or not a network cable is unplugged during an active session. To handle this scenario reliably, software-based network-failure detection is now available. Since this handling is done in the low-level communication stack, it has the potential to degrade performance. However, the 5.1 release includes an optimized detection mechanism that can be easily controlled by the user. This mechanism is activated only when the connection is idle, thus ensuring minimum overhead over the network stack when a communication session is active.
- This release includes a large number of bug fixes in the space core, query and persistent modules. For more details, see the full list of fixed bugs and known issues.
Benefits of this New Release
- Linear scalability – using the Space Based Architecture model, writing an application that linearly and dynamically scales across multiple machines is as simple as writing an application that runs on a single machine.
- High Availability, end-to-end – unlike traditional application architectures, GigaSpaces provides a single, guaranteed, high-availability and scalability model for the entire application business logic and middleware stack. This obviates the complexity associated with integrating the different high-availability and scalability solutions for databases, message queues, application servers, and other middleware components.
- Performance – end-to-end transaction latency is minimized through the removal of the tier-based overhead (e.g. networking, different clustering models of the various tiers, distributed transactions overhead, etc). High throughput is achieved by parallelizing transaction processing within each processing unit and between units as well as a result of the collocation of the tiers.
- Deployment optimization – deployment of the entire application stack using a dynamic SLA-driven approach, which analyzes machine availability and suitability, load-balancing, and hardware or software configuration.
More in this Section
JavaSpaces Template
JDBC Template
JMS Template
Remoting
Deploying Spring Applications into the Service Grid
Declarative Caching
Write-Read Through and Write-Behind
Overview
 Write-Read Through for JavaSpaces API
Write-Read Through for Map API
Read-Through & Write-Through in Clustered Space
Read-Through & Write-Through Using Hibernate
Write-Behind – The Mirror Service
CacheLoader & CacheStore Considerations
Settings & Configuration
Write-Read Through examples using JDBC, Hibernate with/out Mirror
Limitations
Deployment Enhancements
UI Enhancements
Filtering by Jini group Relocation policy handler
SLA PolicyHandler declarations enhancements
Declarative watches
Deployment Descriptor reference IDs
Collocated space injection and Space association management
POJO lifecycle support
Service Grid Management Framework
Getting Started
|
