Client-Server Application design suggestion
Hi,first i want to thank everyone who helps in this forums, i have learned a lot thanks to you guys ;)
Well here is my problem :
I am developing a client server application, the server connects to the database
and the client connects to the server using the QTcpSocket
The idea is that the client sends request to the server so the server performs some action to the database ( inserting records or retrieve a set of records using select for example ), this requests are sent to the server using XML to encapsulate the commands, and the server answers to the client using XML too
1) is there an XML protocol based in QT4 that i can use or i have to design it from zero ?
2) Suppose that the server receives a "SELECT * from User" request ( parsed from the XML protocol ) then the server must perform the solicited action on the database and somehow send the set of records to the client, what would be the best way to serialize the answer ? it must include blobs in case it is necesary
3) once the data has arrived to the client using the XML protocol what would be the most eficient way to use it ? should i fill it on a QStandaridItemModel for example ?
thank you very much for your ideas
PD: sorry my bad english
Re: Client-Server Application design suggestion
Quote:
Originally Posted by
berzeck
Hi,first i want to thank everyone who helps in this forums, i have learned a lot thanks to you guys ;)
Thx
Quote:
1) is there an XML protocol based in QT4 that i can use or i have to design it from zero ?
Search the forums (or google) for XML-RPC.
Quote:
2) Suppose that the server receives a "SELECT * from User" request ( parsed from the XML protocol )
Never do that. This is a plain way to abuse the protocol. You should have a set or commands which are safe to execute and don't allow a "do anything you want" command.
Quote:
then the server must perform the solicited action on the database and somehow send the set of records to the client, what would be the best way to serialize the answer ? it must include blobs in case it is necesary
SOAP protocol (or similar) is just the thing for you. Qt XML-RPC probably does what you want.
Quote:
3) once the data has arrived to the client using the XML protocol what would be the most eficient way to use it ? should i fill it on a QStandaridItemModel for example ?
It really depends what the data is and what you intend to do with it.
BTW. If XML is not a requirement, search forums and google for Qt+IPC - some other solutions might pop up. If you are willing to pay for a solution, then Thorsen Consulting have a nice library for IPC.
Re: Client-Server Application design suggestion
Thank you very much for your answer i will check it out for Qt XML-RPC as you suggested
I will post here when i have studied the solution
thank you again
Re: Client-Server Application design suggestion
Hi,
Personally I would use webservices ;)
Re: Client-Server Application design suggestion
Maybe an object oriented middleware will help you:
www.zeroc.com
Good luck,
Tom
Re: Client-Server Application design suggestion
Quote:
Originally Posted by
steg90
Hi,
Personally I would use webservices ;)
Webservices are exactly the same as XML-RPC. It's an approach, not a unique solution.
Re: Client-Server Application design suggestion
Quote:
Originally Posted by
berzeck
Thank you very much for your answer i will check it out for Qt XML-RPC as you suggested
I will post here when i have studied the solution
thank you again
Hi,
there is a Qt based application server that supports XML-RPC based on web services: FEAST
http://trolltech.com/partners/direct...ers/clausmark/
http://dist.trolltech.com/pdf/Clausm...nBrief_web.pdf
http://www.clausmark.com/feast_en.phtml
FEAST handles the concurrent user situation as well as taking care of
backend data sources with connection pooling etc. Actually FEAST is more
then a server; it is development framework for distributed applications
based on Qt.
FEAST uses SOAP HTTP as the communication protocol (it does not rely on
gSOAP though) so it is easy to use over the internet through firewalls
etc.
/Niklas