> So either force the clients to use the same protocol you have defined, 
> or listen on different ports for the different protocols you want to 
> use. It sounds like you have now gone with the second option.

Yes i have gone with the second option. Because now I can for example 
write an adapter for googe (in my esb) but the server who handles those 
requests doesn't have to know about that adapter ! ( it just sends it, 
for example, in json to the esb. The esb will see that it should send it 
to google and will load the appropriate adapter and sends a request to 
the google server!) .. I am very pleased with this solution. :) after 
all it is (I think) the most elegant way to solve it.


> That's what I mean. If the overhead of Ruby is small compared to the 
> overhead of whatever is going on in the SQL database, then there's 
> little point rewriting the Ruby part in C++. Measure first, optimise 
> later.
Again you are right! I will first build the prototype in Ruby and make a 
few account for a few clients i have. By storing the request (in some 
kind of logging server) i can determine what the bottlenecks are and 
which language i should use to solve it :).

Thanxs Brian for the input ! REALLY appreciated :)
-- 
Posted via http://www.ruby-forum.com/.