Gigaspaces.com - Application Server
Home
  • Send to a friend
  • Print

Migration Worries? See How Easy It Is!

If you're responsible for developing or managing an enterprise application, you probably wish you could...

  • scale applications under any load
  • guarantee performance and availability
  • have predictability and confidence in your ability to scale
  • make apps ready for virtualization and the cloud

But this requires migrating to a new application model -- which is really hard work, right?

Wrong!

 

  • With GigaSpaces XAP, the Scale-Out Application Server, migration to a scale-out model is made simple, gradual, and painless.
  • Coming Soon: GigaSpaces XAP 7.0 will enable applications that use the latest versions of JEE, to be plugged into XAP and scaled out with no migration effort. To this end, XAP will soon be fully integrated with Glassfish, EJB 3.0, JPA, and other parts of the latest JEE specs. Read more...

 

Let us show you how - below is a brief migration story, just to give you a taste of how easy it is. Further down this page is a five-minute migration guide which explains what exactly migration involves.

 


Real-Life Migration Story - from Tier-Based to XAP in 4 Days

The Application An online gaming application, in which web clients send "tickets" to three servers, which process the ticket and calculate its odds, then save the result to a database cluster.
Original Setup Full staging environment with real data, running on JBoss. Infrastructure consisted of Apache load balancer, Tomcat, JBoss (x3), Oracle RAC, Sun JMS Grid.
Migration Time Four work days
Migration -Step One
 Caching the data, by configuring GigaSpaces as Hibernate L2 cache.
Immediate benefits: Improved read performance.
Migration -Step Two Packaging the business logic service (a POJO) in the XAP Processing Unit and replacing the existing remote call with XAP remoting / JavaSpaces notify.
Immediate benefits: Improved availability through hot failover and automatic re-initialization and relocation of services in case of failure.
Migration -Step Three
 Virtualizing messaging, by replacing existing JMS server with XAP's built-in JMS implementation.
Immediate benefits: Reliable messaging (the original setup suffered from sporadic message loss).
Migration -Step Four
 Moving to an in-memory data grid, with the database in the background ? this involved converting the JDBC DAOs to read to and write from data grid, and setting up asynchronous persistence by deploying a GigaSpaces Mirror Service.
Immediate benefits: Increased performance 100-fold (improvements of 10x-100x are typical for GigaSpaces XAP users).

 

Five-Minute Migration Guide

Here is what it takes to migrate to GigaSpaces XAP. Note that you can choose to integrate only one or more of these layers (you can use XAP only for messaging, only for messaging and data, etc.): 

Web tier

You can deploy your standard WAR in the GigaSpaces SLA-driven environment, and enjoy benefits such as self-healing and dynamic load-balancing.

Messaging/events

GigaSpaces XAP’s virtualized messaging tier can be integrated by replacing your existing MDB with a XAP event listener.

Remoting

To take advantage of GigaSpaces XAP’s Service Virtualization Framework (which provides reliable, fail-safe, synchronous remote invocations, alongside advanced options like asynchronous and map/reduce style invocations), all you need to do is annotate your POJO or write a few lines of Spring XML configuration.

Data access (Basic)

The easiest option is to use GigaSpaces XAP as a 2nd-level cache for Hibernate. This is a limited approach, which is very easy to implement, and yields a significant performance boost in read-mostly scenarios.

Data access (Advanced)

Converting your DAOs to read from and write to the data grid. this requires a bit more work, but it allows you to enjoy a significant performance boost for both read and write scenarios, and use XAP's asynchronous persistence capabilities to reliably offload data to the database.

Transactions

GigaSpaces XAP supports traditional transactional models; local and distributed Jini transactions; and Spring declarative transactions, so your applications will work as-is with their existing transaction strategy.

Migration: The Bigger Picture

When we think about migration, we often think about how much work it will take to port our application to the new platform. But this is only one part of a bigger picture. Here are four broad migration issues you must consider:

  • Gradual transition — the solution must not require a radical re-vamp of the entire IT organization. It must be possible to ease into the new environment, one step at a time.
  • Non-intrusiveness — the solution must not require major changes to the existing IT infrastructure and existing applications.
  • Applicability — the solution should be applicable to as many servers, applications and scenarios as possible. This improves the cost-benefit ratio by allowing you to spread out the effort of migration, and the resulting benefits, across the entire organization.
  • Future-proof — the next steps in your roadmap should not impose an additional migration cost. The solution should already support these future steps.

Read More: