Web Services and Serializable Objects

Mon, 24 Sep 2007 18:44:22 GMT

I've been currently working on getting one database syncronized with another. The task is hard to maintain two databases, so I thought about another way to approach the problem. Since everything eventually gets down to business logic, why maintain two databases? For reference purposes, one database is MS SQL and contains everything important for our main application. The other one is provided by a third-party via a Linux box running MySQL. Well, I would connect via ODBC and Read/Write data to the MS SQL Database for ease of programming (less ODBC drivers to handle on 30+ PCs). You may ask why I did such a thing? Well, the ODBC drivers are unreliable and as I found out, don't even work with Vista. So our client PCs would have been screwed if they relied on those drivers. Our one server, however, managed just fine so it did all the work for the clients.

Enter Web Services and XML.

The server, rather than updating a client database, now retrieves rows and provides business level objects via XML to the clients for direct use. It is a no brainer. Works far better and has less CPU usage on our main server. I define a single namespace with my objects and serialize them between web service and client app. On another note, it is also scalable but then again so was my other solution (provided the SQL Server was detached and moved with the sync service). However, this eliminates the need to detach anything. On the downside, I do not have a SQL Server method of backing up the data with my other data. I now need to backup seperately.

Journal-X1-5446

Web Services and Serializable Objects