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.