Slashdot Mirror
Corba language neutrality gone?
Linuk writes "Here's an interesting article, CORBA 3.0 POSTMORTEM, about the OMG's adoption of EJB as its eagerly awaited component spec. It argues that OMG has now given up on its vendor neutral and language independent pretentions. "
I don't entirely agree. UML is more than a way to 'draw your object model'. And as far as complexity goes, I think UML is way more complicated than Booch or OMT are/were.
But, as far as 'consistent lack of substance' goes for the object community, I think you're right on. I think that goes for more of the younger programmers who have all been indoctrinated into the Object Way. Seems like most of the people that call themselves object mentors, etc., talk a whole lot, and by the time they're done talking, the industry has passed them by without them getting anything done.
Yes
If EJB is adopted as a "standard" then I will have to agree that CORBA will become language-specific. This is really *BAD*!
Java is not the end! Tomorrow new languages could emerge from some research lab but it's usefulness will be hamper if we *LOCK* ourself to a language-specific standard.
We need a BINARY interface standard!!! Not a language-based interface.
Let's not let Sun corrupt CORBA for it's own selfish reasons! I am starting not to like Sun anymore.
Come on, C is not all that faster then C++ if you use it correctly.
And have a good, correct compiler (which is more of a problem).
p.s. How many compilers do we know of that have
bugs in (i.e. gcc2.7, gcc2.8, egcs1.0, egcs 1.1 etc.)
This whining about Microsoft is getting tiring. Microsoft has almost no presence in the Unix world, and the failure of Corba to take of on Unix has nothing whatsoever to do with Microsoft.
The first part of this, about the standardization of symbols and layouts for diagrams of electrical circuits, is correct. The conclusion drawn from that is not.
To quote a wise friend from long ago, "Hardware is just iron. Software is knowledge." You can't define a one-to-one correspondence between a symbol and a software component the way you can with resistors, op amps, Level 3 switches and so on. UML is a brave attempt to do so but still falters on semantics and only narrowly avoids the tarpit of overspecification.
-------
Java binaries are designed to be cross platform.
Across vendors.
What else is?
Tomorrow, when others are available, OMG will
work with them, if there is an OMG tomorrow.
We already have IIOP as a binary standard. Is there more to EJB than a standard set of IIOP-compatible interfaces we should use to talk to middleware?
With garbage collection, Java classes are much less likely to need finalizer methods, and they won't be causing dangling references. And if I allocate 1000 objects and free 900 of them, the manual memory manager has to do immediate bookkeeping for each of the 900 dead objects, while the garbage collector only cares about the 100 live objects and can do the work during idle time.
But then all your code (along with all the libraries you use!) has to be written with GC safety in mind. And a GC that has to deal with the dirty tricks C++ allows (like per-class allocators and pointers into the middle of objects) is inherently less efficient than one for a language in which all code is well-behaved.
Java is not the end! Tomorrow new languages could emerge from some research lab but it's usefulness will be hamper if we *LOCK* ourself to a language-specific standard.
Yes, for example, programs written in Dylan run faster and require only about 50% - 60% the lines of code as the equivalent Java program. Harlequin Dylan has CORBA bindings already.
It is true that the CORBA object model is sort of a least common denominator, but at least it is one more way for programs written in different languages to talk to each other.
AIUI, Dylan is a higher-level language that doesn't special-case primitive types and encourages slinging around closures and other powerful but hard-to-optimize idioms. Were they comparing a native Dylan compiler to a native Java compiler, or a portable Dylan bytecode interpreter to a JVM, or were they cooking their results?
Say, is international standard supported by hundreds of vendors suddenly vendor standard?
DCOM - M.S.
CORBA rest of the world.
I think you should look at Object Management Groups'homepage before you let something this stupid from you again.
What are you talking about?
I've heard enough of this nonsense.
C++ is _always_ faster than Java - in all circumstances.
C++ destructors only contain the minimum number of instructions required to clean up the object - often NO instructions are needed at all in trivial objects. In Java _everything_ is heap allocated, and through observation I commonly notice that Java consumes 4 to 8 times as much in use memory as the C++ algorithmic counterpart. Most C++ programs have a great percentage of objects created automatically (i.e., on the stack) so no significant memory freeing CPU time is incurred at all.
Obviously, the author of the previous remark has no significant C++ programming experience.
Not exactly, while things like a ICU, chip, etcetera, are not standardized them selves, how they are built is, in a way Software Languages are just like symbols, there is a Linux project out there that makes programming more symbolic, by allowing you to show source code in a more heirarchal manner.
I'm no hardware/electronic expert, but I think an example is a gate is almost like an if statement, so essentially designing a circuit is essentially like programming. Looking at it more abstractly like buying a prebuilt circuit board or components and putting them together to produce a functional product, is like buying various software libraries and components and putting them together to form a functional product.
I think they are the same if you examine it that way.
Roger, roger, roger...
Oh, yes, you can be sure that when ole roger pipes up he'll eventually be telling you how great COM+ and MTS is (and it isn't that bad) and how CORBA is shite. Well, screw you roger, because you've been bought and sold for whatever the current rate of exchange is for 30 pieces of silver.
Not so long ago you where the big CORBA booster, and then, quite suddenly, you switched to the MS camp - wonder why?
Some of the things that roger says is valid but the MS song he keeps singing is getting monotonous.
C-structs not flexible enough???
I don't know exactly what you mean by this, but I've seen code that uses structs and classes interchangably, and from my exprience if classes internal data structure are standard for all compilers then a C program could easily use a class as struct. So it would be nice if you explain, as I'm unsure to what you are refering to.
Free (some more, some less) CORBA implementations for C++: MICO, ORBit, ILU For Java: JacORB, ILU, JavaIDL (included in JDK 1.2) For Python: FNORB, ILU, SYLO
Don't forget OmniORB (C++) -http://www.uk.research.att.com/software.html
and ORBacus (C++/Java) - www.orbacus.com
Never say never, and never say always.
Working for NASA, we have to create GUI's that must recognize the system they are on and adapt to the windowing enviroment they are in. We had a C++ solution that took minutes to load due to the building of the windows from raw C++ code. With Java, we have window systems and the program with it up in seconds.
And when the Java program is threaded properly, we can match OR outperform a similar C program. The Java Virtual Machine (The REAL one, not the MS one) can free objects without a significance performance hit by 'lurking' in the background and recognizing dead objects. C++ has to have explicit calls.
Obviously, the author of the previous remark has no significant Java programming experience.
GTK+ is written in C (in an object oriented fashion), so I think it might be.
No
I feel your pain... got a lot of it myself...
The idea seems to be to spread your app out
over several processors and have the various
pieces coordinate and communicate by passing
messages through this mess of middleware called
CORBA(non-MS) or DCOM(MS). It combines OO
programming/design, networking, and distributed
systems in a swamp where the buzzwords swarm
like mosquitoes. It is supposedly the major
battleground for the software wars of the next
decade... The books I have found are completely
obtuse... and I have many years experience with
a variety of systems and languages...
aaaarrrrrrghhhhh!!!
Marx, Lenin & Stalin couldn't have put it
better!
True, CORBA is a standard, but every single vendor (okay, the 3 or 4 ORBs that I've used) all have proprietary extensions that lock you into their implementation. And, it's so hard to not use those extensions because standard CORBA just doesn't do what you want it to do.
Garbage collection only solves (if that) problems with memory. Destructors provide a more general mechanism for dealing with resource allocation/deallocation (locks, kernel objects, etc.)
I really, really agree.
a programmer nearing 40
NASA, blah blah blah...
C++ also has thread support via well known cross platform APIs such as ACE, RogueWave and ObjectSpace.
Your argument is tired and flawed. Everything you mentioned as a Java benefit is also equally applicable in the hands of a capable C++ programmer, with the only exception being is that C++ is an order of magnitude faster than Java.
I think it wouldn't be too hard to write a Java sort that runs faster than a bubble sort implemented in C++. :-P
Daniel
All Java container classes' element manipulation is mutex protected. This is expensive.
C++'s STL containers are not mutex protected. They are merely threadsafe. It is the responsibility of the code author to implement locking strategies at a higher level - if _required_ (most often is as the case it is not). Locking atomic elements in containers is generally not desirable anyway due to the fact that data consistancy often requires a higher level lock anyways to ensure coherency between sibling data structures.
Every object in Java is heap allocated, and is quite expensive to create/collect as result.
Even when you know when memory should be reclaimed you can only hint to the JVM to do so.
In C++ you explicity control all object memory (warts and all). You may employ custom memory allocators that best fits the pattern of specific object usage often yielding huge speed gains. Or, more simply, create transient objects on the stack where appropriate and cleanup is practically non-existant. In C++ you simply have more control over what's going on in your program.
Java has no notion of "const" which leads to the inefficient practice of creating a deep copy of often non-lightweight objects to return to the Java 3rd party library user "just in case". And no, garbage collection and "final" won't help you here.
Java/JVMs check every array reference to see if it out of bounds. C++ does not. This makes Java slower as result.
I'm not saying that C++ is as programmer friendly as Java, but just stating the fact that it is faster in program execution in the hands of equally proficient programmers. You can't have you cake and eat it too. You make a lot of compromises when you choose any language, and for Java, the compromise for having a programmer safety-net is that it happens to be slower in execution.
Its the only distributed protocol that matters at this point. CORBA and COM are meaningless in the long run and have already been overwhelmingly crushed into oblivion by HTTP. If you want to see where distribution is going, look at HTTP-NG, which encapuslates an object model.
He's right.
No.
Actually, you can say that about NT in general
"NT is fast"
No.
"NT is stable"
No.
"NT is secure"
No.
Dead wrong.
Read Paul Wilson's survey paper on garbage collection. C and C++ programs are. by necessity, structured around their data life cycles because you have to do memory management by hand. If you're not locked into that paradigm (because your language gives you garbage collection), you can often use more efficient algorithms which give you more asymptotic speed.
In C++ the constant factors may be lower, but in Java the order of complexity may be much much better.
That's not C++ with threads, just a proprietary thread library on top of C++. Your other libraries are almost certainly not threadsafe, since there's no standard way to make them so. Or worse, they might use a different proprietary thread library than you like, and then you're SOL.
You either have method source or you don't. "private:" only tells the compiler outside code isn't allowed to call that method (and allows some layout rearrangement) - its prototype is right there in the class definition either way.
RPC over HTTP is just silly. You want efficiency (headers in text that needs to be scanned? ugh) and security (which generally comes from TLS/SSL anyway, no matter how you frame the stream inside), not caching or content negotiation. The only handy HTTP feature is tunneling through firewalls, which is just abusing it as glorified TCP and gives security admins fits.
This is patently rediculous. If you have a terrible C++ compiler (like GNU c) then you can have poor performance due to that. But that's not C++'s fault, it's the compiler's. Try egcs. There's a very strong anti-C++ bias in GNU/Linux land and it's really disappointing.
To suggest that C++ is necessarily much slower than C, and about the same speed as Java, displays your total lack of experience with these languages. You use one poorly written or just plain huge program written in C++ and write off the entire language. Get some actual first hand experience with these technologies before spouting off this nonsense and continuing the stupid cult of C uber alles.
>There are well-known techniques for hoisting
>array bounds checks out of loops. This makes
>array bounds checking essentially free.
Unless you employ the loop forever until we
get an out of bounds exception "optimization"
instead of checking a high/low limit
which so many "expert" Java programming books
and programs advocate/implement because
it is faster in the current crop of Java JVMs.
In an ideal we world we could optimize any program
for days until we get just a handful of optimal
machine instructions. But we must program in
the present using current tools if we are ever
to get anything done, and we can't wait for
the ever-elusive gonna-be-released-real-soon-now mythical Java compiler/JIT that will lead us
to the path of truth.
C++ is a great application programming language.
I've been using it with UNIX for 7 years now.
And, no, I've never used MFC or a Microsoft
Visual C++ "wizard" either.
C++ can take advantage of garbage collection as equally well as Java if you choose to use a conservative garbage collector and choose to program in that style.
Even without GC, a well-crafted C++ program needn't copy data unnecessarily as much as any Java program.
Bad code is bad code whether it be in Java or C or whatever. Making general judgements based on trivial programming test cases is silly.
The article is completely wrong as it speculates from a press release about ejb interoperability.
Below is a copy of a post to comp.object.corba last week from an "OMG Public Relations Specialist".
[remove copy of previous post about death of CCM]
> I think that you are reading more into the press release than what is
> actually there. It has been apparent for a long time that the CORBA
> Component specification must be aligned with EJB to be successful, in
> particular for CORBA components written in Java.
>
> However, this does not mean that CORBA Components is being dropped, or
> that it won't have support for other languages besides Java. In fact,
> if the Components submitters proposed a Java-only solution, I expect it
> won't get adopted by the OMG.
Yes, Jon, reports of the CORBA Component Model's demise are greatly exaggerated.
Since this is the industry's only multi-language, multi-platform component model, getting it right is important and, yes, it is taking a while to complete. And you're right, a Java-only solution probably wouldn't make it through the OMG's process, since we know the success of the CORBA Component Model is dependent on interoperability regardless of language. The OMG is still 100% committed to adopting the CCM and making it a success. But the CCM really had nothing to do with the source of this confusion.
We invited prominent industry press and analysts to participate in our April 6 Technology Briefing, of which this press release was one part. Anybody here who wants to see or hear what was said should visit http://www.omg.org/news/pr99.html#ejb, where the full transcripts are available in written and audio form.
The objective of the Technology Briefing (which is part of a regular series of briefings we have planned to inform press and analysts about the OMG's work) was to clarify some of the misconceptions (especially that EJB is replacing CORBA) we have recently been encountering. We chose to focus the message in the area of application servers. We wanted to be sure our audience understood that Java/CORBA is *already* being used on the middle tier. The CCM will simply build on this existing market strength with support for other languages.
Ed Cobb, primary author of the CORBA Component Model, participated because BEA is a vendor of application servers and he is the best informed party in the area of components, which will eventually be a factor in this space. Sun participated because EJB is their product. Sun also helped to emphasize the strong link between CORBA and Java, a fact which they stated repeatedly. We have seen people in the past claim that this link did not exist, so the Sun presence helped us convey that correct message. And, while the CCM will extend the EJB programming model to support multiple languages and will define the integration between the EJB programming model and a supporting CORBA infrastructure, that wasn't the point of this call.
Journalists and analysts who actually articipated in the call did not get the message that the CCM is "dead". Some of these articipants included Dana Gardner from Infoworld, Eric Brown of Forrester Research, Roger Smith of Software Development, John Abbott of ComputerWire, Beth Gold-Bernstein of Hurwitz Group and Paul Harmon of Component Development Strategies. We also pre-briefed some analysts, including Karen Boucher of The Standish Group, Jim Kobielus of The Burton Group and Steve Garone of IDC. This is an impressive group of people who know their stuff and not one of them drew that mistaken conclusion from the call.
I invite qualified journalists and analysts to contact me if they are interested in finding out more about our Technology Briefing series. We haven't finalized the focus and date of the next Briefing yet but it will probably be in June. Unfortunately, we do need to limit participation in these calls only to qualified journalists and analysts.
The CCM is being reviewed by OMG's membership. I'd like to remind everyone that this is an open process, and encourage anyone who is interested to download and read the current draft and make their own minds up. It's available at http://www.omg.org/cgi-bin/doc?orbos/99-02-05. And, if you have suggestions or feedback, participate in the process and make sure you're heard.
I hope this clarifies the OMG's position- please feel free to contact me or anyone at the OMG if you still have concerns.
Chris Vander Rhodes
OMG Public Relations Specialist
chrisvr@omg.org
he does, but com is now his bread and butter
From a quick read through the responses to the article, it would
/. are implying, it
*appear* that its author, Roger Sessions, has a rather Microsoft-
centric viewpoint. Now that's fine as far as it goes. But when such
a person issues pronouncements about competing technologies, it does
rather call into question their assessments, does it not?
Put more bluntly: is this just FUD?
If it is FUD, as many of those posting comments to
is a remarkably feeble attempt. One would think that Microsoft's army
of apologists would have caught on by now. Consider: in a document
authored by one of Microsoft's engineers was this little gem: "Loosely
applied to the vernacular of the software industry, a product/process
is long-term credible if FUD tactics can not be used to combat it. OSS
is Long-Term Credible." (From the so-called "Halloween Documents".)
Now admittedly this quote was in the context of how Microsoft might
"deal with" OSS. But it was revealing in that strongly implies that
Microsoft does employ FUD tactics as a matter-of-course.
In spite of this, Mindcraft recently published the results of a Windows
NT vs. Linux performance test that was sponsored by Microsoft. And
from all evidence, it looks like the whole thing was ill-disguised
FUD.
Do we now have another "independent expert" trying a similar stunt?
Hasn't it yet occurred to Microsoft and its minions that the IT world
has caught on to them?
Do these people care so little for their reputations that they'll try
*anything* to push their Microsoft-centric viewpoint--no matter how
desperate?
You really have to wonder.
What he should have said is that the ratio is as follows
3/6 Visual Basic
2/6 Visual C++
1/12 Visual J++
Yes I work at NASA, that wasn't the point. I used an example from work to counter his sweeping suggestion. No, you cannot code a more efficient C++ solution with the example I gave. We have tried for 8 years!). Java has a generic lightweight windowing solution for all platforms: Swing. Hand coding examples of windows in C++ for various OS's is not my cup of tea, jolt, or an other substance you can throw at me. I can have my solution up and running in nearly 1/10th of the time in Java than in C++. (IN THE EXAMPLE I GAVE!)
Also my example was about saying *always*. It wasn't to say that C++ is never faster than Java. I just pointed out a solution that broke the stereotype. Want another? Try a really simple approach
BTW, Coding C++ for 6 years now. Working with Java because I want to. Nothing against C++, just trying to break some myths about Java.
It's really sad I was becoming a big fan of the vendor neutral standards too - you know that "rebel alliance" over the past 20 years or so: W3 Sun MIT Berkley - but it looks like Microsoft's IIS and COM and Active/X means MS Word documents will replace HTML/XML/SGML. TCP/IP is markedly inferior to NetBEUI so the writing's on the wall there too ...
Yup we'll all have to move over to MSN. It's too bad I'm actually rabidly anti M$ myself (really I am, trust me) but I've had to adjust.
Signed, Bob Fudspreader MS Certifed NT Expert
Yeah Bob I agree it really is too bad about the death of all those standards. The one I thought had so much promise was SMIL - I was rootin' for it but now it's totally dead. Microsoft's figured it out: with only one vendor you don't *need* standards. Besides if everyone in the world runs Windows200o with MSMultiMedia the multi-media experience will be much superior to SMIL based distributed client server multimedia applications. It's too bad.
Too bad too that Apache is so much slower than IIS as those independent tests showed too. I really was anti MS until I coudn't deny the facts any longer.
The thing is you and me Bob and so many others have accepted the sorry truth: the standards are dead. At the Linux Uninstall Fest I was at yesterday it was all the talk. Luckily working with M$ stuff ins't *that* bad.
Signed Biff Bonebrain, Certified MS 2000 Engineer (i.e. now - before I was really anit-MS man wow!)
It is interesting that someone writes a silly biased article about CORBA that gets flagged on /. and then suddenly there's all these posts appear that with crocodile tears regret the death of a standard "that never really got off the ground".
./ this afternoon while the sysdamins reinstall NT on the servers!").
Kinda makes you wonder if the Visual Basic -> C++ translator broke down over at Redmond and a lot of young MicroSmurfs had free time on there hands ("hey everything crashed again let's all FUD
As for the article itself uhmm, no. Someone show me *WHERE* the "CORBA 3.0 Spec" *exclusively* ties CORBA to Java. Someone show me the CORBA 3.0 final written-in-stone specification please. WTF is this guy talking about?
Heh heh if the article and the posts were FUD your post must be meta-FUD ... FUD about FUD get it? :-) Err I guess it's just sarcasm.
:-) OK heh heh maybe that's the java (brown liquid version) talking ...
How about we all start to *really* confuse things and start to assert AT EVERY OPPORTUNITY that NT and MS "are OK if you're using older programs from the early or mid 1990's" but that the "technology has become a bit antiqated with the rise of the internet". It has the added bonus of being true - COM Active/X etc are pretty old ideas and they just plain haven't worked out for Microsoft.
CORBA works. Does anyone in industry think COM apps running on a "cluster" of NT systsm will provide mainframe reliabilty? (Sessions talks about using NT in E-commerce that way) - I mean jeez even with 7-10 IP addresses for www.microsoft.com and bastions of "clusters" of dozens of majorly expensive machines that rotate through their duties as systems crash and reboot (we're talking a multi-million dollar web server set up here) would anyone seriously suggest that such an installation is: 1) a robust cost-competive alternative to top end Suns SGI's and the like 2) the only alternative 3) easy to admin (!!)
I bet one or two Sun boxes could handle the entire at www.microsoft.com
Reality check:
http://www.fourmilab.ch/documents/msapogee.html
Pray tell *where* anywhere does OMG state this?
... let's kill off those pesky standards organizations (there all just fronts for Sun anyway!) let MS be free to innovate!
So CORBA is a language specific standard now exclusively tied to JAVA - yeah and Unix is dead as a door nail right? Thanks for the "analysis".
Oh my Gawd! I've been using dead technology all week long!
This quote is telling:
"it's time to conduct more than a postmortem of CORBA 3.0 Perhaps it's time to conduct a postmortem of the OMG".
Yeah that's it
Programmer over 40...
There is no reason to be afraid my freind.
Go check EJBoss you will see thatsome GNU people love object orientation the web and all things net and still adhere to your views... the average is more around 30 though;-)
Ah get out of here, this is really tiring.
Hell no, I will not let go of OO. I just look at the sky, and keep on doing OO, why the heck do you want me to do C. I only regret that OO came with the clout of snobism about it. It is a shame, it is just a simpler way, period.
"Strip your feet of lead my friend, strip your feet of lead"
--Bauhaus, the sky's gone out--
CORBA was designed with blindfolds. So now
their favorite language is Java. Big deal.
Check out ILU at www.parc.xerox.com . It is better, it can do IIOP, and the C++ binding is CORBA-compliant.
>>
;))
Let me first issue the disclaimer that I am not a Real Programmer..
>
Unfortunately, the learning curve for CORBA is staggering
> If it were not for projects like GNOME, you might as well pronounce CORBA dead right now
PARDON??? we use it here, pick up any paper and you will see a lot of high paid jobs for it. Banks love it! We love it! (mostly
I think to many people think of technology as a bunch of acronyms with feature lists, never use it or read between the lines.
They need anti FUD glass.
AC.
Let me first issue the disclaimer that I am not a Real Programmer..
;))
It really worries me that a lot of people who are paid to watch technologies do not use them and consider the 'feature list' when one does not feel that they know what the features really mean. This is not an insult against you in particalar but many people have read that artical and feel they have an opinon about this draft of the new Corba standard.
Unfortunately, the learning curve for CORBA is staggering
Are you speaking from experience or did you read an article that said this? I didn't find it that hard, the language binding are easy (certainly for Java, less so for C++), but making distributed programs has a high learning curve and that doesn't matter about the language or the protocols that you use, in this case Corba is a good tool for doing a 'hard thing'.
If it were not for projects like GNOME, you might as well pronounce CORBA dead right now
PARDON??? we use it here, pick up any paper and you will see a lot of high paid jobs for it. Banks love it! We love it! (mostly
I think to many people think of technology as a bunch of acronyms with feature lists, never use it or read between the lines.
They need anti FUD glass.
AC.
I don't think language neutrality is gone from CORBA. It's more of a favorite son approach -- some things are just easier to do in Java. Legacy data can still be accessed in any language with an IDL binding.
IMO, this is a pragmatic solution that reflects the way people really work. Criticizing the OMG because they can't make C++ and COBOL binaries be transportable is missing the point.
It is a shame that my tax dollars at NASA were spent on software engineers that rewrote C++ GUI code on every platform instead of buying a good cross-platform GUI library such as Qt.
As for the NASA Java code example you supposedly gave - you gave no such concrete example, just a vague reference to some obscure NASA project with no mention of source code so that it can be scrutinized. Even the URL that you mentioned shows that the optimized C/C++ prime number generator is _faster_ than Java JIT compiled code! How does this advance your argument?
Then you go on to talk about the speed in which you can write code in Java is quicker than you can personally write in C++. This is irrelevant to the point of the discussion. The original poster was refering to C++ execution time being faster than Java code execution time. I have seen no proof in this thread to the contrary.
Check the homepage of this reference - ... but keep your eye on
objectwatch is mainly a consulting operation
with a focus on M$ technologies...
This doesn't necessarily make their comments
wrong, and Sun may want to be a little
Microsoft,
the biases here
... at a Microsoft training seminar (I wasn't there by my own choice, of course). He tried hard to give an impression of objectivity, and most of the Microsoft junkies there bought it, but to me it was completely transparent. He took choice quotes from EJB and CORBA advocates and used them with no pretense of context to put them down, and made some VERY dodgy assumptions to suggest that EJB wouldn't reach the place that Microsoft was in 1995 until about 2002, and CORBA not until 2005.
While Microsoft does have the lead in this area at the moment, I'd say EJB is right now where MS was in 1996-ish, and gaining fast (the only reason MS got the head-start was because all they have to do is say "this is a standard" and it is, wheras Sun and OMG both have to deal with this bizarre thing called "user feedback").
He also claimed that MS is working very hard on making COM interoperable with the other standards and neither of the others was making any effort in this area (he didn't make any attempt to back up either of these completely false statements). I picked him up on this one, and finally got a grudging admission that "yeah, EJB *will* be great".
He also claimed that the only thing EJB has going for it is the Java Platform, and that unless you buy completely into Java Everywhere, you shouldn't even consider it (and made some disparaging remarks about Java on the client side, which is supposed to turn everyone off using it on the server side too).
Sorry for the long post, but I think this makes it abundantly clear that Roger Sessions is anything but an unbiased observer. He's a fully paid off Microsoft lacky, and the only reason he doesn't work for Microsoft is that this way, they can claim that he's an objective outsider.
Stuart (sab39, but can't remember my password).
Neither CORBA nor COM are going to bring us to the distributed promised land. Both of them are "vendor standards" to a significant degree and ignore real-world concerns like portability, scalability, maintainability, reliability, all of those -bilities. On top of which both are "baroque" structures, with far more specifications and restricting requirements than are really necessary to get the job done. This latest move to require Java in the middle tier for CORBA is just another example.
COM and, to a lesser extent CORBA, only work to the extent that you sacrifice your freedom and flexibility to the vendor agenda. Yes, they both work to a degree and people are actually using them in real life.
But.
But the real issue is that these things are all being brought to market on a vendor product cycle rather than being allowed to develop "ecologically" in sync with the heterogeneous demands of distributed processes and the evolution of the net.
--------
This whole issue of distributed objects and objected oriented
hype is irrlevant to the real world of appliations and systems and
software development in the GUN-Linux-"Free Software" world
that most readers here dwell in, except to the degree that a few
projects have partially (and really, very, very partially) used some
aspects of CORBA or attempted to use CORBA for object
integration. Notably GNOME and KDE. That implementation
will always remain, at best, partial and eventually will phase out.
This does not mean that GNOME and KDE will phase out,
however. Developers who actually have to write apps despise
CORBA and for good reason.
Another poster noted that CORBA and the "object model"
of development is dead, but that the horse is still twitching.
So long as the horse is still twitching, the hype and buzz will
be good for one's career in the proprietary corporate world,
particularly in IBM centric shops needing mid-level integration
using IBM tools and of course in MS shops using exclusively
MS platforms with COM as the integration method and in Sun
shops using proprietary SUN unixes and proprietary database
systems and proprietary SUN./IBM Java.
CORBA and its many variants (including JavaBeans and all
the variations of Microsofts's COM, really) is too unwieldy and
complex. These variations of CORBA are inherently inconsistent
and often incompatible in practice. Partly this is intentional, as each
vendor wants to lock in customers and developers. But mostly
it is because CORBA and COM and SOM and Java the whole
works is a technology which is alread passe and lifeless and ugly
and unwieldy. I am speaking from experience here having worked
with IBM"s SOM years ago when it was held out as the
final solution for object modeling at the system level. Well,
that was abandoned for CORBA. CORBA is being abandoned
for Java, and on and on with the hype.
It's important to understand the role of these technologies and
their purpose. Their only purpose, really, is to provide a framework
wherein vendors can "distribute" software or code from owned
"servers" to paying "clients". Sort of like renting software. That
is it. There is nothing more to it. The rest is utter hype.
Does this mean that I am opposed to object oriented software
development? Not at all. I love C++ for gui development, for
music software, and much more, and I use it. I like Python
a lot even though I've not used it much to date, and Lisp is the
grandfather of it all -what I stareted with. However, at the system
level I do not feel that the kind of object integration hyped
by these vendors (and it really is the vendors, not the
programmers, who hype it) is desirable - especially in the free
software world, which holds the key to the future and is where
all of the energy and "light" is right now.
The future is in using simple scripting languages and XML and
so forth in combination with solid systems and open data
formats wherein the *DATA*, not code, is the medium of integration
between applications and systems. Nothing can be simpler, and
nothing else really works, in the long run. Sounds too simple
to be true, but the truth is better than marketing hype by bold
faced liars intent only on advancing their own careers. XML and
its ilk is the future, not CORBA.
Scripting languages which allow integration and open protocols
for networking are already here. Some of this may have object
oriented features, which is fine and dandy. But, that is vastly
different in nature from "system level object integration" which
really means, beneath all the hype, only one thing - let our
proprietary object model integrate your system. We will rent
you code which we will distribute to you for a price. This code can
run your toaster, your tv and your home computer. Leave the
driving to us.
We read a lot these days about Linux meeting the challenge of
enterprise level. Ho, hum. What a boring topic. "Enterprise"
means "corporate". Linux and free software (GNU, etc) was not
created to serve faceless, lifeless, anti-god corporations but to
serve people. To empower people to take control of their own
software or at least not to be controlled in merely using software.
Translated to the level of concrete applications, this means
continuing to develop good apps using open protocols and to
make source code available, object oriented or not, and to use
integration tools provided with unix (and GNU equivalents which
are often better) to "layer" small tools and apps to create
subsystems for any purpose - even for corporate enterprise.
But, we play by our rules, not the rules of Java as defined by
Sun or COM as defined by MS. Above all, keep it simple.
a programmer - over 40
there are a few cases where Java is faster than C++.
one is when your system has a lot of object creation and destruction. C++ has to run the destructor every time, plus has to deal w/ the memory freeing overhead. Java ('cause of the garbage collection) can put it off till the system load is a bit lower, or if you have _lots_ of ram for ever.
i'm not trying to say that java is faster than c++, just that c++ is not _always_ faster than java.
I agree 100% about the use of OO languages.
henri
uh, yeah....
you write your code in c, compile it and run it.
it works when you and 2 other people test it.
you move it out to production, 10000 people hit it. boom it dies. why? your SINGLE computer can't handle the load.
so you start to distribute chunks of it, i'll open a socket to this other computer and that way we can spread the load!
so you spend hours/days/weeks writing and testing and breaking your code up into smaller chunks that can run independently of each other and writing a general protocol between them so you don't have to re-write the distribution part every time....
hmmm... starting to look familiar.
wouldn't it have been easier to use some sort of 'component spec' that hides the transfer protocol, has been tested, is documented, and could possibly work with some other vendors components? (and _maybe_ you could use some 'opensource off the shelf' components and save yourself some time and effort in the first place.)
you can still write your code in C, look at GNOME (jeez, i hope that's not written in C++ or i'll look kinda foolish here)
henri
Today almost all circuit diagrams are standard. We all know what a resistor, a capacitor, or a gate looks like. This wasn't always so. Standardized circuit representations and a big library of pre-designed circuit pieces are what made low-cost, mass-produced consumer electronics possible.
Now the same thing is happening in software, but it'll take a while until everyone agrees on some sort of standard. I expect most of the long-term impetus for this to come from open source developers who want to make long-distance collaboration easier, even though commercial developers have a MAJOR interest in making it easier to assemble programs from lists of objects that all fit together easily without a lot of wiggling and cramming.
I have no idea yet what that standard will be. UML is only a few years old. Conceptually, it's about where circuitry schematic design was in 1910 or so, and it didn't really get "hardened" until 1925 or later.
--Robin Miller
Cheap Computing columnist
If they choose a different component spec, it would probably be based on C++. And then most people would be happy because C++ is the 600-pound gorilla of the object world.
But the fact is, a component spec isn't necessarily tied to a language. So they like the EJB components: that means someone will do compatible components in C++ as well. It's not as if the components are inherently Java-specific.
Most of you are whining because they didn't go with the Windows of the OO language world (C++). Think about it.
-- brandon s. allbery, sysadmin @ cmu electrical & computer engineering "Think, youth, THINK!"
You can get garbage collectors for many languages, including C and C++.
While I would agree that Java programs can be faster than C++ programs, anything written in Java can always be rewritten and made faster in C++ if you are willing to commit the time and knowledge to get it done.
True. In some cases the difference will be a few percent, in other cases, it will be several magnitudes.
The real issue is that Java is much easier to program, much more portable, and arguably easier to maintain. While it may be worth programming some things in order to squeeze out some more performance, there are cases where Java will be far more cost effective.
Right tool for the right job.
He basically claims that OMG is giving up language neutrality. Here is a quote from the OMG press release that he is supposedly commenting on:
The press release is simply a joint announcement from Sun and OMG announcing that there will be a close collaboration between EJB and CORBA. Importantly, EJB will be supporting the core of CORBA's network communication model: IIOP, which pretty much guarantees that you can write your objects in any language and on any platform, as long as you can make TCP sockets.
I must say that this guy's experience is really, really, far from my own and that ceretainly shapes his very, very different interpretation of this press release. He says that he sees half of all programmers who are working with object integration programming with VB. I certainly don't.
I think people should read the OMG release themselves and draw their own conclusions, but I read it as a commitment from Sun to cooperate with OMG to come up with a vendor neutral object specification ... something to address the fundamental questions of vendor and platform dependence raised by Microsoft's DOM.
Posted by Mr G:
.." is total ignorance at high volume.
Sessions is a lackey. He's been one for a long time now. Ignoring that and moving on to the
technical stuff.
The OMG has not recanted on their earlier convictions. Reading that into the press release is nonsensical.
Think about RMI. The idea behind RMI was to
make simple distributed applications easy to
build. The idea behind EJB is to make those
simple applications more scalable by moving a
lot of the complexity to the people who build
the EJB Container.
That is, 90% of the EJB spec is defining the functionality the container provider must
include. And a lot of this functionality is
already available from CORBA vendors.
So what else made it into the EJB spec ? That's
right. An EJB to CORBA mapping and a definition
of RMI-IIOP. The idea being that all the effort
that's been expended on building CORBA components
can be seamlessly (ore nearly seamlessly)
incoporated into EJB.
If you've built a CORBA application, you can
talk to it from Java. If you've built an ORB,
you can leverage everything and build an EJB
container.
Why wouldn't the OMG be ecstatic ? Java's huge
and only going to get bigger. And EJB was designed from the ground up to be CORBA friendly.
The paragraph beginning "I don't current work in Java, so it seems
Posted by rolandpj:
The array access is probably still an issue, I think there may have been advances in that area by newer VM's but I can't say for sure.
There are well-known techniques for hoisting
array bounds checks out of loops. This makes
array bounds checking essentially free. The good
JIT's do this already, although there are probably
some cases that they can't yet analyse properly.
This will improve with time, and as the previous
poster mentioned, without source-code changes.
Posted by woz-e:
:)
Hmm, I'm not sure whether or not this is a
troll or whether you need the clue stick
liberally applied to your skull, Jeff. Do
remember that using HTTP in areas like
wireless networks, medical equipment and
process control nets is not the most advisable
approach.
I think I'll go for the clue stick
*twack* *twack* *twack*
Posted by surfside:
Roger Sessions originally worked on the CORBA Persistance standard, which was subsequently rejected by the OMG. Ever since that unfortunate mishap, he has decided to side with Microsoft and print very anti-CORBA messages on his ObjectWatch site (read some of his other articles). Be aware that all he does is Microsoft/COM now and that many of his claims for COM and COM+ are speculative and somewhat misleading (at best).
I have worked with both CORBA and COM. I have had to explain the differences in the object models over and over, and I have developed in both environments. COM works well if you are a Microsoft shop, with all Microsoft desktops, and you only run on a Microsoft LAN, interfacing to a Microsoft database. CORBA works if you have a distributed heterogeneous network across multiple platforms, and multiple languages.
'nuff said.
Language neutrality is a wonderful wonderful goal, its just that i have not seen an implementation of it yet which is... well.. good. or something that you look at and say, thats the right way to do it (tm). ,CORBA was okay but it was very very slanted to C++ type languages, and even imperitive languages in general... (a mix of C++, haskel (http://haskell.org/), Prolog, whatever) is many times what one WANTS to be able to do in a project but with current systems it is almost impossible to do in any sort of portable way...
Now in my mind a standard should encourage interopabilty first, AND sepertate from the IDL etc.. build up a good general IPC mechanism which can be generalized to dynamic libraries, internet connections, or whatnot, and then build the other stuff on top of it... the low level IPC functions should always be availible, those may be used for languages where the IDL mapping just doesnt work, or for small uses where you just need to comunicate.
in any case check out ILU
ftp://ftp.parc.xerox.com/pub/ilu/ilu.html
http://notanumber.net/
>Obviously, the author of the previous remark has no significant experience in writing proper C++. There *IS* no such thing as "proper" C++. All C++ is pretty much garabge, plain and simple. The only people who doesn't seem to have realized this yet is the microsoft crowd.
CORBA's problems are the same as all the problems of all OOA/D technologies, methods, schemes. Since they don't have any formalism they pretend to have it by making overly complex (pommobabble) presentations. UML is really just a way to draw your object model, it doesn't do a lot other than that. Drawing your object model is important, especially if you've got a large team of implementors who all need to be on the same page but it doesn't get you any closer to implementation or improve you implementation.
Have you ever learned Booch? or OMT? They are much too complex (proof of this is in the list of successful projects which have relied upon them..) This is the achilles heel of OOA/D. There are libraries full of books that discuss the philosophy and outline "methods" which are overly complex and get your project nowhere. The trick to good OOA/D and programming is to be dynamic because you can never figure out all the problems until you start solving some problems and plans change. There is also a lot to be said about finding the right balance between planning for the future in your design but implementing no more than you need, CORBA has plenty of useless features because they were afraid to say "no" and they wanted it to be everything to everybody; the best CORBA brokers are the ones that implement the few pieces that are really needed and ignore the rest.
I don't know, I'm a professional object programmer and we use UML at work. I'm also a functional programmer and I'm becoming more and more disgrunteld with all the talk in the object community and the consistant lack of substance. I think that the free software community is going to be the break through for CORBA and it is because they aren't playing the CORBA game, they are doing what is needed.
Microsoft made a competing product more successful - not because it was better, but because they didn't want people to use a standard that would allow them to port their apps to other platforms. That's all I'm saying - I think this was good for Microsoft and bad for Corba.
But the victims _are_ doing something about it. I was just lamenting that it would have been nice if we could interoperate with Win32 easily, like we could have if they'd adopted Corba.
Matt. Want XML + Apache + Stylesheets? Get AxKit.
Corba _has_ taken off on Unix. I was lamenting that it hasn't taken off on 99% of the worlds computers...
Matt. Want XML + Apache + Stylesheets? Get AxKit.
It's a real shame that Corba didn't take off in the way it should have. Yes I know it's used in a lot of high end systems - and it performs very very well in those systems. Unfortunately only 1 thing contributed to its failure: Microsoft. Sad really. Why MS felt that they had to provide a proprietary system is known - they had to get vendor lock in. That attitude sucks. Corba is a more powerful and easier to use object model than COM. Developing for COM is not nearly as easy.
I suppose it'll end up in the great bit-bucket of marginally used but superior technologies...
Matt. Want XML + Apache + Stylesheets? Get AxKit.
With CORBA as it stood, there was even a fraction of a chance I could manage this. With JavaBeans, forget it.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Umm, while COM is certainly pretty much a Microsoft only technology and thus relegated to the NT servers and desktops...
There's no reason you have to use a Microsoft database. There are ODBC and OLE-DB providers to connect to Oracle and others.
We use Oracle running on big Sequent boxes at work, and the Microsoft stuff has no more trouble talking to them than anything else.
Are you sure you've used both?
CORBA has always suffered from the Lowest-Common-Denominator problem. Using CORBA for large-scale applications is painful, as there are many OO features it does not support, for example method overloading. But perhaps CORBAs (2.0) biggest problem is that you cannot transfer objects, only (C-like) structs. This makes it really hard to write fast distributed programs in a object oriented way. Most times you have the choice between an extremely bad performance (because you use too many calls) or losing almost any platform-neutrality (for example by seralizing objects and sending them as byte arrays). CORBAs main probelm is that is was made to support every architecture, every language. Unfortunately, if you design a standard so you can support Fortran and Cobol, you have to give up many modern features and make it almost unusable.
Free (some more, some less) CORBA implementations for C++: MICO, ORBit, ILU For Java: JacORB, ILU, JavaIDL (included in JDK 1.2) For Python: FNORB, ILU, SYLO
Sure this might favour Java a little bit, but I can't see it tying developers to that language inextricably.
anything written in Java can always be
rewritten and made faster in C++
Possibly. But the difference won't be more than a few percent. If you really want speed, use C. Or better yet, use assembly. The question is whether your time and effort and the lost of portability is worth it.
The CORBA specification has long lacked the ability to pass objects by value rather than referrence. By creating this component specification, CORBA gains a much needed ability to pass complex objects between ORB's beyond arrays and structs. Remember that OMG's goal is to create a neutral platform for network programming between platform implementations. XML doesn't do the trick because unless the embedded objects are scripts or even java binaries, they are still tied to a platform.
The EJB component specification is AN implementation of the specification, it certainly allows other bindings to be implemented in the future. Without this spec, CORBA will always lack the few advantages that DCOM has by allowing binaries to be passed around and used by other ORB's. The objects will of course need to be platform-independant. If they're not java objects, then the OMG would have to create some platform indepent binary specification, thus duplicating Sun's efforts with java.
Conservative garbage collectors are inherently broken. Some JVMs actually use conservative garbage collectors, and there are serious problems with them. They're particularly bad for applications that deal with very large amounts of almost random data. The collector believes that almost everything that was allocated has a reference, and doesn't free anything.
And what's this about Java programs needing to copy things unnecessarily? A "well-crafted" Java program doesn't need to do that either.
Finally, while Java programs always use the "new" syntax to allocate objects, it's really up to your virtual machine to decide where objects get allocated. A JVM could, conceivably, allocate short-lived object on the stack. And if you have a good heap allocator, that doesn't matter too much anyways. (HotSpot apparently has one that's significantly faster than any known C++ heap allocator, and some of its speed comes from GC-related optimizations)
No wonder he says half his audiences use VB, and only 1/12 use java. He's talking to M$ audiences.
--
Infuriate left and right
I recently gave a series of three talks to over fifteen hundred developers in Canada. In each talk I asked how many were programming in Visual Basic, C++, and Java. The ratios were about 3/6, 2/6, and less than 1/12, respectively.
He specializes in M$ development. He gives talk on M$ development.
Now if he'd talked to pure Unix audiences, the VB component would have been ZERO. And that's probably closer to reality for server development than M$ audiences.
--
Infuriate left and right
Why people waste their time with anything else is beyond me. HTTP, SMTP, and HTML are forever; everything else will quickly end up in the dustbins of computer history. I have way to much fear, doubt and uncertainty about the future of any other protocol to even consider using it. Jeff
So the answer is: when you fall, blame Microsoft. When your product isn't adopted, blame Microsoft. We're all victims of Microsoft.
It's really easy to be a victim. But victims don't get things done
I've finally had it: until slashdot gets article moderation, I am not coming back.
Don't forget HITLER
I've finally had it: until slashdot gets article moderation, I am not coming back.
> Not so long ago you where the big CORBA booster, and then, quite suddenly, you switched to the MS camp - wonder why?
It makes him more money? It's a distributed object service, not the cure for cancer. He doesn't need any more reasons than money.
I've finally had it: until slashdot gets article moderation, I am not coming back.
I mention DII, DSI, and POA as "services", knowing they're not part of the Common Services list, but some so-called ORBs (*cough* ORBit *cough*) don't even implement those completely.
There's nothing better I'd like to do than write one of the services, but security is something you can't do an amateur job with. I'm a complete crypto dunce. And from the look of it, it's one of the biggest and hairiest services of all, encompassing auditing, non-repudiation, domain policies, custom policies, principal authentication, and on and on. Seems terribly complicated to me at least.
I've finally had it: until slashdot gets article moderation, I am not coming back.
TAO looks nice, but it still doesn't come with anywhere near a full complement of the common services.
I need a freely-available ORB that implements DII, DSI, POA, and Security. The last one is important because I want to create a multi-user collaborative system based on MOO, and the only sane way to do security in this system is to authenticate the sender of a message. Your obj.foo() method is called, first thing you ask is "who wants to know?". The Security service gives you an answer with get_credentials(). I still can't get something as simple as that in a free ORB. Some offer me SSL, which is like giving me a secure phone line when I still don't have caller ID.
I've finally had it: until slashdot gets article moderation, I am not coming back.
Roger Sessions used to work for IBM, and was a part of the OMG team that developed the CORBA Object Persistence framework. Seems to me that if anyone hoped big things were ahead for CORBA, it would be someone who worked on the CORBA specs personally. At a recent technical lecture I attended in Toronto, Ontario, which was sponsored by Microsoft, Roger Sessions did not give unfair praise to the Mighty MS even though they were paying him. Instead he gave a fairly interesting and robust set of case studies in high-volume transaction-processing and distributed commerce applications and how traditional TP, current and future CORBA standards, and Microsoft COM+ (and the existing COM/MTS/etc) hope to handle these situations. He even said a few things that were hardly complimentary to Microsoft, but he also said that Microsoft tends to get flack for things they don't deserve flack for, such as their lack of interest in cross-platform standards. If you were Microsoft, you wouldn't be either. The question is, who do you want to commit your enterprise's middle tier to for now and in the future? Someone with no commitment to platform independance (Microsoft), someone with no commitment to language independance (Sun/EJB), or someone who flails around and then recants on their earlier convictions (OMG, and their commercial implementors: IBM, and BEA). All around, a pretty mixed bag.
Personally I don't mind Java, and I don't think Roger Sessions went out of his way to make any negative comments about Java itself, he just made the fairly real-world comment that most 3-tier client-server distributed applicaiton developers work in C++, VisualBasic (I choke at this, but it's true), or even COBOL (also a choker).
I don't current work in Java, so it seems reasonable to me that anyone who is expecting that we should all move to Java just to use these scalability services in Enterprise Java Beans is not going to see the kind of quarterly results that they wanted if they base their whole developer product lineup around EJB. What if I need highly tuned compiled components and low level platform services access in my code? Should I go with EJB and code the guts of an EJB in another language, and use Java Native Interface to call some code in C? Sounds like too much work. All that BS about Java being as fast as C++ assumes that your system is constricted purely by network throughput. roger Sessions even echoed this common point and *agreed* with the Java folks that the performance of a system doesn't change much whether it's in C++, Java, or Visual Basic. Personally, I'll beleive the "experts" until I can find a test case in which that isn't true, but when I get there, I don't want to be stuck using JAVA when I need a high performance component.
I bet that a lot of companies are going for an all Microsoft/COM+ middle-tier for now, and using a COM to CORBA bridge or a COM to EJB bridge when necessary for future integration to non-microsoft platforms.
Anyway, I got this from the home page's opening lines:
We specialize in offering training and consulting on Microsoft's distributed component architectures, including Java, COM, DCOM, MTS, Falcon, and Wolfpack. This web site is a valuable source of information about Microsoft's distributed object architectures, the architecture that Microsoft calls DNA (Distributed interNet Applications).
Roger Sessions is available to come to your company and teach courses on Microsoft distributed object technologies.
Roger Sessions' new book is COM and DCOM; Microsoft's Vision for Distributed Objects, published by John Wiley and Sons. This book gives an overview of the various technologies Microsoft has introduced to support distributed object applications, and to compete with mainframes for the commerce market. These technologies include Java, COM, DCOM, MTS (Microsoft Transaction Server), Falcon, Wolfpack, and a sophisticated framework for support of distributed transactions.
I can't say this guy is unbiased. I guess since the OMG made Java the middle tier standard instead of, oh say, Visual Basic or COM/DCOM, his business might be impacted???? I think his trustability with me just dropped a couple of magnitudes.
Um, pardon me but doesn't Python also use a VM underneath, so that .pyc files (in theory) are also "binary portable"?
I agree with you about the still-present language independence though: The events could go in this order:
Man, this is the first programming-related article that I have ever read that has left me totally clueless. Am I the only one that doesn't see what the big deal of CORBA is, or what the heck a "component spec" is useful for? What ever happened to just writing your program in C, compiling it and running it?
Am I _that_ clueless?
Yes!
Marshalling data over IDL has been a real handicap for CORBA: C-structs just aren't flexible enough. From what I know, COM is no better in this regard either.
Java and CORBA have some great features: however, it makes a lot of sense to drop CORBA's language-inflexibility and RMI's inscaleability in favour of CORBA/EJB.
It come as no surprise that out of the 1,500 people who went to hear Roger Sessions, 50% were VB programmers, and only 8% Java.
If James Gosling (say) had conducted a similar experiment, I suspect the numbers would be somewhat different...
Marshalling code for mapping C-structs to IDL structs is trivial. However, to convert a data object that uses inheritence into IDL structs is more difficult.
Programmers are faced with two alternatives:
1. use structs in the IDL, and write marshalling code to convert the object hierarchy into structs. This is certainly do-able, but ugly: code needs to be changed whenever the data object changes.
2. serialize the data object into a byte array (e.g. using Java serialization), and pass this as a sequence of bytes. This is unsatisfactory because (a) the IDL interface becomes meaningless and (b) it makes the IDL language dependent.
IMHO, the former approach is too painful to deal with, which is why I think it makes sense to explore language dependent alternatives to IDL.
I knew I had seen that name and book title before (COM and DCOM - Microsoft's Vision for Distributed Objects) - I obtained that book around 1,5 years ago and I got it here in my bookshelf.
You definitely see that he is not too happy with Java view of the world in the book. On the back of the book it says "An expoert's unbiased appraisal of Microsoft's object technologies and how they can work for your enterprise" - well, I would not call it unbiased.
Calling Java proponents for "wannabees", "rebel alliance" and some other things does not give an impression of someone that strives to be unbiased and keep a neutral tone.
At least as far as I got in the book, I did not read all of it.
Well, networking is what happened - especially the Internet. CORBA provides a standard way to access software, using object interfaces, in a way that is language- and platform neutral - and transparent to the application.
And since OO many times is a good way to handle complex softway models, choosing the OO paradigm as a base for this interface architecture is not too bad.
Note that OMG is not only about defining how objects communicate with each other, their effort is to provide all sorts of standardised interfaces related to software objects.
However, I think that there is a bit too much of trying to be buzzword compliant in some cases.
CORBA is certainly not the answer to all interoperability needs and it won't solve all interoperability/integration problems by just plugging in CORBA interfaces everywhere.
I think CORBA 3.0 is a step on the way of making it more useful and allowing integration with EJB is good.
I had become a big fan of CORBA and the potential that it has. One of the things that I was anxiously awaiting was their new Component model. In my opinion the decision to drop language independence is a Bad Thing[tm].
I really hope they change their mind on this matter. I do agree with the article though that the proposal in its current state is just too large and complex. I guess that is one of the major drawbacks of design by committee, you end up with huge, bloated specifications... they should go back to the idiom of KISS.
I need a freely-available ORB that implements DII, DSI, POA, and Security
Looking at the TAO website (and having worked with it last year for a bit), it seems like TAO is pretty near a full compliment. You specifically mention DII, DSI and POA (none of which are services, BTW) all of which TAO has (in fact TAO was the first orb that had POA AFAIK). They don't have security according to their docs, but the security spec isn't terribly complicated. Why not help them implement it?
There is also MICO.
I am not knocking OpenStep, I program in it every day. But there are some great things that CORBA allows you to do without forcing everyone to use the same platform/language, etc.
Stephen Blake
ok, as i understand it, the middleware stuff in Corba is going to use JavaBeans. Now, the big that's Bad News is that Java is a specific language, we'd prefer a language-agnostic middleware thang.
so, is there any possibility of taking JavaBeans and decaffinating them? to wit, create a non-Java implementation of the exact same set of protocols for doing the job and imlement them in something you can call C++Beans, or PerlBeans, or PythonBeans, or maybe even (caution flame-bait ahead) VisualBasicBeans
curious,
sdp
If you are going to do some actual OO programming: ... C++ is a nightmare.
lots of objects, reflection, inheritance, threads,
A good programmer can probably pull of some tricks to get it working but the Java solution will nearly always be more elegant (small, simple maintainable).
I'm not saying that C++ is a bad language though. It just has a different purpose. It allows you to program OO if you want to and it allows you to program in a more traditional way if the OO thingies take a high performance hit.
Java on the other hand tries to take away the traditional performance hit of OO programming and thus allows to program in intuitive style.
First generation VM's did a lousy job at it. The current generation VM's actully makes this work on the server side and the next generation VM's will also make this work on simpler machines. (if your interested in this stuff check IBM's new VM and SUN's upcoming hotspot compiler, both beat the shit out of native compilers and MS fast but incompatible VM)
OMG now must have recognized this. Java is quickly becoming the programming language of choice on servers (mainly because of its scalability and ease of use, and yes it performs well too). Any succesful future CORBA implementation will have to support this language as much as possible otherwise Java developers will simply choose something else (RMI) and only use Corba to talk to legacy software (i.e. cobol, c an c++).
Greetings Jilles
Jilles
AIUI, Dylan is a higher-level language that doesn't special-case primitive types and encourages slinging around closures and other powerful but hard-to-optimize idioms.
You're reasonably close. ;-) Dylan does allow some very powerful dynamic features which are a royal pain to optimize. (I spent last week crawling around inside a Dylan optimizer, so I know what I'm talking about.) However, these are all optional features--you can easily write very static programs which run fast.
Primitive types are handled specially in Dylan, but the language tries to be graceful about it. Just because integers show up in the class hiearchy doesn't mean that they're actually compiled that way. It's sort of like making 'int' and 'Int' into the same thing, and having the compiler use the more efficient representation whenever possible. It's actually pretty easy to get right.
Were they comparing a native Dylan compiler to a native Java compiler, or a portable Dylan bytecode interpreter to a JVM, or were they cooking their results?
Actually, the benchmark compared Harlequin Dylan to Microsoft Visual C++. It was run by a scientist who needed to do some number-crunching.
Harlequin Dylan finished within five percent of MSVC++. Gwydion Dylan (which I help maintain) wouldn't have done so well because it's still not finished. We usually see code that runs at half the speed of C.
All that said, there's no reason why Java should be any slower than Dylan. A good Java compiler should be able to match a C++ compiler for most tasks, which should amount to a three-way tie: C++, Dylan and Java, with some of the naive Dylan programmers paying a slight performance penalty by using excessively dynamic features.
Actually, Microsoft created COM because they wanted compound documents. CORBA wanted to invent the entire 4-Door sedan, Microsoft wanted a good enough wheel barrow for each feature they added to Microsoft applications:
Compound Documents
Embedded Controls
Database connectivity (several tries, and none of them has supplanted ODBC)
COM/DCOM has a lot of holes (tossing binaries around the Internet to be executed is terminally stupid), but CORBA has taken way too long to support some of the same features.
Dave Williams
I have to make a comment on this.
Yes C++ has to run a destuctor, but the work that the destructor doesn't go away in java, you just have to find some other way to do the work.
As for freeing memory, if speed is an issue here, why not write a free operator for the class which does something like add the memory block to a list of memory that needs freeing and free it later when you have the time.
At least you can do that in C++, in java you have no choice but to do things the way that the system thinks is the best way.
(Not trying to complain about java, just saying that you can do just about anything in C++ that you can do in java with a bit of effort)
Sig is taking a break!
All Java container classes' element manipulation is mutex protected. This is expensive.
This is no longer true with the Collections classes - they are a set of useful containers (vectors, maps, hash tables, linked lists, trees, and so on) that are not syncronized by default but also provide syncronized wrappers for the times you need them to be. The Collections package is built into Java2, but has also been availiable for the 1.1 JDK over a year (at least since the last JavaOne). Plus, there's also the free JGL if you want the equivilent of STL for Java.
In C++ you explicity control all object memory (warts and all). You may employ custom memory allocators that best fits the pattern of specific object usage often yielding huge speed gains. Or, more simply, create transient objects on the stack where appropriate and cleanup is practically non-existant. In C++ you simply have more control over what's going on in your program.
That all sounds very good until you have to maintain this carefully balanced cleanup code.
One of the reasons I like Java is that in theory you can just select better and better VM's with better ways to handle small temporary objects and ability to clean things properly, all without touching the code. I'm not saying that is fully realized yet, but it has proven true that over time the app I was working on had good solid improvements in performance as we migrated from VM to VM (eventually to 1.2 which had a great leap in UI performance).
Java has no notion of "const" which leads to the inefficient practice of creating a deep copy of often non-lightweight objects to return to the Java 3rd party library user "just in case". And no, garbage collection and "final" won't help you
here.
All I can say is, if you distrust your libraries so much that you have to hand it copies of objects, you need to re-think the libraries you are using!
In practice, the only time I've ever had to make deep copies of objects was in implementing a object transaction system, where you wanted an original copy of your object to roll back the changes.
If you want to provide a const level of safety I think a much better approach is taken by the Collections package - have a well defined interface into your object and the provide a read-only wrapper that throws exceptions when something attempts to modify the object.
The array access is probably still an issue, I think there may have been advances in that area by newer VM's but I can't say for sure.
Overall, I'd probably agree that C++ is still faster than Java - but as you can see many of the old arguments are being addressed and I think now the difference is close enough that Java is a very attractive choice for many projects (especially server side projects).
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Yeah, one person I know who went to a seminar
of his has the same viewpoint. Everything MS
all the time.
His article in the IEEE Software on Linux made
him sound like a drooling idiot. Some of his
other articles sound reasonable, but I'd really
hate to be dependent upon his mindset for
anything.
If they gave out cash awards for core dumps...
Obviously, the author of the previous remark has no significant experience in writing proper C++.
If Java performs so much better in certain areas, why didn't you just code the C++ to do it that way???
I guarantee you that I can get a C++ program to run faster than any Java program, because ultimately if the C++ is slower, I'll just figure out how the Java code is implemented and the implement the C++ that way or better.
I will grant you that you might be able to get a Java program up and running quicker, but given enough effort, the C++ will be faster.
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.
1. The deadline for CORBA Component model proposals isn't until August 1999, so no decision has been made.
2. The OMG press release doesn't say what Mr. Sessions implies. It certainly doesn't say that vendor/language neutrality is being abandonded for the Component Model. It's basically just says EJB and CORBA work real good together. Read it for yourself here
3. And finally, from ObjectWatch's home page: "We specialize in offering training and
consulting on Microsoft's distributed component architectures"
Well put. I wanted to make some similar points but I've been outclassed. Interesting that the only criticism of the post was "well, you must be a socialist." I'd call that kind of attack "fighting truth with name-calling."
I've also suspected for a long time (as an outsider, I'm not a paid programmer but do some programming in the course of my work) that the real reason for a lot of these elaborate object-oriented schemes was to keep proprietary software viable. I think it's no accident that the proprietary world loves C++ while the free software world seems to prefer C. Many would agree that the data structure is the most important part of an algorithm, if you know the whole data structure (including function names), you can in many cases re-implement the algorithm. If you "hide" parts of it by making them private, it makes the task harder. It also makes it harder for you to tell if the algorithms are crap. CORBA, COM, and all that, seem to be a way to extend this stuff to distributed computing. I'll stick with things like Perl and Python for my "middleware" application glue. I also think you're right that standard, extensible data formats are more important than all this middleware stuff.
>The future is in using simple scripting languages
>and XML...wherein the *DATA*, not code, is the
>medium of integration between applications and
>systems.
I think you're right on all points, especially the one item quoted above. All this thrashing about by the proprietary vendors will prove to be pointless after XML with XSL enters the game. The CORBA/COM debacle of these past years shows to anyone who is interested just what these vendors really want: Customers tied to proprietary product interacting with other proprietary product.
Fundamental computing/networking tools are too important to the future of our species for us to swollow these types of base, myopic decisions driven by quarterly returns: Get your profits from second tier applications, not first tier tools.
If a tool is not a sensical open standard which is readily used by anyone, then it is flawed and should be avoided. XML is a most sensical open standard readily used by anyone at the tool-building level as well as the application-building level.
Everything in the Universe sucks: It's the law!
...and by that reasoning assembly language is ALWAYS faster than C++.
...and I've seen LOTS of slow C++ and lots of fast Java.
The practicality of implementing what Java has built in to it in C++ is laughable. I'm sorry but most software development houses don't have the time to re-invent the wheel.
Any true software developer would never say one language is ALWAYS better than another. Sure, they'll have a preference, but sometimes Java just makes more sense than C++.
Use the PL that makes sense. For some things, Prolog just kicks ass.
If you like, think of Java p-code as the back-end of any compiler. Then you have a language-neutral binary standard.
Do not confuse "Java the platform" with "Java the language". I can compile Java code to native machine-specific binaries if I choose, and get comparable performance to C++. When I compile for the JVM, then the result is the same but just for a different platform.
So... it locks you into Java no more than the COM spec locks you into C++ (it doesn't). I can write COM components in C, C++, Java, VB, etc. I just need to make the binary layout look right when dealing with interface pointers.
Isn't there an Eiffel compiler than generates Java p-code?
This is only new BS from an old and well-known source of anti-CORBA FUD. Now, before you fear of CORBA's death: Although I haven't yet read the Component spec, I don't see why it should mean end of language neutrality. CORBA has no binary standards for any other spec (except Java), all standards we need are source and wire; binary is a bonus.
Additionally, you should know the OMG process. OMG has no design/development staff - they issue RFPs, collect proposals, discuss them and eventually they ADOPT something, which needs to have at least prototypical implementation. EJB happened to be a great spec, it has existing implementations to proof that it works, so why not using it? All OMG need to do is additional work to map the same designs, interfaces and rules to the general environments/languages -- that's why the Component spec is bigger than the EJB spec. If OMG were dropping language independence, they would just adopt EJB as-is.
Only the uninformed developer, or the typical pointy-haired manager, will take this bullshit seriously.
That's the name of Roger Sessions' new book.
No it is not.
The fact that OMG chose EJB as their implementation does not mean CORBA has lost its language independence. It's like saying that since OMG chose IIOP as their implementation of GIOP, that all CORBA applications are tied to IP networks. Which is bullocks.
Most people in this forum, and apparently the author of this article we're referring to, don't seem to have the foggiest clue about CORBA or the issues we're talking about. With a few exceptions of the people who actually made intelligent posts trying to explain the OMG specs.
As for CORBA being dead, well, those of you who have access to Gartner Group's reports can go dig up what they came up with their studies of nearly 500 major corporations. Seems to me DCOM has lots of catching up to do!
-- Jay
Thanks for trying to explain this. Maybe one or two of the people will actually grasp the facts you mentioned here.
Sometimes I wonder why even bother teaching people to read. Most of them can't comprehend the sentences anyway.
-- Jay
I tried to read it, but it was too MS slanted. I scanned to the Visual Basic part and had to stop. The scary part is the people who read his drivel probably respect what he has to say.
This is Micro$oft propoganda. And it is wrong.
The death of CORBA is absurd. Due to the OMG's imperfect but democratic process, it is better now than it ever has been. This microsofty is announcing the death of CORBA due to the birth of EJB. Absurd.
Technically important, and strangely absent from the posting was the true relationship of EJB and CORBA. EJB does not replace CORBA at all! It is built on top of it. EJB uses RMI for distributed object communication, and RMI (and IIOP) have been enhanced so that the protocol of RMI IS IIOP. This means that an RMI client may make calls to a CORBA server, and vice versa.
CORBA
I agree about the language neutrality reason.
By the way java is really inefficient at the actual status.
I think that could be a lot better if they use only object oriented languages instead that all languages (e.g. C++, Fortran 90, Ada 95 and so on)
And if they must choose just one object oriented language they could choose C++ that is far better than java about speed and diffusion among developers.
Bye,
Antonio
I agree.
By the way this flame has been generated by an error inside the broad lines of the objectwatch article.
In fact they substain that the OMG choice imply a revolution about CORBA, the choice of Java as the only CORBA language.
Of course such gigantic error has been generated by their Microsof experience.
In their experience, I presume, there isn't any difference about source compatibility and binary compatibility.
Such ipothesis is reasonable if we think that the DCOM model is limited just to the x86 windows platform.
So they assumed that using Java for binary compatibility forces the CORBA users to use only Java and this assumption is so wrong that started our fury.
Goodbye,
Antonio
I have been reading about OMG's creation of XMI. Surely that is vendor independant, it is based on XML.