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

Maybe yes

[Suhas]

Microsoft beats the shit out of all platforms as far as tight integration and speed of execution is concerned.I really doubt you can do that on Linux unless there is an EJB app server on linux in which case you can use JSP, EJB's to build your stuff.

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.

Re:Maybe yes

[Evil Grinn]

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

The "developer edition" is free-as-in-beer. Its limited to three concurrent connections, though.

Re:Maybe yes

[Suhas]

that's what you are good for. Shovelling butter.

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.

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

Re:perl modules analogous to COM objects

[dannyspanner]

My perl CGI scripts -> your ASP (VB) scripts

You would be better off with something like Mason for a better analogy. It's like ASP on steroids. It works with "components" that allow you to split up your pages into reusable blocks and provides great mechanisms for templating and caching. It beats PHP hands down too, but then it is based on Perl! :)

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).

Distribution is key

[stephend]

This kind of side-steps the question but...

I believe the original intention of n-tier architecture was to separate out the business logic from the data storage and presentation logic. This is still an important issue for web applications, but scalability is probably of greater importance.

If you can run your app across several machines, preferably load-balanced, you're well away. Stuff like ASP and PHP can make that kind of thing tricky (as they're built into the web server).

The site I'm helping develop at work runs the web server (3xStrongholdApache), the application server (6xDynamo) and the database (2xOracle) on separate machines. If you swap Dynamo for Enhydra all that software will run on Linux.

Re:Distribution is key

[FlavorDave]

I agree with your view of scalability as the most important . The ability to scale is especially apparent if you go the Enterprise Java Beans route. Each vendor's Application Server has its strengths and weaknesses.

Ideally you can pick an Application Server that has facilities that are most important to you application (handling DB connection pooling or specialized handling of resources your beans depend on, etc.)...

Also, n-tier can used in design but deployed on 2 tiers (like client/server). On the last big app I helped design we kept entity, logic, and interface objects separate so later on we could move to 3 tiers later if needed. The system is currently a fat client with logic and interface in the front room and a SQL server in the backroom.

It should work well now that we're looking at deploying a web solution. We can toss our interactive screen objects and implement an interface layer that talks to a browser instead of the local screen.

A couple of well placed design patterns early on(especially Facade when dealing with interface objects) go a long way to facilitate these changes.

But I would be wary of designing and implementing n-tier just for the sake of saying "We're n-tier". If your implementation doesn't have room or capability to scale, one of the major benefits of going n-tier is lost.

-- Dave

w2k

[Lord Omlette]

changed that... With WLBS, Session state is distributed, so it's possible to have working Server farms. Whether their performance/stability/religion is acceptable to you is another thing altogether, but it's no longer as tricky as it used to be...
--
Peace,
Lord Omlette
ICQ# 77863057

in terms of m$' 3-tier thingee

[Lord Omlette]

the reason most nt projects are like what you described is as much for speed as for separating everything out... consider compiling your php as an interim step to fully scalable code.
--
Peace,
Lord Omlette
ICQ# 77863057

Why n-Tier ??

[shishu]

As someone already mentioned ... the primary reason (these days) for going n-Tier is that you can scale by load balancing the specific layer of your application which is taking the maximum hit.

Another reason (separating presentation from
other things) ... lets graphic/page designers
work on the front end while application
developers develop the application in parallel.
Also it allows you to build different interfaces
(or even different applications) over a common
group of functionality (the business logic).
e.g. you might have an internal administrative interface for a system that has another interface open to the public internet and maybe a third monitoring and maintainance interface.

Re:Why n-Tier ??

[Evil Grinn]

Another reason (separating presentation from other things) ... lets graphic/page designers work on the front end while application developers develop the application in parallel.

Has anybody ever actually worked on a project where this goal was realized ?

The way its always been in my personal experience is this: designers just create static pages and then programmers must go in and insert the "magic code" to make the app work. This often involves manual editing of complex HTML that was created with the aid of design tools. I do not consider this to truly live up to the claims that people usually make about separating content from presentation.

WebMacro looks like it might actually solve such problems... haven't used it myself, though.

PHP is much better, stable and funcional

[rod]

Dear dotters,
I've been working with large site for a couple of time as systems engineer. I already used BroadVision 1to1 with SSJavaScripting and Corba, ASP with relational databases and MTS among others. All I know is that PHP is much better. It has a number of good libraries, support for a level of objects, and is extremely FAST and STABLE.
Now, it's my preferred platform. I don't want to use that snowball n-tier technologies anymore. It's sure a problem in the future.

Sigh.

Re:PHP is much better, stable and funcional

[Ramshackle]

Well, what you're leaving out is that Broadvision is absolute crap. Like you said, it's server side JavaScript! Not Java. What a ludicrous concept.

On the other hand, server side Java is a great (IMO the best) way to implement an n-tier architecture. Our typical setups are I-Planet for static content, BEA WebLogic for Servlets and EJBs (may or may not be separate machines or clusters of machines between these tiers), and Oracle on the back end.

XML

[Aquafina]

The future of 3-tiered development will be like this:

gui -> business logic --> data layer

xml -> php/asp/com/jsp/etc... --> mysql/oracle/ms-sql/etc...

I've played with xml. I love that stuff. No more of those messy html snippets embedded within php scripts. Yuck!

So, noone thought of TCL?

[mi]

It's not just for GUI, you know :)

For a web-server you can have either:

• mod_dtcl in your Apache
• install NeoWebScript, which is an Apache with TCL and tons of TCL extensions
• use AOLServer -- don't let the name scare you, it is a highly-optimized multi-threaded web server. Its main features include database connection-pooling and a powerful Tcl API for application development
• install tclhttpd -- a web-server written entirely in TCL (with SSL support available), which works quite well for me

Your database may be MySQL or PostgreSQL (my preference).

PostgreSQL can be built with TCL support (a client library loadable into a TCL interpreter) and a server-side extension allowing you to write server-side procedures in TCL (not anemic at all, IMHO). Postgres can be built to support SSL connections and comes with pgaccess -- a fairly powerfull database browsing and management GUI-tool (written in TCL/TK).

For MySQL there are also at least two TCL-extensions that provide for TCL access to its client API:

• mysqltcl
• TCL-mySQL

For distributed objects, etc. you could use TCL-DP. Don't let the word beta scare you -- it does wonders. The remote ends can even talk over e-mail!

And there is nothing to beat TCL/TK for a cross-platform front-end application! That's a given...

-mi

P.S. It sucks that paragraph-tags can not have attributes in /. comments. IMHO <p align="justify"> is perfectly valid and quite desirable for a paragraph with over 120 characters...

Re:So, noone thought of TCL?

[realkiwi]

The webs best kept secret is called Tcl/Tk...

I agree 100% that it is by far the best way to go.

But... there are not as many programmers available as there are for Java.

Strange that both of these languages came from Sun isn't it.

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 :)