Raible Designs

[DJUG] JUG Central and BPEL

Last night, I attended Denver's JUG meeting. Below are my notes from the event.

I'm at DJUG listening to Christian and Kris (from Adigio) talk about their experience with using Spring, WebWork, Hibernate, Lucene and SiteMesh to develop JUG Central (I wonder if they knew this name and concept already exists?). JSPs are for the view and MySQL powers the data. This presentation is designed to explain a bit about each framework, and also tips/tricks and pitfalls they experienced when developing the site. They started working on the application in August of last year and deployed it into production in December.

Christian said they weren't going to go into the how for each framework, but Kris has had quite a few slides on SiteMesh so far. I don't blame him - it's a great tool and only a handful of folks (of about 50-60) have heard of it.

SiteMesh Pitfalls: Poor integration with Velocity and some other frameworks. BTW, if you're using Tapestry - Erik Hatcher recently created a JIRA patch with a Tapestry Decorator.

Now Kris is talking about WebWork and since he's a framework junkie, apparently this is going to be the largest part of the presentation. I think one of the nicest parts of WebWork is its auto-type conversion. The only other frameworks I've seen that have this is are JSF and Tapestry. For those that like WebWork and don't like JSF - you might find it disturbing that the WebWork actions (and their tests) in AppFuse are very similar to the JSF managed beans. I would take it as a compliment if I were a WebWork developer.

One nice thing about XWork's action configuration is you can specify a "method" parameter for a particular action. Struts recently added this with its MappingDispatchAction. I'm using this on my current project and it works quite well. Kris really likes WebWork's front-page controller pattern - where you use the <ww:action> tag to execute the action when the page is loaded. Personally, I don't have a problem with going through actions to get to my view templates. Kris finished up his WebWork piece with a plug for AppFuse (thanks!) and WebWork in Action. Congrats to all the authors - wonder if it'll be published before WebWork Live?

Now Christian is talking about Hibernate and its mapping files - and how you can generate your database schema from them - or generate your mapping files from a database. They used XDoclet to generate the mapping files in this particular project.

Hibernate Pitfalls: Think about lazy-loading early. Problems arise when you try to share Hibernate-managed objects across (Hibernate) sessions transparently. Christian mentions that Spring's OpenSessionInViewFilter is a nice way to solve the problem.

Hibernate Tips: Spring simplifies using Hibernate and makes declarative transactions easy. Read Hibernate in Action before starting development. Plan to spend some time learning how to express your data model with Hibernate relationships (one-to-one, one-to-many, many-to-many, etc.).

Christian is now talking about Spring and how it works. After thinking and writing about Spring so much in the last year, I'll just skip over regurgitating this part. ;-) His main recommendation: use real injection instead of appContext.getBean("beanName").

Other tools used: Lucene for searching and POI for indexing Word, Excel and PowerPoint files. Velocity used for templating e-mail messages.

Service-oriented Architecture (SOA) with Business Process Execution Language (BPEL)
Presented by Kevin Geminiuc and Owen Newnan from Policy Studies

This point of this presentation is to communicate what it's like to implement BPEL in a J2EE Container. BPEL is a layer on top of web services. BPEL is a programming language that you can use to program business processes. Allows you to divorce your business process from being human-centric to being document-centric. At Policy Studies, they're using iLog JRules rules engine and Oracle's BPEL implementation.

Benefits:

• Process Visiblity
• Process Agility
• Powerful Language
• Open
• Backed by "the Big Boys" (BEA, Microsoft, IBM)

History: Formerly knows as BPEL4WS, WSBPEL. Open standards based. Orchestrates web services with SOA.

Where we are today: Emerging technology (prepare to bang your head against the wall). .NET and Java products exist, as well as J2EE container integration.

BPEL & WS Standards: BPEL, XPath, WSDL, WS-Addressing, SOAP, XML-Schema, WSIF (Axis), TBD (WS-ReliableMessaging and JSRs 207/208). Note that since BPEL depends on web services (which is not a truly reliable service). Because of this, there are some proprietary extensions available.

At this point, I became bored with the presentation and quit taking notes. While the speakers had good intentions with their knowledge sharing, their delivery needed some work. The code walkthrough and demos were presented with a monotonous and unexcited tone, and a handful of folks left during this part. In summary, BPEL looks like a good way to orchestrate your various business processes. It allows you to call web services, EJBs and whatnot simply by defining their locations and methods in XML.

In his demo, Kevin used Oracle's BPEL Designer, which is an Eclipse plugin that has a nice drag-n-drop editor for managing your BPEL XML files. He also used Oracle's BPEL Process Manager, which seemed to be a lot like Jetspeed - you just drop in the .ear and then deploy your processes to it. The only bad part about the Process Manager is it's administration/deployment interface only runs in IE.

If you're using BPEL in your projects, I'd be interested to hear the tools you're using. As far as open-source BPEL process engines, they mentioned Twister and ActiveBPEL.

JTidy Filter

For those folks looking for pretty HTML when doing a "view-source", they might want to check out the JTidy Filter. I tried to integrate this into AppFuse, but no dice. It never prettied up the HTML - maybe it's a SiteMesh conflict or something, who knows. I doubt I'll add this to AppFuse. Mostly because no customer/project has ever asked for this and because I couldn't get it to work (failed the 10 minute test, but I actually spent an hour on it).

Short and sweet contracts

This has been a good month for Raible Designs. Not only did I manage to land a new gig, but I've also had a couple of 1-day contracts. The first one was an architectural review (at the beginning of the month), and yesterday I delivered a presentation on TDD and Spring for a client. These short-n-sweet gigs are a lot of fun. It's a good way to get out and meet members of the Java Community and see what tools they're developing with. The first client is using Struts, Spring and Hibernate. The second client wanted to use Struts, but after my talk, they're thinking about Spring MVC. They plan on using Spring to make EJBs easier, and they're using TopLink on the backend.

The only bad part about yesterday's experience is I developed a full-body ache as soon as I left the client's site. I managed to catch a cold from Abbie this weekend, and that turned into a cold+fever last night. I've had the fever ever since and didn't go into work today. It's really shitty timing for getting sick - we have a deadline on Thursday and we're heading to Oregon to see my parents this weekend. Last I checked, my fever was at 102°F. Hopefully, I'll wake up tomorrow and it'll be gone.

Integrating JSF and Tapestry into AppFuse

Well it looks like I accomplished my goal for the year: integrate Spring MVC, WebWork, Tapestry and JSF into AppFuse. I decided to integrate JSF and Tapestry at the same time so I could get a good feel for their differences. Also, I figured there would be a lot of similarities I could re-use between the two. I found this to be a great idea. Often I'd use the first framework as a template and the second would go much quicker. It turned out to be a good strategy because I often found bugs in the first while working on the second. I really enjoyed developing with both JSF and Tapestry - here's my notes from my development marathon over the last week:

Tapestry

• For Tapestry, I created a patched version of the 3.0 source. I did this because I wanted some non-standard things, like friendly URLs, a global properties file and a popup calendar that works with IE/XHTML. The Tapestry Community was gracious enough to supply the source - so I didn't have to do much patching myself.
• Pure HTML, like Tapestry has, is ssoooooo much nicer to work with. The syntax highlighting in HomeSite is fully functional again! I've been an HTML developer since 94 and I felt like it was 97 all over again - when we didn't write apps, just static HTML.
• Overriding the default Tapestry ValidationDelegate was pretty easy - and there's even an example in Tapestry in Action. I was able to add asterisks for required fields and error messages next to the fields fairly easily. Erik Hatcher also hooked me up with a Label component for non-validating fields.
• For the contrib:Table component, you can easily i18n column headings by using "keyName:propertyName" as the column value. However, if your keyName has a period in it (i.e. user.username), you can't override the ValueBlock b/c user.username is an invalid OGNL expression. I patched Tapestry to solve this.
• The ability to use <span key="keyName"/> to render i18n keys is awesome. So simple.
• Tapestry has a very rich validation framework that requires virtually no configuration. No setting up your resource bundle, etc. It just works. Client-side too.
• It would be nice to show all the client-side validation errors in a single dialog instead of one-at-a-time (WebWork does this too).

JSF/MyFaces

• I like how you don't have to create mappings - just link to the .jsp with an .html extension.
• For some reason, when I save a user and server-side validation occurs, the user's username and roles disappear. Good thing client-side validation is available.
• It was easy to override the Labels to add asterisks thanks to some code from David Geary on the MyFaces mailing list. In order to make it work, I had to ditch my HTML <table> and use an <h:panelGrid>. Now my JSP is Tag Soup. I think JSF is going to have to ditch JSP if they want to get anywhere. Hopefully JSF will soon support HTML templates like Tapestry and parse them with a Servlet Filter or something.
• It's unfortunate that I have to specify a "styleClass" attribute on all my <h:message> tags - I'd like to just set a default for these tags (others too).
• I ditched JSF's message setting and opted for setting my own List of messages in the session and then grabbing them out with a MessageFilter. This was so much easier to implement than the standard JSF message setting stuff.
• I'd rather not have to specify <f:loadBundle> at the top of each page. It's going to be the same for my whole app - it'd be nice to set a default bundle and variable name that all tags could access.
• It was quite a bit easier to integrate JSF into AppFuse than Tapestry. This was mainly due to the fact that I could re-use a lot of the JSP code, as well as the WebWork Actions are pretty close to the JSF Managed Beans.
• Spring Rocks - it never caused any issues with either framework. I just wish MyFaces wouldn't warn that it can't find a variable that it's already found. I had to turn logging down to FATAL so I don't get any meaningless messages from MyFaces.
• With JSF, why do I have to specify the supported locales in faces-config.xml? Why can't it look up the available bundles like JSTL with Spring/WebWork/Struts does?

So after all of this, which is my favorite? Unfortunately, there is no clear winner. They're both pretty cool, but not that much better than Struts, Spring or WebWork. In reality, I like them all, that's why they're all integrated into AppFuse!

Update: I forgot to mention that I was very pleased with the latest version of Canoo's WebTest. It now uses HtmlUnit at its core and its JavaScript support has vastly improved. I wouldn't have been able to do integration testing on the JSF version without this (updated) library. Not only did it work great, but it found XHTML issues in my code - that rocks! The JSF and Tapestry versions of AppFuse are the only ones that run Canoo tests with JavaScript turned on. This is mainly because the old tests worked fine w/o JavaScript and I didn't want to break them.

The AppFuse Generator

I found the AppFuse Generator project in my comments last night. Richard So seems to have created a nice code-generation tool for AppFuse. It looks like it can create/modify all the files you need to CRUD a database table. I took a brief look at the code and it's all based on Velocity templates, so you should be able to easily tweak things.

This tool does seem to generate the DAOs/Managers - which can lead to more code to maintain. It would be nice if it could be modified to be similar to AppGen where there's a "detailed" version (that generates everything) and a "default" version (which only generates the web tier classes). The default version could use the generic "dao" and "manager" beans. I wonder if this tool supports running/installing the same table more than once? This currently doesn't work too well with AppGen, but shouldn't be too hard to fix.

In reality, I'm pumped that Richard has created this, as well as a project to back it up. I especially like that he's going to try and create an Eclipse Plug-in as part of this project. Nice work Richard!

Can you base a web framework on another web framework?

It looks like the Struts guys are going to base Struts 2.0 on JSF (detailed proposal, wiki). It should be interesting to see a web framework developed on top of another web framework. Of course, it's been done before. The two things I really like in this proposal are 1) a built-in IoC container and 2) the security stuff (remember me, user registration). Here's the details from the proposal:

3.5 Service Provisioning APIs

Inversion of Control (IoC) containers (the techniques are also referred to as Dependency Injection) are becoming a popular mechanism for assembling the required services and logic of an application. If Struts included such a framework, it would provide a solid basis for building maintainable apps, as well as allowing the framework to configure itself using the same capabilities.

Rather than building such a container ourselves, we should seek to incorporate an existing one that is license-compatible and which can be integrated into the JSF managed beans facilities (so that value binding and method binding expressions can leverage the facilities of this container transparently). From my research so far, I like Spring's capabilities in this area the best, but am open to other suggestions.

3.6 Authentication and Authorization APIs

In order to support reasonably complete solutions for applications that wish to provide their own authentication and authorization services (as well as interact with container managed security), we need APIs available for performing user registration, implementing "remember me" features, and represent the results via a wrapped request (so that apps depending on getRemoteUser(), getUserPrincipal(), and isUserInRole() will still work). Using JDK 1.4 as a base platform would allow us to integrate mechanisms like JAAS. Other alternatives include plugins like SecurityFilter.

I added the emphsis on Spring. I'm all for this because 1) I'm on the JSF Expert Group (as of last week) and 2) it'd be nice to see JSF stretched, poked and prodded. IMO, JSF needs more "real-world" usage and the popularity of Struts will give it that. By "real-world" usage - I mean it needs to be used by developers that aren't cooped up in some cube with a fancy IDE. I also like the proposal because there's tons of Struts apps out there - and many of them might want to "upgrade". This means more (potential) work for me. Of course, I also plan on spending more time with Tapestry so I can offer client's an "educated" suggestion. BTW, the reason I joined the JSF EG is to be the "developer's voice" among the IDE Vendors. So if you'd like your voice to be heard - send me your suggestions, I'm all ears.

The question is - when will Shale be released? Of course, since it's open-source, the answer is "when it's ready". My guess is 1 year from today. I'm thinking of making AppFuse 2.0 use this new stuff. Of course, it'll have Tapestry and JSF options long before that.

If nothing else, the Shale proposal should motivate other web framework developers to highlight their roadmaps and what's new and cool on their horizons.

I don't hate JSF

I'm still amazed by all the traffic and comments received by my experience with JSF. In some cases it feels like I insulted some of these guys wives or something. Here's some good quotes from the comments:

The less than positive experience is because Matt wants to write an app while asking a million questions all over mailing lists and not investing the time to learn.

I think you're too in love with struts to have a clear sight on what's going on.

Pick your poison and stop bad-mouthing others because you don't get.

I admit that I was a bit harsh on JSF in my post. Here's why. I developed 5 simple apps this summer, all doing the same thing with different frameworks: Struts, Spring MVC, WebWork, Tapestry and JSF. All of them hooked into the same backend, which was Spring+Hibernate. I had a learning curve to overcome with WebWork, Tapestry and JSF. I already knew Struts and Spring MVC, so those versions where easy to develop with. Of the three (WebWork, Tapestry and JSF), I was able to complete the JSF version the fastest. It took me a 1 1/2 days for WebWork, 3 days for Tapestry and 1 day for JSF. Or so I thought.

The JSF app was pretty close to being finished, but I was missing one thing - a sortable/pageable table. And I hadn't written the test for my page classes yet. This was Wednesday. I made a post late that night on how much I liked the JSF-Spring integration library. If you'll notice in this post, I mentioned that I got the displaytag to work too (almost). I found that I had to use an empty tag to pull the list of users from my page bean into the request, and then the displaytag could render the list. This was almost perfect, but the <h:commandLink> didn't work, so I had no way of editing a record from the table.

At this point, it all started to break down - and my frustration began. I was sooo close to completing this application and so far (even with the minor snags I'd hit) it was the easiest one to develop. Juergen left a comment stating that Spring's core now had a DelegatingVariableResolver in its core. So I figured I'd make my application more "pure" and use that instead of the JSF-Spring integration library. This was my first mistake. The DelegatingVariableResolver from Spring didn't work with Sun's RI and only worked with MyFaces. I figured it wouldn't be hard to switch (JSF is a standard, right?) - so I went to it the next day. I'd also heard that MyFaces had a sortable/pageable dataGrid - so the switch seemed like a good idea.

The first bump in the road was that while the DelegateVariableResolver worked, MyFaces reported an error. The Spring guys blamed MyFaces and MyFaces blamed Spring. Result: it's a bug that no one will fix. I spent a couple hours being a good open-source citizen by 1) trying to fix it and 2) reporting it. The second bumb in the road was that I had to change a few things that worked in the RI but didn't work in MyFaces (I forget what now). However, this wasn't so bad since it also fixed a couple of issues.

Next I tried to use MyFace's <x:dataTable> to replace the display tag. Since it had a sortHeader component, I figured this would be easy. It turns out this component requires you to implement custom logic in your page bean. Things might've changed since July, but I doubt it. Lastly, aftering getting everything to work, I went to work on writing a jWebUnit test to test it all. While doing so, I found that it was almost impossible to test my edit screen. With other frameworks, I could specify a URL with a record id and then proceed to change form fields and push buttons. With JSF, there was no easy way to determine the URL. The rendered UI used heavy JavaScript and when you clicked on a link in the dataTable, this called a JavaScript function. I have no problems with JavaScript and I think it's a great technology. However, the current UI testing frameworks I use (jWebUnit and Canoo WebTest) use the Rhino JavaScript library (js.jar) and it sucks at JavaScript. It reports errors where there are no errors - and hence, I tend to exclude the JAR and disable JavaScript support in my tests. If there was better JavaScript support in these testing frameworks - I'd likely have to problems with JSF's "I post for every link" mantra.

In most of my development life, I've most often been a framework user rather than a developer. This means that if I find problems, I don't extend the framework - I look for other solutions. Call me whatever you like, but I'm just trying to get my job done and the project completed. I don't want to mess with the internals of a framework to make that happen. With JSF (and Tapestry too), you have to be more of a framework developer. You have to be willing to create your own components. These frameworks are designed as component frameworks and they want you to extend them. That's one of the major points of their architecture.

So here I am again, posting about JSF - which will undoubtably get an incredible amount of hits just because it has "JSF" in the title. Why? Because you can't ignore JSF. Even if you don't want to develop with it - there's going to be tons of jobs that require JSF in the near future. In fact, there are already quite a few. Surprisingly enough, in my job search last month, I has a more opportunities for JSF (and WebWork suprisingly enough) than Struts. Finding a Tapestry gig - good luck. Of course, I'm a consultant, not an employee - so I don't often don't get to choose frameworks for companies.

I think JSF is an immature technology that will rapidly mature. I hope it does b/c it was fairly easy to develop with - there were merely some minor bugs in the two implementations. These can be fixed. In reality, I think we should all quit bashing on JSF and jump in to try and make it better. Rather than complaining, let's try to help.

I've done my part and applied to be on the JSF Expert Group. They probably won't let me in though - everyone seems to link I hate JSF. If I had my way, I'd scrap the sucker and make Tapestry the JSF standard.

There's a new sorting and paging taglib in town

From the Apache News Blog, I found there's a new sorting and paging taglib in town. We already have the Display Tag and the Value List Handler, but now we have the Data Grid. It looks pretty good too - although it doesn't seem to support/enforce XHTML. For your viewing pleasure, I've setup a demo. To be fair, you can also checkout the Value List Handler Demo and the Display Tag Demo.

[DJUG] JMX and JDO 2.0

Last night I attended the local Denver JUG meeting. Chris Huston gave a presentation on JMX and Dion gave a presentation on JDO 2.0. Below are my notes from the event.
-----------------------------

Java Management Extensions one of the first JSRs and now included in to JDK 5. Monitors health of the system. Alter sys-admin of error conditions. Provides capability of to view and modify runtime parameters.

MBeans are deployed in an MBeanServer and their capabilities are exposed through Connectors. Then tools talk to these connectors to get their information.

JMX is covered by two separate specifications: JSR-3 (MBeans) and JSR-160 (Connectors). BTW, Chris has some good slide-making capabilities - I'll have to get some tips from him for my next preso. For example, he shows an entire class and its methods, then he fades it and zooms in on certain methods and highlights them to explain what they do.

Four types of MBeans: Standard MBeans, Dynamic MBeans, Model MBeans and Open MBeans. More info on these Mbeans can be found at http://docs.sun.com.

Standard MBean: All you need to do create an interface for your class your class name with "MBean" appended to it.

In order to deploy, you need to create and configure an MBeanServer. You can create an MBeanServer using javax.management.MBeanServerFactory.createMBeanServer(). MBeanServers keep track of MBeans using a javax.management.ObjectName. After creating and configuring an MBeanServer, you simply need to register your MBean using an Agent. All pretty simple so far, right? Now you have to use a Connector to expose your MBean to the outside world.

"Connectors are the fly in the ointment." MX4J is an open source project that has good Connectors: i.e. RMIAdaptor and HTTPAdaptor. There's also SNMP Adapters from a number of commercial vendors. In order to solve the current lack of good Connectors we have JSR-160: Distributed Services Specification. This JSR defines one connector: JMXConnector (part of JDK 5).

Chris is now showing us a counter widget deployed as a Swing app and managed using MX4J's web interfaces. Very cool stuff - the ability manipulate runtime parameters. As Chris stated - the real power of JMX will come from the tools. I wonder if there's MBeans available for monitoring webapps - seems like there'd be quite a market for management beans you could just drop in and deploy.

Notifications are another feature of MBeans and can be sent by an MBean. Two important interfaces: NotificationEmitter and NotificationListener.

Chris gave a good introduction to JMX, but I don't see myself using it anytime soon. It seems to be something that framework and container developers might use, but not many application developers. Maybe I'm wrong - are you deploying MBeans as part of your web applications? Chris mentioned that Hibernate and Spring have MBeans as part of their distribution - anyone using these? If nothing else, it's great to know that JMX is available if I ever do need to monitor and control applications.

-----------------------------
Now Dion's up after a 1/2 hour break with announcements. Dion is talking about JDO 2.0. I think JDO would be a lot more popular if it wasn't for Hibernate. Hibernate seems to have done JDO better and faster.

What is JDO?

• Allows for object persistence
• "I have objects, some need to be persisted"
• "Keep state and behavior together. That is the OO way."

JDO Main Objectives:

• To enable pluggable implemenentations of data stores into application servers
• To provide applicaiton programmers a Java-centric view of persistent information, including enterprise data and locally stored data.

Other Objectives:

• Transparent Persistence
• Persistence-by-Reachability
• OO framework on top of potentially non-OO stores.
  • RDBMS (98% of the time)
  • Files
  • TP Monitors
  • Legacy
  • Properietary
• Integrate with existing technologies
• Java compatible - no need to learn new language
• Usable in managed and non-managed environments
• Define easy semantics for caching objects
• Ability to run in all Java platforms (J2SE, J2EE, J2ME)

When JDO first started, a bad thing happened - the object database guys were heavily involved. JDO 1.0 had 80% of its Expert Group from object database vendors. JDO 2.0 got object guys off the committee and real-world (relational) folks onto it.

JDO 1.0: Most of it is not very new - just a standard way of implementing persistence. Other proprietary tools already accomplish most of what JDO is.

JDO 2.0 Strategic Goals:

• Easy to Use
  • natural programming model
  • configuration and deployment
• In a Wide Variety of Environments
  • J2SE (rich clients)
  • application, web servers

JDO 2 Status: First Early Draft Review is out there. Soon there's going to be a Community Review - then things will start rolling after that.

JDO 2.0 Goals:

• Maintain JDO 1.0 Compatibility (big thing with Sun)
• Standardize Mapping to Relational DB (was vendor extension in 1.0)
• Multi-tier Development Improvements
• Usability Improvement
• Better Object Modelling
• Richer Queries - JDOQL, SQL and Named Queries
• More Vendor Support - try to get Hibernate and Oracle on the bandwagon for political reasons

Dion's take on politics between EJB 3 and JDO 2

• Let's get a standard around transpanent persistence first
• Let's have a standard that can be shared between various groups: J2EE, J2SE, J2ME
• Why have more than one O/R mapping specification?
• Specifications such as EJB could be an umbrella spec for the cross cutting concerns

Why are people even arguing about it? Money. Because companies have invested a lot of time and money into X technology and therefore they bash the other. This problem might be solved by an O/R Mapping JSR that both EJB and JDO have to adhere to.

JDBC vs. JDO

JDO will use all J2EE services inside a container.

Deployment time scalability - database becomes bottleneck as number of users increases. JDO middle tier can relieve this load on the databse. JDO's configuration can be altered at deploy time to handle better scalability through caching.

JDO 2.0 Multi-tier Development - big thing is disconnected objects through attach/detach. Very simple API for detaching and re-attaching objects. Internally there's a version that's used to determine if the object is the same one.

JDO and EJB
As opposed to Entity bean, JDO instances...

• May have subclasses
• May exist outside a container
• Has 1 optional interface to implement
• Accessible as transient objects

And as of JDO 2 (new and improved object modeling!)

• Persistent Abstract Class Support
  • map abstract classes to tables
  • map properties, fields to columns
  • create new implementation instances
• Persistence Interface Support
  • map interfaces to tables
  • map properties to columns
  • more, but I missed them

Some argue that JDO is what Entity Beans should have been!

• JDO is "purer" way to use OO
• Since Entities should be used via local interfaces, why not just do Session Facade -> JDO objects
• CMP in Sun AppServer uses JDO

Some argue that JDO complements Entity Beans because Entity beans can use JDO.

EJB3 is totally moving directorys with regards to Entity Beans, and they are much more like JDO.

EJB3 EntityManager == JDO PersistenceManager == Hibernate Session

JDO and Connector Architecture - JDO is NOT a framework, but plays well with others!

The JDO architecture uses the J2EE Connector architecture for application servers. The JDO PersistenceManager is a caching manager as defined by the J2EE Connector architecture.

A PersistenceManager may define the following Connector components:

• ResourceAdapter
• ConnectionManager
• ManagedConnectionFactory
• ManagedConnection
• LocalTransaction

Persistence Contract (behind the scenes)
- To achieve transparence, JDO:

• Defines a PersistenceCapable interface
• Used too mandate binary compatibility among all vendors (optional in JDO 2)
• Uses tools to make a class persistence capable

- Declares any fields available for persistence storeage

- Defines methods that allow JDO instance management

• jdoIsDirty()
• jdoIsDeleted()
• jdoMakeDirty()

JDO has a number of callbacks that you can implement: jdoPostLoad(), jdoPreStore(), jdoPreClear(), jdoPreDelete().

In JDO 1: one interface: InstanceCallbacks
In JDO 2: InstanceCallbacks purely extend interfaces: LoadCallback, StoreCallback, etc.

Ways to make classes persistence capable: byte code enhancement, annotations (maybe for JDO 2.1).

JDO Interfaces: PersistenceManagerFactory, PersistenceManager, Transaction (new set/getRollbackOnly() in JDO 2) and JDOHelper (class with static methods, for use by persistence-aware classes), Query, Extent. You'll probably never use an Extent; like "select * from table". Represents all instances of a class or subclasses.

A persistence cabable class is just a POJO - you could use the same class for JDO and/or Hibernate. A default contructor is required in JDO 1, but not in 2.

JDO 2.0 has "use cases" for lazy-loading. This enables you to configure fetching based on certain situations. Sounds pretty cool.

Extent is usually optimized for better performance. If you're selecting all records from a table, you're probably better of using Extent vs. Query in order to avoid OutOfMemory errors.

New in JDO 2: ability to specify query filters in other languages - i.e. SQL or HQL or user-defined. These languages are up to the JDO vendor to implement.
JDO can use stored procedures if you map it in your metadata.

JDO 2.0's Query API looks very rich. It allows you to limit your results to certain properties/columns, as well as set what type of to return.

JDO 2.0 supports obtaining a java.sql.Connection from PersistenceManager. However, this may reduce portability since not all SQL is portable b/w databases.

Overall, I thought this was a great talk by Dion. If you're looking to start working with JDO 2.0, I'd recommend JPOX (also see JPOX with Spring or Tapestry). Unfortunately, their implementation still requires you to "enhance" your classes at build-time, but hopefully they'll have a transparent mechanism for manipulation (i.e. cglib) soon.

One thing's for sure

The Java Community certainly does care about JSF. Regardless of whether folks like it or hate it - there's definitely a lot of opinions! Who woulda thunk a simple blog entry would get so much traffic? Wierd.

You know it's a late night when Erik posts before you go to bed...