Porting Spring PetClinic to GigaSpaces
Upcoming SlideShare
Loading in...5
×
 

Porting Spring PetClinic to GigaSpaces

on

  • 5,019 views

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 ...

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

Statistics

Views

Total Views
5,019
Slideshare-icon Views on SlideShare
3,649
Embed Views
1,370

Actions

Likes
1
Downloads
53
Comments
0

7 Embeds 1,370

http://www.openspaces.org 1304
http://openspaces.org 56
http://www.slideshare.net 5
http://www.linkedin.com 2
http://203.208.39.99 1
http://72.14.235.132 1
http://translate.googleusercontent.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Porting Spring PetClinic to GigaSpaces Porting Spring PetClinic to GigaSpaces Presentation Transcript

    • Migrating JEE Apps to GigaSpaces Case Analysis – Spring PetClinic Uri Cohen, Product Manager Sept. 24 th , 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 2 nd 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 1 No No Web (Http Session) 2-3 1 1 Effort (3 is biggest) Yes
      • ORM 2 nd level cache: No
      • DAO: Yes
      Data Access Yes No Remoting Yes Minor to none Messaging Config change Code change Converted Layer
    • 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
      • 1 st 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
      • 2 nd Step: Partitioning
        • You should determine how objects will be partitioned
        • May involve duplicating parent routing fields to nested objects
      • 3 rd 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