What to use for distributed computing.
David Chieu
I have a situation where I need to implement some distributed objects in a
client/server environment. On the client or the server side, I have an
opportunity to use either Java/RMI or CORBA.
Can someone tell me the benefits of using one over the other in providing a
distributed platform solution for my customers?
Thanks.
PS: Can you also reply to David_Chieu@CandleCom
George Reese
David Chieu (David...@candle.com) wrote:
: I have a situation where I need to implement some distributed objects in a
If it is a pure Java environment, use RMI. Otherwise, if you need to
integrate your objects with non-Java objects, use CORBA.
The CORBA people like to whine a lot about this sort of answer, since
it is not CORBA. But in a pure Java world, there is no need for
CORBA. I just had to take that shot cause I was appalled at all the
whining they did at JavaOne.
--
George Reese (bo...@imaginary.com) http://www.imaginary.com/~borg
i speak religion's message clear i am the prayers of the naive
i am denial guilt and fear i am the lie that you believe
-nine inch nails
Jeff Nelson
George Reese wrote:
> The CORBA people like to whine a lot about this sort of answer, since
> it is not CORBA. But in a pure Java world, there is no need for
> CORBA. I just had to take that shot cause I was appalled at all the
> whining they did at JavaOne.
Could you expand on this further? What was said at JavaOne
about the future of RMI and CORBA?
As a certified Java professional and a committed CORBA fanatic,
I endlessly hope that Sun will move toward implementing
RMI on top of CORBA rather than continuing to snub an
open standard. Sun has absolutely no reason to use a
proprietary protocol for RMI.
- Jeff "Was I whining?" Nelson
--
DiaLogos offers CORBA training, consulting, and implementation.
CORBA allows programs to share objects with other programs,
even on different computers or in different countries.
Http://www.dialogosweb.com
George Reese
Jeff Nelson (jne...@dialogosweb.com) wrote:
: George Reese wrote:
:
: > The CORBA people like to whine a lot about this sort of answer, since
: > it is not CORBA. But in a pure Java world, there is no need for
: > CORBA. I just had to take that shot cause I was appalled at all the
: > whining they did at JavaOne.
:
: Could you expand on this further? What was said at JavaOne
: about the future of RMI and CORBA?
:
: As a certified Java professional and a committed CORBA fanatic,
: I endlessly hope that Sun will move toward implementing
: RMI on top of CORBA rather than continuing to snub an
: open standard. Sun has absolutely no reason to use a
: proprietary protocol for RMI.
CORBA does something *different* from RMI. CORBA is an architecture
that enables object-based communication in a heterogeneous
environment. RMI is an architecture that enables object-oriented
communication in a homogeneous network environment.
What exactly is it you think you want?
Jeff Nelson
> : Could you expand on this further? What was said at JavaOne
> : about the future of RMI and CORBA?
Again, could you expand on this?? I'm really interested.
NSA and OMG jointly hosted a Security Workshop at the
same time as JavaOne.
> : I endlessly hope that Sun will move toward implementing
> : RMI on top of CORBA rather than continuing to snub an
> : open standard.
> CORBA does something *different* from RMI. CORBA is an architecture
> that enables object-based communication in a heterogeneous
> environment. RMI is an architecture that enables object-oriented
> communication in a homogeneous network environment.
My point is rather simple. RMI can be implemented on
top of CORBA.
To expand on this, RMI remote interfaces are equivalent
to CORBA interfaces. RMI Remote Services are equivalent
to CORBA servers. Even RMI's naming service is nearly
the same and could be implemented on top of CORBA's
Naming Service. As far as I can tell, the folks that
designed RMI simply didn't know about CORBA.
Further, this would benefit RMI; it could take advantage
of CORBA services. For example, Sun has plans
to support security - already in CORBA. Just grab a
CORBA document for a smorgasboard list of features
that you would want in RMI.
What functionality of RMI do you deny can be implemented
on CORBA? Interface inheritance? Passing remote
interfaces as arguments and return values? Throwing
remote exceptions?
- Jeff
orfali
>
> My point is rather simple. RMI can be implemented on
> top of CORBA.
>
> To expand on this, RMI remote interfaces are equivalent
> to CORBA interfaces. RMI Remote Services are equivalent
> to CORBA servers. Even RMI's naming service is nearly
> the same and could be implemented on top of CORBA's
> Naming Service. As far as I can tell, the folks that
> designed RMI simply didn't know about CORBA.
>
> Further, this would benefit RMI; it could take advantage
> of CORBA services. For example, Sun has plans
> to support security - already in CORBA. Just grab a
> CORBA document for a smorgasboard list of features
> that you would want in RMI.
>
> What functionality of RMI do you deny can be implemented
> on CORBA? Interface inheritance? Passing remote
> interfaces as arguments and return values? Throwing
> remote exceptions?
>
> - Jeff
> --
Jeff, you're absolutely right. RMI can be implemented on top of IIOP.
Netscape/Visigenic's Caffeine shows how much of this can be done today (but it doesn't
ship behavior around). It was obvious to many of us at JavaOne that RMI has a long
way to go before it's anywhere as complete as CORBA. For example, RMI must
implement/define persistent references, transactions, security, and the list goes on.
One of the reasons for the "whining" is that nobody could get a date on when they
would deliver all this function. Yes, there are people at JavaSoft who are thinking
about putting RMI on top of IIOP. In the Java Enterprise session (by Shel
Finkelstein), CORBA/IIOP was mentioned as the preferred way to implement Enterpise
Beans. This is because Enterprise Beans use the Java Transaction Service (JTS), which
is based on CORBA OTS.
If you need a pure Java solution today, my recommendation is to use
Visigenic/Netscape's Caffeine instead of RMI. RMI is a dead-end. In the end, there
will only be two ORBs: DCOM and CORBA/IIOP. There is no room for RMI. We elaborate on
this in our book "Client/Server Programming with Java and CORBA." We also compare RMI
with Caffeine. I am working with Netscape and Visigenic to make sure *everyone* hears
about Caffeine. RMI only helps DCOM/ActiveX in the long run :-). BTW, I'm a great
admirer of RMI--I think it's brilliant. However, I want it on top of IIOP. Today, I
can get most of this from Caffeine. Eventually, OMG will standardize the reverse
language mappings. So I'll be able to get this function from any CORBA ORB.
Bob Orfali
orfali
Peter van der Linden wrote:
>
> >What functionality of RMI do you deny can be implemented
> >on CORBA?
>
>
> 1. simplicity. RMI is simple.
> CORBA is a complex solution to a complex problem.
>
> 2. language-dependence. RMI is bound to Java, and
> does not suffer from the need to speak all languages.
>
Peter, we run the same program in our book using both
CORBA/Caffeine and RMI. You tell me which is simpler.
Bob Orfali
Eric McDermid
In article <334D4F...@dialogosweb.com>,
Jeff Nelson <jne...@dialogosweb.com> wrote:
>
>To expand on this, RMI remote interfaces are equivalent
>to CORBA interfaces. RMI Remote Services are equivalent
>to CORBA servers. Even RMI's naming service is nearly
>the same and could be implemented on top of CORBA's
>Naming Service. As far as I can tell, the folks that
>designed RMI simply didn't know about CORBA.
They were quite aware of CORBA. Jim Waldo (RMI architect)
was one of the people who submitted the joint HP/Sun
proposal back in 1990/91.
CORBA has to deal with the assumption that objects are distributed
across a heterogeneous network, and implemented in multiple
languages. Hence the added complexity of IDL, etc. to create
a neutral playing field.
RMI, on the other hand, can assume a purely homogeneous network
of Java Virtual Machines. Further, it can count on a
common language and object model throughout that network.
This not only means RMI is simpler to use, it means it can
do things that CORBA cannot.
>What functionality of RMI do you deny can be implemented
>on CORBA?
Try passing an object of arbitrary complexity by value. Next,
pass an instance of a derived class that the recipient doesn't
know about. That's trivial in RMI, and very, very powerful.
It is probably also what the original poster meant by calling
CORBA "object-based" distributed computing and RMI "object-oriented"
distributed computing.
Mind you, I don't deny that with enough jury-rigging, you could
eventually manage something similar with CORBA. But if you're
distributed app is written entirely in Java, why bother?
This is not a simplistic case of "RMI good, CORBA bad", or
vice versa. CORBA is clearly the best thing going for
heterogeneous systems. That doesn't make it the best solution
for pure Java environments.
Similarly, the fact that RMI looks to be the best thing going for
pure Java environments does not imply that it should be munged
to handle heterogeneous systems.
Finally, I reject the assumption that RMI and CORBA are mutually exclusive.
It is entirely possible for a distributed application to make
use of RMI among it's Java components, and use CORBA to interact
with non-Java components (for instance, standard CORBA services).
-- Eric McDermid
Peter van der Linden
>What functionality of RMI do you deny can be implemented
>on CORBA?
There are two that I can think of:
1. simplicity. RMI is simple.
CORBA is a complex solution to a complex problem.
2. language-dependence. RMI is bound to Java, and
does not suffer from the need to speak all languages.
--
Peter van der Linden Java Programmers FAQ: http://www.best.com/~pvdl
-disclaimer-
unless stated otherwise, everything in above message is not personal opinion
and is an official statement of Fun-Fun Novelty Robot Weapons Inc.
orfali
Eric, the point Jeff makes is that it can all be done on top of
IIOP, which will only help RMI's cause. Without IIOP, how will RMI
cross firewalls? How will it implement security, transactions,
persistent refs, etc? Why reinvent the wheel? JavaSoft does not have
infinite resources. If they did, I'd like to see them put more energy
into bean containers and enterpise beans (ActiveX is ahead of us in
those areas).
IIOP has all of these features today. We would like to see RMI
implemented in top of IIOP. This would unify the CORBA and Java camps.
If you want to see a good example of what I'm talking about today check
Netscape/Visigenic's Caffeine. It has RMI-like functions on top of
an IIOP ORB--including:
1) No CORBA IDL needed. You make your Java interfaces remotable
by extending corba.Object. Instead of using rmic, you invoke java2iiop.
Caffeine has a bytecode postprocessor that automatically generates
IIOP stubs and skeletons. You can optionally generate CORBA IDL by
invoking java2idl.
2) Like RMI, Caffeine passes objects by value.
3) Like RMI, Caffeine suports a URL-based naming system. You bind CORBA
IORs to URLs.
Caffeine also allows Java objects to call C++ objects etc. Caffeine is
built on top of IIOP, consequently it supports CORBA OTS (on which the
Java Transaction Service is based). Unlike RMI, Caffeine supports
persistent object references. The Caffeine runtime will be available in
every Netscape browser and server. It is the core of Oracle's NCA. It
will be shipped with every copy of NetWare. It is supported by Sybase's
Jaguar and JavaBuilder tools. Finally, it will be included with
Borland's JBuilder and Netscape's Visual JavaScript.
So what does RMI have over Caffeine? It is part of JDK 1.1--it is free.
It also lets you pass behavior (i.e., classes) as arguments. I happen
to like these last two features. However, passing classes in method
arguments is controversial in some circles (for example, it will freak
out most enterprise client/server developers). These folks will insist
on signed manifests and the like before they let you pass classes as
arguments.
For a comparison of RMI and Caffeine, see our book "Client/Server
Programming with Java and CORBA."
Bob Orfali
Peter van der Linden
Oh -- there's another way in which RMI wins against CORBA.
RMI is free.
George Reese
Eric McDermid (mcde...@best.com) wrote:
: Finally, I reject the assumption that RMI and CORBA are mutually exclusive.
: It is entirely possible for a distributed application to make
: use of RMI among it's Java components, and use CORBA to interact
: with non-Java components (for instance, standard CORBA services).
I applaud this sentence wholeheartedly--it is exactly what I think the
CORBA crowd fails to understand. I also want to add one more
important thing that RMI handles--distributed garabage collection.
Steinar Bang
>>>>> lin...@positive.eng.sun.com (Peter van der Linden):
> Oh -- there's another way in which RMI wins against CORBA.
> RMI is free.
Umm...? Check out the free CORBA implementations page:
<URL:http://adams.patriot.net/~tvalesky/freecorba.html>
Greg Pasquariello
But the RMI simplicity can be implemented on _top_ of CORBA (specifically
IIOP) without loosing either the simplicity or the language dependence.
Things like object pass-by-value that are not part of the CORBA spec per-se
can be implemented with no need for the programmer to be aware of the
change in implementation.
At this point, I use the technology that's appropriate for the job at hand,
but I have difficulty seeing how RMI, as it's own protocol, can compete
with CORBA and/or DCOM. Assuming that it can't, it might be wise to
consider layering RMI on top of CORBA.
In another posting you also brought up the issue of the cost for CORBA
implementations. My personal opinion is that runtimes will become
commodities and that you will pay for development licenses and possibly
services. In that case, RMI could be considered a freely available, though
limited (in CORBA terms), development framework.
-Greg Pasquariello
Peter van der Linden <lin...@positive.eng.sun.com> wrote in article
<5ijr0q$d...@engnews2.Eng.Sun.COM>...
> >What functionality of RMI do you deny can be implemented
> >on CORBA?
>
> There are two that I can think of:
>
> 1. simplicity. RMI is simple.
> CORBA is a complex solution to a complex problem.
>
> 2. language-dependence. RMI is bound to Java, and
> does not suffer from the need to speak all languages.
>
>
Jeff Nelson
Peter van der Linden wrote:
>
> >on CORBA?
>
> There are two that I can think of:
>
> 1. simplicity. RMI is simple.
> CORBA is a complex solution to a complex problem.
In what way is CORBA more complex than RMI?
If you are talking about the need to write IDL for CORBA,
there isn't one anymore. In fact, in RMI you have
to remember certain details about inheriting from
RMI base classes like java.rmi.Remote and always
throwing java.rmi.RemoteException. No need to bother
with these inconveniences for CORBA.
> 2. language-dependence. RMI is bound to Java, and
> does not suffer from the need to speak all languages.
How does this severe limitation prevent RMI from being
implemented on CORBA? Based on the features of RMI today,
I would say that it could definitely have been built on
CORBA, whether RMI itself is crippled or not has no
bearing on this.
Let me point out a difference of my own, RMI's naming
service is not location transparent. You have to explicitly
specify the host name of the object you are trying to locate
on your network. That's unfortunate because redistributing
objects to other nodes would require modifying source code
and recompiling. Even DCOM is smarter than that. Of course,
none of this prevents the implementation of the RMI naming
service on top of the superior CORBA naming service.
>Oh -- there's another way in which RMI wins against CORBA.
>
> RMI is free.
Well, that was really your (or at least Sun's) call, wasn't it?
Sun has a perfectly good CORBA product (several of them
actually), and they have even built support for them directly
into the standard JDK 1.1 core. Yet someplace in there,
they decided to
(1) charge for the CORBA server development kit
(2) make Yet Another Distributed Software Architecture
Jeff Nelson
Nice post, thank you for your insight on this.
Eric McDermid wrote:
> Finally, I reject the assumption that RMI and CORBA are mutually exclusive.
> It is entirely possible for a distributed application to make
> use of RMI among it's Java components, and use CORBA to interact
> with non-Java components (for instance, standard CORBA services).
But, today, this requires the attention of the developer.
Had RMI been implemented on top of CORBA, an RMI developer
might have been able to step in and use RMI to access a
CORBA server. Alternatively, a CORBA user might have
been able to step forward and use CORBA to access an RMI
server.
As it is, I expect someone will eventually write a bridge
between the two technologies, just as bridges are available
between CORBA and OLE/COM.
> Try passing an object of arbitrary complexity by value. Next,
> pass an instance of a derived class that the recipient doesn't
> know about. That's trivial in RMI, and very, very powerful.
Again, addressing the implementation of RMI on top of
CORBA, the CORBA Externalization service could be used
to for passing an object by value in RMI. One other note,
a Java implementation of the Externalization service would
definitely benefit from Java's class streaming and
reflection capabilities. Meanwhile, a COBOL implementation
of the Externalization service would have to bend over
backwards. This demonstrates how CORBA can take
advantage of the good features of one language
while still achieving language interoperability.
Passing an instance of a derived class unknown to the
recipient is, of course, impossible in basically any
language except Java. However, RMI could still be
implemented on top of CORBA to achieve this. Off the
top of my head, ClassLoader could be implemented in
CORBA, permitting any CORBA application at all to
request the bytecode - as an encapsulated sequence
of octets - for a particular class. This would
permit a Java client to lookup the implementation
of an object reference if the class loader knows
about it, or maintain and use the object reference
as it is, if the class loader does not know about it.
This would permit, (1) Java native objects to be
passed by instance with loadable implementation and
(2) RMI to transparently use other objects as
object references, despite their implementation
in other languages.
Chris Kessel
|> > There are two that I can think of:
|> >
|> > 1. simplicity. RMI is simple.
|> > CORBA is a complex solution to a complex problem.
|> >
|> > does not suffer from the need to speak all languages.
CORBA is complex? In what way? RMI seems the complex choice, you have
to know, or determine, what objects are local and remove. With CORBA
you don't care, the object is the same regardless of its location.
Setting up an IDL for a CORBA object isn't much harder than writing
a Java class defination for the same object. Initializing the orb in
the code is just a matter of handful of lines, after which your code
doesn't need to be aware of CORBA.
With RMI your code has to be aware which objects are remote and which aren't,
which seems less "simple" to me.
CORBA can be complex, if you make it so, by using all of the various
services, but that just goes to show its scalability. A basic CORBA
application is just that, basic.
--
-----------------------------------------------------------------------
Christopher Robin Kessel Portland, Oregon | Yes, I was named
chr...@protocol.com Protocol Systems | after *that* Christopher
-------------------------------------------------| Robin. Winnie the Pooh
Pooh: I'm Pooh. | is my hero. :)
Tigger: What's a Pooh? |
Pooh: You're sitting on one. |
-----------------------------------------------------------------------
Joe DiFonzo
I was at JavaOne, and I *definitely* got conflicting messages from Sun.
On Thursday, Shel Finkelstein (Javasoft) talked about "enterprise
beans" for large-scale distributed computing with Java. The interaction
between GUI beans (client-side) and enterprise beans (server-side) was
defined as IIOP -- or possibly other comms standards later on.
But on Friday morning, Jim Waldo (Javasoft) said that RMI is the
next step *beyond* CORBA/IIOP. In fact, he called RPCs the technology
of the '70s, CORBA the technology of the '80s, and RMI the technology
of the '90s. Yet he never discussed the obvious (at least to me)
shortcomings of RMI for enterprise use (as compared to CORBA), such
as transaction support, directory services, load management, etc.
Based on what I saw, though, there is no commecial CORBA implementation
today that can do some of the things that RMI does. CORBA is about
remote access to objects. RMI is about "networked" objects. In RMI,
I can pass an object from one Java VM to another across the network;
not just the state, but the actual CODE! This is, of course, due to the
architecture independence of the Java bytecode. If it is a complex
class, I can trace its entire inheritance tree to get every class
that contributes to the one I'm passing.
So I'm still a bit confused. Maybe the message will get clearer with
time, but my guess is that Sun will say "pick the tool that serves you
best" and leave it up to the user. Don't forget, Sun makes the Neo
ORB as well as the Java VM.
Joe DiFonzo
dif...@magicnet.net
Mark Baker
Jeff Nelson wrote:
> In what way is CORBA more complex than RMI?
> If you are talking about the need to write IDL for CORBA,
> there isn't one anymore. In fact, in RMI you have
> to remember certain details about inheriting from
> RMI base classes like java.rmi.Remote and always
> throwing java.rmi.RemoteException. No need to bother
> with these inconveniences for CORBA.
Throwing java.rmi.RemoteException is hardly an inconvenience.
It's what you have to do when you're building distributed
systems. I appreciate the fact that RMI forces me to think
this way.
> > 2. language-dependence. RMI is bound to Java, and
> > does not suffer from the need to speak all languages.
>
> How does this severe limitation prevent RMI from being
> implemented on CORBA? Based on the features of RMI today,
> I would say that it could definitely have been built on
> CORBA, whether RMI itself is crippled or not has no
> bearing on this.
Peter's statement was slightly inaccurate. RMI is bound
to the JVM, not Java the language. A subtle but extremely
important difference, IMHO.
> Let me point out a difference of my own, RMI's naming
> service is not location transparent. You have to explicitly
> specify the host name of the object you are trying to locate
> on your network. That's unfortunate because redistributing
> objects to other nodes would require modifying source code
> and recompiling. Even DCOM is smarter than that. Of course,
> none of this prevents the implementation of the RMI naming
> service on top of the superior CORBA naming service.
'Naming' isn't a naming service. It's more suitable for
doing something akin to resolve_initial_references. Javasoft
recognizes this (check the rmi-users list archive). They've
got a new API for naming and directory services (JNDI?).
Still, I believe it's in everybody's best interest to do RMI
over CORBA/IIOP. I don't think we're too far from seeing
that announcement, though Javasoft has been talking about
doing it since last summer.
MB
Rich Salz
In <334EA2...@nortel.ca> mba...@nortel.ca writes:
> They've got a new API for naming and directory services (JNDI?).
Yes it's JNDI, but it's not new. It's X/Open Federated Naming
all over again. :)
/r$
Woody Jin
In article <334E9D...@magicnet.net>, dif...@magicnet.net wrote:
>
>Based on what I saw, though, there is no commecial CORBA implementation
>today that can do some of the things that RMI does. CORBA is about
>remote access to objects. RMI is about "networked" objects. In RMI,
>I can pass an object from one Java VM to another across the network;
>not just the state, but the actual CODE! This is, of course, due to the
>architecture independence of the Java bytecode. If it is a complex
>class, I can trace its entire inheritance tree to get every class
>that contributes to the one I'm passing.
This is RMI's main advantage against CORBA.
The questions are, "How many applications *really* need this ?",
"Does CORBA have an alternative ways to do this ?".
Well, we'll have to see ...
--
Woody Jin
Michael Stal
wj...@cs.uh.edu (Woody Jin) writes: > In article <334E9D...@magicnet.net>, dif...@magicnet.net wrote:
> >[...] In RMI,
> >not just the state, but the actual CODE! This is, of course, due to the
> >architecture independence of the Java bytecode. If it is a complex
> >class, I can trace its entire inheritance tree to get every class
> >that contributes to the one I'm passing.
>
> This is RMI's main advantage against CORBA.
> The questions are, "How many applications *really* need this ?",
> "Does CORBA have an alternative ways to do this ?".
> Well, we'll have to see ...
One additional remark: You should wait for CORBA 3.0 which is due
for this year. This may include a possibility to pass objects by
value. In addition, it will offer a lot of other things such as a
message passing facility. Back to your question: Do we need to pass
objects by value? I think, this feature is useful for situations
where fine-grained objects needs to be passed around. Consider mobile
agents as an example. It also may be used for load-balancing issues.
For really big objects such as a multi-megabyte matrix I do not think
passing objects by value is the right thing to do. It depends on the
application whether passing objects makes sense, but it is definitely
useful for some problems.
-- Michael Stal
ron_e...@msn.com
In article ,
chr...@iago.NoSubdomain.NoDomain (Chris Kessel) wrote:
> CORBA is complex? In what way? RMI seems the complex choice, you have
> to know, or determine, what objects are local and remove. With CORBA
> you don't care, the object is the same regardless of its location.
>
> Setting up an IDL for a CORBA object isn't much harder than writing
> a Java class defination for the same object. Initializing the orb in
> the code is just a matter of handful of lines, after which your code
> doesn't need to be aware of CORBA.
>
> With RMI your code has to be aware which objects are remote and which aren't,
> which seems less "simple" to me.
>
> CORBA can be complex, if you make it so, by using all of the various
> services, but that just goes to show its scalability. A basic CORBA
> application is just that, basic.
Chris - Very well said - I agree 100%!
Why do people think RMI is so much easier than CORBA? Don't you have to
write interfaces? Don't you have to use a preprocessor to create
skeleton and stub code? Do you have to write implementation code? In
the end, CORBA wins!
My $.02
-Ron Emrick
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Mark Baker
Joe DiFonzo wrote:
> I was at JavaOne, and I *definitely* got conflicting messages from Sun.
>
> On Thursday, Shel Finkelstein (Javasoft) talked about "enterprise
> beans" for large-scale distributed computing with Java. The interaction
> between GUI beans (client-side) and enterprise beans (server-side) was
> defined as IIOP -- or possibly other comms standards later on.
>
> But on Friday morning, Jim Waldo (Javasoft) said that RMI is the
> next step *beyond* CORBA/IIOP. In fact, he called RPCs the technology
> of the '70s, CORBA the technology of the '80s, and RMI the technology
> of the '90s.
I don't think these messages are conflicting. Javasoft recognizes
that it needs distinct short term and long term strategies. Short
term, it's got to beat DCOM. The best way to do that is to team up
with the OMG. But long term, native Java distribution (RMI, JavaSpaces)
is the way to go. I think this is a great idea.
>Yet he never discussed the obvious (at least to me)
> shortcomings of RMI for enterprise use (as compared to CORBA), such
> as transaction support,
JTS will apparently be OTS compliant.
>directory services,
JNDI isn't COS Naming compliant (though it's pretty close), but is
a better solution, IMO.
>load management, etc.
I'm sure they've got that in their sights.
MB
--
Mark Baker; mba...@nortel.ca dis...@acm.org
Northern Telecom Ottawa, Ontario, CANADA
Ricardo Delima - Technology Office
>>>>> "chrisk" == Chris Kessel <chr...@iago.NoSubdomain.NoDomain> writes:
chrisk> With RMI your code has to be aware which objects are remote and
chrisk> which aren't, which seems less "simple" to me.
and that's exactly the way it should be. Remote and Local computing are
inherently different.
r.
Matt Kennel (Remove 'nospam' to reply)
On 11 Apr 1997 16:54:54 GMT, Greg Pasquariello <gp...@dbintellect.com> wrote:
:But the RMI simplicity can be implemented on _top_ of CORBA (specifically
:IIOP) without loosing either the simplicity or the language dependence.
:Things like object pass-by-value that are not part of the CORBA spec per-se
:can be implemented with no need for the programmer to be aware of the
:change in implementation.
What about distributed garbage collection and concurrency?
These are semantic parts of Java which would be nice to have preserved
in a distributed environment.
Can CORBA expose 'inner classes'?
--
Matthew B. Kennel/Institute for Nonlinear Science, UCSD/
Don't blame me, I voted for Emperor Mollari.
Ricardo Delima - Technology Office
>>>>> "orfali" == orfali <orf...@ricochet.net> writes:
Ok. I'll bite.
orfali> Jeff, you're absolutely right. RMI can be implemented on top of
orfali> IIOP. Netscape/Visigenic's Caffeine shows how much of this can be
orfali> done today (but it doesn't ship behavior around).
RMI ships behavior around.
orfali> It was obvious to many of us at JavaOne that RMI has a long way to
orfali> go before it's anywhere as complete as CORBA. For example, RMI must
orfali> implement/define persistent references, transactions, security, and
orfali> the list goes on. One of the reasons for the "whining" is that
orfali> nobody could get a date on when they would deliver all this
orfali> function. Yes, there are people at JavaSoft who are thinking about
orfali> putting RMI on top of IIOP. In the Java Enterprise session (by Shel
orfali> Finkelstein), CORBA/IIOP was mentioned as the preferred way to
orfali> implement Enterpise Beans. This is because Enterprise Beans use
orfali> the Java Transaction Service (JTS), which is based on CORBA OTS.
One of the most absurd aspects of any discussion involving RMI vs. CORBA
issues is the desire to treat the CORBA spec as the yard stick by which to
measure against RMI instead of just picking one of the various CORBA
implementations and doing so. The fallacy lies in that there is no such
thing as a complete implementation of the bloody aforementioned spec and we
all know that. RMI is part of the Java Core Language, it is in the JDK and
will be in all the 1.1 browsers. The same cannot be said about a 100% pure
java CORBA implementation.
orfali> If you need a pure Java solution today, my recommendation is to use
orfali> Visigenic/Netscape's Caffeine instead of RMI. RMI is a dead-end.
orfali> In the end, there will only be two ORBs: DCOM and CORBA/IIOP. There
orfali> is no room for RMI.
There is room for RMI for the simple fact that no current CORBA
implementation can do what RMI can do which is allow the movement of data
and behavior across remote JVMs. A Real Distributed Object Oriented
Technology.
orfali> BTW, I'm a great admirer of RMI--I think it's brilliant. However,
orfali> I want it on top of IIOP.
The dissonant sounds of "RMI is a dead-end" and "I'm a great admirer of
RMI" are still ringing in my ears. How about "I am a great admirer of
dead-end RMI" :-)
The crucial question here is WHY would you want to do that. What will RMI
gain from using IIOP as wire protocol? is this were those fictitious
CORBAservices that you seem to believe are ubiquitous come into play? Why
IIOP?
orfali> Today, I can get most of this from Caffeine. Eventually, OMG will
orfali> standardize the reverse language mappings. So I'll be able to get
orfali> this function from any CORBA ORB.
This is the second fallacy about your argument for RMI in top of
IIOP. Bob, "Eventually" doesn't cut it these days. RMI is here *now*, is
FREE, and is ubiquitous (because Java is).
I don't understand, I am obviously missing a key piece of information
here. What is this protocol jihad that most CORBA people seem to engage on?
There are clear boundaries in the capabilities and playing fields of RMI
(JVM to JVM) and CORBA (heterogeneous systems). There are even exceptions
to these rules. So why, why is it that some people find it impossible to
accept that there are things that CORBA cannot do, that there are places
where CORBA shouldn't be used. The RMI folk seem to perfectly be content
accepting that RMI is not appropriate for Heterogeneous Distributed
Computing.
ricardo
Jim Sharpe
Peter van der Linden wrote:
>
> Oh -- there's another way in which RMI wins against CORBA.
>
> RMI is free.
Has anyone reading this thread looked at ObjectSpace's Voyager?
It was just publically announced (April 2nd I or there abouts),
is also free, 100% pure Java, and on the surface seems both
more powerful than RMI and easier to use.
Comments?
p.s. I don't have any association with ObjectSpace other than
being very impressed with Voyager.
Bill Janssen
Bob, I've noticed that you often say "IIOP" when you mean "CORBA", as in
Eric, the point Jeff makes is that it can all be done on top of
IIOP, which will only help RMI's cause. Without IIOP, how will RMI
cross firewalls? How will it implement security, transactions,
You mean CORBA here, don't you? I only make the point because IIOP is
a pretty crufty RPC protocol, compared to TIRPC and DCE RPC; if I was a
CORBA proponent, I wouldn't brag about it. Its chief virtue is that it
(just barely) works.
Bill
--
Bill Janssen <jan...@parc.xerox.com> (415) 812-4763 FAX: (415) 812-4777
Xerox Palo Alto Research Center, 3333 Coyote Hill Rd, Palo Alto, CA 94304
URL: ftp://ftp.parc.xerox.com/pub/ilu/misc/janssen.html
Bill Janssen
Based on what I saw, though, there is no commecial CORBA implementation
today that can do some of the things that RMI does. CORBA is about
remote access to objects. RMI is about "networked" objects. In RMI,
I can pass an object from one Java VM to another across the network;
not just the state, but the actual CODE! This is, of course, due to the
architecture independence of the Java bytecode. If it is a complex
class, I can trace its entire inheritance tree to get every class
that contributes to the one I'm passing.
Most CORBA-style systems don't talk about that feature incessantly,
but do allow it. Why not brag about it? Because most CORBA system
implementors seem to have been around for a few years, and have lived
through many different `languages to end all languages'. They feel
that language-specific binding mechanisms don't actually work very
well in the real world.
orfali
Ricardo Delima - Technology Office wrote:
>RMI ships behavior around.
Ricardo, IMO you're asking for real trouble when you start shipping behavior around
inside method parameters--a la RMI. You're much better off shipping your classes
using signed JARs and digests, which are also part of JDK 1.1.
> One of the most absurd aspects of any discussion involving RMI vs. CORBA
> issues is the desire to treat the CORBA spec as the yard stick by which to
> measure against RMI instead of just picking one of the various CORBA
> implementations and doing so. The fallacy lies in that there is no such
> thing as a complete implementation of the bloody aforementioned spec and we
> all know that. RMI is part of the Java Core Language, it is in the JDK and
> will be in all the 1.1 browsers. The same cannot be said about a 100% pure
> java CORBA implementation.
I used VisiBroker for Java's Caffine as the example RMI must beat. Yes, it is
bundled in Netscape's browser and it is 100% pure.
> There is room for RMI for the simple fact that no current CORBA
> implementation can do what RMI can do which is allow the movement of data
> and behavior across remote JVMs. A Real Distributed Object Oriented
> Technology.
Like I said earlier, this feature introduces a lot of problems.
> The dissonant sounds of "RMI is a dead-end" and "I'm a great admirer of
> RMI" are still ringing in my ears. How about "I am a great admirer of
> dead-end RMI" :-)
You can admire something and still think it's a dead-end :-). I think you guys
at JavaSoft East did a wonderful job defining an ORB that was Java-friendly. However,
the commercial implementation of this ORB is Netscape/Visigenic's Caffeine. If
JavaSoft had bundled Caffeine with JDK 1.1 instead of Joe, RMI would be history. It
would have also been our best weapon against DCOM, which is the real competition.
BTW, I would never deploy RMI in a mission-critical application.
> The crucial question here is WHY would you want to do that. What will RMI
> gain from using IIOP as wire protocol? is this were those fictitious
> CORBAservices that you seem to believe are ubiquitous come into play? Why
> IIOP?
Here are just a few reasons why RMI on IIOP: 1) security and transactions are
built into the IIOP FAP, 2) IIOP will be supported by most firewalls (thanks to
Netscape and Iona), and 3) IIOP is an open protocol--even Microsoft had to put DCOM in
the open domain to play in the enterprise. In summary, if you want RMI to live and
prosper my advice to you is to build it on top of IIOP. Otherwise, you're dead meat.
If CORBA doesn't kill you DCOM will.
> orfali> Today, I can get most of this from Caffeine. Eventually, OMG will
> orfali> standardize the reverse language mappings. So I'll be able to get
> orfali> this function from any CORBA ORB.
>
> This is the second fallacy about your argument for RMI in top of
> IIOP. Bob, "Eventually" doesn't cut it these days. RMI is here *now*, is
> FREE, and is ubiquitous (because Java is).
OK, so Caffeine and VisiBroker are here today. BTW, I don't own stock in
Visigenic nor do I work for them. I just feel that it provides the
best choice for an RMI-like solution today on top of CORBA/IIOP.
> I don't understand, I am obviously missing a key piece of information
> here. What is this protocol jihad that most CORBA people seem to engage on?
> There are clear boundaries in the capabilities and playing fields of RMI
> (JVM to JVM) and CORBA (heterogeneous systems). There are even exceptions
> to these rules. So why, why is it that some people find it impossible to
> accept that there are things that CORBA cannot do, that there are places
> where CORBA shouldn't be used. The RMI folk seem to perfectly be content
> accepting that RMI is not appropriate for Heterogeneous Distributed
> Computing.
Ricardo, we could happily have come to a compromise if DCOM wasn't breathing
down our necks. Java and CORBA are our last chance. We can't afford to blow this
one. There is no room for Unix-like compromises (and splinters). We need to put out
the best technology and stick to it. JavaSoft is confusing the industry with two
naming services--JNDI and CORBA COS. And two ORBs--CORBA and RMI. What's next?
JavaSoft doesn't have the resources to re-invent CORBA. If you have extra resources,
give us some Bean containers. The best compromise is for JavaSoft to define the
portable object platform and for OMG to define the distributed object
infrastructure. By stepping into OMG's turf you will alienate your natural
alies--Oracle, Netscape, IBM, SunSoft, Novell, etc. If you insist on taking an NIH
attitude towards IIOP, you risk losing the whole Enchilada. Hey, if we wanted rule by
diktat we would go to Microsoft. In distributed object systems "open means CORBA."
Why don't you push your ideas through the OMG?
Bob Orfali