Client-Server Solution Design

Question

I am trying to figure out what the best way to structure a client-server solution. In a nutshell, my solution should have a back-end that does logic, and be able to support multiple clients in an intranet. The key here is that there won't be thousands of simultaneous requests...it will likely be capped at a a couple hundred users, so scalability isn't really an issue. (picture the service running in an office building, on a local network). I'm struggling with the overall flow of how this should work, and which technologies I should be using.

The components are as follows:

• Logic portion, which will be on the server
• A Database
• Multiple desktop, mobile and web clients

So far what I've been able to come up with is the following:

1. I need to have an application server which will be managing the API calls from the logic, and the DB access.
2. A web server to sit on top of it, which will be managing the incoming requests.
3. The logic portion.
4. Clients which will conform to the API which we will define.

So I'm not sure how all this ties together...How will the "logic" interact with the application server? Does the "logic" need to be written like a server?

what I see is something like this:

        req  
client ----> web server ----> app server -----> Logic

                                |-----> DB

           response 
app server ---------> web server ----> client

So if I wanted to deploy a small-scale commercial solution, would this be the way to structure it?

Please let me know if I've been unclear, or if you need any more information.

Answer 1

You question is very general. The solution you suggested is a general too. If you won't pull out any specific requirements you will create a general-purpose system with average performance for average users. Assuming you have both mobile, desktop and web clients the idea to have a web server at front-end is a good point. But the issue then is to keep all business logic on the AppServer side. You can have some logic in the database in case of bulk data manipulations and having a performance requirements but this is rather an exception than the rule. Anyway you should have any specific requirements otherwise the design process looks like Feng Shui. Also you have to choose a technologies and build stack.