John Reynolds's Blog

October 2005 Archives

AJAXOffice, the next big thing

I'm kidding. Really.

Jonathan makes good points in his recent blog about OpenOffice and AJAX:

"The language in which a product is written has nothing to do with the value it conveys."

I like browser-based tools.

My primary email is now Google's Gmail. Other mail clients have more features, but with Gmail all my information is as close as the nearest public "kiosk" browser or WiFi hotspot... Gmail even works on the browser on my Dell Axim PocketPC.

Despite the availability of much better tools, my primary blog editor is browser-based. Java.net's Moveable Type is, to put it politely, somewhat minimalistic, but it serves my needs, and (once again) it's as close as the nearest (full screen) browser (doesn't work too well on the default PocketPC browser).

When GCalendar comes out, I will use it. GCalc and GBase might be quite nice too. Once again, it's about having the functionality as close as the nearest browser... perhaps degraded due to the limitations of the browser, but available.

I'm probably naive, but I also think of services provided by others as "safer" than those that are hosted on my own machine. Sure, somebody may hack Gmail and get access to my correspondence, but I think the likelihood is about the same as that of someone hacking into my home machine and doing the same thing. I hate to admit it, but if Gmail gets hacked, I am more likely to know than if someone hacks my home machine.

So does this mean I want an AJAX presentation layer for OpenOffice? I guess the answer is a definite "that would be nice, but it's only part of the solution".

What I want is a significant chunk of the OpenOffice functionality available from a trusted service provider, and delivered through a browser-based interface (that does not require me to install plugins).

Plugins to enhance the user-experience would be great, but I want to be able to use these tools from public kiosks (where they frown on users installing additional plugins).

Jonathan's comments about "giving services an opportunity to project multiple user experiences" is dead on target. Just don't discount the "public kiosk" browser as one of those experiences.

Beyond Java, but not beyond the JVM

I've yet to read Bruce Tate's new book, Beyond Java, but I think that I already get the point from reading articles that have accompanied the release.

Java and web development grew up together, but Java has never really been tailored for web development. It's a general purpose language that is good for many things, but not particularly great for generating browser-based applications.

This puts Java at a distinct disadvantage in terms of ease-of-use when compared to web-UI-only languages such as PHP. Not really a big surprise.

The big surprise is that nobody (that I know of) has built a web-domain-specific language on top of the JVM. Perhaps JSP was a step in that direction, but when you compare it with Ruby on Rails it's just not in the same league.

Java's web-based-ui impedance mismatch is mirrored on the desktop front. Hans Muller shared with us the good news that Swing is now the Dominant GUI Toolkit, but the blog also pointed out that WinForms was the previous king-of-the-hill.

WinForms is a domain-specific toolkit for building form-based applications. Form-based applications aren't sexy or exciting, but they are what most businesses need, so it's no surprise that a form-base toolkit was the reigning number one.

Java may lose its dominance as our day-to-day language of choice, domain-specific development environment/tools are a natural progression, and something that we should embrace. What we shouldn't embrace is the demise of the JVM. The JVM can support any number of languages, as Javascript (Rhino), Jython, and Groovy demonstrate. There is no need to throw this baby out with the bath water.

How Beans side-tracked Enterprise Java

My enthusiasm for Java took a distinct nose dive the first time I encountered the implementation details for the dreaded Enterprise Java Bean. It was quite a shock, and I did everything that I could to avoid using them. Now that EJB3 has significantly lessened the learning curve, many of my initial complaints have been addressed, but there's still something not-quite-right.

Beans?

Java Bean was a cute pun. What better name for a nice little package of Java functionality; but when you look at the Sun's definition for Java Bean, it becomes pretty clear that the original analogy didn't anticipate Enterprise Java.

From Greg Voss's Java Bean tutorial:

"A Java Bean is a reusable software component that can be visually manipulated in builder tools."

If the word "Service" had been used instead of the word "Bean", J2EE would have made more sense.

Think about it; the original EJBs only had Remote Interfaces. In the original EJB model, Entity Beans only appeared as an afterthought. When you use the word "Bean" this makes no sense. When you use the word "Service" it makes perfect sense.

The result of this poor word choice may have been five years of arguing about POJOs and misusing EJBs (both Entity and Session).

EJB3 goes a long way towards erasing the differences between EJBs and POJOs, and that is definitely a good thing in terms of simplifying our programming model, but are we still impeding ourselves with our own terminology?

Most EJBs, POJO based or not, are not really Enterprise in scope. Most EJBs are tightly coupled to specific applications and live within the same JVM. The term is still causing confusion.

The term "Enterprise" is a natural companion for the term "Remote". If something is useful across the Enterprise, then it probably has a remote interface. Think Jini. Think Web Services. Those are the real Enterprise aspects of Java

SOA: Real Meat, and Potatoes too

The answer probably requires a change of perspective. Jame's falls into the same trap that I fell in... SOA isn't really about a programming paradigm, it's about a product paradigm.

Let me rush to explain....

To programmers SOA looks a lot like OOP (especially a lot like OOP as promoted by the SmallTalk language). Clearly defined interfaces, message oriented invocation, etc. What's the difference?

To product managers SOA looks only vaguely like OOP. SOA is about composing solutions from mostly pre-existing business services (Pay attention to the business services part).

SOA is about Meat and Potatoes programming (programming to pay the bills). It's not really sexy, and it's not really about anything new.

Most companies already have a lot of legacy assets. They are not very interested in developing a wonderful new object hierarchy. They are very interested in squeezing every last bit of value out of a system that they've already paid for. To a product manager, SOA is the lure that a magic "connector" between a legacy asset and a new-fangled ESB (Enterprise Service Bus) will let the company squeeze five more years out of that old COBOL application.

It's the connectors that make the immediate business case for SOA.

Nobody (well, almost nobody) is creating SOA solutions from scratch. Instead, we're figuring our how to duct tape a snazzy JBI connector onto our 20th century legacy code.

I can't blame you if you're still confused. The sometimes mundane reality isn't much like the hype.

Not wishing to end on a down note, I've got to say that once the messy SOA-enabling slogging of today is behind us, SOA should actually be fun to work with. I just hope that I live that long ;-)

Continue Reading...

This work is licensed under a Creative Commons License.