CORBA or some other methodology?

Discussion in 'Java' started by Ted Holden, Nov 18, 2004.

  1. Ted Holden

    Ted Holden Guest

    Another seriously stupid question here......

    I've got a situation in which a java applet has to retrieve
    information from a server and the process which generates the
    information is complex and performance-critical enough that it pretty
    much has to be written in C++ asnd not Java.

    The one thing I know of which does that sort of thing is CORBA.

    But then, my knowledge of Java is pretty miniscule. Does anybody have
    any reason to believe that there might be any other methodology for
    doing that sort of thing, i.e. for allowing a Java applet to access a
    server object written in C++ which for any reason might be preferable
    to CORBA?
     
    Ted Holden, Nov 18, 2004
    #1
    1. Advertising

  2. Ted Holden wrote:
    > I've got a situation in which a java applet has to retrieve


    Applet? Well, consider an application, deployed via JavaWebStart.

    > information from a server and the process which generates the
    > information is complex and performance-critical enough that it pretty
    > much has to be written in C++ asnd not Java.


    Java performance is in general on par with that of C or C++. It always
    depends a little bit on who fabricated the benchmarks, if C/C++ or Java
    comes out better. If you want to have a conservative estimate, than
    assume that Java is maybe 10% slower than C/C++.

    > The one thing I know of which does that sort of thing is CORBA.


    You talk about performance, and then you talk about CORBA? With its huge
    marshaling/unmarshalling overhead? Well, yes, CORBA can be used to
    exchange data, but any other TCP or UDP based protocol would do, too.
    You could build your own, customized protocol (which you can fine-tune
    to your needs, but which is probably the most work). You could use HTTP
    + HTML to transport the data, you could (not recommended) use SOAP. Or
    whatever suits your needs.

    If you go for an applet, you would have to take care that the Java
    security mechanisms don't come in your way. E.g. unless the applet is
    signed, it can't communicate with any other server than the server from
    which it was loaded.

    Oh, and if you go for CORBA be prepared that a lot of corporate
    firewalls have the necessary ports closed, so you need to be prepared to
    tunnel, or convince people to open the ports.

    > But then, my knowledge of Java is pretty miniscule. Does anybody have
    > any reason to believe that there might be any other methodology for
    > doing that sort of thing, i.e. for allowing a Java applet to access a
    > server object written in C++ which for any reason might be preferable
    > to CORBA?


    Sounds like you already made up your mind and that you want to go for
    CORBA. CORBA would almost be my last choice, not my first.

    /Thomas
     
    Thomas Weidenfeller, Nov 18, 2004
    #2
    1. Advertising

  3. Ted Holden

    Dave Monroe Guest

    (Ted Holden) wrote in message news:<>...
    > Another seriously stupid question here......
    >
    > I've got a situation in which a java applet has to retrieve
    > information from a server and the process which generates the
    > information is complex and performance-critical enough that it pretty
    > much has to be written in C++ asnd not Java.
    >
    > The one thing I know of which does that sort of thing is CORBA.
    >
    > But then, my knowledge of Java is pretty miniscule. Does anybody have
    > any reason to believe that there might be any other methodology for
    > doing that sort of thing, i.e. for allowing a Java applet to access a
    > server object written in C++ which for any reason might be preferable
    > to CORBA?


    Applets have a security restriction that prohibits them from
    interacting with either the host system (other than cookies) or any
    network address other than the one that served the applet in the first
    place.

    The security restriction can be bypassed by affixing a digital
    signature to the applet. At that point it's up to the user at the
    host end to either accept or reject the signed applet.

    I would suggest you go server-to-server rather than applet-to-server.
    The applet-to-server architecture is pretty lame.

    Take a look at servlets and/or Java Server Pages. Also RMI-IIOP.
     
    Dave Monroe, Nov 18, 2004
    #3
  4. Thomas Weidenfeller wrote:
    > Ted Holden wrote:
    >
    >> I've got a situation in which a java applet has to retrieve

    >
    >
    > Applet? Well, consider an application, deployed via JavaWebStart.
    >
    >> information from a server and the process which generates the
    >> information is complex and performance-critical enough that it pretty
    >> much has to be written in C++ asnd not Java.

    >
    >
    > Java performance is in general on par with that of C or C++. It always
    > depends a little bit on who fabricated the benchmarks, if C/C++ or Java
    > comes out better. If you want to have a conservative estimate, than
    > assume that Java is maybe 10% slower than C/C++.
    >
    >> The one thing I know of which does that sort of thing is CORBA.

    >
    >
    > You talk about performance, and then you talk about CORBA? With its huge
    > marshaling/unmarshalling overhead? Well, yes, CORBA can be used to
    > exchange data, but any other TCP or UDP based protocol would do, too.
    > You could build your own, customized protocol (which you can fine-tune
    > to your needs, but which is probably the most work). You could use HTTP
    > + HTML to transport the data, you could (not recommended) use SOAP. Or
    > whatever suits your needs.
    >
    > If you go for an applet, you would have to take care that the Java
    > security mechanisms don't come in your way. E.g. unless the applet is
    > signed, it can't communicate with any other server than the server from
    > which it was loaded.
    >
    > Oh, and if you go for CORBA be prepared that a lot of corporate
    > firewalls have the necessary ports closed, so you need to be prepared to
    > tunnel, or convince people to open the ports.
    >
    >> But then, my knowledge of Java is pretty miniscule. Does anybody have
    >> any reason to believe that there might be any other methodology for
    >> doing that sort of thing, i.e. for allowing a Java applet to access a
    >> server object written in C++ which for any reason might be preferable
    >> to CORBA?

    >
    >
    > Sounds like you already made up your mind and that you want to go for
    > CORBA. CORBA would almost be my last choice, not my first.


    The fact that the server object is written in C++ should have little
    influence on your decision as long as the protocols can be implemented
    in both C++ and Java (and there are many). My choice would rather evolve
    around things like:
    -what level of security do I need (authentication, encryption,
    signature, etc...)
    -do I need real RPC capabilities or just "posting/retrieving" data?
    -is this on a LAN, WAN,...
    -what ports can I use?
    -what sort of bandwith do I have?
    -do I want synchronous/asynchronous behaviour?
    -do I need this thing to look good on slides?
    -do I have people that know this technology?
    -etc....

    Perfectly acceptable security can be achieved with a simple https post
    or get. Now, if you want procedure calls with type marshalling but
    simple stuff, why not XML-RPC?
    You want the marketing hype, why not a web-service?
    Goold old heavy industrial strength on a LAN, Corba?
    etc...

    Bruno

    >
    > /Thomas
     
    Bruno Grieder, Nov 18, 2004
    #4
  5. Ted Holden

    Ted Holden Guest

    On 18 Nov 2004 03:59:54 -0800, (Dave Monroe)
    wrote:


    >Applets have a security restriction that prohibits them from
    >interacting with either the host system (other than cookies) or any
    >network address other than the one that served the applet in the first
    >place.


    >The security restriction can be bypassed by affixing a digital
    >signature to the applet. At that point it's up to the user at the
    >host end to either accept or reject the signed applet.


    >I would suggest you go server-to-server rather than applet-to-server.
    >The applet-to-server architecture is pretty lame.
    >
    >Take a look at servlets and/or Java Server Pages. Also RMI-IIOP.


    Thanks! I should have mentioned that this application also requires
    media support in the form of the JMF and I would GUESS that would rule
    out servlets. The real question I had was whether or not some other
    way of connecting a server-side object to an applet might have come
    along which was viewed as superior to CORBA.

    Part of the problem I'm having is that just a few years back Java
    seemed like a reasonable and simple idea, i.e. an effort to have
    modern-looking and maintainable code for webcentric applications,
    nonetheless at this juncture there seems to be this bewildering sort
    of a collection of things including servlets, server pages, SOAP,
    struts, whatever those are, beans, enhandced beans, and whatever else.
    It would help some if there were any sort of a general page which
    offered brief and simple descriptions of all such, what they did, and
    why they existed.
     
    Ted Holden, Nov 18, 2004
    #5
  6. Ted Holden

    Ted Holden Guest

    On Thu, 18 Nov 2004 09:25:15 +0100, Thomas Weidenfeller
    <> wrote:


    >
    >You talk about performance, and then you talk about CORBA? With its huge
    >marshaling/unmarshalling overhead? Well, yes, CORBA can be used to
    >exchange data, but any other TCP or UDP based protocol would do, too.
    >You could build your own, customized protocol (which you can fine-tune
    >to your needs, but which is probably the most work). You could use HTTP
    >+ HTML to transport the data, you could (not recommended) use SOAP. Or
    >whatever suits your needs.


    For a number of reasons, the server object in question almost has to
    be in C++ and not java. It strikes me as more likely that the
    performance differential would be several to one for this particular
    task, the code is proprietary and a company secret which we don't need
    anybody trying to reconstruct from byte code, and it would be a major
    sort of hassle to even try to rewrite in Java.

    The question is, can SOAP or any other sort of an alternative to CORBA
    handle C++ objects?
     
    Ted Holden, Nov 18, 2004
    #6
  7. Ted Holden

    Ted Holden Guest

    On Thu, 18 Nov 2004 15:36:08 +0100, Bruno Grieder
    <> wrote:


    >Perfectly acceptable security can be achieved with a simple https post
    >or get. Now, if you want procedure calls with type marshalling but
    >simple stuff, why not XML-RPC?


    Thanks!

    Can xml-rpc handle an object written in C++, and, if so, where can I
    read more about it?
     
    Ted Holden, Nov 18, 2004
    #7
  8. Ted Holden wrote:
    > On Thu, 18 Nov 2004 15:36:08 +0100, Bruno Grieder
    > <> wrote:
    >
    >
    >
    >>Perfectly acceptable security can be achieved with a simple https post
    >>or get. Now, if you want procedure calls with type marshalling but
    >>simple stuff, why not XML-RPC?

    >
    >
    > Thanks!
    >
    > Can xml-rpc handle an object written in C++, and, if so, where can I
    > read more about it?
    >
    >
    >
    >

    Cannot be simmpler: www.xmlrpc.com
    and for C/C++
    http://xmlrpc-c.sourceforge.net/xmlrpc-howto/xmlrpc-howto-c.html

    Bruno
     
    Bruno Grieder, Nov 18, 2004
    #8
  9. Ted Holden

    Dave Monroe Guest

    (Ted Holden) wrote in message news:<>...
    > On 18 Nov 2004 03:59:54 -0800, (Dave Monroe)
    > wrote:
    >
    >
    > >Applets have a security restriction that prohibits them from
    > >interacting with either the host system (other than cookies) or any
    > >network address other than the one that served the applet in the first
    > >place.

    >
    > >The security restriction can be bypassed by affixing a digital
    > >signature to the applet. At that point it's up to the user at the
    > >host end to either accept or reject the signed applet.

    >
    > >I would suggest you go server-to-server rather than applet-to-server.
    > >The applet-to-server architecture is pretty lame.
    > >
    > >Take a look at servlets and/or Java Server Pages. Also RMI-IIOP.

    >
    > Thanks! I should have mentioned that this application also requires
    > media support in the form of the JMF and I would GUESS that would rule
    > out servlets. The real question I had was whether or not some other
    > way of connecting a server-side object to an applet might have come
    > along which was viewed as superior to CORBA.
    >
    > Part of the problem I'm having is that just a few years back Java
    > seemed like a reasonable and simple idea, i.e. an effort to have
    > modern-looking and maintainable code for webcentric applications,
    > nonetheless at this juncture there seems to be this bewildering sort
    > of a collection of things including servlets, server pages, SOAP,
    > struts, whatever those are, beans, enhandced beans, and whatever else.
    > It would help some if there were any sort of a general page which
    > offered brief and simple descriptions of all such, what they did, and
    > why they existed.


    Take a look at 'axis' from apache.org.

    Interoperability issues, these days, can often be addressed by web services.
     
    Dave Monroe, Nov 19, 2004
    #9
  10. Ted Holden

    Ted Holden Guest

    On Thu, 18 Nov 2004 19:28:40 +0100, Bruno Grieder
    <> wrote:

    >Cannot be simmpler: www.xmlrpc.com
    >and for C/C++
    >http://xmlrpc-c.sourceforge.net/xmlrpc-howto/xmlrpc-howto-c.html
    >
    >Bruno



    Thanks!

    One other question. XMLRPC and SOAP/AXIS have been suggested here as
    alternatives to CORBA. There is one other thing which CORBA does
    which I might or might not need for this particular application but
    which is nice to have as a general rule, and that is to maintain some
    notion of state in the sense that an application which needs one
    generates an object of a particular type for itself and holds onto it
    as long as it needs it for whatever it is doing, which might require a
    number of method calls for the object being used and not just one.
    State is maintained in the objects data members while that is going
    on.

    Do xmlrpc and/or SOAP/Axis have this same capability? In particular,
    the documentation for xmlrpc appeared to be a little thin and it
    wasn't totally obvious.
     
    Ted Holden, Nov 19, 2004
    #10
  11. Ted Holden

    Ted Holden Guest

    On 19 Nov 2004 03:25:39 -0800, (Dave Monroe)
    wrote:

    >Take a look at 'axis' from apache.org.
    >
    >Interoperability issues, these days, can often be addressed by web services.





    Thanks!

    One other question. XMLRPC and SOAP/AXIS have been suggested here as
    alternatives to CORBA.

    There is one other thing which CORBA does which I might or might not
    need for this particular application but which is nice to have as a
    general rule, and that is to maintain some notion of state in the
    sense that an application which needs one generates an object of a
    particular type for itself and holds onto it as long as it needs it
    for whatever it is doing, which might require a number of method calls
    for the object being used and not just one. State is maintained in
    the objects data members while that is going on.

    Does Axis have this same capability?

    Also there is a requirement that a C++ server object operate with a
    Java applet on the client. The statement I read on the Axis doc page:

    "Numerous tests have been done to test the ability of Axis C++ client
    side to interoperate with Axis Java server side and the results are
    successful. Efforts are under way to make the Axis C++ server side to
    inter operate with Axis Java client side."

    indicates that I might end up using Axis to write a Java server object
    wrapper for a C++ object and then have the client access the Java
    server object.

    All of that's a little less clean than Corba in a way but, if what I
    read is correct it's probably still faster and might involve fewer
    hassles with gateways and what not for an application which might be
    used by the public at large. I get the impression that CORBA might be
    better suited for corporate applications in which gateways and
    firewalls and such are not so much of an issue.
     
    Ted Holden, Nov 19, 2004
    #11
  12. Ted Holden wrote:
    > On Thu, 18 Nov 2004 19:28:40 +0100, Bruno Grieder
    > <> wrote:
    >
    >
    >>Cannot be simmpler: www.xmlrpc.com
    >>and for C/C++
    >>http://xmlrpc-c.sourceforge.net/xmlrpc-howto/xmlrpc-howto-c.html
    >>
    >>Bruno

    >
    >
    >
    > Thanks!
    >
    > One other question. XMLRPC and SOAP/AXIS have been suggested here as
    > alternatives to CORBA. There is one other thing which CORBA does
    > which I might or might not need for this particular application but
    > which is nice to have as a general rule, and that is to maintain some
    > notion of state in the sense that an application which needs one
    > generates an object of a particular type for itself and holds onto it
    > as long as it needs it for whatever it is doing, which might require a
    > number of method calls for the object being used and not just one.
    > State is maintained in the objects data members while that is going
    > on.
    >
    > Do xmlrpc and/or SOAP/Axis have this same capability? In particular,
    > the documentation for xmlrpc appeared to be a little thin and it
    > wasn't totally obvious.
    >
    >

    That sounds like a stateful session bean! (too bad you app is written in
    C++, not in Java).

    I am not sure I understand your question: session management is a server
    side issue more than anything else. Can your C++ app maintain a session?

    Please note that - officially - web services do not maintain sessions
    state. Now, in Java, there are ways around this using the session context.

    b.
     
    Bruno Grieder, Nov 22, 2004
    #12
  13. Ted Holden

    ted holden Guest

    Bruno Grieder wrote:


    > I am not sure I understand your question: session management is a server
    > side issue more than anything else. Can your C++ app maintain a session?
    >
    > Please note that - officially - web services do not maintain sessions
    > state. Now, in Java, there are ways around this using the session context.
    >
    > b.



    With Corba, a client app instantiates a copy of an object, accesses methods
    of the object, possibly more than once, and then releases it. State can be
    maintained by the class data of the object.

    As I'm now hearing it, xmlrpc doesn't do that. The choice is between Corba,
    and figuring a way to make the app run without server-side state
    maintainance and I'll probably go with xmlrpc; it just requires a bit more
    thought in designing the app. Xmlrpc appears to be better adapted to
    distributed apps.

    Should need arise, there is also now a sort of an updated version of the
    same sort of thing as CORBA:

    http://www.zeroc.com/ice.html

    which might be useful for some future project, but not this one.

    Again, thanks!
     
    ted holden, Nov 22, 2004
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. imavroid
    Replies:
    0
    Views:
    861
    imavroid
    Mar 12, 2006
  2. Replies:
    3
    Views:
    453
    Clint Hill
    Jul 25, 2005
  3. Imran Aziz
    Replies:
    2
    Views:
    1,232
    Imran Aziz
    Aug 5, 2005
  4. arieljake
    Replies:
    3
    Views:
    352
    arieljake
    Feb 9, 2005
  5. Tomek
    Replies:
    1
    Views:
    1,053
    Jack Klein
    Jun 1, 2006
Loading...

Share This Page