On Thu, 2005-03-03 at 13:54 +0000, Jarl Lindrud wrote:
Iain Hanson <Iain.Hanson <at> videonetworks.com> writes:
So anything less than CORBA should not be considered?
For RPC, Yes.
My experience with CORBA is that you _do_ pay for things you don't need. Try building a simple server/client app with my RPC library, and then build it with ACE TAO, and I wonder which method you'll find to be simpler/easier/faster...
Here is an example CORBA client. And it doen not matter which ORB you use. #include <iostream> #include "echoC.hpp" // generated from the idl file int main ( int ArgV , char * ArgV ) { try { // _var types are smart ptrs to ref counted objects. CORBA::ORB_var Orb = CORBA::ORB_init ( ArgC , ArgV , "TAO"); // get IOR from a file so we can talk to server CORBA::Object_var Factory_Object = Orb->string_to_object ( ArgV [ 1 ] ); // This is a CORBA safe downcast My::Echo_Factory_var Factory = My::Echo_Factory::_narrow ( Factory_Object.in( ) ); My::Echo_Server_var EchoServer = Factory->get_server ( ArgV [ 2 ] ); CORBA::String_var Echoed = EchoServer-> ( "Hello World" ); } catch ( CORBA::Exception & E ) { std::cerr << "CORBA exception raised!" << std::endl; } } I don't think 5 lines of code is exactly heavyweight. I could of done it in 3 lines if I did not use a factory, but that would have been unrealistic. I won't show the server but it 2 classes the factory publicly inherits from Echo_Factory and implements a single function get_server. Likewise like for EchoServer.
Which code is less invasive, more intuitive, and more proportional to the task? And oh I forgot, don't forget to first build all of ACE and TAO, and then link the whole shebang to your own 5 lines of code. To me it feels like I'm getting far, far more than I asked for. But that's just me :-)
ACE is nothing to do with CORBA. It just happens to be what TAO uses internally. Building Open source or installing per build libs has nothing to do with how easy it is to use. Your comparing apples and carrots.
If you need scaleability, then obviously CORBA is one of the few options you have. But if you don't need scaleability, or naming services, or whatever, what's wrong with using something much simpler?
Because when you app grows you will have to re-write it. More likely, is that won't happen and people will re-invent the again. Take a look at the development of SOAP :-(. /ikh
Iain Hanson <Iain.Hanson <at> videonetworks.com> writes:
Here is an example CORBA client. And it doen not matter which ORB you use.
#include <iostream> #include "echoC.hpp" // generated from the idl file
int main ( int ArgV , char * ArgV ) { try { // _var types are smart ptrs to ref counted objects. CORBA::ORB_var Orb = CORBA::ORB_init ( ArgC , ArgV , "TAO");
// get IOR from a file so we can talk to server CORBA::Object_var Factory_Object = Orb->string_to_object ( ArgV [ 1 ] );
// This is a CORBA safe downcast My::Echo_Factory_var Factory = My::Echo_Factory::_narrow ( Factory_Object.in( ) );
My::Echo_Server_var EchoServer = Factory->get_server ( ArgV [ 2 ] );
CORBA::String_var Echoed = EchoServer-> ( "Hello World" );
} catch ( CORBA::Exception & E ) { std::cerr << "CORBA exception raised!" << std::endl; } }
I don't think 5 lines of code is exactly heavyweight. I could of done it in 3 lines if I did not use a factory, but that would have been unrealistic.
Depends on what's in the 5 lines.
I won't show the server but it 2 classes the factory publicly inherits from Echo_Factory and implements a single function get_server. Likewise like for EchoServer.
You're making my point for me. For something quick and dirty, who is going to want to type all that out? And before I do, I have to learn about IDL, _var types, safe downcasts, factories, CORBA::string's, etc, while in the back of my mind there's the nagging suspicion that I've missed some subtle detail somewhere. And whoever will be looking at my code needs to learn these things as well. I also have to modify the build process to handle the IDL files, and then find an ORB to build and link to. None of this is difficult, but I personally find it rather cumbersome, and above all, for my situation it's just plain unnecessary. All I wanted to do was to make a couple of remote calls between two C++ programs! Something along these lines seems to me much more proportional to the task at hand: // server RCF_BEGIN(I_Echo, "I_Echo") RCF_METHOD_R1(std::string, echo, std::string); RCF_END(I_X); struct Echo { void std::string echo(std::string s) { return s; } }; int main() { RCF::RcfServer server(50001); server.bind<I_Echo,Echo>(); server.start(); return 0; } // client RCF_BEGIN(I_Echo, "I_Echo") RCF_METHOD_R1(std::string, echo, std::string); RCF_END(I_Echo); int main() { std::cout << RcfClient<I_Echo>("localhost", 50001).echo("ho hum"); return 0; }
Because when you app grows you will have to re-write it. More likely, is that won't happen and people will re-invent the again. Take a look at the development of SOAP .
I guess the argument boils down to this: does anyone write network applications for which CORBA-style scaleability is not a requirement? I would think so, but maybe I'm wrong. RPC's don't scale too well, we both agree on that. But why do you think all applications need to scale? If I'm prototyping something, then the last thing in the world I need is scaleability, and I certainly wouldn't want the development cluttered and slowed because someone has decreed that we must all use CORBA because it scales so well. Your position seems to be that programmers should not be afforded the option of choosing; they should just bite the bullet and always use CORBA. If they don't like that, then they should just avoid networking altogether. /Jarl.
participants (2)
-
Iain Hanson -
Jarl Lindrud