Next session: Java Desktop Network Components. I'm trying to attend sessions that I don't know much about. J2EE ones are likely to bore me. I just noticed that Amy Fowler is one of the presenters - and I've heard she's hot - so I'm sitting up close (5th row).
JDNC is designed to provide shortcults for building common archetypal applications. Better clients with less effort. Less (maybe no) coding. Gentle learning curve and incremental development model. Assumes network or web data source. Geared towards Java application and XML developers. Sun is going to do a lot of work to get Tools vendors to include JDNC. It seems similar to AppFuse, but I'm guessing it's more of an API than a project template. Their goals seem to be the same - get something to show your manager in a matter of hours, not weeks.
Swing Extensions API: targeted for Swing developers, extended components with more features, networked data connectivity and data-binding. I wonder how JDNC compares to Spring's RCP project? Amy mentions JGoodies and how they'd like to include it as part of JDNC.
JXTable: Asynchronous data loading. Sorting, filtering and highlighting.
JTreeTable: Hiearchical-columnar view (outline)
JForm: Data-binding and Validation (as you type). Sounds a lot like what Keith is working on for Spring.
Damn - missed one...
JDNC API: Very high-level components. Built on the foundations of SpringSwing/JFCX. Solution focused and conforms to the JavaBeans Architecture Spec - BeanInfos provided for tool friendliness. Encapsulates complex operations (threading, network connectivity, data modeling). Provides usability features.
Components: JNTable, JNTree, JNTreeTable, JNForm, JNEditor. These components wrap, rather than extend lower level component. Expose simpler API and provide more defaults (i.e. scrolling).
Now we're looking at the Bug Editor Demo (WebStart). The features they're showing are similar to what folks want in the display tag - sorting, filtering, column visibility. It's very cool to see that this is now a built-in feature of Swing. I wonder how hard it is to use JDNC and JGoodies in project? Is it just a matter of adding a couple of JARs to your classpath? It'd be cool to add J2ME and Swing clients to AppFuse. I think the hardest part would be emulating the current (container-managed) security model that exists in the webapp clients.
Sorry, zoned out on e-mail for a while there.
Amy is now showing code and how to create a form for the detail view. It's interesting that the data-binding, including exceptions, is similar to Spring.
JDNC Markup Language: Looks very cool. You can actually develop a Swing app with XML!
Important thing to remember: JDNC simplifies rich client development on all levels. Overall I think JDNC is a very cool open-source project - it's nice to see Sun trying to make developer's lives easier. For more information on developing Swing apps, checkout javadesktop.org.
I'm sitting in a session on clustering. I'm interested in this topic because I'm going to try and setup Tomcat clustering for Roller. Furthermore, I'm going to try and do it between my current ISP and Groove Systems. Rather than just hopping ISPs, I figured it would be easier to setup a highly available system. I was talking to Dave last night about setting up clustering on JRoller.com. The main problem there is handling file uploads. A lot of folks have uploaded files, and if you setup a cluster, you'll either have to do it on the same machine or mount the first machine's "resources" directory onto the second machine. Regardless, I doubt it would be that difficult.
A typical cluster architecture has a firewall, followed by load balancers that proxy to a webserver farm. Then there's another firewall that talks to J2EE app servers that talk to a highly available database.
Gotcha #1 Apps don't have to be cluster-aware do they?
In a perfect world, this can be true. Programming model issues: serializability and handling failures. HTTP Session and EJB Stateful Session bean state. Tip: Serialize only when needed. Here's a personal tip - add <distributable> to your web.xml file. In most cases, you're appserver will tell you when objects in the session are not serializable. It's a simple way to test if your application is ready for clustering.
Gotcha #2 Idempotence
I missed the definition but it seems to be the ability to do something again and again and get the same results. Here's the real definition of idempotent. Basically, can your application handling retrying something?
Gotcha #3 Using the session or SSB's state as a database
The session is designed to handle conversational state, not information that might need transactional attributes. Stuffing a large volume of data in the session is just a memory issue on a single server - but it becomes a performance issue in a cluster.
Gotcha #4 Upgrades/Patches without impacting availability
Tip: Rolling upgrades and Quiescence. What is quiescence? It's the ability to prevent new users from coming into your app while upgrading, while continuing to service existing users. Quiescence in clustering refers to the ability to bring down servers, upgrade them, and re-introduce them to the cluster.
This talked switched speakers about 10 minutes ago. The new guy is talking about how vendors might implement clustering solutions. In other words, it's boring and doesn't interest me. I care about what I need to do to deploy to clustered servers.
Now we have another speaker - to talk about performance. Performance is always addressed at the end isn't it? Even in the real world. It was funny talking to Dave last night about JRoller. He said that Matt and Rick setup Roller on a test box and hammered it while there were trying to figure out issues. The hit it more often then the production JRoller instance gets. Unfortunately, there were unable to reproduce any issues. The main things that Dave did to fix the latest release was to remove OSCache and to remove Roller's Query API. Now it uses Hibernate directly (I'm guessing that Castor is no longer a persistence option).
That's it - session is over. Now onto learn more about JNDC.