Rickard �berg wrote:
> Before we move along I want to note that while the above
> is perfectly correct, you must remember that in the J2EE
> context the implementation language is *always* Java. And
> yes, I do know that clients can be in C++ or whatever,
> and yes, I do know that even the container can be in C++
> or whatever. But the EJB's always live in Java-land. And
> that's the important point here.
I still see this as incredibly short sighted. J2EE may have started as Java
only, but do you really think Sun want's to keep it Java only? To make
severely limiting design decisions based on what I think is a temporary
limitation doesn't sit well.
> And as above, the remote side *always* is Java in this particular
> problem (server-server interop).
Again, short sighted. Yes, I've seen that jini expects every non-Java end to
embed a JVM purely for communication, and that just doesn't feel right
either.
> > * Many organizations want cross-language remote call capabilities.
> No problem, an API-based solution can still cover this.
As above, at the cost of having to embed a JVM.
> > * Many embedded device developers won't support Java.
> > Maybe the device has a very small footprint, or the
> > developers feel they can better control the environment
> > without a Java VM.
>
> Sorry, but this point is completely unimportant in this
> context. We are (at least I am) only talking about
> server-server interop, and in this case the beans are
> always in a JVM.
>
> > * Some types of Java technology won't support dynamic
> > code loading (Java VM in a small-footprint device,
> > embedded VM in a database system, "trust" levels
> > that permit local code only, etc.)
>
> Absolutely, in which case one would have to pre-install
> the wire-protocol implementation that one wishes to use.
> This is regardless of which protocol is used.
I agree with you on this one, but for different reasons. To limit an
enterprise-scale architecture because some embedded/small-footprint device
can't handle it just doesn't matter to me.
Another poster also pointed out a gotcha for downloaded stubs -- security.
Downloaded classes could have god-knows-what hidden inside of them. While
not a problem for internal apps, external apps (B2B style) might get stubs
from other companies (or the classic evil middleman). With a wire-protocol,
they could only fiddle with the data. With an API protocol, they have to be
able to execute their code in my enterprise computer (as well as fiddle with
the transmitted data).
Jeff
===========================================================================
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".
