Upload
uri-cohen
View
3.337
Download
8
Tags:
Embed Size (px)
DESCRIPTION
This presentation shows the general methodology of porting a JEE web application to GigaSpaces XAP and the lessons learned from the process of porting the Spring PetClinic sample application to the GigaSpaces platform
Citation preview
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