Managing the data lifecycle
Matching: static X
IBM recently announced WebSphere Application Server V7 . It’s a release with lots of great features. I want to bring one new feature in particular to your attention in case you don't catch it in the high level announcement material.
In its last version, WebSphere began shipping an implementation of the Java Persistence Architecture (JPA), which is the persistence mechanism specified for EJB 3, part of the J2EE 5 standard. JPA takes many of the best features of frameworks such as TopLink and Hibernate to create a standard, more flexible, leaner persistence architecture than that provided in EJB2.
For enterprise applications that require container management and full-blown object-relational mapping, the JPA implementation in WebSphere is definitely something you should investigate using. (For new data-centric applications that don’t require object management or complex ORM, I will of course be a proponent of using the pureQuery API. :-) Remember, WebSphere sMash uses pureQuery for its data access, so it’s not just me saying this.)
WebSphere Application Server ND v7 now leverages pureQuery. It accelerates execution with Heterogeneous Batching and it gives a fast track to static SQL with a new generator.
Heterogeneous batching provides the capability to save on network costs by batching up updates across multiple objects (tables) in a single network call. See Vitor's article for more about heterogeneous batch.
I assume most of you know the benefits of static SQL in terms of performance, access path lockdown, and security. If you don’t, go read this article. The performance benefits of static SQL are further quantified in this article.
The procedure to enable the JPA app for static SQL is fairly simple. You run a command (wsdb2gen) on the JPA application to gather up and generate the possible SQL statements (i.e. CRUD statements) for your objects. Also it will generate SQL for all the named queries in your application. You can then bind the output from this command line tool using the DB2 Bind commands (or tools) to create the SQLDB2 packages (you can also do this from the WAS Console) and then you deploy them on the appropriate DB2 servers. Our enablement team is working on some educational materials and demos to show how this works, and I’ll be sure to let you know when those are available.
The nice thing about this WebSphere JPA/pureQuery integration is that you don’t have to run your application to gather the SQL. Simply run the wsdb2gen tool against the application. No need to exercise different code paths, etc. And, since you need the IBM Data Studio pureQuery Runtime anyway, you can always use the client optimization capability in the pureQuery Runtime to go back and capture any SQL that other parts of your program may be producing.
Over time, you’ll see more and more capabilities designed to make the DB2 and WebSphere combination work better together, with pureQuery acting as the enhancer for that optimized capability.
Let me know if you have any more questions about this capability (or anything else you may want to know about Data Studio) by clicking on the comment link below or sending an email to email@example.com.
If you want to hear more about JPA and pureQuery, there are a couple of IOD sessions you should sign up for on Friday, October 31.
My colleague, David Wisneski, will be going into a lot of detail in his talk:
TAD-1537 Developing and Deploying JPA Applications with Static SQL and pureQuery (Friday, October 31 at 10:00 a.m. at the Mandalay Bay South Conventiion Cetner, Breakers I)
Right after that, I will be presenting on:
TAD-2476 JPA, Hibernate, and pureQuery – the best of Both Worlds. (Friday, October 31, at 11:30 a.m in the Mandalay Bay South Convention Center, Breakers H)
And if you want to talk to me earlier, you can catch me at my Meet the Experts session (MTE-3169A) on Thursday, October 30th, at 9am. Hope to see you there!