Jay and Andre:
Thanks for enlightening me over the many issues regarding EJB. I was especially
interested in how the various groups do not understand the other roles. DBA's do not
understand EJB, etc. I think people need to put themselves in these other roles, in
order to understand the big picture. Before I ventured into J2EE (hey! I amit. The
complexity of J2EE intrigued me), I did some work for a while supporting a home build
gateway for a major credit card company, using several gateways and routers. You
understand how TCP/IP works after a while (especially after seeing how a gateway
functions). And now I am playing with being an Oracle DBA, but I am learning how all
the pieces fit totether. The people on this list are very bright, and I really love
Orion and jboss. I always look at things this way. If I don't know something, some
bright person can teach me. If a newcomer asks a question, and I can answer it, we
have another potential Orion or J2EE member in the fold.
Randy
-----Original Message-----
From: Jay Armstrong
To: Orion-Interest
Sent: 2/17/01 9:11 AM
Subject: RE: Where are the perfumes bubble bath beads
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?
>
>
>
