I want to create a no-gui command line application with client and server application running on different systems. Now I want to call objects in server from client application, something like RPC. Which technology is the best candidate here? COM, COM+, DCOM, CORBA, ATL, or anything else? I only have overview about these technologies, so please tell me which one is the best one to use.

plz help someone...

Thnx, here it goes :

- Basically my server will load plugins dynamically and make these plugins available to clients
- Reflection is needed for loaded classes
- plugins will be hosted only at the server
- It needs to be developed in c++ only
- Platform is Win XP
- Intended to be run in LAN
- Traffic will be low-medium

plz suggest

I don't have any experience with rpc with exception of some simple ruby applications but since no one is answering maybe I can help. Ruby has an xmlrpc module in its standard library something similar seems to be also available for c++. http://xmlrpc-c.sourceforge.net/
If you think rpc is the right way to go just google for rpc and c++ and you will easily find such libraries.

But since you only want to support win xp, c++ and lan(local, ~safe) maybe a much simpler solution can be used in your case. Can't you simply send the whole plugin to the client (plugin.dll)? Or make the plugins behave on the lan like a command line applications, you send a string like "SomePlugin -switch1 -switch2 ..." to the server and the server sends you the output as a string.

EDIT:
If you have problems saving arbitrary objects into strings you may want to look into boost::serialization and maybe yaml.


[Edited by - Kambiz on September 19, 2008 12:44:40 PM]

disclaimer this is from memory - and i dont have a lot of personal experience on the topic !!

COM, - component object model, not rpc layer unless combined with dcom marshalling which uses windows rpc mechanisms.

COM+, - = MTS ( managed transaction services) ? - i think was a MS layer on top of dcom, i remember seeing books on it around year 2000 - with a focus on business services. but i think but is largely abandoned by MS.

DCOM, - largely legacy now given NET remoting.

CORBA, - rpc mechanism similar to dcom. mostly out of favour - considered overly engineered, designed by committee with too many self interested groups leading to overly complicated specification, also has supposedly many incompatible vendor implementations. lots of language bindings available.

ATL, - is just a c++ heavily templatised method of working with COM/DCOM objects

text based xml, (slower than binary)

xml-rpc - (not rpc) basic messaging system using xml

soap - (is rpc) more complicated xml system - supports service discovery (reflection) and is schema orientated (wsdl).

rest - simpler than soap - uses http style urls for communication.

(note - none of these xml protocols have anything to say about client authentication or security models )


ASN.1 - (not rpc) low level specification for data serialization over networks that handles endiness and has special provision to support future extensions to types. it specifies a grammar for types and distinguishes the actual encoding system of which there are many (BER etc). its probably too heavyweight for small scale (individual) projects. used in ssl etc.

if interoperability is not important then hand rolled rpc mechanism might be the simplest. - maybe adapt boost serialization if using c++, and just pipe serialized obejcts over a network layer. i dont think you will easily extract real reflective capability with this approach however.

ACE is a binary protocol for messaging with lots of language bindings that might be interesting. i dont think its strictly rpc but could probably be adapted. dont know about reflection support.

c++ is generally really bad for anything to do with introspection/reflection, due to inherent lack of support in the language. so generally with c++ you have to map from a domain model (specified by eg. wsdl, asn.1, com idl file) to c++ types, rather than just annotating the implementation language.