>
>The trouble is that many companies employ Java developers who can barely
>string a piece of code together. Add to this J2EE and they start gibbering
>in the corner! A lot of Java people are self-taught or converters from some
>older language like COBOL. I mean no disrespect, but often this doesn't turn
>out the best Java programmers.
couldn't agree more. getting skilled people to develop in a complex j2ee
environment is a real problem. it took us a while until we had our
development process optimized in a way that we could really use less
skilled/experienced developers. now the "gurus" work mostly on improving
tools (a code generation framework for generating cmp-ejbs with a service
layer and tons of helper classes and a web-application framework) and
making architecture decisions and the freshmen happily work inside their
servlets and xsl-templates with strict coding guidelines on top of a
service layer which is ejb-based, so they don't have to understand (the
more the better) the whole thing. works very well.
we've been using j2ee (or parts of it using jserv, JonAS and now orion) for
more than a year in projects and our observations/experiences were as follows.
in the beginning you tend to use things because they are there not because
they are most appropriate. specifically we underestimated the price you
have to pay for putting things in an ejb in maintenance (rarely really had
performance issues because of ejb overhead), required developer-know-how
and depending on your container, development cycle efficiency. in the small
scale a nice gui-editor might be sufficient but if you have a large online
shop application with content management deployed many times, maintenance
of xml-deployment files becomes a big issue, especially when the software
evolves with time and the number of deployments grows. I'm not saying don't
use ejb, just use it more consciously. we are very happy with j2ee and have
several applications out there that are considered successful projects.
the other thing is maturity of available software and using the latest
standards. we decided about a year ago to code according to EJB1.1 because
we knew orion was conformant to that and the spec had simply improved a lot
since 1.0. problem was, we didn't really have a choice in appservers as
there were no alternatives out there supporting ejb1.1 in our price range.
the decision was daring if not completely braindead. we ran into so many
infancy problems with orion that made us spend manweeks if not more in
diagnosing orion bugs, coding workarounds and banging our heads against the
wall (things are fine now and I would still recommend orion as a product
btw.). boy, would we have liked to have source code for orion at the time
;-). we had relied on the cmp-speed of orion and a switch back to JoNAS
wouldn't have been possible without major changes in our infrastructure. we
pulled through somehow but got in really serious trouble because of project
delays. looking back it would have been better to have done the project
with servlets and some o/r-mapping and jta at the time and evaluate an ejb
based solution a little longer. I can only advise people not to
underestimate those problems and to include them in their risk management
strategy. this is why I haven't thought about using jboss yet, because I
think it takes several real life projects to discover the less obvious bugs
and get an acceptable level of stability. however, I'm sure orion will
overtake many competitors (definitely all OS ones) but it will take time
before it can be compared to something like orion (which is very usable
right now) simply because the only thing that makes a product good is users
that depend on the product doing its job.
to sum things up, J2EE for us has definitely been a success in real life
projects and a very powerful architecture once you free yourself from
technological trigger-happiness and learn what the trade-offs are.
robert
(-) Robert Krüger
(-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH
(-) Brüder-Knauß-Str. 79 - 64285 Darmstadt,
(-) Tel: 06151 665401, Fax: 06151 665373
(-) [EMAIL PROTECTED], www.signal7.de
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
