|
|
|
 |
<< Monday, May 12, 2003 >> |
|
Appropriate use of J2EE/EJB
An oft-heard complaint, echoed recently by Annrai O'Toole, is that J2EE app servers are oversold:
The J2EE vendors have done a fantastic job of convincing the world
that you can't run a line of Java unless it runs inside a J2EE
container. This is just pure bunkum.
I like his formulation that "J2EE is the Java equivalent of a mainframe." We also have, of course, in COM+, the Windows version of the same idea, which in its earlier MTS incarnation predated J2EE. I also notice that the real mainframes haven't gone away. With respect to the middleware services for which the J2EE server is best known -- "TP-heavy" transaction management, connection and object pooling, role-based security, and declarative control of these aspects -- the question of when and why this stuff is or isn't overkill seems never to go away.
Here are some of the arguments and counter-arguments I hear:
| You need a J2EE container / EJB architecture because... |
But... |
|
Your app has to scale.
|
Other clustering and load-balancing solutions are available -- for Java, for Windows (with and without COM+), and for LAMP.
|
|
Your app is heavily transactional.
|
TP-Heavy solutions like CICS, Tuxedo, and TopEnd haven't gone away. TP-Lite is arguably getting more interesting, as well, now that the database engines can cluster, and produce/consume Web services.
|
|
You need object-relational persistence.
|
And there are other ways to get it. E.g.: Castor, servlets with JDO (Java Data Objects), Apple's Enterprise Object Framework.
|
|
You need a low-impact way to evolve business logic.
|
J2EE's complexity bites you. It's easy to change what's inside a chunk of business logic, but it's hard to refactor in-the-large.
|
|
You need your business logic available to multiple applications.
|
What if those other applications aren't Java-based?
|
|
You want to standardize on one environment and one language.
|
Even the most dyed-in-the-wool J2EE developer is likely to touch (at least) SQL, JSP, XSLT, and a scripting language for automation.
|
For an upcoming article, I'd like to explore these and related themes with people on all sides of this complex, many-sided discussion. In an earlier posting, I characterized one axis of the debate as robustness versus agility, and wondered how we can have our cake and eat it too. Sam Ruby pointed to WS-Transaction, to which Patrick Logan replied "I think we need a rethinking of databases, messages, and coordination." I'm sure that's true. Meanwhile, what to do?
I'm going to contact some people privately, but it seems useful to invite feedback here as well, hence this comment link.
|
|
Interfaces and habits
It seems kind of unfair, doesn't it? First, developers have to understand and accommodate users' habits. Then we have to deliver solutions that add value while surreptitiously encouraging users to adopt better habits. Finally, we have to bring to the surface, examine, and modify our own deeply-ingrained habits. That's a painful and psychologically hard thing to do. But happy users are not the only reward. The habit of breaking habits will serve you well. [Full story at InfoWorld.com]
|
|
Bayesian vs. latent semantic analysis
By way of Michael Alderete's blog, I found this fascinating item by Tim Oren, a venture capitalist whose eight-year stint at Apple included advanced research on the use of latent semantic analysis for document categorization. Although he can't say for sure, Oren strongly suspects that although OS X Mail is widely thought to use Bayesian techniques, it in fact uses latent semantic analysis:
So what's Apple doing with latent semantics to catch spam? Not sure. The simplest approach is to use a related factor analysis technique to find the best fit to predicting spam/not-spam in a training sample; it's not a full PCA but I suppose you could call it latent semantics. It would be more interesting if they are using the full deal, maybe computing separate models for spam/not. Because, you see, latent semantics naturally lends itself to automatic sorting and organization of the document space over which the model was computed. And afew years back, the Apple group that I and then Dan Rose managed did an automatic e-mail organization project rather unfelicitously called piles, that included a user interface for just such a thing. (IP alert: Some of it was patented.) Hmmm.... [Due Diligence]
I wonder if Apple will clarify? Meanwhile, I just picked up a weekend's worth of mail. Here's the score:
rightly sent to Spam folder: 237
wrongly sent to Spam folder: 0
rightly left in original folders: 14
In other words, a perfect performance. How long can this last? One of the good messages, from an old acquaintance, pointed out that the SpamBayes glow will inevitably fade as spammers regroup to attack it. I'm sure that's true. In the long run a multi-pronged approach seems best. Server-based gateways to keep the worst of the junk off your network, digital identity, filtering, blacklisting, whitelisting, digital postage -- all of these strategies will play important roles.
To reiterate, though, there's more going on here than spam prevention. Bringing advanced computational methods for document categorization to the desktop will create a host of new opportunities. Our personal data stores are about to become the laboratory for some really fascinating experimentation.
|
|
|
Recent Entries
|
|
NEWS 
