What is the weakness of CORBA?
Kelvin
I am doing a research on the existing distributed technologies, Corba,
DCOM, RMI, CGI, for my thesis paper.
It seems that Corba is really good. Does it have weakness? Things that
you guys don't like about Corba?
Like cost ($$$), learning curve, functionality, etc??? Any feedback is
appreciated. I need you guys help since I am not a Corba expect!
Kelvin
Thaddeus L. Olczyk
wrote:
Corba runs in a heterogenous enviroment. This almost certainly ensures
that at least one part of a Corba system runs on a platform running a
Microsoft operating system. This is a major defect.
Marc Girod
Ke> It seems that Corba is really good. Does it have weakness? Things
Ke> that you guys don't like about Corba?
CORBA calls are based on RPC, which are synchronous.
Because of this, the client expects to wait for the return of its call,
from an abstract point of view, i.e. this is built in the interface
semantics.
The price is that the round-trip cannot be factored away while
composing functionality. It results that fine-grained interfaces clash
with scalability.
This is a big penalty, albeit well shared with the competion.
Best Regards!
Marc
--
Marc Girod P.O. Box 320 Voice: +358-9-511 23746
Nokia Networks 00045 NOKIA Group Mobile: +358-40-569 7954
Hiomo 5/1 Finland Fax: +358-9-511 23580
Steve Vinoski
news:1y4s7cw...@sirion.ntc.nokia.com...
> >>>>> "Ke" == Kelvin <esc...@vividnet.com> writes:
>
> Ke> It seems that Corba is really good. Does it have weakness? Things
> Ke> that you guys don't like about Corba?
>
> CORBA calls are based on RPC, which are synchronous.
> Because of this, the client expects to wait for the return of its call,
> from an abstract point of view, i.e. this is built in the interface
> semantics.
>
> The price is that the round-trip cannot be factored away while
> composing functionality. It results that fine-grained interfaces clash
> with scalability.
This is a criticism that has been fairly leveled at CORBA for quite awhile,
but one that won't last much longer. The CORBA Messaging service now
provides for asynchronous messaging, varying qualities of service, and
time-independent invocation (store and forward routing), ala
message-oriented middleware. See the relevant C++ Report columns by Doug
Schmidt and me at http://www.iona.com/hyplan/vinoski . Orbix 2000 already
implements some parts of CORBA Messaging, and I believe both ORBacus and TAO
either already do so as well, or are very near doing so.
--steve
--
Steve Vinoski vinoski at iona.com
Chief Architect 1-800-ORBIX-4U
IONA Technologies, Inc. Waltham, MA USA 02451
200 West St. http://www.iona.com/hyplan/vinoski/
Copyright 2000 Stephen B. Vinoski. All Rights Reserved.
Kelvin
>>eryone,
>> I am doing a research on the existing distributed technologies, Corba,
>>DCOM, RMI, CGI, for my thesis paper.
>>you guys don't like about Corba?
is
>>appreciated. I need you guys help since I am not a Corba expect!
>>
>>Kelvin
>>
>
>Corba runs in a heterogenous enviroment. This almost certainly ensures
>that at least one part of a Corba system runs on a platform running a
>Microsoft operating system. This is a major defect.
So you meant one of the platform has to be Microsoft OS? Corba cannot run
in a homogenous enivironment, such as all Unix?
Steven Collins
"Kelvin" <esc...@vividnet.com> wrote in message
news:8h8sgg$st2$1...@kellogg.csupomona.net...
> >Corba runs in a heterogenous enviroment. This almost certainly ensures
> >that at least one part of a Corba system runs on a platform running a
> >Microsoft operating system. This is a major defect.
>
>
> So you meant one of the platform has to be Microsoft OS? Corba cannot run
> in a homogenous enivironment, such as all Unix?
>
No Kelvin, he is saying that anything that by design is allowed to run on a
Microsoft OS (heterogenous enviroment) has a defect because it will almost
certainly be run on a Microsoft OS. 8^).
Chris Hafey
"Kelvin" <esc...@vividnet.com> wrote:
> Hi everyone,
> I am doing a research on the existing distributed technologies,
Corba,
> DCOM, RMI, CGI, for my thesis paper.
> It seems that Corba is really good. Does it have weakness?
Things that
> you guys don't like about Corba?
> Like cost ($$$), learning curve, functionality, etc??? Any
feedback is
> appreciated. I need you guys help since I am not a Corba expect!
There are several freely available ORBs, so cost is only an issue if
you must use a specific ORB. The learning curve is steep, but I think
distributed programming is hard to begin with, so this isn't CORBA's
fault. CORBA will make it easier, but you must have a firm grasp of
OO, Design Patterns and networking to begin with. Functionally, CORBA
is very good for integrating different systems especially at the
enterprise level. I do have some issues though:
*) IIOP does not handle firewalls or network address translation. The
simplest example is where a server needs to invoke a callback method on
a client that is behind a firewall (typical internet scenario). This
is currently impossible because IIOP only allows invocations in one
direction (from originator to destination). Bidirectional IIOP is
supposed to fix this, but the specification is still being worked on
which means it will not be widely available for some time. This is a
serious issue for anyone that has to deploy an internet application or
has internal NAT/firewalls to deal with. Note that the DCOM/RMI may
have this same issue.
*) CORBA is not a complete component solution. Since CORBA isn't well
suited to GUI components, you will usually end up mixing CORBA with
some other GUI component architecture (COM or Java Beans) on the client
side. Also, there are few (if any) off the shelf CORBA components.
This means that implementing CORBA applications often requires more
work than other solutions. This is especially true when it comes to
persistence.
Chris Hafey
Sent via Deja.com http://www.deja.com/
Before you buy.
Douglas C. Schmidt
>> CORBA calls are based on RPC, which are synchronous.
RPC calls may have been synchronous (actually, even this isn't really
true for Sun RPC). However, CORBA calls can be either synchronous or
asynchronous.
>> Because of this, the client expects to wait for the return of its call,
>> from an abstract point of view, i.e. this is built in the interface
>> semantics.
No, that information is "out-of-date." While your "grandfather's
CORBA" may have worked this way, today's CORBA does not.
>> The price is that the round-trip cannot be factored away while
>> composing functionality. It results that fine-grained interfaces
>> clash with scalability.
That's incorrect.
>> This is a big penalty, albeit well shared with the competion.
Nope, your informationn is out of date. Please see
http://www.cs.wustl.edu/~schmidt/C++-report-col15.ps.gz
http://www.cs.wustl.edu/~schmidt/C++-report-col16.ps.gz
http://www.cs.wustl.edu/~schmidt/C++-report-col17.ps.gz
http://www.cs.wustl.edu/~schmidt/C++-report-col19.ps.gz
for a series of articles that Steve Vinoski and I wrote about CORBA
support for asynchronous method invocations (AMI), time-independent
invocations (TII), and the CORBA quality of service (QoS) policy
framework. As Steve Vinoski mentioned, many of these features are
available in Orbix2000, TAO, and other ORBs.
To find out how AMI is implemented in TAO, please see
http://www.cs.wustl.edu/~schmidt/ami1.ps.gz
http://www.cs.wustl.edu/~schmidt/ami2.ps.gz
The latter paper has some performance experiments that demonstrate the
performance boost of AMI. In addition, please see
http://www.cs.wustl.edu/~schmidt/RTAS00.ps.gz
for even more information on how to improve ORB performance via
buffering of one-way and AMI two-way calls, as well as the performance
of so-called "reliable one-ways," which are yet another interesting
feature added to CORBA recently.
Thanks,
Doug
--
Dr. Douglas C. Schmidt, Associate Professor TEL: (949) 824-1901
Dept of Electrical & Computer Engineering FAX: (949) 824-2321
616E Engineering Tower WEB: www.ece.uci.edu/~schmidt/
University of California, Irvine, 92697-2625 NET: sch...@uci.edu
Andy Bolstridge
people more interested in telling you about their evangelism than in telling
you anything useful.
To answer your question... its not a simple question that can be answered.
It depends on what you want to do.
I think the general consensus about CORBA is that it is difficult to learn
how to use, it can have a high learning curve too (but these things are true
of most complex technologies). Naturally, if it important that it be easy to
use, you're better off with Java/RMI or VB/DCOM. depends.
That said, I have seen posts where people claim CORBA is easy to use (where
they make reference to COM programming...)
What else.. CORBA is designed for distributed system first, and local,
in-proc second. Some implementations make this a disadvantage.
CORBA doesn't have any mechanism for keeping track of remote objects (I'm
thinking of ditributed reference counting, or heartbeats)(except that the
fault-tolerant spec adds these). But.. you should be able to implement these
yourself - bt again, thats a bit tricky if you want something that does all
you want out of the box, nice and easily.
The CORBA spec is just that - a spec, with wooly bits. This means that some
implementations do it differently, so you end up programming using one or
another CORBA implementation and not many of them. (In my experience, that
is). However, once you've got past the core of the spec, the services can be
written and sold by any company so you can pick and choose some services
that are better written than others.
Some services are slow in comparison to other technologies - but this
depends on how you use them for particular requirements.
Bit of a ramble, but I hope it helps.
Cheers, Andy.
Jun Nolasco
"COM and CORBA, Side by Side" by Jason Pritchard
Jun Nolasco
Kelvin wrote:
>
> Hi everyone,
> I am doing a research on the existing distributed technologies, Corba,
> DCOM, RMI, CGI, for my thesis paper.
> It seems that Corba is really good. Does it have weakness? Things that
> you guys don't like about Corba?
> Like cost ($$$), learning curve, functionality, etc??? Any feedback is
> appreciated. I need you guys help since I am not a Corba expect!
>
> Kelvin
kelvin
Two words....
Persistence bites
(of objects(servants) not object references)
-Kelvin
Marc Girod
I have read your articles, as well as Steve and Michi's book, and I
roughly know about asynchronous support in CORBA.
My critique was not about performance, nor even about synchrony at the
low-level. It was about the semantics of interfaces, the means to
ensure serialization of behaviour and their price, and the support for
scopes: IDL interfaces are not suitable to build composable
components.
What I witness now, is the move towards coarse-grained, non
composable, components in the EJB style. I believe they break the
open-closed principle, and show thus a move backwards from
object-orientation.
I think this is motivated by a wide-spread belief that exposing
fine-grained interfaces has failed.
Douglas C. Schmidt
>> My critique was not about performance, nor even about synchrony at
>> the low-level. It was about the semantics of interfaces, the means
>> to ensure serialization of behaviour and their price, and the
>> support for scopes: IDL interfaces are not suitable to build
>> composable components.
I have no idea what you mean by this. Can you please be more
specific? A small example would help to clarify your point.
>> What I witness now, is the move towards coarse-grained, non
>> composable, components in the EJB style. I believe they break the
>> open-closed principle, and show thus a move backwards from
>> object-orientation.
I won't argue with you about this because I agree with you in general.
However, I think the motivation for breaking the open-closed principle
is rooted more in the "pragmatics" of real-world component design than
it is in any particularly good "paradigm" for design.
>> I think this is motivated by a wide-spread belief that exposing
>> fine-grained interfaces has failed.
That statement doesn't make any sense to me -- and it doesn't ring
"true" to me either. Can you please be more specific here, as well?
Philip Lijnzaad
Kelvin> Hi everyone,
Kelvin> I am doing a research on the existing distributed technologies, Corba,
Kelvin> DCOM, RMI, CGI, for my thesis paper.
Read Orfali & Harkey: "Client/Server Programming with Java and CORBA", 2nd
edition (Wiley). They have extensive comparisons among the technologies you
mention.
Philip
--
/dev/brain: character special (53/0)
-----------------------------------------------------------------------------
Philip Lijnzaad, lijn...@ebi.ac.uk \ European Bioinformatics Institute,rm A2-24
+44 (0)1223 49 4639 / Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) \ Cambridgeshire CB10 1SD, GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53
Srdjan Stakic
>
> Kelvin> Hi everyone,
> Kelvin> I am doing a research on the existing distributed technologies, Corba,
> Kelvin> DCOM, RMI, CGI, for my thesis paper.
>
> Read Orfali & Harkey: "Client/Server Programming with Java and CORBA", 2nd
> edition (Wiley). They have extensive comparisons among the technologies you
> mention.
It's too light, but might be good for starters. To make a good comparison,
take some simple example problem, and implement solutions by using all major
technologies (well, 5-6) of them. By the time you finnish, you'll have most
of the answers.
Robert O'Dowd
>
> Kelvin> Hi everyone,
> Kelvin> I am doing a research on the existing distributed technologies, Corba,
> Kelvin> DCOM, RMI, CGI, for my thesis paper.
>
> Read Orfali & Harkey: "Client/Server Programming with Java and CORBA", 2nd
> edition (Wiley). They have extensive comparisons among the technologies you
> mention.
>
I don't know that book specifically, but I have found that a number of
books and papers in the same category start with an assumption that
one of the technologies is inherently better than the others.
For example, if you start with an assumption that "Java is the
most elegant programming language for client/server programming"
or (alternatively) that "<name your technology> is best" it is
fairly easy to make a case to support your position. It is actually
difficult for authors to objectively compare the technologies because
all are human, and have knowledge/experience/preconceptions.
The reality (at least, my reality :-) is that ALL distributed
technologies have strengths and weaknesses. Looking at comparisons
between CORBA and other technologies is complicated by the fact that
it is programming language neutral and not all of the alternatives are.
And any comparison between the technologies in the context of one
programming language will be influenced by the authors
knowledge/experience/affection related to that programming language.
Michi Henning
> To make a good comparison,
> take some simple example problem, and implement solutions by using all major
> technologies (well, 5-6) of them. By the time you finnish, you'll have most
> of the answers.
Gee, that's nice 'n' easy -- I'll report back to you in about two years ;-)
And, besides, there are no weaknesses in CORBA, so there! ;-)
Cheers,
Michi.
--
Michi Henning +61 7 3891 5744
Object Oriented Concepts +61 4 1118 2700 (mobile)
Suite 4, 904 Stanley St +61 7 3891 5009 (fax)
East Brisbane 4169 mi...@ooc.com.au
AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html
Philip Lijnzaad
Robert> Philip Lijnzaad wrote:
>>
Kelvin> Hi everyone,
Kelvin> I am doing a research on the existing distributed technologies, Corba,
Kelvin> DCOM, RMI, CGI, for my thesis paper.
>>
>> Read Orfali & Harkey: "Client/Server Programming with Java and CORBA", 2nd
>> edition (Wiley). They have extensive comparisons among the technologies you
>> mention.
>>
Robert> I don't know that book specifically,
on the whole, I think it is well balanced. They don't seem to be too partial
to Java, although some of Java's strenghts clearly shine through.
Robert> but I have found that a number of books and papers in the same
Robert> category start with an assumption that one of the technologies is
Robert> inherently better than the others.
yes, this is always a risk, and you can only judge by not just knowing _all_
the technologies, but having experience with _all_ of them. This is not
really an option.
On a more philosophical note, it is plainly impossible to avoid bias when
you're writing a book, especially in a fast developing area as Internet-wide
distributed computing. To think you would be able to is a bit naive. The
best you can hope for is that the writer is explicit about his biases, and I
find that Orfali and Harkey are.
Robert> The reality (at least, my reality :-) is that ALL distributed
Robert> technologies have strengths and weaknesses.
yes, but some more than others for a given application area, or even for a
combination of application areas. For most distributed systems, cgi-bin,
sockets and RMI just don't cut it, for instance.
Robert> Looking at comparisons between CORBA and other technologies is
Robert> complicated by the fact that it is programming language neutral and
Robert> not all of the alternatives are.
CORBA, sockets, and cgi-bin are, and I suppose DCOM is (or could be)
too. So only RPC and RMI are not.
Robert> And any comparison between the
Robert> technologies in the context of one programming language will be
Robert> influenced by the authors knowledge/experience/affection related to
Robert> that programming language.
yes yes yes, this is clear. But if you're a newbie and you are faced with a
distributed computing problem, where do you start? Starting with all
technologies at the same time? Great if you got the time and money. But
usually you have choose, one way or another. I think reading a few books and
consulting a newsgroup like this one is about the best you can do in this
respect.
Philip
--
Is your dog vegetarian too?
Philip Lijnzaad
Robert> The reality (at least, my reality :-) is that ALL distributed
Robert> technologies have strengths and weaknesses.
Philip> yes, but some more than others for a given application area, or even
Philip> for a combination of application areas. For most distributed systems,
Philip> cgi-bin, sockets and RMI just don't cut it, for instance.
Oops, mega typo: I of course meant RPC, not RMI here:
For most distributed systems, cgi-bin, sockets and RPC just don't cut it, for
instance.
(silly TLAs)
Ensar Gul
I recently ported an application developed in pure Java and sockets to Corba
based system and I found out
that you can not send objects easily in Corba. In the object oriented world of
Java, methods return objects and you pass around objects via sockets using
object serilalization mechanism. Even though new Corba specs includes sending
objects by value not all ORB support this.
--
Ensar Gul
Alcatel
email: ens...@se.bel.alcatel.be
phone: +32 3 241 5963 Alcanet: 605 5963
Douglas C. Schmidt
>> 1.
>> Let's suppose I have two functions foo() and bar(), each involving
>> remote access of a resource (server). Because of the logical synchrony
>> of the procedure call metaphor,
It sounds to me like you are restricting this statement to two-way
synchronous method invocations (SMI), right?
>> composing them (at the client side) into a "higher level" foobar()
>> function which will apply them in sequence involves an overhead
>> with respect to implementing the modification in the server.
That claim is only correct if you use two-way SMI calls for foo() and
bar(). If you use two-way asynchronous method invocations (AMI)
calls, however, there need be no "logical synchrony". Moreover, good
ORBs can do all sorts of interesting "latency hiding" optimizations of
two-way AMI calls, e.g., buffer them, in order to decouple the logical
and physical aspects of invocations.
Please see the discussions in
http://www.cs.wustl.edu/~schmidt/ami2.ps.gz
for more information and benchmarks results.
>> 2.
>> For composition to be practical, the effort requested must be
>> proportional to the incremental advantage expected from the
>> composition. It must be possible to abstract the mass of the existing
>> functionality built upon at a bounded cost. This cost can be bounded
>> only if the representation is static (doesn't depend on something yet
>> unknown).
>>
>> Typing is the most powerful means commonly used to encode such static
>> information. Yet it traditionally relies upon scopes, and scopes often
>> implicitly bound to sequential procedure calls.
>>
>> Genericity and of access control also are secondary means to respect
>> the "staticness" of information presented through typing.
This is an interesting claim, but I don't see how it relates to
pros/cons of CORBA. Can you please clarify this, perhaps with a
concrete example?
>> Did I make some progress in presenting my claim?
I don't understand point #2 so I'll withhold judgement until you
clarify it. As for point #1, I don't think you are considering the
CORBA AMI capabilities so your criticism doesn't seem valid. Perhaps
you could clarify this further in the context of AMI, rather than SMI.
Thaddeus L Olczyk
wrote:
>Ensar Gul wrote:
>>
>> Kelvin wrote:
>>
>> I recently ported an application developed in pure Java and sockets to Corba
>> based system and I found out
>> that you can not send objects easily in Corba. In the object oriented world of
>> Java,
>
>CORBA is as object oriented as Java(tm), as far as I can see. Is there
>any particular aspect of OO that Java(tm) supports and CORBA does not?
>
>> methods return objects and you pass around objects via sockets using
>> object serilalization mechanism.
>
>If you were happy to send Java(tm) object implementation byte codes via
>sockets, then why didn't you send object implementation byte codes via,
>say, a sequence of octets with CORBA?
>
>Of course, if you code in Perl or Python, you can go one better and send
>object implementation source as sequences of characters. And you get to
>leverage the far more powerful OO support in both languages, if that's
>the kind of thing that you're interested in.
>
Don't these "agents" have a name-- worm!
Jim Melton
Marc Girod wrote:
> I consider requirements to be met for components to be "composable" in
> a practical sense. I claim that CORBA is weak on at least two:
>
> 1. Due to the procedure call metaphor, some critical aspects of
> physical message passing cannot be decoupled from the logical ones.
> 2. Too few information may be represented statically to build
> efficient layers
>
> 1.
> Let's suppose I have two functions foo() and bar(), each involving
> remote access of a resource (server). Because of the logical synchrony
> of the procedure call metaphor, composing them (at the client side)
> into a "higher level" foobar() function which will apply them in
> sequence involves an overhead with respect to implementing the
> modification in the server.
It seems to me that this is not a criticism of CORBA per se, but rather of
client/server programming in general. Are you arguing that composition of
the client calls into a client-side foobar() method should automatically
be as efficient as a foobar() server method? Why would you think that to
be true?
Take the orb out of the loop. If I have a class that supports foo() and
bar() methods and a user of that class wants to compose them to a new
method foobar(), it is completely free to do so. However, if there were an
optimization in the implementation that could be achieved by implementing
foobar() natively, my client would not see it.
I'd suggest that implementing a foobar() method in a CORBA servant is no
more complex than implementing one in a native OO language.
One thing that cannot be ignored by system architects is where the network
boundaries are placed. While it is theoretically possible for every object
to be a CORBA object, simple reason demands that the low bandwidth of the
network not be placed in the critical path. Performance optimization is
simply a matter of identifying the bottlenecks and reducing them. Remote
object access can be a bottleneck that could be eliminated in some cases
by making the object local.
I guess I'm with everyone else, and I really don't understand what your
true objections are.
Douglas C. Schmidt
>> One thing that cannot be ignored by system architects is where the
>> network boundaries are placed. While it is theoretically possible
>> for every object to be a CORBA object, simple reason demands that
>> the low bandwidth of the network not be placed in the critical
>> path. Performance optimization is simply a matter of identifying
>> the bottlenecks and reducing them. Remote object access can be a
>> bottleneck that could be eliminated in some cases by making the
>> object local.
Collocation is certainly one solution. Transforming the overall
application programming model from a synchronous two-way approach to
an asynchronous two-way approach is another solution, as per my
earlier email. This requires knowledge of more sophisticated
patterns, such as Proactor and Asynchronous Completion Token.
However, these patterns aren't hard to apply once they are understood.
>> I guess I'm with everyone else, and I really don't understand what your
>> true objections are.
Right, I agree. Marc, perhaps it would be easier to make your point
if you could show a brief example and illustrate how non-CORBA
solutions could solve it better than a CORBA solution.
Steinar Bang
> Hi Marc,
>>> My critique was not about performance, nor even about synchrony at
>>> the low-level. It was about the semantics of interfaces, the means
>>> to ensure serialization of behaviour and their price, and the
>>> support for scopes: IDL interfaces are not suitable to build
>>> composable components.
> I have no idea what you mean by this. Can you please be more
> specific? A small example would help to clarify your point.
Fresco
http://www.iuk.tu-harburg.de/fresco/
designed its GUI components from flyweight primitives, using object
factories called kits.
It's descendant Berlin
http://www.berlin-consortium.org/
takes that one step further and implements real CORBA IIOP support,
with the factories and their resulting objects both residing on the
display server.
Hm... this is actually an example of building composable components,
by using IDL interfaces...:-)
However, I do not know if the individual primitives building up the
components created in the kits are actually fully blown CORBA objects
(although in Fresco they were... as far as Fresco's CORBA support
went, that is).
Marc Girod
DS> It sounds to me like you are restricting this statement to two-way
DS> synchronous method invocations (SMI), right?
You are right. From your paper, I must admit that I had overlooked
AMI, and that it does address my concern. Congratulations.
DS> Moreover, good ORBs can do all sorts of interesting "latency
DS> hiding" optimizations of two-way AMI calls, e.g., buffer them, in
DS> order to decouple the logical and physical aspects of invocations.
I have to understand this better. I wouldn't want to rely upon the
quality of implementation of the ORBS, but on a specified behaviour. I
cannot say at this point whether I can or not code this.
DS> This is an interesting claim, but I don't see how it relates to
DS> pros/cons of CORBA. Can you please clarify this, perhaps with a
DS> concrete example?
I'll try... later.
Thanks!
Douglas C. Schmidt
>> You are right. From your paper, I must admit that I had overlooked
>> AMI, and that it does address my concern. Congratulations.
Great!
>> I have to understand this better. I wouldn't want to rely upon the
>> quality of implementation of the ORBS, but on a specified
>> behaviour.
At this point, the CORBA Messaging specification doesn't define
explicitly policies to manage AMI or reliable one-way buffering
strategies. However, it's something worth considering if you're
planning to lobby the OMG for enhancements to these specs.
>> I cannot say at this point whether I can or not code this.
You might check out
$TAO_ROOT/tests/Buffered_AMI/
$TAO_ROOT/tests/Buffered_Oneways/
in the TAO release at www.cs.wustl.edu/~schmidt/TAO.html to see how
TAO implements buffering policies.
>> I'll try... later.
Sounds good -- I look forward to further discussions.
Derek Thomson
>
> Two words....
>
> Persistence bites
>
> (of objects(servants) not object references)
Why? Compared to what, exactly?
Persistifying a servant (an interface implementation) is the domain of the
implementation language, surely?
If your implementation is expressed in Python (with, say Fnorb
[http://www.fnorb.org]), then persistifying it is obviously a no-op.
If it's in Java, then it's a little trickier, but it's supposedly do-able with
all that serialization stuff. That's the theory, at least. Of course YMWV
depending on how much stress was on the Sun or IBM Java coders when they coded
the serialization that attempts to handle your particular class structure.
If it's C++, or C, then you've got to code it yourself. But that's the way it
has always been with these languages. The runtime environment contains no
information about the structure of the classes. What you could do, though, is
define the servant's state with an IDL struct, and, when the time comes, copy
the state into the struct and convert it into a sequence of octets with the
standard CORBA Codec interface. There, that's as easy as the Java case. Now I
think about it, that approach could come in quite handy when the Java
serialization implementation handles a particular case less than perfectly.
Regards,
Derek
Derek Thomson
Yes, but the same problem applies to sending Java bytecodes around. You have to
have the security in place as appropriate to ensure that you are not going to
execute untrusted code. It's as simple as that. Java doesn't have any magic
solution here, I'm afraid (yet again).
Regards,
Derek.
Derek Thomson
>
> *) CORBA is not a complete component solution. Since CORBA isn't well
> suited to GUI components, you will usually end up mixing CORBA with
> some other GUI component architecture (COM or Java Beans) on the client
> side.
That's very odd. Gnome seems to use CORBA for this quite well. Or perhaps I am
imagining all the CORBA interfaces to the Gnome apps and applets that I use?
Perhaps they are all Java Beans in disguise? I mean, Beans are just everywhere
as Java on the client side has been so successful :)
[I'm not really as down on Java as that sounds. But it's awfully hard to forgive
the hype that we were all subjected to not long ago, and are expected to forget
- now that Sun have seen the light that Java is *server* side technology.
Please, pay no attention to that man behind the curtain ;)]
And yes, Gnome's not perfect, and it's use of CORBA probably isn't. But it's
early days yet, and we get to participate.
> Also, there are few (if any) off the shelf CORBA components.
Yes. I hope Gnome can help change that - there's nothing like a bit of interest
from a new problem domain. Not only for GUI components, but for the "hidden"
objects that GUIs talk to. It would be nice to have a few standard
(Gnome-standard, if not OMG-standard) interfaces floating about, wouldn't it?
> This means that implementing CORBA applications often requires more
> work than other solutions.
Why? Which other solutions? DCOM is unscalable, and RMI is only a valid choice
if you can do everything in Java, including the client-side, which we should
*not* do, according to Sun. And then there's proprietary lock in, which will
bite you if you use RMI and find out that the JVM doesn't work as well as
promised on some particular hardware or in a certain usage situation. If all the
interfaces are in CORBA IDL, you get to dump the broken technology and change to
something that works.
> This is especially true when it comes to
> persistence.
I don't think this is true. I answered this not long ago in this newsgroup. In
short, if you use Java to implement your servants, then surely it's at least as
good as Java?
Regards,
Derek.
Timothy Docker
Derek Thomson <de...@ooc.com.au> writes:
> if you can do everything in Java, including the client-side, which
> we should *not* do, according to Sun. And then there's proprietary
> lock in, which will bite you if you use RMI and find out that the
> JVM doesn't work as well as promised on some particular hardware or
> in a certain usage situation. If all the interfaces are in CORBA
> IDL, you get to dump the broken technology and change to something
> that works.
>
This *not* is fairly strongly worded. Is there a reference to this
change in approach from sun?
Tim Docker
Derek Thomson
The strong wording is a reflect of my anger with Sun :|
This has been the state of affairs since the abandonment of the Hotspot
optimization technology for GUI development.
Since then, I've not seen any visible effort to make Java GUIs feasible. No, I
can't find a reference, Sun wouldn't say this, they might want to go back and
fix it later. It's pretty obvious that they are not exactly pushing it, and it
doesn't look like it's going to be fixed any time soon.
Besides, there is currently no benefit in using Java for GUIs. Given the design
of the GUI APIs (for both AWT and Swing), it actually takes *longer* to produce
a GUI than for any other API that I've seen [okay, except Motif ;)]. It just
goes to show, library design is *everything*. I'd rather use GTK+ with C, than
Swing with Java!
And if I was concerned with portability, Python/TK and Perl/TK are far more
portable, look better, perform better, and have a good API.
Now I'm going to swing this back to CORBA at the same time saying something
positive about Java, and say the the Java CORBA binding is excellent! Again,
library/class design is important. It's a shame, because there is nothing that
was done in the Java mapping that could not be done (now) in the C++ mapping.
Sadly, the C++ mapping is heavily biased towards being an ARM C++ mapping.
Regards,
Derek.
Marc Girod
>>>>> "JM" == Jim Melton <Jim.M...@lmco.com> writes:
JM> Are you arguing that composition of the client calls into a
JM> client-side foobar() method should automatically be as efficient
JM> as a foobar() server method? Why would you think that to be true?
As soon as it doesn't stand, the system stops being scalable through
composition. This means that there is an upper boundary (in
complexity, size, whatever) above which applications are beyond the
reach of design through composition.
JM> I guess I'm with everyone else, and I really don't understand what
JM> your true objections are.
Do you mean you understand my false objections? Er... which ones?
I sort of understood that Doug understood this (first) objection of
mine...
Best Regards!
Douglas C. Schmidt
>> JM> Are you arguing that composition of the client calls into a
>> JM> client-side foobar() method should automatically be as efficient
>> JM> as a foobar() server method? Why would you think that to be true?
>>
>> As soon as it doesn't stand, the system stops being scalable
>> through composition. This means that there is an upper boundary (in
>> complexity, size, whatever) above which applications are beyond the
>> reach of design through composition.
I don't think that statement makes any sense given the extremely vague
way in which you've defined your terms. More importantly, what you
seem to be hinting at in your comments isn't an issue with CORBA
per-se, it's an issue related to composition in distributed computing
systems in general. Until you provide more details and candidate
solutions, however, it's hard to know precisely whether your claims
are valid.
>> I sort of understood that Doug understood this (first) objection of
>> mine...
I understood it, but I didn't agree with it ;-).
I think we're still waiting to get a lucid description of what you're
talking about, complete with concrete examples.
Jim Melton
Marc Girod wrote:
> Hello Jim,
>
> >>>>> "JM" == Jim Melton <Jim.M...@lmco.com> writes:
>
> JM> Are you arguing that composition of the client calls into a
> JM> client-side foobar() method should automatically be as efficient
> JM> as a foobar() server method? Why would you think that to be true?
>
> As soon as it doesn't stand, the system stops being scalable through
> composition. This means that there is an upper boundary (in
> complexity, size, whatever) above which applications are beyond the
> reach of design through composition.
Well, since you can't give us an example, I'll make one up that
illustrates what I think you might have been saying.
Function foo() invokes a remote (CORBA or not) operation A() as part of
its operation. Function bar() also invokes the remote operation A() as
part of its operation. It turns out that there is some commonality between
foo() and bar() and if re-written as foobar() one of the remote calls to
A() could be eliminated. This would be more efficient than simply
composing foo() and bar().
Note that this efficiency really has nothing to do with distributed
computing either. It's simply an optimization technique. Of course, remote
operations will ALWAYS be more expensive than local ones (with th