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. "
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 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.