SOAP (nor XML-RPC) will not scale as well as IIOP used by Corba, simply because it's human readable. It consumes more bandwidth and is much more difficult to parse. I agree that It's nice for toy appliacations.
The argument that port 80 is already open on most firewalls, is really silly. If everybody does some kind of RPC over it, soon there will be closed to not allow arbitrary calls.
Use Corba ! There is no other way in your enviroment at the moment. I can recommend Orbacus (http://www.ooc.com). It's fast AND stable AND comes with source code.
You may also have a look at Smalltalk. It's at least as crossplatform as Java and probably still more mature. I can recommend Visualworks now available from CinCom (www.cincom.com). They also have Corba support.
It' a really great book. I'm wondering why it got 9 and not 10 points.
It also shows how much C++ complicates things because of the missing garbage collector and how complicated it is to use dynamic invocation with this static language.
Is Sun going to release the source..?
on
HotSpot arrives
·
· Score: 1
As far as I know they are not going to release the source. There are papers about dynamic optimization on the self web site. As far as I know the self source code is available. The hard thing to do is to get to an practical implementation that doesn't consume too much memory. Memory consumption was one of the problems with Self. Also a solution that is easy to retarget to different platforms is probably also a hard thing to do because processors are so different today (Pentium versus Risc).
Is's frustratring to see that many C++ programmers seems not to have any idea about how modern garbage collectors work.
C++ is not designed to use Garbage collection, because the collector has no reliable way to find out if something is a pointer or not. Therefore only conservative, non-copying collectors can be used with C++ unless one accepts very stringent restrictions.
With modern GC's that have a copy phase the time for a GC cycle only depends on the on the number of remaining objects. The garbage is just left behind. This clearly shows that the GC can be faster than a simple straightforward C++ solution, that depends on the number of objects allocated, which is usally much bigger.
Also keep in mind that the GC may run in an idle phase of the application and therefore the response time that the user sees could be better than if the memory would be deallocated immediately.
Slashdot Mirror
SOAP (nor XML-RPC) will not scale as well as
IIOP used by Corba, simply because it's human
readable. It consumes more bandwidth and is
much more difficult to parse. I agree that It's nice for toy appliacations.
The argument that port 80 is already open on most firewalls, is really silly. If everybody does some
kind of RPC over it, soon there will be closed to not allow arbitrary calls.
Correct.
But you should't use vendor specific extensions
to Corba, which is not easy to achieve than you might think.
Expect XML-RPC to be much slower than
Corba. Since its human readable it requires
a more complicated parser and it needs more
bandwidth.
Use Corba !
There is no other way in your enviroment at the moment.
I can recommend Orbacus (http://www.ooc.com).
It's fast AND stable AND comes with source code.
You may also have a look at Smalltalk. It's
at least as crossplatform as Java and probably
still more mature. I can recommend Visualworks
now available from CinCom (www.cincom.com).
They also have Corba support.
It' a really great book. I'm wondering why
it got 9 and not 10 points.
It also shows how much C++ complicates things
because of the missing garbage collector and
how complicated it is to use dynamic
invocation with this static language.
As far as I know they are not going to release
the source. There are papers about dynamic
optimization on the self web site. As far as I know the self source code is available. The hard
thing to do is to get to an practical implementation that doesn't consume too much memory. Memory consumption was one of the problems with Self. Also a solution that is easy to retarget to different platforms is probably also
a hard thing to do because processors are so different today (Pentium versus Risc).
Is's frustratring to see that many C++ programmers
seems not to have any idea about how modern
garbage collectors work.
C++ is not designed to use Garbage collection,
because the collector has no reliable way to find
out if something is a pointer or not. Therefore
only conservative, non-copying collectors can be
used with C++ unless one accepts very stringent
restrictions.
With modern GC's that have a copy phase the time for a GC cycle only depends on the on the number
of remaining objects. The garbage is just left behind. This clearly shows that the GC can be
faster than a simple straightforward C++ solution,
that depends on the number of objects allocated, which is usally much bigger.
Also keep in mind that the GC may run in an idle
phase of the application and therefore the response time that the user sees could be better than if the memory would be deallocated immediately.