The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

client-Server myth?

I have been into emdedded system for quite sometime, however, planning to get my hands dirty on Distributed Systems( client/server). I have to design an application that would be client server in nature, client will be desktop(Not browser) in this context and server will reside on FreeBSD/Linux.
Data will reside on server and will also be available on user's machine locally. Client will use windows. Now as per my research, there would be some middleware..
Anyways, my question is how should i go about understanding the requirements and skillset required for this project? What is that(Skills) i need to know, in any particular order?
On clients side im planning to use .NET, is that decision right? What about the .NET learning curve required for this project?
Same goes for server-side i.e. FreeBSD/Linux? Any particular skills i need to know to build server-side? What about the server-side learning curve?

Your recommendations will be highly appreciated.
clientServerWannaBe Send private email
Tuesday, March 28, 2006
 
 
There's no way to give a meaningful answer to this without knowing what you're trying to make.

What is the myth?

Why does your research show you that you need middleware?
sloop
Tuesday, March 28, 2006
 
 
In my sphere, "client/server" means there is a program such as SQL Server on a server controlling access to the database, and a program on each workstation that actually runs the interface logic.

Other "middleware" apps can provide business logic, interfaces, etc.

There is no myth here - it really works and works well.
Karl Perry Send private email
Tuesday, March 28, 2006
 
 
Considering the original poster's inexperience with this sort of thing, I would strongly discourage the use of .NET on the client in tandem with a Linux/BSD server.

Probably the easiest way to get started is to use Java on both ends, and use sockets or RMI for communicating between the two. C++ may be a better option depending on what he's trying to accomplish, but the learning curve is considerably steeper.
TheDavid
Tuesday, March 28, 2006
 
 
A classic client/server app has the "fat client" with all the logic, and a database on the server.

If the client's on a Windows box, there's really no reason NOT to go with .NET. He'll be able to get his client app running quickly without the gigantically steep learning curve that Win32 requires.

As for the server, there isn't a relational database in the world that you can't connect to with .NET, regardless of what OS it's running on.

If there's some middleware in there, .NET is still a good choice, you just need to make sure there's some sort of .NET connector first.
Chris Tavares Send private email
Tuesday, March 28, 2006
 
 
If you want to know more about how to build applications like this, read "Patterns Of Enterprise Architecture" by Martin Fowler.

  http://www.amazon.com/gp/product/0321127420/
enterpriser
Tuesday, March 28, 2006
 
 
Thank you everyone for your answers
Chris replied
"

As for the server, there isn't a relational database in the world that you can't connect to with .NET, regardless of what OS it's running on.

"

Chris, what if i want to use a flat-file based system rather than a relational database on linux/freeBSD. Are there any flat-file systems that you connect with .NET on linux/freeBSD?
Thanks in advance for your help.
clientServerWannaBe Send private email
Thursday, March 30, 2006
 
 
Advantage Database Server is a flatfile database (my def: it uses individual files for data, indexes and memos rather than glomming everything into a single file) that has a Linux flavor.

 http://www.advantagedatabase.com

Make sure are not confusing "server based" with "client/server."  A Microsoft Access database can be stored on a server and accessed from multiple client pc's each running an instance of an app, but it is NOT  client/server since there is no application/service running on the server that provides database services to the client application.
Karl Perry Send private email
Thursday, March 30, 2006
 
 
Are there flat-file databases you can connect to? I have no idea.

I do know this: if you can call into the code from C or C++, you should be able to call into it from C#. Your flat-file database has a C api of some sort, yes? And that API runs on Windows, yes? If so, you can most likely call it from a .NET app. If you have and ODBC or OLEDB driver, you can access those trivially. If it's a C library, you'll need to write a tiny bit of shim code - basically declarations. If it's a COM api, you just add a reference and you're off and running.

The .NET folks spent a LOT of time on interoperation with other technologies, and it shows. There's very few DLL's that it can't call into.
Chris Tavares Send private email
Thursday, March 30, 2006
 
 
Why does it need to be a flat file, non-server?  Seems to me even if you had a single or couple table database with no relations it would still make sense to do it in an MSDE or mySQL since that would speed up access.
Lee
Friday, March 31, 2006
 
 
And for connecting windows to linux, ODBC will work.  Then the database used doesn't matter.
Lee
Friday, March 31, 2006
 
 
I think there are tools to read and write XML in both PHP and .NET. This may be an option to consider.
On your server, have a resource protected and accessed by a service/monitor.
On your client, have a proxy agent that can model the state of the service's protocol and present the remote resource as if it is a local resource.
Have a look at ReSTful services, that use HTTP's GET, PUT, POST, and DELETE to treat resources as (virtual) XML files. The server provides some sort of list/directory of hypretext links to existing resources and some sort of resource factory.
purple bobby Send private email
Sunday, April 02, 2006
 
 
Tom Vu
Sunday, April 09, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz