Migrating JEE Apps to GigaSpacesCase Analysis – Spring PetClinic

Uri Cohen, Product Manager

Sept. 24th, 2008

Agenda

• Background & Motivation

• What’s In an App Server

• Migration in Practice– Messaging

– Data Access

– Web front end

• Architectural Considerations

• Live Demo

Background

• GigaSpaces as an application server

• Previous projects to map the migration efforts and gaps

Motivation

• Feasibility study, learn about:– User experience (migration complexity)

– Gaps between JEE & GigaSpaces

– Use that as input for next releases planning

• Share outcome with user community– Provide a common basis for compatison

– “Here’s how it should be done with GigaSpaces”

What’s In an App Server?

• Data access

• Messaging / event processing

• Remoting

• TX management

• Web

Migration in Practice• Messaging / event processing

– Replace MDBs with GigaSpaces event listeners

• Remoting– Replace SLSBs with GigaSpaces SVF

(Remoting/Executors)

• Data access– Use GigaSpaces 2nd cache for Hibernate– Convert your DAOs to use GigaSpaces, use mirror to

persist

• TX management – Use Spring…

• Web – Use GigaSpaces web processing unit– Use GS HTTP session replication

Migration in Practice

Converted Layer

Code change Config change

Effort (3 is biggest)

Messaging Minor to none Yes 1

Remoting No Yes 1

Data Access

• ORM 2nd level cache: No

• DAO: Yes

Yes 2-3

Web (Http

Session)No No 1

Converting Your Messaging Layer

• Convert you MDBs to GigaSpaces event containers

• You can use IMessageConverter on the client side

• You can use annotations / XML• Considerable performance boost

– Without affinity: up to 3 times faster– With affinity: up to 6 times faster

Converting Your Messaging Layer

Converting Your Messaging Layer

Converting Your Remoting Layer

• Usually implemented by SLSBs with JEE• No or minor code changes needed• You get:

– Location transparency

– Dynamic service discovery

– Synchronous or asynchronous invocation

– Cluster wide invocations (Map/Reduce)

– Data affinity

– Automatic failover

• Service Interface

• Client:

• Server:

Converting Your Remoting Layer

Converting Your Data Access Layer

• Currently this is not effortless• 1st step: Domain model

– Dealing with relationships• Need to change domain model

– Add foreign key fields, update setter, O/R mappings (if you use mirror)

• No lazy loading– Load on a per case basis, might mean you should

change the DAO• No object navigation and aggregations in queries

– Need to query the space multiple times and aggregate

Converting Your Data Access Layer

• 2nd Step: Partitioning– You should determine how objects will be

partitioned– May involve duplicating parent routing fields

to nested objects

• 3rd Step: Changing the DAO– Naive approach: Convert all JDBC/Hibernate

calls to space calls– Better approach: Use Remoting/Executors,

take advantage of data affinity and collocation

Converting Your Data Access Layer

• Other issues:– Non String IDs: need to create cluster-wide ID

generator– No dirty checks: similar to lazy loading, need

to persist on a case-by-case basis– Semantics:

• When saving with Hibernate/JPA, generated ID is injected into the object

• Solve at the DAO level

Architectural Considerations

• Web app & space in the same PU– Partitioned or replicated?– Is it really collocation?– No dynamic scaling

• Web app & space in separate PUs– Separate scaling models – more flexible– No collocation

• Local cache can help

Let’s See It in Action

Future Roadmap (Suggestions)

• Object navigation in queries– user.address.street=’Oxford’

• Native aggregate functions– max, min, avg, std, custom

• Relationships– JPA support

• Embedded EJB container?

Q&A