Developing "Nth-Tier" Web Applications For Unix? 28
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."
Maybe yes (Score:1)
Depends on the tech you want to use ... (Score:2)
JSP and servlets (Score:2)
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 (Score:4)
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.
Best Bet (Score:2)
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 (Score:3)
For full-on EJB (J2EE) support, try Allaire's JRun [allaire.com]. 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 (Score:4)
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?
J2EE is the way to go (Score:2)
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 (Score:2)
Re:Maybe yes (Score:1)
The "developer edition" is free-as-in-beer. Its limited to three concurrent connections, though.
Distribution is key (Score:1)
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.
w2k (Score:1)
--
Peace,
Lord Omlette
ICQ# 77863057
Re:perl modules analogous to COM objects (Score:2)
--
Peace,
Lord Omlette
ICQ# 77863057
in terms of m$' 3-tier thingee (Score:1)
--
Peace,
Lord Omlette
ICQ# 77863057
Re:Teirs (Score:2)
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:Distribution is key (Score:1)
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
Why n-Tier ?? (Score:1)
Another reason (separating presentation from
other things)
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.
PHP is much better, stable and funcional (Score:1)
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.
XML (Score:1)
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!
Re:perl modules analogous to COM objects (Score:1)
You would be better off with something like Mason [masonhq.com] 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! :)
So, noone thought of TCL? (Score:1)
It's not just for GUI, you know :)
For a web-server you can have either:
Your database may be MySQL or PostgreSQL [postgresql.org] (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 [postgresql.org] (not anemic at all, IMHO). Postgres can be built to support SSL connections and comes with pgaccess [www.flex.ro] -- 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:
For distributed objects, etc. you could use TCL-DP [cornell.edu]. 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:Definitely yes (Score:2)
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.
Re:Teirs (Score:2)
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.
Re:Maybe yes (Score:1)
Re:So, noone thought of TCL? (Score:1)
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:PHP is much better, stable and funcional (Score:1)
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.
Re:Why n-Tier ?? (Score:1)
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.
A victim of my own tagline (Score:2)
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