Hello,
I think will have to make amends for my post where I recommended
to "consider steering clear of J2EE". Thus deepening the off-topicness.
Jess Holle said it:
This affects things ranging from surveys of developers asking "Which of
the following do you use? (a) J2EE, (b) .NET, ..." where developers may
say "no, I don't use J2EE as I don't use EJBs" to a silly stigma against
things like Hibernate (...)
I have indeed fallen into the trap of equating J2EE and EJB. Sorry about
that.
But I must somewhat disagree with Wade Chandler
<[EMAIL PROTECTED]> when he says:
J2EE is an API set to support some specifications
and strongly with Leon rosenberg <[EMAIL PROTECTED]>:
Hibernate and spring are heavily J2EE based
Going by the large bookshelf on my left, wherefrom I grab the olde book from
O'Reilly, "Java Enterprise In A Nutshell", I read:
: Before we go any further, let's be clear. The term 'enterprise computing'
: is simply a synonym for distributed computing: computation done by groups of
: programs interacting over a network.
Oops, let's jump directly to the reference then! (Note: For me at least,
'enterprise computing' is a synonym for reliable, stable applications possibly
running on a single central server for which the APIs used and exported are
well known, for which you can find support and for which you can do maintenance.
Or put another way: I don't care about the 'distributed' part until I need it.
End of Note.)
Skipping the adjectives, a J2EE-compliant platform is a container environment
that presents the following APIs, called the "Java Enterprise APIs", to client
code:
- JDBC 2.0: Working with databases (now in J2SE)
- RMI: Remote method Invocation ("Java RMI" + "RMI/IIOP", "Java RMI" is now in
J2SE)
- Java IDL: CORBA distributed objects
- JNDI: Accessing Naming and Directory Services, generally through LDAP (now
in J2SE I think)
- EJB: Enterprise JavaBeans
- Servlets: Everyone knows what that is. Have a Tomcat.
- JMS: Enterprise Messaging.
- JTA: Managing Distributed Transactions.
plus (according to <http://java.sun.com/j2ee/1.4/docs/api/index.html>)
- JavaMail: Mail sending and Mail processing API (can be downloaded separately)
- JMX: Instrumentation and Management interfaces (can be downloaded separately)
- XML: DOM and SAX and XSLT and stuff (can be downloaded separately)
- XML-RPC: The SOAP way of doing RMI
You can chuck the J2EE container environment and mix-and-match open or closed
implementations of the above APIs. Then you can layer higher-level stuff on
top of the above: JDO, Hibernate, iBATIS, JSP/Struts, Java Tuple Spaces.
Whatever. But using the APIs does not mean that you are 'J2EE based'. It
just means that you use an API that has been included in the J2EE specification.
Wade again:
I believe what we see more of is the marketing hype
and FUD confuses the use cases for many people and
recruiters and human resource departments at
organizations make it even more confusing for some
others by the fact they don't know what their
organization needs and all they know is what is on
paper and then they try to talk about things like they
know what they are talking about.
Couldn't agree more. Myself, I have to stop and ask "Do I REALLY need
this API? Would it make my life easier or would it make it more
difficult? What about about using 'simple solution X' here?"
And given the time constraints, 'simple solution X' it often is.
Jess Holle again:
The fact is that EJBs are just the most complex piece of J2EE.
App server vendors love to get you all wrapped up in them because
unlike most everything else in J2EE you need a full blown app server
to do them (...)
This paragraph made me think of this article by Neil_Ward Dutton
<http://www.regdeveloper.co.uk/2005/12/16/service_component_architecture/>:
Im happy to admit that theres long been a conspiracy theorist
living in my brain, telling me that J2EE was an attempt by the
established players (IBM, BEA and Oracle, aided by Sun) to lock small
vendors out from the Java application server market opportunity. For most
of the time the primary "evidence" to support my feverish imaginings was
the fact that certifying products to J2EE has always been expensive ? and
it has become more expensive as the specification has become more
complicated. Small vendors had real trouble getting the resources together
to play that game. Now, though, Im starting to think that the increasingly
audible developer discontent with J2EE adds fuel to my fire.
It is entirely possible that J2EE was developed altruistically by the
folks involved in the process. However good the original intention was,
though, the large vendors sales and marketing teams have certainly been
happy to associate complete J2EE compliance with the ability to deal
with real-world requirements in customers minds.
Right, my bus leaves in 2 minutes...
Best regards,
-- David
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
