Disadvantages of CORBA - Object

This is a discussion on Disadvantages of CORBA - Object ; I have seen countless number of articles referring the advntages of CORBA. Can some CORBA experts/gurus tell us about its disadvantages?...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 10 of 12

Disadvantages of CORBA

  1. Default Disadvantages of CORBA

    I have seen countless number of articles referring the advntages of CORBA.
    Can some CORBA experts/gurus tell us about its disadvantages?



  2. Default Re: Disadvantages of CORBA

    In <4205cd00$0$1022$afc38c87@news.optusnet.com.au> "Tuicear" <NA> writes:

    >I have seen countless number of articles referring the advntages of CORBA.
    >Can some CORBA experts/gurus tell us about its disadvantages?


    Well, I'm not a guru, nor an expert, I'm more a pragmatic practician, but
    here you go:

    1. Firewall unfriendly. There's no real CORBA standard to bind an ORB and
    it's clients to a port or a port range, there are (only) vendor specific
    options.
    2. Regarded as complicated. This is in some parts a prejudice, in some parts
    justificated: remote invocation of CORBA interfaces is at least as simple
    as over XMLRPC (which is regarded as easy), but the C++ language mapping
    predates the STL and features three different storage classes and
    clumsy handling of sequences - there are other examples.
    3. No standard to get the initial reference for the naming service. I don't
    know why, but there never has been an OMG blessed standard to get an initial
    reference for the naming service over the network. Of course, this results
    in different solutions from different vendors, all using some kind of
    broadcast request.
    4. No official perl mapping. There are at least two perl ORBs available as
    open source, but neither the mapping is official, nor the implementations
    are complete. Others may count this as an advantage, take your pick.
    There are a couple of other script language ORBs, though, but perl
    is still the favourite of sysadmins here in Europe, it seems.

    Awaiting your comments,
    Uli
    --
    Dipl. Inf. Ulrich Teichert|e-mail: Ulrich.Teichert@gmx.de
    Stormweg 24 |listening to: Suicide Drive (The Deep Eynde)
    24539 Neumuenster, Germany|Public Pervert (Interpol) Cauchemar (Opération S)

  3. Default Re: Disadvantages of CORBA

    <Ulrich.Teichert@gmx.de> wrote in message
    news:IBHsFJ.BEB@fake.nms.ulrich-teichert.org...
    > In <4205cd00$0$1022$afc38c87@news.optusnet.com.au> "Tuicear" <NA> writes:
    >
    >>I have seen countless number of articles referring the advntages of CORBA.
    >>Can some CORBA experts/gurus tell us about its disadvantages?

    >
    > Well, I'm not a guru, nor an expert, I'm more a pragmatic practician, but
    > here you go:
    >
    > 1. Firewall unfriendly. There's no real CORBA standard to bind an ORB and
    > it's clients to a port or a port range, there are (only) vendor specific
    > options.
    > 2. Regarded as complicated. This is in some parts a prejudice, in some
    > parts
    > justificated: remote invocation of CORBA interfaces is at least as
    > simple
    > as over XMLRPC (which is regarded as easy), but the C++ language mapping
    > predates the STL and features three different storage classes and
    > clumsy handling of sequences - there are other examples.
    > 3. No standard to get the initial reference for the naming service. I
    > don't
    > know why, but there never has been an OMG blessed standard to get an
    > initial
    > reference for the naming service over the network. Of course, this
    > results
    > in different solutions from different vendors, all using some kind of
    > broadcast request.
    > 4. No official perl mapping. There are at least two perl ORBs available as
    > open source, but neither the mapping is official, nor the
    > implementations
    > are complete. Others may count this as an advantage, take your pick.
    > There are a couple of other script language ORBs, though, but perl
    > is still the favourite of sysadmins here in Europe, it seems.


    Like most other "Choice" issues relating to middle-ware, much of these
    issues are historical. To defend more recent CORBA implementations...

    1. Recent ORBs have made good progress at dealing with this. In NSDOM (HP
    NonStop), we have a choice of using a well known port to come into the
    system, or using object defined ports. These can be configured in the IR. I
    agree though, that this is platform specific, but vendors are dealing with
    that, even if CORBA isn't explicitly.

    2. Once standards are set up in a shop (usually by one or two
    CORBA-knowledgeable people , in a matter of days), The process of defining
    a CORBA IDL to deploying usable servants descends to simple repetition. Like
    any middleware, there's typically fear involved, when dealing with something
    new. The same comments have been made of Tuxedo, MQ-series, ...

    3. Corbaloc has become a very good mechanism for obtaining initial
    references to name services. Rather than having to configure the IR or ORB
    or property files or... <pick your poison>, it's far easier to use a
    corbaloc style string reference to otain the name service. Corbalocs are
    supported but many ORBs, including the default Sun JDK 1.4.2, which makes
    that a good method for off-platform clients.

    4. <sigh/> I can't defend this one.

    Cheers,

    Randall



  4. Default Re: Disadvantages of CORBA

    In <ndWdnegtgtgMopvfRVn-1g@rogers.com> "Randall S. Becker" <r.s.b.e.c.k.e.r.n.o.s.p.a.m@n.e.x.b.r.i.d.g.e.c.o.m.s.p.a.m.f.r.e.e.> writes:
    [del]
    >Like most other "Choice" issues relating to middle-ware, much of these
    >issues are historical. To defend more recent CORBA implementations...


    [Firwall unfriendliness]
    >1. Recent ORBs have made good progress at dealing with this. In NSDOM (HP
    >NonStop), we have a choice of using a well known port to come into the
    >system, or using object defined ports. These can be configured in the IR. I
    >agree though, that this is platform specific, but vendors are dealing with
    >that, even if CORBA isn't explicitly.


    I know that Orbix has something like that as well, but that wasn't my point:
    there is no standard to do this.

    [Complicated]
    >2. Once standards are set up in a shop (usually by one or two
    >CORBA-knowledgeable people , in a matter of days), The process of defining
    >a CORBA IDL to deploying usable servants descends to simple repetition. Like
    >any middleware, there's typically fear involved, when dealing with something
    >new. The same comments have been made of Tuxedo, MQ-series, ...


    I meant I wrote that remote invocation of methods is easy? But the C++
    mapping isn't. I know that there are a number of reasons for it's clumsiness,
    and most other (if not all) mappings are better, simply because they came
    *after* the C++ mapping. 'Nuff said.

    [Initial references]
    >3. Corbaloc has become a very good mechanism for obtaining initial
    >references to name services. Rather than having to configure the IR or ORB
    >or property files or... <pick your poison>, it's far easier to use a
    >corbaloc style string reference to otain the name service. Corbalocs are
    >supported but many ORBs, including the default Sun JDK 1.4.2, which makes
    >that a good method for off-platform clients.


    I don't really like corbaloc, because it's still vendor depended. The name
    of the option is the same, yes, but it is interpreted differently.

    [No official perl mapping]
    >4. <sigh/> I can't defend this one.


    Yeah, I wish I'd the time to do something about it. Perhaps it's time to
    quit my job :-| (where I only have to fight with a stupid XmlRpc
    implementation)

    HTH,
    Uli
    --
    Dipl. Inf. Ulrich Teichert|e-mail: Ulrich.Teichert@gmx.de
    Stormweg 24 |listening to: Suicide Drive (The Deep Eynde)
    24539 Neumuenster, Germany|Public Pervert (Interpol) Cauchemar (Opération S)

  5. Default Re: Disadvantages of CORBA

    Oops! Ulrich.Teichert@gmx.de was seen spray-painting on a wall:
    > In <ndWdnegtgtgMopvfRVn-1g@rogers.com> "Randall S. Becker"
    > <r.s.b.e.c.k.e.r.n.o.s.p.a.m@n.e.x.b.r.i.d.g.e.c.o.m.s.p.a.m.f.r.e.e.>
    > writes: I meant I wrote that remote invocation of methods is easy?
    > But the C++ mapping isn't. I know that there are a number of reasons
    > for it's clumsiness, and most other (if not all) mappings are
    > better, simply because they came *after* the C++ mapping. 'Nuff
    > said.


    That can't be. Most mappings came about _before_ the C++ mapping.

    The thing about the C++ mapping is that it happened somewhat
    concurrently with C++ standards being in flux so that the CORBA C++
    mapping had to cope with a C++ that wasn't quite 'final' and which was
    changing in still painful ways.
    --
    let name="cbbrowne" and tld="gmail.com" in name ^ "@" ^ tld;;
    http://linuxdatabases.info/~cbbrowne/lisp.html
    "Paranoia is not only good, it is indispensable."
    -- Jim Wildman on Unix Sysadmining
    <http://www.rossberry.com/jim/linux/sysadmin.html>

  6. Default Re: Disadvantages of CORBA

    In <36o65pF551110U1@individual.net> Christopher Browne <cbbrowne@acm.org> writes:

    >Oops! Ulrich.Teichert@gmx.de was seen spray-painting on a wall:
    >> In <ndWdnegtgtgMopvfRVn-1g@rogers.com> "Randall S. Becker"
    >> <r.s.b.e.c.k.e.r.n.o.s.p.a.m@n.e.x.b.r.i.d.g.e.c.o.m.s.p.a.m.f.r.e.e.>
    >> writes: I meant I wrote that remote invocation of methods is easy?
    >> But the C++ mapping isn't. I know that there are a number of reasons
    >> for it's clumsiness, and most other (if not all) mappings are
    >> better, simply because they came *after* the C++ mapping. 'Nuff
    >> said.


    >That can't be. Most mappings came about _before_ the C++ mapping.

    [del]

    Sure? All mappings I've worked with came out after the C++ one: Java,
    python and perl (though not offical). I know that the C mapping came before,
    but what else? Am I too focused on OO-languages or simply too young ;-?

    TIA,
    Uli
    --
    Dipl. Inf. Ulrich Teichert|e-mail: Ulrich.Teichert@gmx.de
    Stormweg 24 |listening to: Suicide Drive (The Deep Eynde)
    24539 Neumuenster, Germany|Public Pervert (Interpol) Cauchemar (Opération S)

  7. Default Re: Disadvantages of CORBA

    "Tuicear" <NA> wrote:

    > I have seen countless number of articles referring the advntages of CORBA.
    > Can some CORBA experts/gurus tell us about its disadvantages?


    Well, I've just started with CORBA, but I have a few thoughts anyway


    1) The security framework is big [1] and complicated and not widespread
    among implementations. It seems to be targeted to handle CORBA in
    large systems. I've not figured out how to implement a security-
    model for a small RPC like system. I've just written a tiny system
    where a Java-client manages the DNS-zones for a SQL based DNS server -
    and for now I just had to give up authentication-based security
    and fall back to the IP based rules in the firewall

    2) OMG seems to insist on using the name-service. In a small system,
    like the one mentioned above, this may not be a very good idea.
    If all you need is a simple interface into a server application,
    - why install a third-party (name-server) service on the customers
    machine only to bootstrap the initial communications, when the
    corbaloc feature needed to bootstrap the name-server can boostrap
    the communications to your own service just as well? You get
    another service that consumes resources on a server, and another
    service that may contain exploits or other security threats.
    You also complicate the install-program, and may mess up things
    if the machine already has a name-service for another, unrelated
    application.

    3) The basic name-server has no security, so any 12 yo "hacker"-wannabe
    that can communicate with the name-service, can basically overwrite
    the name-record for your service, and make the clients connect to
    his machine. This opens up for man-in-the-middle proxy attacks,
    or more serious problems where a phony server may steal data,
    or provide clients with made-up data.

    There are also problems of a more trivial nature between implementations.

    A) I was unable to make wide strings work between two implementations.
    When I researched the problem and did some googling, I soon
    discovered that this seems to be a major pain.

    B) Even a simple thing like connecting a client to a server may fail
    between implementations. I as unable to connect a client using the
    current jre from Sun to a server linked with OmniORB 3 (Debian/GNU
    Linux - stable release) without inserting a "1.0@" prefix to the
    corbaloc uri.

    Problems like these takes a lot of time to figure out, especially when you
    are new to CORBA, and expect the library to behave as documented.

    The most serious problem, however, as I see it, is the lack of a common,
    solid, but still simple-to-use/simple-to-deploy security platform. From my
    experience - if security becomes too complex to manage, it is simply
    switched off. That's not a good approach today.

    Jarle

    [1] http://www.jgaa.com/images/corbasec.jpg
    --
    Jarle Aase http://www.jgaa.com
    mailto:jgaa@jgaa.com

    <<< no need to argue - just kill'em all! >>>

  8. Default Re: Disadvantages of CORBA

    Jarle Aase wrote:
    > Well, I've just started with CORBA, but I have a few thoughts anyway


    >
    >
    > 1) The security framework is big [1] and complicated and not

    widespread
    > among implementations. It seems to be targeted to handle CORBA in
    > large systems. I've not figured out how to implement a security-
    > model for a small RPC like system. I've just written a tiny

    system
    > where a Java-client manages the DNS-zones for a SQL based DNS

    server -
    > and for now I just had to give up authentication-based security
    > and fall back to the IP based rules in the firewall


    I would recommend you to rather use/study CORBA CSIv2 specification
    than old CORBA Security Service. This will also allow you to
    interoperate with various EJB app servers securely.

    > 2) OMG seems to insist on using the name-service. In a small

    system,
    > like the one mentioned above, this may not be a very good idea.
    > If all you need is a simple interface into a server application,
    > - why install a third-party (name-server) service on the

    customers
    > machine only to bootstrap the initial communications, when the
    > corbaloc feature needed to bootstrap the name-server can boostrap
    > the communications to your own service just as well? You get
    > another service that consumes resources on a server, and another
    > service that may contain exploits or other security threats.
    > You also complicate the install-program, and may mess up things
    > if the machine already has a name-service for another, unrelated
    > application.


    You can also use simple corbaloc of your target service and -ORBInitRef
    functionality to setup service's ref into your client ORB.

    > 3) The basic name-server has no security, so any 12 yo

    "hacker"-wannabe
    > that can communicate with the name-service, can basically

    overwrite
    > the name-record for your service, and make the clients connect to


    > his machine. This opens up for man-in-the-middle proxy attacks,
    > or more serious problems where a phony server may steal data,
    > or provide clients with made-up data.


    If you use CSIv2 or CSL2 for security unaware applications, I'm sure
    you will be able to change basic unsecure name-server into secure one.

    > There are also problems of a more trivial nature between

    implementations.
    >
    > A) I was unable to make wide strings work between two

    implementations.
    > When I researched the problem and did some googling, I soon
    > discovered that this seems to be a major pain.


    If your one implementation is Sun's JDK ORB (as seems to be the case
    below), then I believe you that you might have hard time to get it
    working together with other more compliants ORBs.

    > B) Even a simple thing like connecting a client to a server may

    fail
    > between implementations. I as unable to connect a client using

    the
    > current jre from Sun to a server linked with OmniORB 3

    (Debian/GNU
    > Linux - stable release) without inserting a "1.0@" prefix to the
    > corbaloc uri.


    I've also been hited by this issue, and I think this is just a bug in
    Sun's JDK ORB, since when version is not specified in corbaloc, ORB
    should use 1.0 GIOP/IIOP by default.

    > Problems like these takes a lot of time to figure out, especially

    when you
    > are new to CORBA, and expect the library to behave as documented.


    If you are new to CORBA, I would recommend you to use the best CORBA
    implementation(s) for learning architecture details and then to move to
    less good implementation(s) if your project requires it.

    > The most serious problem, however, as I see it, is the lack of a

    common,
    > solid, but still simple-to-use/simple-to-deploy security platform.
    >From my
    > experience - if security becomes too complex to manage, it is simply
    > switched off. That's not a good approach today.


    Unfortunatelly you are right. Anyway, various vendors don't sleep and
    try to solve this issue in various products. <advert>Our company
    provides basic OpenPMF implementation for free under GPL license, you
    can find more about it on http://www.openpmf.org</advert>

    Cheers,
    Karel
    --
    Karel Gardas kgardas@objectsecurity.com
    ObjectSecurity Ltd. http://www.objectsecurity.com


  9. Default Re: Disadvantages of CORBA

    The world rejoiced as Ulrich.Teichert@gmx.de wrote:
    > In <36o65pF551110U1@individual.net> Christopher Browne <cbbrowne@acm.org> writes:
    >
    >>Oops! Ulrich.Teichert@gmx.de was seen spray-painting on a wall:
    >>> In <ndWdnegtgtgMopvfRVn-1g@rogers.com> "Randall S. Becker"
    >>> <r.s.b.e.c.k.e.r.n.o.s.p.a.m@n.e.x.b.r.i.d.g.e.c.o.m.s.p.a.m.f.r.e.e.>
    >>> writes: I meant I wrote that remote invocation of methods is easy?
    >>> But the C++ mapping isn't. I know that there are a number of reasons
    >>> for it's clumsiness, and most other (if not all) mappings are
    >>> better, simply because they came *after* the C++ mapping. 'Nuff
    >>> said.

    >
    >>That can't be. Most mappings came about _before_ the C++ mapping.

    > [del]
    >
    > Sure? All mappings I've worked with came out after the C++ one: Java,
    > python and perl (though not offical). I know that the C mapping came before,
    > but what else? Am I too focused on OO-languages or simply too young ;-?


    You're evidently too young, and it's not any OO focus at issue.

    There were mappings for Ada (object oriented), Common Lisp (again,
    OO), Smalltalk (duh!), COBOL (probably not OO) since way back.
    --
    (format nil "~S@~S" "cbbrowne" "gmail.com")
    http://linuxfinances.info/info/corba.html
    I was just wondering if the Chinese are busy trying to deal with the
    "Year Of The Dragon" bug.

  10. Default Re: Disadvantages of CORBA

    Karel Gardas wrote:

    > I would recommend you to rather use/study CORBA CSIv2 specification
    > than old CORBA Security Service. This will also allow you to
    > interoperate with various EJB app servers securely.


    I'll do that.

    >> 2) OMG seems to insist on using the name-service.


    > You can also use simple corbaloc of your target service and -ORBInitRef
    > functionality to setup service's ref into your client ORB.


    I'm working on three projects involving CORBA right now, and in all three
    cases the client must be able to dynamically connect to one or more
    servers. The setup is done in a "connection" dialog in the client. I'm not
    using the name-servers. But that means that I'm implementing the programs
    in direct violation with the recommendations from OMG.

    >> 3) The basic name-server has no security,


    > If you use CSIv2 or CSL2 for security unaware applications, I'm sure
    > you will be able to change basic unsecure name-server into secure one.


    The problem is that I'm making Open Source programs, - and the users may not
    want, or may not have the possibility, to deploy CSIv2 or CSL2. Security is
    not enforced into the name-server by the specifications, and that means
    that _lots_ of name-services will not have any kind of security. My
    response is to omit the name-server.

    >> A) I was unable to make wide strings work between two
    >> implementations.

    >
    > If your one implementation is Sun's JDK ORB (as seems to be the case
    > below), then I believe you that you might have hard time to get it
    > working together with other more compliants ORBs.


    Yap. Sun should really fix the bugs.

    >> B) Even a simple thing like connecting a client to a server may
    >> fail

    >
    > I've also been hited by this issue, and I think this is just a bug in
    > Sun's JDK ORB, since when version is not specified in corbaloc, ORB
    > should use 1.0 GIOP/IIOP by default.


    That's also my conclusion. Poor implementations, especially ones that are
    included with widely used sdk's, can give CORBA a bad reputation. Sun
    should either fix the most annoying bugs, or withdraw the CORBA-support.

    > If you are new to CORBA, I would recommend you to use the best CORBA
    > implementation(s) for learning architecture details and then to move to
    > less good implementation(s) if your project requires it.


    I never do that. I implement my projects in the same environments where they
    will be deployed. That way _I_ crashland in reality, in stead of the
    end-users of my software I've been coding for 20 years, so I'm used to
    figure out how to make things work.

    >> The most serious problem, however, as I see it, is the lack of a
    >> common, solid, but still simple-to-use/simple-to-deploy security
    >> platform.
    >> From my experience - if security becomes too complex to manage,
    >> it is simply switched off. That's not a good approach today.

    >
    > Unfortunatelly you are right. Anyway, various vendors don't sleep and
    > try to solve this issue in various products. <advert>Our company
    > provides basic OpenPMF implementation for free under GPL license, you
    > can find more about it on http://www.openpmf.org</advert>


    I'll have a look at it.

    Jarle
    --
    Jarle Aase http://www.jgaa.com
    mailto:jgaa@jgaa.com

    <<< no need to argue - just kill'em all! >>>

+ Reply to Thread
Page 1 of 2 1 2 LastLast

Similar Threads

  1. Replies: 0
    Last Post: 05-31-2006, 02:17 AM
  2. Replies: 0
    Last Post: 05-31-2006, 02:15 AM
  3. Współpraca java w Serverm CORBA Delphi i CORBA ORB dla J2ME
    By Application Development in forum Java
    Replies: 0
    Last Post: 05-31-2006, 02:12 AM
  4. Replies: 2
    Last Post: 09-23-2004, 03:37 AM
  5. Replies: 2
    Last Post: 02-10-2004, 12:27 AM