Eric Williams wrote:
> The reaction is almost univerally the same... "bleagh" as
> you put it.
I say again: "Bleagh".
> But I think the longer you work with EJB, the more you grok why these
> restrictions
> are in place and the more you come to think that the EJB specification
> writers
> did the right thing.
OK, you're on shaky ground at the moment :-) but I'll work with you for
now....
> An EJB server *has* to be able to control its
> environment,
> to include all resource utilization. Stability, security, and
> scalability demand
> it.
Yes.
> And the EJB specification writers had to enable vendors to offer
> advanced
> products based on the specification (eg, EJB implemented *in* a
> database, or a
> multi-VM shared-memory approach, etc.)... some of which are incompatible
> with
> threads or file I/O.
Yes.
But it is then incumbent upon the spec. writers to write the spec. in
such a way that perhaps this is one *option*. Alternatively, if the
spec. is really geared towards describing ostensibly reusable bits in a
database or multi-VM shared-memory approach, then it should be optimized
for that. The current specification tries to do both: it claims that it
is a specification for writing distributed *components*, which loosely
speaking are commonly understood to be rather "large" collections of
objects that work together to perform a single "large" well-defined
task. If so, then all such components, if they are to be truly
reusable, should be able to do lots of things to accomplish their task,
including publishing messages, logging to files, poking at the
filesystem, spinning dials, etc. However, this then crashes into the
sections in the specification which are optimized for, as you put it,
"advanced products" that might not even have file or thread
implementations. Which is this spec. written for? If it's supposed to
be written for unbelievably narrow slices of business logic, then fine,
I get that, and the restrictions on threading and file access and all
the rest make sense. If that's true, then I resent the fact that the
spec. sells itself as though it's a distributed component specification,
because components are typically understood to be more complicated than
simple narrow function calls.
Ultimately, of course, I don't care; from a pragmatic standpoint I want
something that makes my job easier; from an artistic I-love-my-work
standpoint I want something moderately elegant. So far I have to take
it on faith alone that this spec. is either, let alone both.
Ironically, what I'm getting out of all this is that the Thing That
Calls EJBs can be 127983% more reusable than the EJBs themselves (which
is fine, of course; it just involves some level setting). For example,
a regular Java bean called, say, Employee that delegates its
implementations to a very narrow
please-don't-call-it-a-component-because-it-isn't-anymore-by-any-definition
session or entity bean. All notifications of property changes, all
interactions with messaging systems, all threading issues, all logging
issues, all resource access issues, all other issues are handled NOT by
the session or entity bean (which was, of course, supposed to be the
spot where all this SHOULD have happened), but by the bean which calls
it.
And finally, to recap what my beans CANNOT do, if I'm understanding this
whole issue:
1. Use anything in the java.io package.
2. Do anything or call anything that might at some point in the call
stack result in new Thread().
2a. Of course this means that I must know the internal details of
every third party piece of software that my EJBs might call.
2b. This of course violates everything you know about encapsulation.
3. Publish messages using JMS (since that might result in a new Thread()
call).
4. Accept user input (no blocking IO calls)
Did I miss anything? Or misstate anything?
Cheers,
Laird
===========================================================================
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".
