Forum OpenACS Q&A: Response to A Technical Paper on Java

I have a feeling your friends worked for a big eBusiness consultant. I
did, too, so I recognize big consulting language when I hear it. I've
also seen the way this stuff *actually* works, and it isn't pretty.

Let's try to clear up some of the marketing hype. What's an
application server? Something that connects back-end data sources,
provides a framework for business logic, and various APIs for session
management, interaction with external systems, an extensible
framework, etc... AOLserver is one darn good application server. Now,
maybe
what you're saying is that we should have a 3-tiered system, with
a web server, an application server, and a database server. Okay, we
have a 3-tiered system from a logical standpoint. Database for data.
Logic in Tcl procs and page flows. And templates/presentation in ADP.

You want me to first pick an application server, then pick a language?
That doesn't work. Every application server is inherently tied to one
(or more) programming language. That's because the neat APIs you need
to use have to be implemented in that language. If I pick WebLogic, I
am stuck with Java. If I pick Zend, I am stuck with PHP. If I pick
AOLserver, I am stuck with Tcl (at least as the primordial glue). The
only people who will possibly overcome this soon are Microsoft with
the Common Language Runtime.

Also, are you performing sorting operations in the application server?
I prefer to use the database's highly optimized indexes and an "order
by" request. Oh yes, sounds far too simple for the "big applications
that happen to use the web." But that's the thing, these applications
*are* simple. We're not writing an operating system here. We're
writing simple components of software that need not be nearly as
complicated as the n-tiered, overly macho EJB world. Sure, the
cocktail party discussion is much more entertaining if you have 18
clustered application server boxes and a reboot engineer, but it's not
necessarily the best technical approach.

As for the pitch on all the wonderful features of the EJB world, show
me one site that uses them nicely and that was developed within a
reasonable budget and timeframe. I've seen this architecture at work
with the leading EJB vendor at one of the biggest banks in the US. The
marketing is very pretty. In practice, though, it is the flakiest,
least reliable, most overly-complicated architecture I've ever seen.
It took almost a year to get things working smoothly at this one
client, and they were paying 6-7 digits for support/licensing to the
big vendors.

How would I connect AOLserver to a DB not knowing SQL? How about
abstraction? In fact, OpenACS 4 allows you to put the queries in a
separate location. Thus, you can have a SQL guru come in and write
queries that fit a certain contract that your Tcl code requests.
That's better than OO abstraction around entire entities, because of
the OO/relational dilemma I mentioned in the paper.

As for this supposed independence from the table structure, I
challenge you to prove this to me. The moment you layer OO on top of a
relational model, you're forced to either perform 20 SQL queries where
one join would suffice, or to create OO structures that inherently
break your neat abstractions by joining entities in single queries.

Finally, the Java platform does not magically enable the clustering
that you mention. You can implement that in AOLserver/Tcl if you want.
Have you built one of these clustered systems? If so, I'm very
impressed and would love to read more about your experience. The
potential complications are enormous, however (session failover...),
and I haven't seen them truly solved in any system yet.

Everything you've mentioned so far is mostly Sun marketing. I have yet
to see a real system that was able to make use both of this magic
clustering/scalability aspect and the supposed componentization of
Java. Just because Java has OO capabilities doesn't mean the code is
automatically reusable as nice components. In fact, to get around the
limitations of OO/relational issues, I claim that the resulting Java
code is almost *less* reusable.

The only place where OO/Java makes sense is for specific, less-DB
related issues. A crypto library, for example. That would be a good
reason to use a Java library (although implementing an ns_ module on
top of OpenSSL or BSAFE seems way better).

I had mentioned to Malte offline that I didn't want to get into a
philosophical debate about Java in general. Unfortunately, that's what
this has turned into :( This discussion could get much longer much
more quickly. However, I feel it is important to respond to these
points which are very theoretical and very reasonable-sounding, but
which are contradicted by every practical situation I've faced.