Developing "Nth-Tier" Web Applications For Unix?

Kismet asks: "I've recently been involved in a largish Web application written using Microsoft tools. It consists of a UI layer written in VBScript for Microsoft ASP, a business tier of COM objects, and a backend on SQL Server 7. How can I implement something like this with Linux? It's really easy to use server-side COM objects with ASP, but is there anything that easy for PHP or Mason or something else on Linux? PHP's database stuff is neat, but I'd like to move that out of the site script."

Comments

Depends on the tech you want to use ...

[RedDirt]

If you don't mind doing Java, then I'd suggest using jsp's for the page, jboss (or enhydra) for the middle tier and Oracle for the backend. Why Oracle instead of Postgresql or MySQL? Because in both of those cases, you have to invest more logic in the middle tier since the database has anemic (postgresql) or no (mysql) support for database side processing. The last project I did used Oracle, Voyager (a corba-like Java server) and Java server pages. Worked out really, really well.

JSP and servlets

[geophile]

I agree with the other posters who advocate Java: JSP for generating pages, and servlets for middle-tier business logic. A minimal solution would be something like Tomcat (which is open source) with Apache. If you want to use EJB, then you'll need something bigger than Tomcat.

As for the database, I like Oracle. You could also consider keeping the database on SQL Server. Either way, you'll need a JDBC driver. Pure Java ("type 4") drivers are a pretty safe bet. WebLogic has (or had) one for SQL Server, and Oracle has a free JDBC driver for Oracle.

Teirs

[PhiRatE]

I think you might have got a little obsessed with the concept of a "teir" for a start.

Essentially, PHP by itself, or any language that supports abstraction, which is pretty much all of them, can be teired, this is simply dividing your program logically into n parts, and having each part communicate with the others only through a tightly defined interface.

The benefits of the 3 teir webscript/operations/database model are laid precisely in this tightly defined interface, benefits such as better security (fine-grained permissions checks can be made within the second teir, avoiding the possibility of last teir compormise, and logical simplicity within the webscripts themselves. However it is not necessary to have a three teir architecture actually run on three different applications as such.

It is entirely practical for example to, in any major database, have both the first and second teirs within the database itself. Oracle, Microsoft SQL 6/7 and the rest of the heavyweights have built in programming languages which allow you to create SQL functions, some fairly simple configuration lets you force all incoming queries to functions rather than using SQL directly, giving you the opportunity to do the second teir authentication and abstraction using the database language.

I don't particularly recommend this in the MS-SQL case at least, the language is ugly, but it does work.

The other option is to create a good library set of objects or functions in PHP say, and use that as your second teir, using require or include to pull in the libraries that do the logic work, and constaining yourself to simple operations and layout within the website PHP themselves.

If you're really set on using a COM style system, you could try something like CORBA, PHP has bindings (http://www.php.net/manual/ref.satellite.php) which allow you to talk to CORBA objects, it is probably not, at this stage, as tightly integrated as COM is into ASP, but a few functions to wrap it up should work effectively.

Personally, for most setups, I would recommend having a logical two-teir structure within PHP, I have found this to be most effective, since most of your logic is in the same language, and it is simple to map from one to another and shift the borders of the interface a bit when the client makes that irritating little request that totally destroys your design.

Having worked heavily with a system that used 4 teirs (two within PHP and two within the database) I can say that that works very well, especially letting the second database teir handle solid permissions checks etc, making it much safer in the event of kids doing strange things with your web forms (although of course you should properly filter that stuff, but its nice to have a safety net or two).

perl is similarly capable for multi-teir design, although I personally find it less usable for web work than PHP.

Re:Teirs

[Kismet]

Thanks for the reply.

I'm not too familiar with the benefits of multi-tier development, but I understand that one of the principle benefits is the ability to distribute the computing of the middle tier by using COM or CORBA.

For this to be most effective, it seems that the best practice would be to remove Stored Procedures and business logic off of the back end and out of the server scripts. This logic would migrate into the middle tier, which could be easily distributed using the mechanisms available to CORBA or COM.

I've read several recommendations already about using Java and jsp, and also an interesting comment about CORBA bindings for PHP. That was kind of what I was looking for: a good Open Source solution for a distributed middle tier using CORBA.

I agree with one comment that it is quite a bit easier integrating this sort of thing with the Microsoft tools, but I'm pleased that at least there are ways of doing it on Linux too.

Again, my main intent with the tiers isn't so much with abstracting the project as it is with distributing it.

I'll have to look into Enhydra and jsp as well as the CORBA bindings for PHP.

Re:Teirs

[PhiRatE]

I appreciate your comments but note that starting off by dissing my experience pretty much makes whatever else you choose to say redundant, I won't listen to it, I'll just get annoyed, especially as I have extensive experience in the question at hand.

The original question was talking about Open Source software. By definition this means that any given piece of business logic is available for hacking into whatever forms are desirable, therefore it is entirely appropriate to discuss solutions based on technology that works for you, rather than what the vendor or author has chosen.

Certainly I have found that one of the true values of Open Source software is that you can use the architecture that should work and fit your software to it, rather than whatever architecture results from the various supported methods of interaction by the software you choose.

A large part of my experience revolves around clustered computing environments, and I assure you that the model I outlined with "php and databases" as you put it, distributes very well.

Both you, and the other reply here pointed out that integrating the middle teirs with the front or back end systems means that it isn't possible to distribute the middle teir seperately to one or the other. This is entirely true, and as far as I can see is the only valid argument for having a network (as opposed to internal) seperation in the interface between the middle teirs and the first and last in an Open Source non-legacy environment (which was the context of the question).

It has been my experience that the twisted, screwed up, heavily internetworked architectures utilised often by large companies to solve problems are the result of the closed-source model of development, and the resulting inability of the company concerned to make what are often minor changes necessary to simplify their architecture.

As a result of many years of heavily closed-source deployment in business, a whole field of expertise has arisen around system topology which involves large piles of middlewear, protocol conversion and application blackboxing.

I believe, from my own experience, that utilising Open Source software whereever possible in solving similar problems, has resulted in smaller, faster solutions that utilise less hardware and provide greater reliability.

Certainly, in my current position, the stuff I'm responsible for is leaving every other department, who are using closed-source solutions to many of the same problems, in the dust. We spent a fraction of the money, and our systems have vastly less downtime, and considerably superior performance and functionality.

I do not doubt that there are times when a real networked N teir setup is good. I maintain however that in the general case the selection of this model over a smaller N is due to software incompatibilities that cannot be resolved due closed-source restrictions on the modification of the application. I also note the Open Source worlds closer adherence to public standards and willingness to use commonly available standard libraries as a contributing factor to the fact that open code cooperates far more effectively than closed source software.

Best Bet

[paulywog]

I think that most of what there is out there has already been said in these few posts --

Your only real option is to use Java technologies like Java Server Pages and Enterprise Java Beans. The nice thing about this option is that many of the Java middle-tiers are cross platform. So if you ever felt the urge to host any tier of your application on a less reliable operating system, you'd be able to do that.

Re:Maybe yes

[zantispam]

Jakarta/Tomcat is a nice servlet container with jsp support. jserv is another servlet container. I personally prefer Tomcat because it's quite a bit easier to set up. For a full CORBA implementation, hook either container into ORBit, the Gnome ORB.

For full-on EJB (J2EE) support, try Allaire's JRun. Though not free in any sense of the word, it is a fully integrated EJB container and app server.

perl modules analogous to COM objects

[po_boy]

I believe that I have been doing this with perl and mysql. I draw the analogy this way:

My perl CGI scripts -> your ASP (VB) scripts
My perl modules -> your COM objects
MySQL -> your MS-SQL database

I use mason as my top tier also. I call perl modules that do the database calls and other more complicated computation/processing. It's my understanding that that is pretty much what COM objects do.

I've mentioned this analogy before in one of those "you can't do 3 tiered architectures in linux" debates before, but I've always been disregarded as a loon with no explanation. If this analogy doesn't hold, why not?

Re:perl modules analogous to COM objects

[Lord Omlette]

does the server automatically (ok, not automatically) handle transactions (atomic operations) for your cgi modules (the "COM objects")? in an n-tier environment, you usually use MTS to handle something like that... in win2k i think it's called com+ but i'm not sure. that's the only thing i can think of that would make your analogy less than kosher.
--
Peace,
Lord Omlette
ICQ# 77863057

J2EE is the way to go

[X]

This is definitely what the standard UNIX approach is to these kind of solutions. Weblogic is an obvious choice because it's been supported on Linux for a while. You'll find these kinds of solutions actually work much better than their COM/MTS/ASP counterparts.

Alternatively, you can go the open source route with something like Enhydra. It's not as sophisticated (yet), but it has most of what people need.

n-tier web applications

[elefantstn]

For great, easy-to-use, scalable open-source web application delivery, check out Enhydra by Lutris Technologies. It uses Java for easily programmable web applications, and comes with Director, which allows you to automatically connect servers for failover at the software level. Not only that, but it's free, or for a nominal fee, buy it and get support from Lutris. Also great is XMLC, which lets you take HTML (or other XML) pages, insert tags, and add in dynamic content very easily. Definitely worth at least downloading and trying out, it only takes about half an hour to learn the basics (assuming you know Java).

Re:Definitely yes

[X]

Weblogic application server is available for Linux. It just happens to be the #1 selling EJB app server out there.

There are also open source C++ app servers out there which will outperform (and obviously out integrate since the source is right there) an MS solution. It's just that you have to be crazy (or Microsoft) to put all that effort into the solution when there are J2EE approaches which are much easier.

A victim of my own tagline

[PhiRatE]

Please ignore the message I'm replying to. I was an idiot for the most part. And I recommend to fellow /.'ers not to reply to posts after working more than 30hrs, you produce drivel :/

I think I have an interesting point on the reduction of necessary teirs by using the benefits of the open source model (good protocol cooperation and source modification) but for the most part that post was long winded and silly, and not only that but I didn't re-read the original question so my ranting about the question being about Open Source software was totally bogus.

I'll promise to be better next time :)