Slashdot Mirror
Review:Advanced CORBA Programming with C++
Michi Henning doesn't know it, but he answered dozens of questions for me over the years through the archives of his hundreds of Usenet posts on dejanews. In fact, more often than not if I'm looking for information on CORBA I'll add his email address to the authors field and go straight to the authority.
With that in mind, I was quite anxious to see their book, and quite impatient when its date was pushed back a couple times. To say that these two are qualified to write on the subject is a huge understatement. Whether or not they could write a book of the magnitude that they attempted with a consistent level of accuracy and readability was another question.
Great Thud Value The first thing to know about this book is that it isn't for wimps. Which is to say that at ~1100 pages it will take a bit of effort to haul this puppy around. My laptop bag is going to be very happy to not be porting this tome around once this review is sent off to Hemos. This is one intimidating book to heft as you decide whether or not to buy your copy. For this reason, I suggest buying it through Amazon. By the time you lift it for the first time it will already be paid for and you can get on with the business of learning more about CORBA instead of wondering if you will ever get through it all. Style Lots of people have a word processor, but these two really lived up to my expectations for an accessable text. Their writing style is non-professorial and never talks down to the reader. It is clear they know their topic like a politician knows a contributor, but they also seem to still enjoy what they do. Many times reading advanced topic books it seems like the author is just waddling through in order to get publicity, a paycheck or a resume item. These guys write on the subject as if they are glad to be working with the stuff. So what's in it for me? The world of CORBA. Nothing less can tell you what the information in this book is. There is simply nothing else on it's level. Once you start sifting through this one, make sure to check out Steve Vinoski's and Michi Henning's web pages for pointers to even more information. Organization The book is partitioned into major topic areas with chapters within each. The title of the book announces the intention to focus on advances topics and, while a novice programmer would have trouble with it, a competent C++ programmer with any network experience would have little difficulty jumping in and starting with just this book. That said, it does get deep pretty quickly.
The entire book is very example heavy and the first part starts the trend with an introduction to CORBA. They walk through a simple application, presenting only the IDL and code needed to get it to compile and run. After reading this section you still feel like your in deep water then take a step back and get a more introductory book to work through first. Part I is probably sufficient to get experienced programmers up and running though.
Part II focuses on the programmers interface to CORBA, IDL and the C++ mapping. These chapters reveal the flavor of the rest of the book. Highly detailed, yet emminently readable. In particular their intermingling of the technical issues with occasional paragraphs about the workings of the standards committee and the motivations behind the design are quite elucidating. It's one thing to understand the standard, but understanding it's foundation, motivation and direction is very important to becoming one of the greats.
Part III covers the "under the hood" aspects of how CORBA communicates between applications. These chapters are insteresting, but rarely come up in normal programming. The only possible use that comes to mind is perhaps in difficult to diagnose problems between vendors. These chapter provide plenty of background and details to point fingers at the right folks.
Part IV is a look at dynamic CORBA. Dynamic CORBA allows compliant applications to assemble the structures needed to communicate with servers that were unavailable, undeveloped or not even thought of at the time the client was compiled. Like Part III this section is more useful to those with fairly specific needs.
Part V delves back into more commonly used aspects of CORBA, the services. Very few CORBA systems are implemented without the naming service and as the state of the art matures more are using trading and events also. These are all well covered, including a smattering of OMG politics.
Part VI looks superficially like a heavyweight section, but even though it is hidden in the back, it's a gold mine of information. Folks implementing there first systems of any scale should make certain to read this section to assure that they don't go down a path that is difficult to recover from later.
This book is worth the price of admission and then some.
You can pick this book up at Amazon.
Table of contents- 1) Introduction
- Part I Introduction to CORBA
- 2) An Overview of CORBA
- 3) A Minimal CORBA Application
- Part II Cora CORBA
- 4) The OMG Interface Definition Language
- 5) IDL for a Climate Control System
- 6) Basic IDL-to-C++ Mapping
- 7) Client-Side C++ Mapping
- 8) Developing a Client for the Climate Control System
- 9) Server-Side C++ Mapping
- 10) Developing a Server for the Climate Control System
- 11) The Portable Object Adapter
- 12) Object Life Cycle
- Part III CORBA Mechanisms
- 13) GIOP, IIOP, and IORs
- 14) Implementation Repositories and Binding
- Part IV Dynamic CORBA
- 15) C++ Mapping for Type any
- 16) Type Codes
- 17) Type DynAny
- Part V CORBA Services
- 18) The OMG Naming Service
- 19) The OMG Trading Service
- 20) The OMG Event Service
- Part VI Power CORBA
- 21) Multithreaded Applications
- 22) Performance, Scalability, and Maintainability
:)
Yes someone who thinks the same. Buy a book that's a little bit ahead of you. One it will last a bit longer, and two you can always grow into it rather than out of it.
The Orfali book, I believe titled "Writing CORBA Applications with Java" has been my primary text to date. It is called the "Martian" book because of the cartoon little green creatures that inhabit the book. The 1st edition has white/red covers and the 2nd edition has yellow/red covers.
I don't mind reading multiple texts on a topic, but want to know up front if the new text covers new ground.
For example, the Martian book talked about how to use dynamic type discovery, but not why it would be useful to an application. (Usenet suggested that only tool writers would care.)
> NT is written in C++, Linux is written in C.
> I'll leave it to the reader to decide how valid
> this "proof" is.
I beg to differ on that point. I'm writing a kernel-mode device driver for Windows NT now, and you're more or less required to write these in C. I would be most surprised to learn that the rest of the kernel was written in C++ (even though MS claims to have an object oriented kernel).
I can heartily recommend everyone to keep a 3-mile blast radius's distance from writing NT device drivers. The design of the NT kernel is not that bad, if unremarkable, but the documentation and building environment is beyond abysmal.
So, why not use something as powerful as Objective C? It's fast, extremely flexible, and can be strongly typed.
r e f l e c t i o n s o f m y i m a g i n a t i o n
I predict that Corba's wire transfer protocol, IIOP, will outlive its C++ API. Why you may ask? Because whoever designed its C++ API knew nothing about proper C++ OO design. Take a look at String_var for example and rip your hair out - what kind of C++ string "class" needs such crude functions like CORBA::string_dup() and CORBA::string_free()?!! Any string class worth anything will clean up after itself, and handle copies and reference counts automatically. The IIOP protocol need not use such a crude binding, and many products products speak it natively. The KDE folks have already rejected the Corba C++ API and the GNOME folks also decided to roll their own as well. Why? Corba's C++ API's huge code bloat. In light of this Corba's bad C++ API no wonder people run away screaming from C++ in favor of Java. And that's a shame.
The more I use C++ the more I disagree with your
first point. Yes, C++ is big. Honestly though,
I think the language is as small as it can be,
given what it has set out to accomplish.
Operators give you the ability to write more
readable code. Templates are nothing short of
amazing.
As for your list of lacking features. You're
absolutely right about garbage collection.
However, there's nothing stopping you from using
a garbage collector. (I've used gc4 in a few
applications. Worked just fine.)
C++ has interfaces! Just virtually inherit a
base class with nothing but pure virtual member
functions.
As for standardised libraries, I think you're more
wrong than right. All the classes you've
mentioned are contained in the STL. Infact, the
STL provides a very rich set of containers and
generalized algorithms to act on them.
But that's not to say that there's nothing wrong
with C++. I'm particularly sore about its
inability to really hide implementation details.
Of course, I haven't been able to think of an
acceptable way of doing this (a seperate public
and private class definition?).
Somewhat related to the above point, I really
think that C++ should have gotten rid of the
pre-processor all together. Some sort of
implementation repository could be far more
powerful.
Lastly, I'm undecided whether C++ should really
be a static or dynamic language. I can't say that
I fully understand the trade-offs but I can say
that they complex, and there are many of them
involved.
C++ is not to blame for Corba's needless complexity.
The authors of Corba's crude and inefficient C++ API are to blame. This is one of the worst C++ APIs I have ever had the misfortune to use.
Corba's IIOP wire-transfer protocol is very simple and very similar to XDR. How they created such a twisted and complex C++ beast out of it is beyond me.
The future of Corba will be in programs that speak IIOP natively such as Oracle 8i or via DCOM/IIOP bridges.
I agree CORBA is pretty complex (perhaps needlessly so), but it is very efficient when compared to XML. The XML equivalent of a CORBA message is roughly 100X larger in size. (I'm not making this up - consult any XML-RPC web page). With the poor bandwidth of today's Internet this is extremely significant. We'll have things like CORBA and DCOM for a while yet.
The kernel, HAL, and other system components are all in C.
higher layers may be in C++ but the core OS is in C.
Unfortunately for you the world has moved on and those people who moved from C++ have gone on to Java. Objective C is increasingly being relegated to interesting also-rans.
Talk about trying to hit a round peg (CORBA) into a square hole! Anyway its doubtful that any major ORB vendor supports the major CORBA features through the C bindings.
Whine, complain!
No-one is forcing you to use C++ - anyway why don't you wait for "Advanced CORBA for Scheme" - because it'll never happen (don't quote me on that!). Anyway the audience of scheme and C++ are different - try and program an OS in Scheme, or, conversely, implement a scripting solution in C++.
I suspect a post merely to make some noise here.
Michi Henning is an active member of the MICO-Devel mailling list and his insightful remarks are much appreciated. Anyway where MICO falls behind TAO in performance, it gains in features.
Took a class from Doug Schmidt on this very topic. His lecture slides and papers on ORB implementation are available off his home page http://www.cs.wustl.edu/~schmidt/. He's also got a couple of books coming out soon, and I think one of them may address the points you're looking for.
>> * The language as a whole is too big.
> C++ is a huge language because Stroustroup, among others, believes that not just one programming metaphor (ie, OO, generic, imperative) suffices. C++ supports more than one style of programming.
This is a specious argument. Scheme supports more programming metaphors than C++, and Scheme is nearly two orders of magnitude smaller than C++. Common Lisp also supports more programming metaphors than C++, but CL is larger than C++.
Language size doesn't correlate to support for prgramming metaphors. C++ is a huge language because it includes all of C with massive bulk of (IMHO poorly designed) OO tacked on. Java also started with C as base and added OO to produce a smaller, more coherent design. (Naturally Java could take advantage of lessons learned from many years experience with C++ and CLOS. Stroustroup primarily had Smalltalk and Simula as examples.)
If you had read the book, you'd know that the CORBA::String_var type doesn't require explicit de-allocation via string_free().
In addition, _var types are "smart" in the sense that they handle the majority of memory allocation issues automagically.
Calling any "free" operation on one of these smart pointers will cause a memory exception.
andrew,
is that you ?
Even is it can't do 90% of what CORBA can do, it will someday, and it has already won by virtue of an overwhelming installed base.
No one is implementing CORBA services on the public web (if they do, they are probably violating many security rules)...its all going to be on a VPN with high bandwidth...in which case XML is a great fit as it does not tie you to any one implementation technology. You could argue that IDL is an equivalent interchange format, but lets face it, IDL's days are numbered given the amount of work going into XML.
Compare:
// bad CORBA example - will delete non-heap allocated memory.
// correct CORBA
CORBA::String_var s1 = CORBA::string_dup("hello");
to the easier to use standard C++ string class:
// correct C++
std::string s2 = "hello";
The C++ string class, on the other hand, just works as you would expect. If you try this simple assignment technique with String_var without using string_dup(), it would deallocate non-heap allocated memory it does not own when it goes out of scope. For example:
CORBA::String_var s3 = "hello";
Also, if you use a naked CORBA::string_dup() (without assigning it to a String_var), you do indeed have to call CORBA::string_free() on it.
This is what I'm talking about.
String_var is not a string class, but something similar to an auto_ptr.
You must explicitly manage CORBA string and object memory with arcane C-like constructs. And that ain't good. Granted, you may be familiar with these rules that they have become second nature to you, but you must admit these rules are far from obvious.
] A pure virtual class is an interface.
:-)
No, a pure virtual is a hack. In practice you have to mix pure virtual classes and real classes
in the inheritance tree, which gives various conflicts, since the compiler doesn't know the PVC is just an "interface"
] C++ does not include garbage collection for ]efficiency reasons
]libraries supporting garbage collection are ]available (Great Circle, for example).
This is a solution which brings its own set of problems (licensing, portability, etc.)
]What where you smoking when you said that C++ ]has no standardized libraries!!??? Have you used ]C++ in the last few years?
Yes, which is exactly my point: a few years ago,
standards weren't this far: egcs did not exist and gcc did not have STL and the standard C++ libraries. Lots of code today doesn't use STL and the standard lib.
Han-Wen (again, now logged in via my nifty new cable modem
No CORBA servers on the Internet??? Please check your facts before making such a bold statement.
Just because CORBA servers are not preceded by a browser message saying "CORBA now loading..."; doesn't mean they aren't a sizeable contribution to the Internet. As an example, I believe CNN.com uses CORBA services extensively.
Again, please read the book first to avoid making inaccurate comments about CORBA.
]C++ was designed such that you don't pay for ]features you don't use.
I question the necessity of this design consideration. IMHO most applications aren't
so time-critical. I would have preferred it if
I would have got more genericity, GC, a smaller language etc. for --say-- 50% more CPU usage.
]What does garbage collection have to do with code ]reuse?
In absence of GC, Software modules cannot work together unless they agree on who gets to delete
objects if no longer needed.
]I'll admit that most are intrusive, but if that's ]a problem, purchase a copy of Great Circle, which ]isn't.
Purchase a copy? So, how would I go about GPL-ing my application?
]Sounds to me like you don't like C++ because it's ]not Java
I'll spare you my gripes Java (which would be less
argumented; I don't use Java). Let me suffice by saying that I need a free compiler and free libraries; last time I looked they weren't available for Java.
]But I don't believe it's because of a major flaw ]in the language.
]it's a flaw in the programmers...namely, failure ]to learn how to use the language properly
I'd like to boldly say "I am flawed", but by now I am too well versed in C++. With hindsight, it has taken me a long time, and my experience that got me there is largely negative, eg.
- don't use multiple inheritance, it's too complicated
- don't use interfaces in a language with only
implementation inheritance
- try not to use templates
etc, etc.
I hope others won't make the same mistakes I
did in learning to use C++. They wouldn't if they
didn't start on it.
Han-Wen
http://www.cs.uu.nl/~hanwen/
Better tell IONA, Inprise, BEA and IBM this as they are continuing to developing their own products. Ultimately commercial concerns are what drive the OMG specs. Sad but true.
As for TAO being the "best ORB out there" - I don't have that much experience with this ORB (Mainly JacORB, MICO, Visigenics, IONA) but this is hardly a measurable statement - best supported? best features? best performance? best what? BTW I have the greatest respect for Schmidt and looking over the TAO features, do feel that this is a "good" one.
As for ORBit - the less said the better.
Outside of a few niches, its history.
"Just the fact that you need IDL is wrong. IDL is completely backwards. You describe your interface in IDL, then compile it to generate code that describes the interface in your favorite language - the same information in two places. Shouldn't the interface be generated from your sources so that it exists in just one place?"
That's really a rather complicated problem. The thing is, C++ does not specify what parts of an object are "data", i.e. fundamentally what gets transferred, and "context properties", i.e. things like pointers to other peer data structures, and more complicated things like reference counts, which must get refreshed correctly on the remote side. With some systems, this isn't relevant, because you execute in a global context of *all* processes. But for efficiency, this isn't really true of C++. As such, I wish it could be done, but I think it is, at least, very hard to do with this crappy language.
Yes, IDL is kindof clunky. FYI, Java will soon remove the requirement of an IDL compiler. It will soon generate this code automatically.
CORBA and XML/HTTP are two disjoint technologies that address disjoint problem spaces. Maybe your question should be IIOP/XML but again thats silly, it should may be SGML/GIOP but whats the point. SGML is about documents and IIOP is about a wire protocol. As such they are incomparable. Stop this madness.
As for Knuths work and this BOOK, thats like saying that the worth of the Q'ran is more than the King James new testament because it has more pages! The fact that one is written in Arabic and one in English should surely influence the size. Back to the subject, Knuths work is a rather terse and scholarly exploration of *FUNDAMENTAL& algorithms whereas Henning/Vinofskis work is a rather thorough exposition of a rather thorough specification.
> 2. C++ is missing some features like garbage collection.
>
> C++ is also missing a built-in mail client, a recipe for ice cream, and fourty-two flavors of regex processing.
>
> You want a feature, there are 1000 different sources for them.
I've seen some big C++ programs that implemented (partially) the functionality of mail client or regex.
However, I've never seen a _real_ C++ program which uses garbage collector mechanism. Some academic samples, yes. But not for real-world programs. It just doesn't fit the language paradigm.
Being C++ programmer with more than 10 years experience, recently I worked on some projects invoving Java and Perl and found that built-in garbage collection is a Good Thing in most cases.
(Not always, of course. There are embedded systems or real-time, etc)
And it's not something you can easily add to language, like libraries. It changes the way you think in the language. (Well, to tell the truth, usually I think in Perlish anyway and than translate it to english, C++, etc)
So, I doubt anyone will use garbage collection in C++. I will not, at least. C++ is C++.
And it's not so bad, actually.
What's wrong with you? Grow up. What's the point of insisting that so-and-so language is dead?
XML messaging over HTTP in xml-rpc is nothing more than a well-formed (structured) CGI (HTTP POST) call. Period.
Repeat: The only thing you gain from passing XML/RPC2 data over HTTP through the POST mechanism (over plain jane CGI/Servlet/etc.) is an incomplete but relatively well understood 'data' (not object) marshall/unmarshall protocol.
Now to go from there to a 'distributed object system' entails a _great_ deal of extra structure both on the server AND the client.
[For example, think about what it will entails to move up from RPC to RMI -- i.e. adding object discovery/binding/etc. - when using XML-RPC. And that's a trivial step up, compared to what else is required.]
SO: By the time you build such extra layers _around_ xml-rpc what do you think you will have? A non-standard (because _you_ added the layers), and most likely inefficient little private protocol.
I agree that CORBA leaves a lot to be desired, but the comparision being made here is uninformed.
/regards/
The guts of NT is mostly written in C. (almost everything under the hood) The UI and a lot of the stuff above the lowest levels is written in C++.
You can use C++ in kernel mode, but you can't use exceptions and it's not supported (They don't want to help you out). Nevertheless it can be done, and a lot of the stuff coming from the Death Star uses kernel mode code using C++.
In most cases it seems as if the Blue screen of Death is directly caused by the shitty examples for device drivers and crappy tools and support for kernel mode code.
There is some argument as to whether there would be more or less BSOD if there were more and better samples of kernel mode code and support of C++.
My friend who has written an extensive amount of it swears that most BSOD would go away if C++ was actively supported for kernel mode code.
BTW, fear for the days when customers wake up and are willing to pay for commerical out of the box stability over features or FUBARED benchmarks showing that thing X performs 3 times faster than Y. M$oftware blue screens mostly because the designers are addicted to the kernel mode speed like movie stars on heroin and this is why NT crashes. When customers start going linux for stability there _WILL_ be a shift toward stability and you will see NT become rock solid as they get BackOffice gets rid of its kernel mode hacks.
"Just say no to kernel mode."
"Error handling code has been eliminated for clarity and brevity."
Get TAO--it's free and comes with full source. Pretty nicely packaged, with docs and all. There's a lot of stuff on Doug Schmidt's page--papers, etc., some of which talk (on the high level though) about implementation issues. I don't know of a single ORB-implementation book, so you might need to read the papers and talk to people who work there and, finally, read the code. And of course, this implementation it is but one among many possible, so keep that in mind. There's a lot of material on RPC (it's an older technology), but again, it's all in papers and theses. Search for Brian Bershad--he's got a lot of related stuff available.
bookpool.com is nearly always cheaper (and significantly so) The downside is they only sell computer books and only the current ones. With respect to "Corba with C++" that is not a downside, or course.
I think this is somewhat true. But so what? At least it takes a lesser effort to learn that stl for example, which bs wouldn't criticize of course. Most of the comments I see on this site must be coming from web-heads considering html some kind of very advanced communications technology making comparisons of corba with this _protocol_ (corba isn't a protocol.) That is comparing apples with oranges. No, it's more like comparing apples with flying high. Nonsense. Whoever needs corba in their work, has to learn about it--this book is pretty good to start (and continue) with. It's well written, has no highfalutin phoney professorly gobbledegood (that the books of Mr. Box, for example, are full of) and it covers the practical matters that you'll need the moment you want to write a single line of corba code.
If Lisp is not more widely used is because most software people are just too dumb.
I erred in my previous example:
// bad CORBA example - will delete non-heap allocated memory.
CORBA::String_var s3 = "hello";
The string literal "hello" is of type "const char*", and as result, a deep copy of the string would have been performed, and no error would have resulted. A shallow copy would be performed only if the constructor or assignment operator argument had been of type "char*". The corrected bad example:
// bad CORBA example - will delete non-heap allocated memory.
char* t = "hello";
CORBA::String_var s3 = t;
But I still stand by my contention that CORBA's C++ mapping is clumsy.
Its not viable to rely on programmer competence or diligence or the SW engineering process to prevent memory leaks, pointer errors, fencepost errors or any of the other problems that dog C++ developers.
I guess all the C++ code I wrote in the last 10 years is not viable then. I will instruct the financial companies and telcos who use it daily to throw it all out immediately.
Give me a break.
Face it - some people know how to design code and some people (regardless of language) will never know.
Another tip - buy yourself a copy of "Purify" from Rational.
The fact's are this: Berlin probably won't go anywhere without major commercial support (like X has.) Until it gets that support, it's just another open source toy.
Uh, no, I'm a programmer. I never wrote a proggy that used CORBA, but I write a lot of stuff that uses the standard C++ library. I'm glad it won't be hard to get coding CORBA with this book.
OTOH, I do think that component stuff is useful, but it would be better if the C++ bindings leaned better on the standard lib and features such as type-safety. I'm quite confident that we'll be seeing such stuff in 1-2 yrs.
The basic arguments I keep hearing are:
1. C++ is bloated, it has too many features.
No one forces you to use all the features. Features which you do not use do not bloat your code. Even though I personally find almost all of C++ features useful in some way, I do not use 100% of them every time I start a project.
Things such as multiple inheritance (which I find extremely useful especially when it comes to CORBA), operating overloading and what not are there to help simplify your code...
I think this is probably one of the few times people have complained that something has too many features.
2. C++ is missing some features like garbage collection.
C++ is also missing a built-in mail client, a recipe for ice cream, and fourty-two flavors of regex processing.
You want a feature, there are 1000 different sources for them.
The addition of things such as garbage collectors, bounds checkers, etc *would* bloat the executable.
3. C++ is too complicated, I can't understand it
This is probably one of the sillier arguments. Just because you don't undersatnd it doesn't mean no one does. C++ and other languages based from it (Java), are easy to understand and work with once you understand the principals.
If you are used to using languages which are not similar to C++ and provide OO features, then you will be confused.
I just find it stupid that someone would consider using an underdeveloped, nonstandard, and completely unsupported language because they don't like the way C++ code looks and they don't understand how it works.
These are the same people who write new SMTP servers from scratch because they didn't like the configuration file format of existing ones.
--
The world is neither black nor white nor good nor evil, only many shades of CowboyNeal.
I don't know what gave you that impression. Writing CORBA in anything but an object-oriented programming langauge is an extremely difficult thing to do because the CORBA bindings for things like C try to emulate OOP.
C++ itself is a fine language. It's been proven that above about 50k lines of code, C++ is far more efficient to work in than C and simply easier to understand.
What really bugs me are the people who say C++ is complex because it features things like operator overloading. This always struck me as funny, just because a feature exists doesn't mean you have to use it.
And C++ is well accepted. BeOS uses it as it's primary application development language as does Windows. Until recently C++ was horrible to develop for under Unix because of the poor compiler support, but Egcs has changed that.
Now I don't want to start a language war, but really... is there any real reason why C++ is a bad language or is it because you simply don't understand it?
--
The world is neither black nor white nor good nor evil, only many shades of CowboyNeal.
Since despite plans for future use of Java in MacOS X's YellowBox, Apple is offering classes in how to program in Objective C today. All of the major applications in Mac OS X that I've seen (OmniWeb, all the administration stuff, etc.) is written in Objective C.
It's still a very viable alternative, and recieved a major blood tranfusion with Mac OS X.
--Matthew
It's a hack, but worth it on large, multiuser projects - .h file looks like this
class SomeImplementation;
class SomeInterface
{
SomeImplementation *imp_ptr;
public:
void method1();
etc...
};
It's a slight pain because programmer needs to instantiate SomeImplementation in SomeInterface constructor and then pass all methods onwards:
void SomeInterface::method1()
{
imp_ptr->method1();
}
etc
It's only worth doing on classes that provide interface between major modules (eg between one programmers area of responsibility and anothers) - but worth it since implementation changes never require recompilation of client modules.
http://rareformnewmedia.com/
It isn't surprising that many systems (and books about them) are smaller than the applications (and books about them) written on top of them.
X is bigger than Linux.
GIMP is bigger than the Standard C Library.
Why should it surprise you that a CORBA book is bigger than a book on fundamental algorithms?
PS: I have both books and they are both great.
--
Marc A. Lepage
Software Developer
This is the new standard text on CORBA development. Its great win over the "CORBA in 2 seconds" type of book is that it is concerned with the standards, not the whizz bang but completely incompatible extras that the vendors love so much.
As an aside, I recommend TAO as an ORB to go along with the book. If you don't need multithreading then MICO would also be a good choice.
-- Thorin sits down and starts singing about gold.
Good thing the reviewer isn't a guitarist. He would be pretty sick and tired of carrying around a guitar, tons of cables, a pack of effects, at least one Marshall and a power plant. Oh, yes, not to mention about a billion picks. How come your new picks always disappears and gets replaced by old, crappy ones?
War is one of the most horrible things a human can be exposed to. And one of the worlds largest industries.
http://www.random.org/corba.html This site allows you to get random numbers via a CORBA interface.
> Writing CORBA in anything but an object-oriented
> programming language is an extremely difficult
> thing to do because the CORBA bindings for
> things like C try to emulate OOP.
I disagree. Once you understand the C bindings,
they are just as easy as the C++ bindings.
> C++ itself is a fine language. It's been proven
> that above about 50k lines of code, C++ is far
> more efficient to work in than C and simply
> easier to understand.
It's been proven that 9 out of 10 statistics are
drawn out of thin air and are worth the paper they
are printed on. NT is written in C++, Linux is
written in C. I'll leave it to the reader to
decide how valid this "proof" is.
The whole CORBA thing feels too complex for the simple tasks its trying to accomplished.
Just the fact that the book reviewed here is 1100 pages, tells me that something is not right. After all Knuth's "Fundental Algorithms" is only about 600 pages. And the content of Knuth's book is much deeper. :-)
...richie - It is a good day to code.
I don't know. The Web seems to work fine with HTML and http. If CORBA made such a tremendous difference why are there no CORBA servers on the Internet?
...richie - It is a good day to code.
- Write and exchange general-purpose documents in IDL format
- Implement a desktop environment using XML and HTTP
I would not want to think about the first, but the second is a quite interesting proposition. If every object on your desktop has a URL then maybe you could get to your desktop from any machine on the internet.
Anyway, have you heard of WIDL? Take a look...Keep in mind that nearly every machine connected to the Internet has a web server.
...richie - It is a good day to code.
OK. I stand corrected...(but can I write code that runs on my computer that calls the CORBA services on CNN.com?)
...richie - It is a good day to code.
Would it be useful for broad in-process use? (no)
Explicit is not always bad. Especially when you have to debug. :-)
For the second point, you are saying that for communication within a single address space http/XML is overkill. Right?
But isn't CORBA also? Even if the remote call gets "reduced" to standard call for performance reasons, it's still seems like a lot tedious work for the programmer.
And, I suppose my challenge still stands: could you implement something like Berlin, completely replacing CORBA and C++ with WIDL(XML)/HTTP and your language of choice?
Too bad I already made plans for this weekend... ;-)
In the future there will be more networked devices, most of which will talk http, so the idea of a UI based on http/XML is not so far fetched. I'll probably look different than today's desktops and I have no idea what it might be like...
...richie - It is a good day to code.
When you pass a message to a program it can do any complex task you want. Only the app code will be more explicit (i.e. you will see that you are doing a network operation, rather than pretend that it's a function call).
A Web server is a simpler thing that exposes an interface to the network (http/XML) and various programs can communicate with it using messages that are readable by humans (to an extend).
Why not imbed an http interface into an app and use it along with XML for message formatting for communications.
Just the fact that you need IDL is wrong. IDL is completely backwards. You describe your interface in IDL, then compile it to generate code that describes the interface in your favorite language - the same information in two places. Shouldn't the interface be generated from your sources so that it exists in just one place?
What exactly do you use CORBA for in Berlin? D-n-D?
...richie - It is a good day to code.
This book answered a ton of questions I had about
CORBA, and how to work with it in a real-world
environment.
There are easily a dozen crappy books out there
that give you the worthless "manager-level"
overview of CORBA technologies, but I have yet to
see one that provides the important details you
need to actually get a CORBA client and server to
get together and do something useful.
If you want to program CORBA, buy this book!
> You could argue that IDL is an equivalent
> interchange format, but lets face it, IDL's days
> are numbered given the amount of work going into
> XML.
... XML is an interchange format, IDL is an interface definition format. Two entirely different problem domains... where are you getting these strange ideas from? CORBA/IIOP, for which IDL is generally used for defining object interfaces, is not there to replace XML/HTTP, it's there to transparently glue applications together out of objects scattered across a (potentially) heterogeneous LAN or (less frequently) WAN.
That's quite different from the enforced (and explicit) client/server split enforced by XML/HTTP "applications" (if you can call them that). Which is not to say that XML/HTTP is going anywhere either; it's very very good for document interchange... just, I don't see how it's really any use for implementation-independent distributed execution, which is what CORBA/IIOP addresses...
Now, as for IDL, you can probably define an XML DTD for interface definitions, but it'd be almost by necessity be trivially transformable into IDL anyway, and quite useless for document exchange.
My challenge to you:
- Write and exchange general-purpose documents in IDL format
- Implement a desktop environment using XML and HTTP
When you have done these things (IF you can find a way to do these things), you will understand what each of these standards are meant to do, and what they are not meant to do.
---
DNA just wants to be free...
HTTP and IIOP address two different problem domains: delivering data versus RMI. There's absolutely no reason why they can't coexist.
---
DNA just wants to be free...
When you pass a message to a program it can do any complex task you want. Only the app code will be more explicit (i.e. you will see that you are doing a network operation, rather than pretend that it's a function call).
Indeed. Except that something like WIDL _forces_ you to draw the in-process/out-of-process lines at design/compile time, without giving you flexibility to redraw them later. I think.
A Web server is a simpler thing that exposes an interface to the network (http/XML) and various programs can communicate with it using messages that are readable by humans (to an extend).
That is very true. The value of human-readable (text) protocols are often highly underestimated.
Why not imbed an http interface into an app and use it along with XML for message formatting for communications.
You're talking about replacing IIOP with XML over HTTP... depending on what you're doing, that's a massive amount of overhead compared to the same thing done with IIOP. Absolutely incredibly massive. (for some things, like I think the intended applications of WIDL, the RMI calls aren't going to be that frequent, so you can afford it)
Just the fact that you need IDL is wrong. IDL is completely backwards. You describe your interface in IDL, then compile it to generate code that describes the interface in your favorite language - the same information in two places.
Mmm... yes and no; what it actually generates is a partial implementation of that interface. That being said, IDL's way of doing things still does strike me as kind of funky.
Shouldn't the interface be generated from your sources so that it exists in just one place?
I could provide an analogy, like "Shouldn't the object code be generated from your sources so that [your code] exists in one place? [As opposed to generating assembly and then assembling that to the object code.]". I think that's mainly a property of the way most build environments and compiler frontends are set up. If the compiler frontend would take IDL directly, that step would be hidden too.
I'll have to think about this some more; there is an additional component of having the interface and implementation split into separate source files. (but, is that a bad thing?)
What exactly do you use CORBA for in Berlin? D-n-D?
It's pretty pervasive, actually. Used for quite literally everything. Everything. Have a look at the design documents; I think they do a better job than I can at explaining it.
---
DNA just wants to be free...
Is there any good reason to use CORBA instead of simpler things, like http protocol and (let's say) XML?
XML is a static data format (yes, XSL adds some rather interesting "intelligent" transformation capabilities, but even so). Similarly, HTTP is a (relatively) simple (mostly) unidirectional data transfer protocol. I really don't understand how either can be compared to a distributed object model. Their uses, capabilities and so forth are entirely different.
The whole CORBA thing feels too complex for the simple tasks its trying to acomplished.
What simple tasks? CORBA is not primarily a standard for document interchange, it's a standard for allowing distributed objects to communicate to implement arbitrary functionalities (which may or may not have anything to do with documents, as such). Although, I wouldn't be very inclined to use it for most web stuff, if that's what you mean.
In any case, the uses to which CORBA is most successfuly put are certainly not simple -- take the Berlin project, for example. I really don't see how XML and HTTP would be suitable for implementing a desktop environment.
---
DNA just wants to be free...
The guy was definately flame-bait, but he did mention that his language of choice is Scheme. There are few languages as object oriented as Scheme & Lisp. However elegant either language might be, though, I think you'll find few production systems using either. Given that, I can see how one can be easily drawn to the Lisp derivatives' simple elegance...
--Be human.
There are several reasons why C++ is a bad language. People not understanding it is one of them, oddly enough. When a language becomes complex enough that someone who has read the standard reference work has trouble reading other people's well written code, you know you have a bad language. Its that simple.
Other reasons why C++ is bad: The handling of templates is just plain wrong. Do proper generic types or do nothing. Operator overloading makes code hard to read, especially when the set of operators is fixed (as in C++). There are legal constructs whose behaviour is undefined. There is no real support for garbage collection, whatever Stroustrup may claim. The standard libraries are template obsessed and hopelessly incomplete. It is pass by value, which is inappropriate for an OO language. Compilers differ massively in even fairly simple things. Multiple inheritance is usually unnecessary and the C++ form of it is overcomplicated
To pick you up on two specifics: It is never sufficient to say "you just don't understand it". If it is that hard to understand, it sucks.
Similarly, language features that are brain-damaged cannot be compensated for just by not using them. Other people, including your colleagues, will use them, and you will have to deal with their code.
Firstly, I should stress that I'm a Java programmer, and while I have some affection for some "completely unsupported languages" I'd use C++ ahead of them for pragmatic reasons. You replied to my post by repeating exactly the points I thought I'd just dealt with. So I'll repeat myself as well.
1. Featuritis. C++'s feature-overload is not bad because it bloats the code - they managed to avoid that. Its bad because it makes the code hard to read and the language complicated. C++ bares no relation to any other object orriented language, least of all Java, whose design is quite sane, at any level other than syntax. The designers have headed off in a distinctly odd direction, whose value is very dubious.
You can keep saying "you don't understand it, you're just STUPID" as much as you like, but it won't make C++ better. The point is that I have to understand the complexities of every single spaced-out language feature, from templates to pass by value to inadequate operator overloading and their wacky implementations in every single compiler before I can be sure of understanding someone else's code. None of that contributes one bit to the work of programming. Its just cruft. It makes it hard to reuse code and hard to organise project teams.
C++'s design violates the "worse is better" principle. They just keep throwing more stuff in, in the hope of making it into a usable language, and it just never works, because the problem is it was hopelessly ill-conceived to start with. Languages are like applications - they should do something and do it well. C++ tries to be all things to all people and does none of them well. "There is more than one way to do it" is all well and good for Perl, but for systems languages it doesn't cut the mustard.
2. Missing features C++ claims to be an object orriented language for large-scale projects. Compared with C, I won't deny that, but compared with anything else it is laughable. Its not viable to rely on programmer competence or diligence or the SW engineering process to prevent memory leaks, pointer errors, fencepost errors or any of the other problems that dog C++ developers. The only way to fix these things is to build features into the language that make them impossible.
I guess all the C++ code I wrote in the last 10 years is not viable then. I will instruct the financial companies and telcos who use it daily to throw it all out immediately.
Maybe 'not viable' was a bit extreme (not to mention vague), but you cannot suggest (as a previous poster did) that C++ plus a bit of discipline and a copy of purify is as good as a language which is inherently proof against many of the errors C++ programmers produce so regularly. Did I say it was impossible to write decent C++ ? I've used purify, and I've written plenty of C++. There are other things you can do to make it a saner development language as well as using Purify. The point is that you shoudln't have to. If the language had been designed better, none of this cruft would be necessary. I won't suggest you made the wrong language choice (not 10 years ago at least) or that your employers should chuck the code out, but its possible they could have saved a lot of time and money.
Face it - some people know how to design code and some people (regardless of language) will never know.
That will always be true, with the caveat that most of the issues WRT to C++ primarily concern implementation and reuse, although they do affect design. Tracking garbage, for instance, is nothing to with OO design, but warps the construction of many C++ programs beyond all recognition.
The industry as a whole has to accomodate lower quality programmers though. Not everyone can afford to hire geniuses and recognising them is notoriously difficult. C++ hinders the necessary compromise by making it possible for those who are going to write bad code to do that much more damage.
Whether competence is measured by ability to wrestle C++ to the ground is another matter entirely.
* The language as a whole is too big. One could
decide not to use the entire language (eg. leave out the operator overloading), but that is likely to give longer and less efficient solutions, which defies the point of using C++ in the first place: having very fast, compiled OOP programs.
* The language lacks features that make it difficult to reuse code: for example
- garbage collection
- interfaces/signatures
- standardised libraries--almost every C++ program I've seen comes with its own list, array
and string classes.
* Any reasonably big project is going to have
extra infrastructure (an embedded language, a component/module architecture, etc.). Using C++ pushes this point somewhat into the future. But when this point is reached, you have more code to convert, and you also have to deal with the messy semantics of C++ which will be in your class structure.
Han-Wen Nienhuys -- LilyPond
As was pointed out by many other people, in one sense, comparisons between XML and CORBA are somewhat silly since they address two very different problem domains.
In another sense, comparing them reveals a fairly deep insight into what's really going on with these two technologies. Both CORBA and XML, are, in a broad sense, attempts to address the problem of messaging (getting two different programs that don't have anything to do with one another to communicate (pass data back and forth when they don't share any address space) properly).
In my opinion, there are two axis on which one can judge a messaging technology. One is efficiency, and the other is coupling.
For example, one common method that people used to use to write programs that had to talk to one another was to directly dump program data memory (write structs) into whatever data stream you were using to communicate with. This is off the scale on the coupling axis, but has the advantage of being generally very efficient. Because the coupling between programs that communicate this way is so high (it's so high that two programs sharing a common code base, but compiled for different architectures may not be able to communicate) this approach is usually dismissed.
XML is very, very low on the coupling scale. There's even a standard describing high semantic content meta data that's used to describe the messages being exchanged. On the other hand, it's also very low on the efficiency scale. You have to translate all of your data to a structured framework of textual tags with largely textual content. This makes XML suitable only for applications in which low coupling is at a premium. Long term archival storage, or transmitting data across the net between diverse, unrelated parties are two examples of such applications.
CORBA has higher coupling. The two programs have to agree on the function call interfaces that will be used to communicate. It's also more efficient. The data is translated to a binary form that's negotiated between the parties so that there's a minimum CPU time cost in the translation. So CORBA occupies sort of a middle of the road strategy. It's perfect for things like GNOME, where you can count on all the applications using the same toolkit, but not necessarily running on the same architecture.
I think CORBA's coupling is too high though. Also, it's reliance on a function call style model encourages the development of messaging protocols that are highly inefficient due to excessive round trip messages. I'm currently working on a somewhat different architecture that concentrates heavily on having a machine independent way of describing the content of an efficiently encoded message which I will call CDL (Common Data Language). The semantic coupling implied by CORBA's function call model would be absent because the architecture wouldn't describe the messages in terms of function calls, but merely in terms of the data to be exchanged. This pushes it much closer to XML on the coupling axis.
Anway, this is a topic with a lot of subtleties, and one that I'm very interested in. If any of you want to talk about messaging and messaging architectures, I'd welcome the exchange of ideas.
If anybody wants to help me build this thing, I'd also very much appreciate it. Be warned that it's written in C++, and I'm NOT going to do it in C. C's expressive power has been long eclipsed by C++, and it's high time that people stopped complaining about how complicated it is and actually learned something new. The Open Source community's penchant for simplicity is laudable, but C++'s power is well worth the complexity.
Need a Python, C++, Unix, Linux develop
Well I bought this book last week and have never worked in CORBA before - I've yet to get round to reading page one as I've been a bit busy gutting an old app to make space for some calls to a third party CORBA object.
The review says its an excellent book (as did Amazon) but mentions that a more basic introduction could be good - does anyone have a real recomendation for a companion text to this for the CORBA virgin.
I want the depth this book promises but I've yet to see a good basic introductory text go to waste.
Tom
Besides I have always got on better with advanced text books than basic ones, give me a language reference over a "learn xxx in 21 days" any day.
In my experiance, advanced text books tend to mean for people who have a solid programming background. Just right now I'm under a lot of time pressure.
Tom
Why didn't they revamp the acronym to be Common Object Brokering of Resources Architecture so it could be COBRA, that's a lot more flashy and cool sounding. Then there would be all these cool products called mongoose, venom, fang, mamba, viper, garter, side winder, cotton mouth, riki tiki tavi, etc.. I think the whole snake theme would make it much more popular. I think that's one of the big differences between free projects and non-free projects, when given the choice the free guys will always pick the cool name.
This is my signature. There are many signatures like it but this one is mine..
My masterthesies will include implementing some CORBA functionality and I have looked for a good book on this, i.e not the usual How-to-write-a-program-using-CORBA book more like a How-to-implement-an-ORB book.
Is this book something for me?
Does anyone have any links och suggestions for books?
Thanks
What do you think?
--exa--
I do understand that the evolution of standards can be painstaking. (I wrote an almost complete DICOM implementation) The compromises don't always lead to the most elegant or desirable solution.
However, a mapping as you describe would be perfect. Though I won't be holding my breath. Till then, the wisest thing to do is keeping your book as the CORBA-with-C++ guide.
--exa--
It' a really great book. I'm wondering why
it got 9 and not 10 points.
It also shows how much C++ complicates things
because of the missing garbage collector and
how complicated it is to use dynamic
invocation with this static language.
I've got a feeling someone could learn CORBA from this book, but please don't hold me to that.
It's certainly worth the money AND the size of the book (good thing slashdot's reviewer isn't a drummer -- he'd get tired of carrying around his drum kit all the time).
"He who questions training trains himself at asking questions." - The Sphinx, Mystery Men (1999)
In theory, at least, using CORBA doesn't tie you in to any particular vendor any more than XML does, since CORBA is standardized. Of course this won't be true in practice for a while.
XML is a good way for applications to exchange data, but it is not a great way for applications to call other application's code in a language independent way. Aside from all the network stuff (which many see as the raison d'etre of CORBA), CORBA and COM are good at providing a language independent interface to shared libraries and applications. That's why Gnome and KDE are using CORBA to provide OLE style linking and embedding, and sharing of common modules. XML doesn't even begin to address this sort of thing.
--------------------------------------
Stephen Molitor steve_molitor@yahoo.com
A few retorts:
1. C++ does not include garbage collection for efficiency reasons. However, if you want it, libraries supporting garbage collection are available (Great Circle, for example).
2. A pure virtual class is an interface.
3. What where you smoking when you said that C++ has no standardized libraries!!??? Have you used C++ in the last few years? Check out something called "The Standard C++ Library," part of the ISO C++ standard, and included with every modern C++ compiler. It has standard classes for strings, lists, vectors, i/o, etc.
---------------------------------------------
Stephen Molitor steve_molitor@yahoo.com
Here it is at amazon. Spyky
> * The language as a whole is too big.
C++ is a huge language because Stroustroup, among others, believes that not just one programming metaphor (ie, OO, generic, imperative) suffices. C++ supports more than one style of programming.
> One could decide not to use the entire language, but that is likely to give longer and less efficient solutions
C++ was designed such that you don't pay for features you don't use. The only feature I'm aware of that will cost without being used is exceptions. That cost is compiler-dependent. As for longer less efficient solutions, anything you can do in C++ you can do in C (For evidence, look at the Kuck and Associates C++ compiler, which compiles to C, or cfront), but do you want to do it by hand? The question of efficiency in this case is again dependent on the compiler. The important point is that the size of the language does not affect the size of your programs.
> * The language lacks features that make it difficult to reuse code: for example
> - garbage collection
What does garbage collection have to do with code reuse? If you want garbage collection in your C++, there exist many implementations you can compile into your code. I'll admit that most are intrusive, but if that's a problem, purchase a copy of Great Circle, which isn't.
.45 to a monkey." Perhaps this is true, and I've seen some cases of programmers shooting themselves in the foot with C++. But I don't believe it's because of a major flaw in the language. I'd suggest it's a flaw in the programmers...namely, failure to learn how to use the language properly, failure to separate what's "legal" C++ from what's "moral" c++ This happens in other languages all the time as well. C++ has a high learning curve to use it effectively, but I think that curve is well worth it.
> - interfaces/signatures
abstract base classes in C++ serve the exact same purpose. Having a separate interface construct would simply be syntactic sugar, which isn't a bad thing, but imho it's not worth the bother in this case, as opposed to operator overloading where it serves to create intuitive abstract data types.
> - standardised libraries
The most recent C++ standard has a standard library including string, list, and array classes. Many compilers do not yet fully implement the spec, but third parties supply Add-ins for just this purpose. For example, before egcs provided the support that it does support (not yet complete, but it's coming), ObjectSpace offered an implemention of the Standard Library for g++.
Sounds to me like you don't like C++ because it's not Java. That's fine. Different strokes for different folks.
I once saw a quote somewhere that said something along the lines of "giving C++ to the average programmer is like giving a loaded
There are only two kinds of programming languages: those people always bitch about and those nobody uses.
As far as C++ is concerned, this is a necessary design consideration. GC is problematic in the context of realtime system design, which is one situation where C++ is used (remember where C++ was designed -- Bell Labs). Perhaps better hooks could have been added for GC, but there already exist GCs for c++, so I guess it wasn't too hard.
>re: Garbage collection
> Purchase a copy? So, how would I go about GPL-ing my application?
That's hardly a language issue. And there already exist other free GC implementations, but Great Circle appears to be the best. If they're not good enough, write your own or use a different language (a perfectly reasonable option given a set of tradeoffs).
Personally, I've gotten by quite well without GC. That doesn't mean I won't look into it to see if it improves my code in the future. But bear in mind that GC is only a partial solution to a greater problem, that being "resource allocation" as a whole. Memory isn't the only thing that needs to be released. Think sockets, threads, etc. As far a code reuse, some component of the code must be responsible for ownership of these resources as well.
> I'd like to boldly say "I am flawed", but by now I am too well versed in C++.
Given your set of rules for using C++, I'd suggest that you could still be better versed in C++ (and I'll gladly admit that the same applies to me). Each of those features has its uses in the proper context. To simply write them off is not necessarily the proper decision. Learn the tradeoffs involved in using them and you can definitely find situations where they're useful. I personally use all the features you mentioned, but only where I see fit.
I don't mean to carry on a language war here, and I would not dare suggest that C++ is perfect...but I think I've developed a reasonable foundation in its use and dislike seeing misinformation passed around about what could possibly be a useful tool for someone. Given the number of opinions going either way about the language, I would suggest to anyone curious about the language to do some research yourself into the pros and cons. It's the only way you'll really know if it's right for you.
There are only two kinds of programming languages: those people always bitch about and those nobody uses.
For those of you who aren't fans of C++ but would like to learn CORBA, I still recommend purchasing this book. The explanation of features and architecture is simply splendid. A copy of this book and the chapter of the OMG CORBA spec corresponding to your preferred language will do wonders.
There are only two kinds of programming languages: those people always bitch about and those nobody uses.
I thought that the book was good at being honest. They did not hesitate to point out the weaknesses of CORBA or pieces where the design may have been a mistake in hindsight.
It is a great book!
Sure, as long you have the proper security rights, which admittedly can be a challenging task.