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. "
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
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
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 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.
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.
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.
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.
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.
howdy... i'd like to point out, as has been mentioned here in numerous sub-threads, the OMG has not altered their model for language independence UNLESS you wish to take advantage of the new (i.e. EJB centric) features. thus, if you need to write applications that cooperate in all the environments you mentioned, you still can... you just won't be able to do things like have the client demarcate a transaction, pass a serialized smart-proxy back to the client, etc. you can still work within the "original" constraints. personally, i have no problem with what the omg folks have decided. i've had extensive experience with the EJB spec to date, and feel quite comfortable with it. there's NOTHING that says we can't wrap EJB activities with IDL interfaces that are language agnostic... (in fact, we've done exactly that... we've created "service-based" idl wrappers around the object model.) it might require a bit more design effort, but anything is possible if you need to get the job done badly enough and there's a big-enough payoff for making this decision. (say, i don't have to write the thread pool, dbms connection pool, event model, object life-cycle, etc, etc, etc.) just my 0.02 Peter
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.
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"
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?