Post on 03-Jan-2016
description
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