Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. ×
News Books Media Book Reviews

Review:Advanced CORBA Programming with C++ 102

Thanks to rw2 for taking some time to review Michi Henning and Steve Vinoski's Advanced CORBA Programming with C++. For more information on this book, click below.
Advanced CORBA Programming with C++
author Michi Henning & Steve Vinoski
pages 1120
publisher Addison-Wesley
rating 9/10
reviewer rw2
ISBN
summary A much anticipated book that lives up to it's promise.

Waiting

I've been programming in C++ for a long time and started working with distributed applications using RPCs and sockets. When I moved on to CORBA lots of things got much easier. Learning CORBA though, wasn't one of them. There has been a perpetual dearth of good materials to learn from. Through C++ Report I was familiar with Steve Vinoski's writing style and experience base. He is always an easy read. A welcome change in what can sometimes be a twisted topic.

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
This discussion has been archived. No new comments can be posted.

Review:Advanced COBRA Programming with C++

Comments Filter:
  • by Jordy ( 440 )
    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.

    --
  • by Jordy ( 440 )
    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?

    --
  • 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.
  • Outside of a few niches, its history.
    One of the niches being, oddly enough, graphical programming. Yup, there's not much life left in that field.
  • 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.
  • 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.
  • 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.
  • 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?
  • http://www.random.org/corba.html This site allows you to get random numbers via a CORBA interface.
  • by tlewis ( 2921 )
    > 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.
  • Who cares what the CORBA vendors do when there are
    such great free ORBs? ORBit supports C, and even
    among C++ ORBs, TAO is probably the best ORB
    out there, and it's free, too.

    CORBA vendors are about as important as compiler
    vendors these days.
  • Is there any good reason to use CORBA instead of simpler things, like http protocol and (let's say) XML?

    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

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

    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

  • My challenge to you:

    - 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? [w3.org] Take a look...Keep in mind that nearly every machine connected to the Internet has a web server.

    ...richie

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

    OK. I stand corrected...(but can I write code that runs on my computer that calls the CORBA services on CNN.com?)

    ...richie

  • Looks interesting. And useful. However, it also enforces an explicit client/server model. You get RMI, but the "remote" is always very explicit.

    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

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

    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

  • 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.
    ---
  • HTTP and IIOP address two different problem domains: delivering data versus RMI. There's absolutely no reason why they can't coexist.

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

    URLs don't imply either XML/HTML or HTTP, though.

    Nor do I think you could do a particularly useful desktop via XML/HTML alone without a supporting technology such as CORBA or COM getting involved somewhere.

    > Anyway, have you heard of WIDL? Take a
    > look...Keep in mind that nearly every machine
    > connected to the Internet has a web server.

    Looks interesting. And useful. However, it also enforces an explicit client/server model. You get RMI, but the "remote" is always very explicit.

    Would it be useful for broad in-process use? (no)

    Again, I don't see it as competing with CORBA; the two just aren't quite in the same problem space, although there is obviously some overlap. (where the overlap occurs, for many applications I probably would choose WIDL)

    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?

    If so, would it be practical?
    ---
  • 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.


    ---
  • Explicit is not always bad. Especially when you have to debug. :-) You can force things to be run out-of-process in CORBA, too, but if you later decide you want them to be in-process, you don't necessarily have to subsequently rewrite (or recompile) any code. For the second point, you are saying that for communication within a single address space http/XML is overkill. Right? You can wrap pretty much anything to be convenient for the programmer; the question is whether or not the runtime overhead is worth it. 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. Having toyed with CORBA a little myself now, I'd have to say that it's really not that evil at all. Even the fearsome memory management funkiness that most people complain about goes away if you use the _var types, which you are supposed to. 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... I'm suddenly getting visions of an environment using an XML-based language (a la Postscript) for the display engine. :P Which might not actually be bad. I dunno. I think Berlin is going to end up being a major test case for CORBA's utility and viability.
    ---
  • 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.


    ---
  • 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...
  • by SimonK ( 7722 )


    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 .... I could go on.




    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.

  • by SimonK ( 7722 )

    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.

  • by SimonK ( 7722 )

    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.

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

  • 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
  • yes so do I - but personally I belive in buying books which will still be useful in a years time.

    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.
  • It's substantially better than the "Martian" book.

    The Martian book is littered with errors and
    inconsitencies and the code is all but useless as
    anything but a basic reference. Though, like the "Martian" book, it covers POA, which is nice since
    pretty much none of the other books do.

    "Advanced..." is really good if you're looking for
    in-depth info on CORBA and the COS specifications.

    -tim
  • 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
  • In a technetcast interview [technetcast.com], Stroustrup states that C++ bindings for CORBA are primitive and biased towards C.

    What do you think?

  • yes, yes, but you know COBRA implies male genitals as well... ;)
  • 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.

  • by koma ( 27783 )
    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.
  • .... a few months ago, only because bookpool.com didn't have it -- and the book arrived a little over a month ago.

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

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

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

    ---------------------------------------------
  • Here it is [amazon.com] at amazon. Spyky
  • If you're looking for a good introduction to CORBA concepts, check out this article by Steve Vinoski (here) [iona.com]. It does a good job of explaining the "whys" of CORBA. Don't be intimidated by the "Advanced" in the title. The book goes into the basics of implementation, just not detailed coverage of why one would use CORBA.

  • Fine, I'll bite:

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

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

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


    What do you dislike about the C++ mapping of CORBA? Just curious...
  • > The ownership of C++ CORBA's strings and objects are extremely convoluted.

    Isn't that what the *_var wrappers are for? For example, using a String_var instead of a String_ptr takes care of ownership and memory management. Plus there exists a *_var for every CORBA object and pseudo-object. I suppose that in this manner, one could handle memory management oneself if so disposed...I personally use the var's for everything...makes for exception safe code too.

    Are there problems beyond memory management?
  • 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.

    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.
  • by RonG ( 59915 )
    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.
  • 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.
  • The differences are there for a reason.

    Keep in mind that the CORBA types and standard C++ types are performing different work behind the scenes. They each meet a different set of requirements. Standard C++ types are not proxies and perform no reference counting duties like their CORBA counterparts.

    Abstracting away reference counting would limit the utility of distributed objects.
  • Compare:

    // 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";
    You should also remember that at the time the C++ mapping was defined:
    - STL was not completely standardized
    - STL was not available for all platforms
    - ANSI C++ compilers were not available on all platforms
    - C++ Exceptions were not supported by all C++ compilers

    The above reasons more than anything else are why the C++ mapping is so clunky. Now that it's being used commercially, the probability that it'll be changed to "clean" it up is just about nil.

    There is, however, an effort happening to come up with another C++ mapping which uses STL containers, strings, etc.

You can't go home again, unless you set $HOME.

Working...