This is going to be a pretty open ended question; but at this point this is all I have to start with. We currently have a 2 tier application design. What that means is that we have a C++ API that connects to our SQL Server and does typical database operations such as insert/update/query. We are looking to make this a 3-tier design with some sort of an application server sitting in the middle. The goal is that as we get more load; we do not need to deal with the DB being the bottle neck. The design is to have all communication from users happen with the ‘middle tier’ and then go to the DB. This will eliminate us putting our complex business rules in the DB triggers and have the middle tier handle them.
The thing I am still unclear on is what that middle tier looks like. Does it have to be a some sort of an WebService? All clients make some connection to the middle tier using HTTP and then we pass that on to the DB? As you can tell; from a C++ API to a webservice; thats quite a big shift. Any resources you have to help me get my mind going on this topic will be greatly appreciated. Thanks!
This is going to be a pretty open ended question; but at this point
Share
Since you already have a C++ API that connects to our SQL Server and performs operations directly on it, this seems to be an already fit candidate to be refactored into the middle tier of your design. This code already manipulates the database according to some rules, which is exactly what your middle tier should do.
The rest of the work that remains to be done is to separate the presentation logic from this API and allow it to reside in its own applications, that connect to the middle tier C++ API in order to have their data processed by it, stored in the database and the results returned back for being displayed to the user.
As for the connection between the presentation tier and the C++ API, depending on what your requirements are, you may use either a proprietary communication protocol (implemented, for instance, through TCP/IP or RPC), or HTTP, by having an intermediary “relay” web-service that calls your C++ API from the server and returns back results to the caller. The HTTP choice, although faster to implement initially, has some aspects to consider, such as the fact that by default, it’s stateless (you’ll need to implement user sessions yourself) and that it will have to be kept in sync with the code, when public methods change during development.