Got a serious question on my mind.
I'm architecting a next generation system who's clients [HTML, VXML, WML and
more]
do almost no transactional operations. Transactional support being one of
the most
useful features in EJB in my view.
Our current generation system generates HTML via servlets+jsp+ tag-lib
classes connecting
to Corba services for business data. So I know too well the development
costs and hugh
inertia to change this architecture represents. To me, replacing Corba
stateless services with
what from J2EE?? There's no good replacement (subject of a serious
complaint) or maping
from what I have to a better more performant, scalable or low cost to build
and change design
from the J2EE pattern.
The hotest architecture is not EJB at all (good) and barely leverages
servlets and jsp's. It's
the XSLT transform engine, XML emitting directly from the DB (Oracle 9i) or
8i with XML connectors
to get you by until 9i ships.
The amount of business logic that's compiled into byte code is practically
nil which is a stark
contrast to EJB, which has all of your business logic located in servlets,
jsps and numerous
EJB's and db schema. This looks like a great win for a cheaper way to
design the HTML content,
and change once you've built it. Just edit the XSL/XSLT docs or change the
schema of your
XDB source.
Admittadly this architecture just eats CPU and latency. But this is what
cheaper faster CPUs
are all about??
Any comments or first hand experiences?
EJB VS XML?
Curt
Architect of a next gen architecture to run a phone company.
Curt Smith
Z-Tel
email: [EMAIL PROTECTED]
work: 404-237-1166 x182
FAX: 404-237-1167
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
