eric r williams wrote:
> Ok, let me chime in with more pro-wire arguments.
Please do :-)
> There are many benefits of wire ptotocols. Let me focus on one major
> benefit.
>
> A wire protocol does not constrain the implementation language.
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.
> IMO,
> this is why JINI will not achieve great success and why RMI-JRMP became
> less important than RMI-IIOP. The "remote" side must be Java, since you
> have to download the Java stubs.
And as above, the remote side *always* is Java in this particular
problem (server-server interop).
> There are some compelling arguments against requiring Java (or Java with
> remote stub downloading):
>
> * Many organizations want cross-language remote call capabilities.
No problem, an API-based solution can still cover this.
> * Many organizations won't adopt a technology if they feel it is
> a closed-end technology that won't interoperate with anything
> else (even if they don't need it to interoperate yet).
Absolutely, and an API-based would give us great interop. along with the
possibilities of container-optimized wire-protocols.
> * 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. What you are talking about is true
client interaction, which could be from an embedded device running C++
programs or whatever. As I noted in my very first reply on this thread
this problem is a superset of what we're discussing. As a reminder, we
are talking about server-server interoperability. Nothing more, nothin
less.
> * 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.
> * Remote stub downloading does not perform as well as local stubs.
Because..? If you're talking about the one-hit at the beginning this
could be fixed if one caches the implementation and do timestamp
checking etc. The only difference between dynamic stub downloading and
"local stubs" is where you get the classes from: preinstalled into local
classpath or from server on-demand. Once the stub has been created there
is no difference.
> Wire protocols enable innovation by constraining nothing except the
> communication.
Not quite with you here. You're saying that by making constraints on a
very low level (wire-protocol) you enable more innovation, than if you
put the constraints at a higher level, i.e. stubs? Yeah. Right.
> Imagine if web browsers were implmented with an API solution, where the
> "stubs" had to be implemented as downloadable "C" shared libraries. To
> view a web site, you'd first bootstrap to the site by downloading its
> implementation shared library. Then your browser would load the shared
> library and call the standard API calls. Just imagine the flexibility of
> this system... not being constrained by HTTP or HTML. You could
> implement some really cool web interfaces this way. But of course, this
> architecture would never be accepted by a broad marketplace. HTTP
> constrains, but by constraining it also enables. Users don't (in
> general) have to worry about what web browser will work with what web
> server. All web browsers and all web servers are generally expected to
> work together, because they conform to the HTTP wire protocol.
Thanks for proving my point. See, most of the content in browsers come
from HTTP/HTML, and this is an a-ok baseline for most people. However,
if you want more than just the bare-bones stuff on your site you use
plugins (compare with downloadable stubs), that perhaps use multimedia
streaming (compare with custom wire-protocols). And all of this is
possible because HTML allows custom code using custom wire-protocols.
Which is used on lots of websites to enhance the experience of their
users.
IMHO (and you're free to disagree) none of your points showed in any way
that in this particular case would it be a better idea to use one
wire-protocol instead of using a (more flexible, IMHO) API-based
solution.
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.dreambean.com
Question reality
===========================================================================
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".
