Fallacy 5: JMS, JCA, JTA, JNDI, XA are too complex, too heavy and aren't needed at all.
Sometimes it is a real fun to see some ideas, improvement and
"simplifications" which are suggested as an alternative to the standard
Java EE 5 APIs. Many developers still believe that a lean
inversion of control container could replace all this technologies. But
in most cases it is not the question of replacement, but only of
extension. In most cases is the usage of the enterprise APIs much
simpler, than wheel reinvention - it is even often impossible to
provide a working alternative.
JMS: the JMS-API is not
complex, but you need some lines of code to write, until you are able
to access a destination. This redundant code can be of course easily
encapsulated. Frameworks like Spring already provide some
simplification (JMS-templates). In Java EE 5 the JMS resources can be
easily injected - so error-prone lookups are no more necessary. But
this is only "syntactic" sugar. The real value of JMS are: persistent
queues, durable topics, transactional behavior, pub/sub capability and
rich monitoring. Things like "once and only once delivery" are hard to
implement without JMS, and can be easily configured in JMS. Because of some
cross-platform products, JMS can be easily used as an integration
framework (you can easily communicate with old legacy systems, without
knowing it...). So from this perspective JMS is great and comparing the
API to the underlying functionality also extremely simple to use.
JCA: Java Connector
Architecture is a connector framework. It is similar to JDBC and allows
"easy" communication with backend legacy systems. Some systems, like
e.g. SAP, already provide an implementation (in this case called
JavaRessourceAdapter). Connector can be easily deployed, than you are
able to access the backend data - without additional hacking. JCA
connectors can be transactional, they care about pooling etc., so lot
of work is already done. To communicate with SAP you only have to know
the system parameters. I did it in a training with my students, the
complete procedure (download, installation, writing and deploying a
sample application) took less than one day it was much easier than
existing alternatives (JCO or proprietary connectors).
JTA/XA:
it's classic: many developers still believe, that transactions are only
needed in big enterprise applications. In fact you even need a
transaction in read-only applications in case DIRTY-READS or
NON-REPEATABLE-READS are not an option. The cool story: with session
beans you do not have to care about transactions - just declare them as
an annotation. Everything else is done by the container. An alternative
is a real pain: you have to fetch a connection associate it with a
thread commit it after successful return and rollback it in case of an
exception. XA or two phase commit: it is not possible to provide a
working alternative in a project, we had enough to make existing
solutions work...
JNDI: is really simple. Nothing else than a distributed, but not
transactional map. You need only to know one method: lookup - and will
get a reference back. In JAVA EE 5 resources from JNDI can be easily
injected - so event the lookup invocation is no more needed. JNDI was
often criticized, but from my perspective it was never the reason why
some projects failed :-)
Conclusion: For real world enterprise applications most of the
functionality of the Java EE 5 APIs is simply needed. The "enterprise"
APIs do often abstract established products and industry standards -
which are complex. The complexity comes from distributed data
processing and not the API so replacing Java EE with some other
technology is not an viable option. Also .NET and other frameworks
provide very similar functionality. Of course most of the enterprise
APIs can be simplified or improved, but this was never a problem in my
projects. We have to struggle with other challenges like: deadlocks, XA
between oracle and informix, asynchronous communication with unreliable
backends etc.
It seems like some developers use Java EE for the implementation of
"guestbooks" and than criticize it. Java EE can be very lightweight:
just use an JSP with SQL JSTL-tags - you are able than to read a
database table and display it in browser with few lines of code :-). You even do not have to
compile...