Managing the data lifecycle
Matching: jpa X
I wanted to bring your attention to an article that was recently published on developerWorks that describes the pureQuery / OpenJPA integration that I discussed in my earlier blog post, which is a new feature in WebSphere Application Server v7 that enables developers to generate SQL from their JPA application entities and named queries, which can then be bound into static DB2 packages, providing a fast path to the security and performance benefits of static access for DB2 data. In addition, when you use this capability, your JPA app can take advantage seamlessly of optimizations provided in pureQuery such as the ability to update multiple tables in a single network call.
This integration is our first step toward providing a strong, integrated stack among DB2 and WebSphere, using pureQuery as the "glue". (As an aside, the Performance Expert Extended Insight Feature also uses pureQuery to provide new insights into the interactions between Java applications and DB2, with the most capabilities being provided for Java applications in WebSphere.)
From a tooling perspective, this initial JPA/pureQuery integration is fairly light, but you will notice that the static binder utility is now invocable from the WebSphere Application Server console, so WebSphere admins won't have to switch to another tool to do the bind. In addition, you'll be able to use the new capability in Data Studio Developer 2.1 to visualizeelapsed time for SQL statements directly from the pureQuery outline.
Nevertheless, there is still much more we can do to make this process easier and less command-line driven. WebSphere plans to ship enabling technology that will "turn on" capability in Data Studio Developer 2.1 to invoke the wsdb2gen utility. In addition, you'll be able to use the output from wsdb2gen within Data Studio Developer and take advantage of other pureQuery outline capabilities, including the ability to correlate SQL statements with specific OpenJPA queries and the relations between the SQL and the associated tables and columns.
Check out the article if you get a chance.
-- Steve Brodsky
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!