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.

Web architecture 101

I want to ask about programming languages: because I've never written web applications and have very little idea.

I might want to write a web application which:

* Talks to a database on the server side
* Generates web pages using data in that database
* Runs on Windows (and IIS I guess)
* Runs on Linux (and Apache I guess)
* Needn't serve very many users: much more like FogBugz than like Amazon.

1) My first question is what languages are good for writing this kind of application? By "good", I think I mean "a single set of source code, to run on either platform with minimal platform-specific differences". As there's more than one possible language, I'd especially appreciate some little comparative statements to explain what's especially good or bad about each, i.e. how or why to choose one over another.

2) If a second requirement is a 'thick' desktop client application which ...

* Need only run on Windows, and provides a richer UI than the web pages
* Implements the same business logic on the data as the web pages
* Works with a replicated local copy of the data, the updates to which it synchs periodically into the main (network) database

... then can business logic (the layer between the UI and the database) be written to run on the web server and be reused in the implementation of the stand-alone desk-top application, and if so how would this affect the architecture of the web application?
Christopher Wells Send private email
Sunday, June 11, 2006
 
 
Pretty much any *nix 'high level language' meets your requirements
 - perl
 - ruby
 - php
 - python

Any of those are simple to learn and can run under *nix or windows.

There's a chance that you could embed python in your desktop app too, also reuse the libs for that, though that would be trickier.
Shannon Russell Send private email
Sunday, June 11, 2006
 
 
"My first question is what languages are good for writing this kind of application?"

I might get flamed for this but this is what PHP is designed for.  I develop with PHP on my Windows box and deploy to Linux -- unless you are doing something really fancy there is nothing platform-specific about it.

It's easy to install, installed just about everywhere by default (even w/ most Windows hosts).  Can talk to just about every database via native APIs or there are several high-level database class libraries.  Plenty of built-in support and external libraries for just about anything you'd ever want to do.

PHP is considered by many to be an ugly language but it's honestly not that bad.  I think it really depends on how you use it.  I think my open source project FruitShow (see my link; powered by FruitShow) is a good example of clean PHP code.
Almost H. Anonymous Send private email
Sunday, June 11, 2006
 
 
I'll be brief, but to the point.

1) There are numerous platforms which can do what you need: Java, Ruby (on Rails), Python, even .NET to a point. However, in my personal experience, one platform that covers it all is PHP, preferrably version 5. (Note: This is not a PHP fanboy post, this is a pragmatic advice drawn from personal experience.)

1a) The above being said, I would suggest you to use whatever language/platform you and your team are most familiar with. Practically avery programming platform has some kind of Web development support in one way or another, and you will be much more productive with something you are already familiar with and need to learn only the Web-specific paradigms.

2) Sure -- learn a bit about service oriented architecture -- http://en.wikipedia.org/wiki/Service-Oriented_Architecture -- and especially Web services -- http://en.wikipedia.org/wiki/Web_service . They are essentially Web pages for other programs, which enable remote procedure calls over the standard Web platform (XML/HTTP). Your thick client can call those services just as easily as it would call a local DLL, provided its computer is connected to the Internet.
Berislav Lopac Send private email
Sunday, June 11, 2006
 
 
"if so how would this affect the architecture of the web application?"

You'd need to provide an API which could be easily callable via a web service -- this is pretty easy to do in pretty much any language.
Almost H. Anonymous Send private email
Sunday, June 11, 2006
 
 
> The above being said, I would suggest you to use whatever language/platform you and your team are most familiar with.

That would be C++ or C#:

* C#: Using C# on the Linux web server means using Mono, right? I see that http://www.mono-project.com does indeed say many promising things about itself, and includes more-or-less complete implementations of the System.Data, System.Web, and System.Xml classes among others.

* C/C++: Aren't the C/C++ library APIs available for accessing databases, Xml, etc., all different for each O/S? In the past I've written C++ abstraction layers to hide the differences between various device, platform, and database APIs ... I hoped that this time, using some other language might implement that abstraction for me, and let me concentrate on the business logic.


> Your thick client can call web services just as easily as it would call a local DLL, provided its computer is connected to the Internet.

Yes I think I understand that if an application accessed via a web server can return HTML to a web browser client, the same application can equally easily to be written to return XML to a thick client.

But what I'm not entirely sure of is how to reuse this code in the architecture of a disconnected client that has a local replica of the database:

a) Put a copy of the entire web service, including the web server (e.g Apache) on the client machine, and have the client talk to it using http://localhost -- is that a common-place architecture, or is it bizarre? http://en.wikipedia.org/wiki/Web_service mentions various transport protocols such as HTTP, which I think of as primarily WAN protocols.

b) Put the business logic minus the web server on the client machine as a stand-alone, long-lived, GUI-less EXE, and have the desktop client talk to it using a more local (less web-enabled) transport, for example an NT anonymous pipe, or TCP to a private local socket, or something.

c) Put the business logic on the client machine as a short-lived, transient EXE (similar to a CGI), and have the client interface to it by exec-ing it and hooking its stdout and stdin.

d) Put the business logic on the client machine as a DLL, and have the desktop client access its API directly, either using LoadLibrary, or using COM if the DLL implements a COM interface -- in that case, the language would need to be compiled (not interpreted), export API functions with standard parameter conventions, and/or be able to implement (not just use) a COM interface; I don't see that this is doable with PHP for example.

-----

So to summarize, it looks like the options are:

* C# (used as a DLL in the disconnected client stack)
* PHP (using option b. above if I want to cache the data from the database, otherwise option c)
Christopher Wells Send private email
Sunday, June 11, 2006
 
 
"But what I'm not entirely sure of is how to reuse this code in the architecture of a disconnected client"

Given the requirement of a disconnected local database and a web-enabled cross-platform environment (seriously, are those the requirements?), then maybe you'd be better off in either Java or C#.  The only reason to hestitate on C# is the uncertainty about mono -- if you're willing to accept some cross-platform compatibility issues than maybe that's the best choice.

"a) ... is that a common-place architecture, or is it bizarre?"

Bizarre.  Total overkill.  You don't want a whole web-services overhead just for a local application when you could write a common library and call it both from the desktop application and the web application.

"b) Put the business logic minus the web server on the client machine as a stand-alone, long-lived, GUI-less EXE"

Same as above..  why communicate over sockets or whatever when you can make direct calls.

"d) Put the business logic on the client machine as a DLL"

Bingo.  You can call C functions from PHP.  You could just build a C# library that works on both the desktop application and in ASP.NET/Mono.  Or build the whole thing in Java (although ugly).
Almost H. Anonymous Send private email
Monday, June 12, 2006
 
 
> Your thick client can call those services just as easily as > it would call a local DLL

Be very careful about this - the design of an API to a local DLL is likely to be very different to how you would design a web service. Beware "chatty" interfaces for remote services.
Arethuza Send private email
Monday, June 12, 2006
 
 
> the requirement of a disconnected local database and a web-enabled cross-platform environment (seriously, are those the requirements?)

The two scenarios (web-based, and disconnected) are both obviously useful; but reusing code between the two scenarios is an implementation detail, not an end-user requirement.


> Bingo.  You can call C functions from PHP.

Yes but not the other way around, eh? If I'm using PHP on the web server (to get PHP's cross-platform goodness), then the code that I'd want to re-use in the desktop 'library' would be PHP (not C).

I don't see that PHP code (for example) can be packaged as a DLL that can be called from C, and ditto most other of the higher-level languages (Java, etc.). Isn't that so?

That's a reason why I was thinking of option c): package the 'library' as a short-lived EXE, coded to be invoked using CLI on the desktop (which is almost the same as being invoked using CGI on the web server).

I can't believe this is a brand new problem: surely there must be some well-known solution[s] to it.
Christopher Wells Send private email
Monday, June 12, 2006
 
 
>> Bingo.  You can call C functions from PHP.
>
> Yes but not the other way around, eh? If I'm using PHP on
> the web server (to get PHP's cross-platform goodness), then
> the code that I'd want to re-use in the desktop 'library'
> would be PHP (not C).
>
> I don't see that PHP code (for example) can be packaged as
> a DLL that can be called from C, and ditto most other of
> the higher-level languages (Java, etc.). Isn't that so?

Don't think of PHP as a "language", but as of a Web platform. Specifically, you don't want to reuse PHP in C except as a Web service deployed and called from a remote server. If you need to call something from the server, prepare it server side as a Web services server and call it from a local client. Then it doesn't matter which language the server side is written in, as long as it conforms to a standard (SOAP is a good choice here) that the client recognizes.

But if you have the same *functionality* you want to execute separately on the server and on the client, and you want to reuse the code, prepare some platform-independent C DLL or .so or whatever and a) include it in the build for the client application, and b) wrap it into a PHP extension to be called server side. PHP extensions are written in C (++) and can be called via Zend engine directly from PHP.

Basically, PHP is a platform built in C, which just has its own syntax for implementations.
Berislav Lopac Send private email
Monday, June 12, 2006
 
 
"then the code that I'd want to re-use in the desktop 'library' would be PHP (not C)."

I'm not sure why.  C is cross-platform as long as you don't call anything.  If your using PHP for the web platform and something else as the desktop platform they could both call a middle-layer written in C/C++ which encapsulates the business logic.  In which case, you can isolate a lot of the platform-specific implementation away from the middle-layer.

It seems to me that you want to mix things at the wrong level.  Think of both the web and the desktop as the presentation layers.  Implement your middle layer as a library (in whatever language/platform) which is then called by whichever presentation layer is in use.

Obviously, it would be a better choice to have a single language/platform across the board.  This would make C# or Java logical choices.  However, you can mix and match a lot of languages and interface them together.  Any language can call C functions.

"package the 'library' as a short-lived EXE, coded to be invoked using CLI on the desktop (which is almost the same as being invoked using CGI on the web server)."

This would be a performance nightmare.  Generally speaking, it's rare that anyone uses CGI on a web server for that very reason.  99% of the time PHP is compiled as a module and linked right into the webserver.

"I can't believe this is a brand new problem: surely there must be some well-known solution[s] to it."

Anything that needs to be cross-platform is a pain in the ass.  Most people just go single-platform, use C#, and be done with it.
Almost H. Anonymous Send private email
Monday, June 12, 2006
 
 
> prepare some platform-independent C DLL

I thought there's no such thing as "platform-independent C": because the C APIs for database and for XML I/O are different on the different platforms; and that's why I was wondering about a business layer in PHP or any other language (C#, Java) that seems equipped with platform-independent APIs for these things.

So, can I package PHP (or Java, or some other well-libraried language I don't know like PERL or Phython) as a DLL callable from a desktop application?

If not, what do you think of the idea of packaging it as an EXE to run on the client, either as one long-lived peer of, or as transient child instances of, the stand-alone desktop client?
Christopher Wells Send private email
Monday, June 12, 2006
 
 
Well PHP is written in C and is cross-platform.  It's also just a very light layer over top of other C libraries.  I can't see why libraries for XML I/O would be any different; what is your chosen database platform?

PHP isn't a good choice as a general-purpose scripting language in this way but you can 'host' many scripting languages (like Python) in your application.  That still, however, doesn't seem like a good way to go.
Almost H. Anonymous Send private email
Monday, June 12, 2006
 
 
Alright I'll look at the PHP source to see how that manages.

> what is your chosen database platform?

I haven't chosen: MS SQL, I expect, and something else, MySQL perhaps.

Thank you for your advice.
Christopher Wells Send private email
Tuesday, June 13, 2006
 
 
About the overkill mentioned above, you don't have to use "real" Web Services or SOAP. Use whatever you like that goes over http. Devlop a server part with most of the logic. It is very ease to talk to this from any language that can handle http and a little parsing. With this solution you can even change language on the client without touching the server.

You should probably read a little about REST.

Read more about dataformats here
http://developer.yahoo.com/common/phpserial.html

and here
http://en.wikipedia.org/wiki/JSON

Regarding what language your team knows, if it's c# it is easiest to start with that. But ASP.NET is not that easy. I think PHP or RubyOnRails are easier to get started with.

Just my thoughts. And for the record, I work in .NET/C# everyday but in PHP only once a month.
JB Send private email
Friday, June 16, 2006
 
 
No one mentioned Perl which is what I suggest given the requrements.  It runs x-platforms (Unix & Windows), has great GUI tools, has great web server support (mod_perl) and you can run Apache under Windows if you want with mod_perl.  Database?  DBI:DBD under perl can connect to just about every RDBMS under the sun.

And, Perl can call C routines and you can call Perl from C including embedding the Perl interpreter in a C program!
~Eric
Friday, June 16, 2006
 
 
also, I should add.  If you're unsure about a database you can use PostgreSQL and PostgreSQL supports Perl as one of its procedural languages; which means you can write database logic (stored procedures, triggers, events) in Perl and you can execute Perl code from SQL calls this way.
~Eric
Friday, June 16, 2006
 
 

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

Other recent topics Other recent topics
 
Powered by FogBugz