> So what's wrong with a single ejb-jar?
4- It harms external bean providers' integration. I'm building a CMS that is
composed of an engine (an ejb-jar) and a web app(for the backend). You
tipically should build a frontend app with the engine and any number of web
apps. etc(with FREEDOM) and a backend app with both the engine and the
web-app. If solely CMS is the customer's need, then all is fine(I guess--
but can't ever tell); but if more EJB's are involved, integrating would
change from adding a file and a <module/> tag to tinkling inside the .jar I
provide. Now, add a Transaction Engine, a CRM engine and a scheduling
component.
How's that component oriented?
How could a non-major seller gain market share? I mean, if a component is
_bundled_ in the app server of choice (most places have a corp. standard),
then it'll be adopted sooner or later, even with the hassle of tinkering
around. But not a small vendor, and never to the developer's entire
satisfaction. One of the things I most appreciate of J2EE is that the
contract is loose enough(not completely) to allow everybody to improve by
building _components_, defining architecture, deployment scenarios, evolving
metodology. The EJB 2 spec is a clear step back if approaching J2EE as an
_open_ platform. What it really does is leave the small guys out. And that's
enough for me to stop and rethink if J2EE really is the way to go-- what
would be next? prosecution of all non J2EE licensees?
===========================================================================
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".
