James Cook wrote:
>
> 1. It opens up more avenues for security attacks
> As opposed to what? Doesn't the marshalling of *anything* over the wire open
> up this possibility? Are some avenues for security attacks acceptable and
> others are not. I think that this is manageable in many circumstances.
Granted, there are circumstances in which different levels of security
are
required. And there is nothing to say that you *must* use dynamic class
loading. But I stand by the statement that there is more of an
opportunity for intrusion if the class files are loaded from a remote
codebase. HTTP servers are compromised all the time. Is the risk
small?
Yes. It the risk more than keeping all the application files together?
Yes.
> 2. does not perform as well as local classes
> The performance penalty is a one-time cost. In fact, for many applications
> this will be spread out and greatly mitigated.
If the classes are stored as individual *.class files, then there will
be a serious "round-trip" penalty... as your VM keeps going back to the
codebase (eg, HTTP server) to retrieve each class file.
Of course, you aggregate the class files into a single JAR, but you
might run into performance problems on a slow link.
> 3. introduces a constant source of environment misconfiguration
> Whether the classes are dynamically loaded, or not, environment
> misconfiguration can occur. I don't agree with your assumption that it will
> be a "constant" source of problems. We manage it quite well, without *any*
> environment misconfiguration in our RMI world.
Here are the things that I see to add to the complexity:
1. You have to establish a separate server (eg, HTTP) to serve up
the class files.
2. Both the RMI-IIOP application and the web server must be up
and running. If not, your clients won't work.
3. Both the RMI-IIOP application and the web server must be configured
with the same class files.
4. If you are communicating with multiple servers, it is possible to
have class Foo.Bar != class Foo.Bar due to the use of multiple
classloaders.
5. Class incompatibility. The RMI-IIOP client application may have
been compiled against a different version of the RMI interface or
valuetype classes that are served up by the remote codebase. In
this case, the classes won't work on the client.
6. There will probably be vendors who will not support dynamic
classloading. Oracle's JServer (in the database) comes to mind.
Assuming you use one of these servers to connect to another server,
you won't be able to use dynamic classloading.
> I don't want to create a religious debate. It seems that the "pure" CORBA
> camp feels dynamic class marshalling is a very bad activity. Maybe it is not
> possible for CORBA to support this behavior.
CORBA is the point of view I come from. And, yes, it would be extremely
difficult to do this with pure CORBA. How would a C++ server running
on Solaris provide a COBOL implementation of a valuetype on an S390?
Outside Java-land, you have system, language and compiler variations
that make this problem intractible.
> RMI has to resort to the aid of
> an HTTP server (or shared file system) to support class marshalling. I would
> think that CORBA (with its separate ORB) could support this behavior
> securely and more efficiently than RMI.
Interesting thought. But it appears that support for classloaing was
tacked-on
to the spec for Java, rather than designed to be tightly integrated with
CORBA.
They could have added support for iiop: codebases and enhanced the
interface
repository to serve up implementation files... but they didn't. They
simply
added a tagged profile to the IOR to refer to the codebase. If I had to
take
a wild guess at why... I'd say they realized that it was intractible as
a general CORBA problem, but that they could implement a simple hack
that
would make it work for Java and would enable the retention of RMI-JRMP
semantics in RMI-IIOP.
> Some (maybe only WebLogic?) have embraced the concept, and I was wondering
> if others have been challenged by versioning of classes and the deployment
> headaches that can result. EJB is new and many people haven't come up
> against some of these challenges in real-world applications. I don't believe
> it is too soon to begin discussing the issue, and perhaps, possible
> solutions.
Since I was wrong about RMI-IIOP not supporting dynamic class loading,
I'm
not sure I want to make a statement about this... but... doesn't
WebLogic
provide only their proprietary implementation of RMI, not RMI-IIOP?
Again,
I could be 2 releases behind in my reading, but I recall some
documentation
describing their proprietary RMI implementation.
As for alternatives to dynamic RMI stub/valuetype classloading, why not
just update the whole application? Updating the whole application isn't
difficult if you deploy via applets, or via a proprietary tool such as
WebLogic ZAC or Marimba Castanet.
Of course, there are some situations where dynamic classloading is
essential.
Mobile agent programming comes to mind. But I'd suggest that this is a
different category of application than an EJB application, which is
aimed at
the high volume transaction processing arena.
-eric
>
> jim
>
> ----- Original Message -----
> From: Eric R. Williams <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, November 08, 1999 11:51 AM
> Subject: Re: Deploying & Maintenance
>
> > I thought that RMI-IIOP did *not* dynamically load classes from the
> > server.... this type of thing is not standard CORBA. (Ie, you can't
> > assume what "language" is on the other end... no guarantees that it
> > is Java.)
> >
> > And IMO, dynamic class loading (ie, from the impl server) was one of
> > the biggest drawbacks of RMI-JRMP. It opens up more avenues for
> > security
> > attacks, does not perform as well as local classes, and introduces a
> > constant source of environment misconfiguration.
> >
> > -eric
> >
> >
> > Alan Greenspan wrote:
> > >
> > > > ...
> > > >
> > > > I was very disappointed to find that CORBA does not allow the dynamic
> > > > distribution of classes. For example, if I have a parameter of type
> > > > Employee<interface>, and I marshall a class that implements this
> > > interface,
> > > > the class that implements must be present on the client. There were
> many
> > > > times that I took advantage of RMI's ability to do this "on the fly".
> > > >
> > >
> > > RMI-IIOP dynamically loads implementation classes the same way as
> RMI-JRMP.
> > > I don't think there are any issues here for EJB.
> > >
> > > Alan
> > >
> > >
> ===========================================================================
> > > 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".
> >
> >
> ===========================================================================
> > 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".
> >
> >
>
> ===========================================================================
> 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".
===========================================================================
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".
