Interest for a (webservice?) connector using e.g. SOAP?
by Thomas \"Man of Ice\" Lund · in Torque Game Engine · 05/12/2004 (3:30 am) · 19 replies
I'm currently working on a backend system for recording scores from a Torque server, and was wondering if others would have similar interest and/or comments on how to do this best.
My backend platform is a JBoss java application server with CMP beans and sessionbeans, but it could practically be anything if implemented right.
I've seen several resources for Torque accessing databases directly, but this architecture ties your clients (the game servers) directly to your data backend, violating the defacto standard of n-tier (n>2) applications. A simple change in your database will require you to recompile all game servers - not nice.
So I've been giving it a bit thought, and using a webservice interface would enable the servers to access backend resources totally independent of technology (c++, .net, java, ejb, whatever), as well as removing the dependency on database table layouts.
Problem with this would be that e.g. SOAP is totally lacking security features - a general trait of webservices.
The alternative would be to tie the connector to a specific technology platform e.g. .net. This would not be a wise move imho.
So looking at the options one could take SOAP and wrap it up with SSL as well as encrypting the content of the data send using individual asymetric server keys, where the backend could verify authenticity of the server before accepting the data requests.
If you made it this far, then what do you think? Is this viable solution for somewhat trusted game servers?
Status for my little project is that I got the entire backend running (for my game project), but havent started work on the connector yet. Exposing session bean methods as webservices using SOAP is trivial (using xdoclet and jboss.net). The backend system has player management, registration of credits (like credits to play a game in the arcade machines), recording of game sessions and recording of scores/highscores. To connect the Torque servers to the backend webservice I was thinking about using Apache Axis for C++.
ETA on my entire game project is before summer. If enough people are interested I would possibly release this system as a resource (free or for money) - or at least parts of it.
My backend platform is a JBoss java application server with CMP beans and sessionbeans, but it could practically be anything if implemented right.
I've seen several resources for Torque accessing databases directly, but this architecture ties your clients (the game servers) directly to your data backend, violating the defacto standard of n-tier (n>2) applications. A simple change in your database will require you to recompile all game servers - not nice.
So I've been giving it a bit thought, and using a webservice interface would enable the servers to access backend resources totally independent of technology (c++, .net, java, ejb, whatever), as well as removing the dependency on database table layouts.
Problem with this would be that e.g. SOAP is totally lacking security features - a general trait of webservices.
The alternative would be to tie the connector to a specific technology platform e.g. .net. This would not be a wise move imho.
So looking at the options one could take SOAP and wrap it up with SSL as well as encrypting the content of the data send using individual asymetric server keys, where the backend could verify authenticity of the server before accepting the data requests.
If you made it this far, then what do you think? Is this viable solution for somewhat trusted game servers?
Status for my little project is that I got the entire backend running (for my game project), but havent started work on the connector yet. Exposing session bean methods as webservices using SOAP is trivial (using xdoclet and jboss.net). The backend system has player management, registration of credits (like credits to play a game in the arcade machines), recording of game sessions and recording of scores/highscores. To connect the Torque servers to the backend webservice I was thinking about using Apache Axis for C++.
ETA on my entire game project is before summer. If enough people are interested I would possibly release this system as a resource (free or for money) - or at least parts of it.
#2
If the problem you're trying to solve is not trying the db directly to Torque, then build a data access layer using whatever technology you want. You can expose access to it via web services if you want, but they would be local to your LAN and not available to the outside world.
05/12/2004 (4:12 pm)
@Thomas: I'm not sure it's all that important to obscure any information through security. If you can expose information like game sessions, high scores, etc. through web services then do it. How secured does that information have to be? Is it really bad to see who's the high scoring player on your server. Personally I don't think so but your mileage may vary.If the problem you're trying to solve is not trying the db directly to Torque, then build a data access layer using whatever technology you want. You can expose access to it via web services if you want, but they would be local to your LAN and not available to the outside world.
#3
using "built ins" like ssl and ip filters all the way up to STRONG encryption digital signatures to public/private key encryptiong of the payload. I have done all these variations and they all work, just depends on how much effort you want to go to.
05/12/2004 (5:23 pm)
Webservices can be made secure just like anything else.using "built ins" like ssl and ip filters all the way up to STRONG encryption digital signatures to public/private key encryptiong of the payload. I have done all these variations and they all work, just depends on how much effort you want to go to.
#4
Adding ssl and ip filters to the exposed webservices would be quite easy.
I'll move forward in that direction, and see what comes out of it. Thanks for the comments.
05/13/2004 (1:22 am)
@Bill: Pulling out lists of e.g. highscores or similar would not have to be secure, but updating them would. How else prevent cheaters from just posting "I scored a gazillion points in 2 secs" by simulating being a game server?Adding ssl and ip filters to the exposed webservices would be quite easy.
I'll move forward in that direction, and see what comes out of it. Thanks for the comments.
#5
Hope this helps.
r/Alex
05/13/2004 (3:06 am)
I built something similar but its more for a business application. I would suggest that you look into ICE by ZeroC. If I'm not mistaken (I just skimmed this post) you should look at thier IceStorm module. :)Hope this helps.
r/Alex
#6
05/13/2004 (10:53 am)
Sounds like you're trying to solve the wrong problem, Thomas. :)
#7
Even if you throw all the cryptography in the world at the problem, it would still be a relatively simple proposition to alter the scores in the server's memory before they're encrypted or sent anywhere.
Cryptography only protects you from man in the middle attacks in this case - don't make the mistake of thinking it will help you with an untrustworthy game server.
05/13/2004 (12:17 pm)
Quote:@Bill: Pulling out lists of e.g. highscores or similar would not have to be secure, but updating them would. How else prevent cheaters from just posting "I scored a gazillion points in 2 secs" by simulating being a game server?
Even if you throw all the cryptography in the world at the problem, it would still be a relatively simple proposition to alter the scores in the server's memory before they're encrypted or sent anywhere.
Cryptography only protects you from man in the middle attacks in this case - don't make the mistake of thinking it will help you with an untrustworthy game server.
#8
As for web services, it would be great to expose things like high scores and such with them. Basically web services should be treated as such, a service. Not a mechanism to provide some kind of secure update facility. That can be accomplished lots of other ways.
05/13/2004 (12:26 pm)
@Thomas: I was reading this thread and thinking about the problem you're trying to solve, which I'm not quite clear on what's trying to be achieved.As for web services, it would be great to expose things like high scores and such with them. Basically web services should be treated as such, a service. Not a mechanism to provide some kind of secure update facility. That can be accomplished lots of other ways.
#9
What I'm worrying about is the communication between game server and backend as well as only allowing the registered servers to update data. Read can be done by all. IP filter and SSL solves those 2 concerns
05/13/2004 (12:27 pm)
Thanks for the warning, but (at least for my project) all servers will run at trusted locations only (hosted by me ;-) )What I'm worrying about is the communication between game server and backend as well as only allowing the registered servers to update data. Read can be done by all. IP filter and SSL solves those 2 concerns
#10
05/13/2004 (12:29 pm)
@Thomas: Communication between your game server and backend should be on a LAN where you can use whatever method you want, behind a firewall, etc. IP filtering, etc. would be ways to manage that. Again it all goes back to how much effort do you want to put into protecting something (we're not talking about credit cards or sensitive data here) but that's your call. Good luck on your efforts.
#11
I'm trying to accomplish several things. First and foremost a separation of technology. I personally hate 2-tier systems and the issues involved with them in regards of maintainability and (lack of) easy upgradability.
So I want to separate the updating and reading of backend data using webservices and some sort of generic connector.
I also want to separate technologies. C++ is definitely not the most productive language for backend systems compared to Java/J2EE, while game servers naturally are C++ - again webservices to your rescue.
In this multi client world we live in, data should also be accessible through e.g. webbrowsers, and not only game clients/game servers. Webservices to your rescue.
I dont see webservices as a read only medium. Webservice is just a fancy word for RPC using xml and http (put in Corba, RMI, DCOM etc instead of PRC if you want). So its not restricted to serving data, but just as fit to update data too - if done securely - whatever that means as nothing is 100% secure.
All this can naturally be used simply using direct database integration, but this ties your systems together and is maintainance hell. n-tier systems are the solution and this is an attempt to create just that. It has a lot of drawbacks too, but one has to weigh in those factors when choosing technology always. To a hammer everything looks like a nail ;-)
05/13/2004 (12:56 pm)
@Bil: I'm trying to accomplish several things. First and foremost a separation of technology. I personally hate 2-tier systems and the issues involved with them in regards of maintainability and (lack of) easy upgradability.
So I want to separate the updating and reading of backend data using webservices and some sort of generic connector.
I also want to separate technologies. C++ is definitely not the most productive language for backend systems compared to Java/J2EE, while game servers naturally are C++ - again webservices to your rescue.
In this multi client world we live in, data should also be accessible through e.g. webbrowsers, and not only game clients/game servers. Webservices to your rescue.
I dont see webservices as a read only medium. Webservice is just a fancy word for RPC using xml and http (put in Corba, RMI, DCOM etc instead of PRC if you want). So its not restricted to serving data, but just as fit to update data too - if done securely - whatever that means as nothing is 100% secure.
All this can naturally be used simply using direct database integration, but this ties your systems together and is maintainance hell. n-tier systems are the solution and this is an attempt to create just that. It has a lot of drawbacks too, but one has to weigh in those factors when choosing technology always. To a hammer everything looks like a nail ;-)
#12
From 2001 to mid-2003, I was working as a technical team manager for an R&D project to build an object oriented multi-dimension database. I stumbled into ICE by ZeroC when it was posted as a resource here in GG late 2002. It actually solved a lot of problems for my team particularly with speed, scalabilty, security and best of all it simplified our design.
From Thomas last post, ICE can help ... a lot. :)
r/Alex
05/13/2004 (7:26 pm)
This will sound like a testimonial so bear with me.From 2001 to mid-2003, I was working as a technical team manager for an R&D project to build an object oriented multi-dimension database. I stumbled into ICE by ZeroC when it was posted as a resource here in GG late 2002. It actually solved a lot of problems for my team particularly with speed, scalabilty, security and best of all it simplified our design.
From Thomas last post, ICE can help ... a lot. :)
r/Alex
#13
I was also toying with letting the client use SOAP for some tasks before actually joining a server, but I had problems with the current C++ soap implementations (I had a bunch of problems getting them to integrate/compile/work with TGE)
I am not using SOAP currently (since I have access to Java directly on the server, and all the game logic and persistence is using Java, not torquescript) but it sounds like a good way to go for what you are doing. You might look into gSOAP, as I believe it might be a bit farther along than Apache Axis C++.
By the way, if you aren't using XDoclet for developing your EJB's, Session beans and web services, you should give it a look, it makes yout life SOOOOOOOo much better :)
05/15/2004 (11:01 am)
As I have been working on my MMO-ish game, I have developed something I call TGE2EE *grin* which basically allows you to instantiate Java objects and manipulate them from torquescript. In addition, all of the TGE objects are exposed as java objects, so you basically can do anything in Java that you can do in Torquescript. My intention is to use this purely on the server side, but it works anywhere. I was also toying with letting the client use SOAP for some tasks before actually joining a server, but I had problems with the current C++ soap implementations (I had a bunch of problems getting them to integrate/compile/work with TGE)
I am not using SOAP currently (since I have access to Java directly on the server, and all the game logic and persistence is using Java, not torquescript) but it sounds like a good way to go for what you are doing. You might look into gSOAP, as I believe it might be a bit farther along than Apache Axis C++.
By the way, if you aren't using XDoclet for developing your EJB's, Session beans and web services, you should give it a look, it makes yout life SOOOOOOOo much better :)
#14
And yeah - been using xdoclet for years - fantastic program. It makes creating backend SO much easier. I designed my backend db, hooked them up in CMP and created session beans in 2 evenings. Fantastic speed of development for a fully transactional system with thread pools, db pools, cluster aware, db independant backend. I cant imagine the time I would need to have the same coded in C++.
I havent tried xdoclet for webservice generation, but a friend of mine made a project where its just a matter of adding 1 xdoclet line to the methods you want to expose using SOAP. How much easier can it get?
05/15/2004 (11:11 am)
Thanks for the info - could you tell me a bit more on your work? Sounds VERY interesting. What kind of tech do you use to expose objects written in language X to language Y? One of those "embed Java in C++" libraries?And yeah - been using xdoclet for years - fantastic program. It makes creating backend SO much easier. I designed my backend db, hooked them up in CMP and created session beans in 2 evenings. Fantastic speed of development for a fully transactional system with thread pools, db pools, cluster aware, db independant backend. I cant imagine the time I would need to have the same coded in C++.
I havent tried xdoclet for webservice generation, but a friend of mine made a project where its just a matter of adding 1 xdoclet line to the methods you want to expose using SOAP. How much easier can it get?
#15
Basically I'm using JNI and the Invocation API to accomplish this. When I startup TGE, I have a ConsoleFunction defined that creates an instance of a JVM running inside TGE. TGE classes (like SimObject, Player, AIPlayer, etc) are available to Java as "shadow" classes, meaning all their methods just proxy calls to the real C++ instances. You can also obtain references to C++ objects from the java side by id or name lookup, just like in torquescript. The tricky bit was getting the various methods on the java objects to be accessible automagically, since writing JNI is like a nightmare C++ version of reflection API, and if you are using reflection to write reflection code well.... you quickly go insane :)
05/15/2004 (11:34 am)
"Thanks for the info - could you tell me a bit more on your work? Sounds VERY interesting. What kind of tech do you use to expose objects written in language X to language Y? One of those "embed Java in C++" libraries?"Basically I'm using JNI and the Invocation API to accomplish this. When I startup TGE, I have a ConsoleFunction defined that creates an instance of a JVM running inside TGE. TGE classes (like SimObject, Player, AIPlayer, etc) are available to Java as "shadow" classes, meaning all their methods just proxy calls to the real C++ instances. You can also obtain references to C++ objects from the java side by id or name lookup, just like in torquescript. The tricky bit was getting the various methods on the java objects to be accessible automagically, since writing JNI is like a nightmare C++ version of reflection API, and if you are using reflection to write reflection code well.... you quickly go insane :)
#16
I'm working on the client side of the gsoap solution. Code is generated and tested locally in a stand alone setup - works like a charm.
But when I try to add it to TGE, it bombs out with external linking problems, problems with the auto generated code using new()
Just wanted to hear if you got this any further than where I'm stuck now
06/09/2004 (1:12 pm)
Hey Tigeba - hope you are still around (you do not have an email address in your profile, so I'll try here)I'm working on the client side of the gsoap solution. Code is generated and tested locally in a stand alone setup - works like a charm.
But when I try to add it to TGE, it bombs out with external linking problems, problems with the auto generated code using new()
Just wanted to hear if you got this any further than where I'm stuck now
#17
06/10/2004 (6:31 am)
I believe I experienced the same problems with GSoap and I was unable to get around them.
#18
I'll write up a resource about this and share the knowledge on how to do so.
07/07/2004 (3:13 am)
With some help from Ben G, I have this running with gsoap. So it is possible, but you need to patch the gsoap files as they try to use stuff from the std namespace, which TGE doesnt like.I'll write up a resource about this and share the knowledge on how to do so.
#19
07/11/2004 (10:43 am)
You can run a webservice under SSL and secure it the same way you would a web page. 
Associate Ron Yacketta
Recently I created a .NET C# webservice for user authentication, worked like a champ! Not a very indie friendly solution, seeing that win 2003 is expensive, but the backend can be written in php (as Daniel Nielson (excuse the sp)) has done and posted a resource about.
-Ron