Andre,
You make many good points.
One of my disappointments with J2EE is that, like many of the "non-EJB"
application servers (such as Netscape App Server), J2EE products are
typically hard to configure. This is due, in part, to the J2EE spec
allowing J2EE products can have a lot of latitude in how they accomplish
configuration. Things like clustering and load balancing between server
instances are wide open. Most of the requests I get for J2EE consulting
have to do with some sort of configuration issues.
Often, I see that large J2EE development projects have organizational
disconnects between the various development groups. For example, the
Oracle dba's are oblivious to how db row and table locks affect the EJBs,
the web developers don't understand what an EJB is or how a JSP can call
it, the network managers understand request-level failover, but do not
understand maintenance of state between redundant EJBs, and the manager who
paid big bucks for the app server is wondering why such an expensive
product doesn't work!
If you look at most of the traffic on orion-interest, it has to do with
configuration issues.
I think use of XML configuration files has helped a lot, but configuring
any large distributed system, even with XML files, is not for the
lighthearted. Knowing that most fancy tools merely modify the underlying
config files, I would be concerned about anyone who reconfigured a J2EE
system with a GUI tool, but without understanding how to do it manually.
If I could wave a magic wand over the J2EE world, it would be to have a
universal Java GUI for easily configuring and monitoring any J2EE product.
It would provide help as to which configuration changes were for J2EE
standard configuration items, and which were unique to a given product
(WebsFear, Orion, whatever).
Before ending this diatribe, let me emphasize the monitoring/diagnostics
thing. Another major issue with J2EE after deployment is integrated
diagnostics. How can you tell, for example, that an Entity EJB is hanging
because someone logged into the db via a telnet session, began executing a
horrendous query, then killed the telnet session without logging out, and
thus locking out some EJBs? How can you tell whether or not an underlying
IP socket connection is waiting to time out?
Well, I've got a deadline due yesterday, so I'll get off my soapbox and
stop preaching to the choir. Someday, I'd love to try solving these
problems. :-}
Have fun!
Jay Armstrong
[EMAIL PROTECTED]
At 12:55 PM 2/16/01 -0700, you wrote:
>Although perfumed bubble bath beads are nice and fun to use, sometimes their
>aroma can be nauseating.
>
>In my opinion the less code the better. Less bugs, and quicker fixes.
>The company I work for now uses iPlanet, and I really miss working with
>Orion. In my opinion even the beta version of Orion were more stable than
>IAS6 is now.
>
>There are several reasons IAS is so big, and I would assume the other heavy
>weights for similar reasons.
>
>IPlanet used to be Netscape Application Server which used to be Kiva
>Application server before the days of J2EE, and it includes support for
>Applogics (Proprietary api for writing servlet-like-things in C++). All the
>J2EE features were just tacked on, and I doubt anybody cleaned up the old
>code, so there's a lot of legacy baggage.
>
> - Full clustering support at all levels.
> - Netscape Directory Server for LDAP backed JNDI and authentication.
> - Netscape Administration Server and Console
> - iPlanet Web Server - Based on Netscape Enterprise Server.
> - 400+ pages of documentation
> - Lots of buggy deployment and packaging tools - Something orion has in
>common ;)
> - Broken ejb compilers (On Solaris)
> - A great feature which randomly throws ClassCast exceptions when using
>SFSBs.
> - AbstractMethod exceptions in compiled jsps.
>
>Although my last three points are just vents of frustration, the point I'm
>trying to make is that size!=quality. Sure iPlanet in a cluster
>configuration can handle more
>requests than Orion, but at $40K+ per server, its probably better to run
>several cheaper servers and buy an expensive, hardware based load balancer.
>
>I think oracle 9I AS brings a lot of database integration to the server, and
>when you look at just the size of the Net8 client, 1Gig doesn't sound that
>far-fetched.
>
>Last of all, everyone is always complaining about orion's documentation.
>True, Orion doesn't provide hand-holding documentation, and the existing
>docs could definitely use improvement, but there is certainly enough there
>to get a basic app up and running. iPlanet comes with a 200 page
>developer's guide, a 100 page administrator's guide and lots of supplements.
>How much value do they add? To a complete J2EE beginner, probably some, but
>their news group contains almost as many and the same type of questions as
>the orion list. Orion is a J2EE server, so to use it, and any other J2EE
>server, you need to understand J2EE. J2EE is complex (that's why we get
>paid the big bucks), but once you get at least a basic understanding
>(things like EARs, WARs, EJB-JARs and resource-refs) the only documentation
>you'll need is for server specific configuration, and the orion docs pretty
>much cover that.
>I agree some of the advanced features (such as SSL, JMS and such) are
>lacking, but even those were sufficient to get me up and running although it
>took longer.
>
>I admit I'm biased since I learned J2EE on Orion, but in my experience,
>Orion is fairly easy to work with compared to IAS and Weblogic. Maybe I
>need to take a look at some of these other servers since everyone is raving
>about their documentation.
>
>Andre
>
>
>-----Original Message-----
>From: Kemp Randy-W18971 [mailto:[EMAIL PROTECTED]]
>Sent: Friday, February 16, 2001 7:06 AM
>To: Orion-Interest
>Subject: Where are the perfumes bubble bath beads
>
>
>Here is a mystery I need help with. If all JSP engines and EJB servers are
>approximately equal, then what explains the size differences in the
>following examples?
>Latest production Orion - 10 MG
>Latest production Resin - 12.8 MG
>Latest productions Jboss/Tomcat - 23.3 Mg
>Latest production Unify Ewave Engine - 18.1 MG
>Latest production Iplanet 6.1 - Approximately 1 Gig
>Latest Productions Oracle 9I AS - Approximately 1 Gig
> In a past commercial for Motel 6, they talk about not having any perfumed
>bubble bath beads, like the higher priced hotels. So I ask these questions.
>What could possible take up 1 gig, when all JSP engines and EJB servers are
>supposed to have similar or identical functionality? Out of curiosity, how
>much space does Weblogic take up? Where are the perfumed bubble bath beads
>in the 1 gig space?
>
>
>
