ERIC BRUNO'S BLOG

Java: The Daily Grind.

December 2006

Is there a fine line between a good Ajax application and one that demands too rich an interface for scripting?

I've been tracking the Ajax phenomenon, and I’ve been wondering, just what are the practical limits of it? For instance, although you can build clever, dynamic, and useful, web applications with Ajax technologies, can you reach a point where it just gets in the way? If you try to add too many bells and whistles to your browser-based application, will it eventually fail from over-complicated code; browser/OS incompatibility; performance/stability issues; and so on?

I don't have the answer to this question because I haven't developed any really large Ajax applications. I've built many relatively small ones, for which it was a perfect fit. But the one thing that keeps getting in the way is that it gets complicated very quickly. JavaScript is tricky to debug, even with the plethora of tools that are currently available.

After reading a blog on the subject at java.net, I see that others feel the same way. It's easy, practical, and correct, to build a relatively small web application with Ajax. However, as the application grows and gets richer (a common problem for successful software), at what point do you wish you could switch to something that's more suited to the task, such as AWT/Swing, or the SWT from Eclipse?

All too often, the point at which it becomes obvious that you need to make that switch, you're already past the point where it's practical to abandon all of your Ajax code. The answer may be convergence: such as Ajax and Swing combined. This is a similar idea as seen with Java SE 6, where Java can be combined with script-based and dynamic languages such as JavaScript, PHP, Perl, and Ruby. No need to make a choice, or go in one direction instead of another, simply use the tools at the time that you feel make sense. As your requirements change over time, augment those tools with others more suitable without wasting your previous effort.

This theory, by the way, applies to more than the just the Ajax vs. thick client issue; it can be applied to other programming decisions we're forced to make. For example, wouldn't it be nice to avoid the whole NetBeans vs. Eclipse decision? But I digress.

I hope we'll see more convergence in technologies, as we've seen with Java and dynamic languages. After all, integration between disparate applications and various data sources is the goal of an even-increasing number of development projects. Shouldn't it also be the goal for developer tools and technologies? If integration and convergence is good enough for our customers, it's good enough for us developers.

Happy coding!
-EJB

Posted by Eric Bruno at 09:22 AM  Permalink |

The first release of Java that was implemented and tested with the full support of the Java community has been released. You should download it today.

The first release of Java that was implemented and tested with the full support of the Java community has been released. Java SE 6 was the first version of Java that was available to the community in source and binary forms with each weekly build. Here are some interesting community and quality-related metrics for this release:

-Over 160 companies help test and verify compatibility and performance of their enterprise applications.
-Over 330 individuals contributed source for enhancements and bug fixes.
-Over 750 bugs were reported by the community.
-Over 300 bug fixes were contributed by the community.

Java SE is the base for enterprise applications built on Java EE, desktop Java applications, and browser-embedded applets. This makes each development and release cycle of Java SE crucial to Java's continued success in the market. Java SE 6 continues Java's history of success, and sets new milestones in terms of community involvement. With the inclusion of performance enhancements and new features such as easier web service construction, and support for dynamic languages, there is no reason why developers should wait before adopting Java SE 6 as their premier development environment. Download it today and start changing the world, one line of code at a time.

For the full story, read my latest DDJ article (http://www.ddj.com/dept/java/196602955).

-EJB

Posted by Eric Bruno at 05:40 PM  Permalink |

I read a press release from Kofax who, through SOA, brings desktop functions to the server.

The novel approach that Kofax has taken to document capture (scanning and imaging) first attracted my attention in a TestDrive advertorial in last month’s Dr. Dobbs. With the introduction of a small device, and a comprehensive set of web service APIs, Kofax has taken what was once a desktop-only function and made it available in a web application.

This is what SOA is truly about; taking isolated functions and computing resources and making them scale upwards. Scanning was once performed via a heavy-client TWAIN application. But thanks to Kofax and SOA, it’s now web-enabled, and it can be integrated with the rest of an organization’s enterprise applications via a standard: SOAP.

Some people get it, and some don’t. SOA is not about Microsoft vs. Sun; or C++ vs. Java. You can build your service provider or service consumer in COBOL and it won’t matter. Simply adhere to the foundations of SOA (which implies XML over a web protocol such as HTTP), and you achieve a level of abstraction that enables you to integrate disparate applications and data types to form new solutions.

Yes, Kofax built a great deal of their interface in Java, but that’s not what’s important here. I’m impressed with what Kofax has done because it’s a shining example of a problem solved with a true service-oriented architecture. It’s not technology for technology’s sake; but a real solution that was not easily achievable without SOA: enterprise integration of what was once a once desktop-only function. Document scanning can now be web-enabled, and be made transaction-aware (through ESB integration, for example) via the straightforward web service interface that Kofax has built to their product suite. That’s sweet.

-EJB

Posted by Eric Bruno at 09:29 AM  Permalink |