구글와이드(336x280)_상단 2개

Server-Side Scripting Shootout IT 영문자료

Server-Side Scripting Shootout
by W. T. Monkey Updated 21 May 2001
W. T. Monkey [an error occurred while processing this directive]likes tools and he's nobody's fool. He never bites people. Except for that one time. And Kristin isn't that upset.

1 Sever-Side Scripting Shootout
3 ColdFusion
5 Perl
Page 1

Here you are, fixing to tackle your very first Web-based application. Your new creation will need access to databases and the ability to respond to user input; it also must be dynamic, scalable, and robust. So obviously, old standbys XSSI and static files just aren't going to cut it this time around.
The good news is that there's no shortage of server-side scripting languages that can be used to build such a site: Perl and ASP (active server pages) are enormously popular, as are PHP, ColdFusion, and JSP (Java server pages). But with such a wealth of options out there, determining which environment best suits your needs can be bewildering.
One reason this decision-making process is so tricky is that the languages all do pretty much the same thing. They interface with databases, they access the file system of the OS, and they create dynamic pages. As a result, the reasons why you'd choose one over another are pretty subjective — it all depends on who you are and what you're trying to do.
So, what kind of programmer are you? Do you hate the look of curly brackets? Well, you should probably avoid Perl or PHP. Similarly, if the idea of using HTML-like tags makes you feel like a fraud (this isn't programming!), stay away from ColdFusion. There are, of course, more weighty matters to consider, like speed and stability. But as we discovered when we pitted Linux against NT, these attributes are evaluated differently by different people.
Since decisions like these are so subjective, we decided to ask actual Web programming professionals to tell us what development environment they prefer, and why. We found one champion for each of the more popular solutions: ASP, ColdFusion, JSP, Perl, and PHP. Hopefully one of the expert testimonials found in the pages that follow will resonate with you, and you'll walk away from this article having made a solid scripting-language decision.
Page 2 — ASP

Scott Mitchell is webmaster for 4GuysFromRolla.com, a site dedicated to ASP development. He's also a consultant and author of a book on ASP.
When deciding whether to go with PHP, ASP, ColdFusion, or something else, the most important matter to consider is who will be working on your website now and in the future. While using PHP may seem the coolest thing (being open source and running on the en vogue operating system of the day, Linux), it's not the best choice if the people working on your site are unfamiliar with Unix, Perl, and C. Even if you do have a Unix guru in-house, there is no guarantee she will be working for you down the line. Who will maintain your site when the Unix master leaves?
Active server pages can be written in VBScript, an easy-to-learn scripting language that uses a syntax similar to Visual Basic's. Since there's a good chance that a number of people at your company already know Visual Basic, you can be confident that an ASP-driven website can be easily maintained now and in the future. If you happen to hire people with other backgrounds, that's OK too: JavaScript, Perl, and even Python can be used to code ASP pages! Furthermore, with the extensive integration capabilities of Microsoft's .NET Framework, you can create powerful ASP pages with expanded libraries.
ASP's most distinguishing benefit is its ability to use COM objects. As with everything else in ASP, using COM objects is incredibly easy. One line of code is all it takes to create an instance of a COM object. From there, you can use the object however you see fit, calling its methods, setting its properties. This creates two awesome benefits: First, you can use the same robust COM objects that you use in Visual Basic or Visual C++ on your ASP pages; second, you can create your own COM objects for use on your ASP pages.
By making use of previously developed COM objects, developers can reduce the amount of code that they need to write. For example, when you install IIS (Microsoft's Internet information server) and ASP, a couple of useful COM objects are registered on your Web server, including the ad rotator. The ad rotator, as its name implies, randomly cycles through banner advertisements. An ASP developer, immediately after installing IIS, can create an ASP page containing two lines of code that will randomly display a series of banners. Try doing that with PHP.
The benefits of COM objects can't be fully appreciated until you've made use of Microsoft's ActiveX data objects (ADO), a combination of robust COM objects that are used for data access. With ADO, which can be used in Visual Basic or Visual C++ programs as well as ASP pages, you can connect to just about any data store, from an SQL 7.0 database to an Excel spreadsheet. And it doesn't stop there; ADO can use almost anything as a data store. Of course, the standard ODBC-compliant databases are all usable. Got a delimited text file? It's a data store. Got an XML file? It's a data store. Even your OS's file system is a data store!
When the need arises, you can create your own COM objects. In fact, Microsoft recommends that you build custom COM objects to handle business-logic issues. Finding developers who can create useful COM objects is not difficult, since COM objects can be created with Visual Basic, Visual C++, or Java.
Making impressive ASP pages is just easy. Few critics will dispute this. The most frequent criticisms focus on the stability and security of IIS, Microsoft's Web server. Personally, I've had no stability problems with IIS or ASP, and seeing that such high-volume websites as HotBot, Buy.com, and Dell use ASP, it's apparent that IIS and ASP scale nicely. But if you are dead-set against using IIS as your Web server, you can still use ASP! There are a number of third-party products, such as ChiliSoft and Halcyon Software's iASP, that let you run ASP pages on non-IIS Web servers.
When deciding on a development environment, ask yourself these questions: Who will be maintaining the website? How easy will it be for new people to make changes to the existing site? How easy is it to access a database or a spreadsheet or an XML file? Can custom COM objects be integrated into the Web pages? You'll find that the best solution to these issues is usually ASP.

Still not convinced? For more information, visit Webmonkey's ASP collection.
Page 3 — ColdFusion

Robert Capilli is a ColdFusion programmer with roundpeg, a Web application development firm.
Of all the Web development tools on the market, ColdFusion is my favorite. Its overall simplicity and tag-based syntax make it easy to learn. It has a powerful IDE that can help you get productive quickly, and it can scale to handle even the biggest commercial websites. And while there's nothing you can do in ColdFudion that you couldn't duplicate in ASP or PHP, ColdFusion shines because it lets you work faster and better.
The reason for this is simple: Unlike other tools, ColdFusion wasn't patched together out of existing technologies. It was designed from the ground up to be a Web application platform. Because the creators of ColdFusion weren't saddled with the wreckage of past paradigms, they were free to find the best way to solve the problems Web developers face. This allowed them to streamline aspects of ColdFusion that were clunky in other technologies.
For example, the following ASP script connects to a database and outputs the results to a browser:

Set OBJdbConnection =


 OBJdbConnection.Open "nba_membership"

 SQLQuery = "Select id, business FROM Directory"

Set RSCustomers = OBJdbConnection.Execute(SQLQuery)

Do Until rsCustomers.EOF

 Response.Write (rsCustomers("ID") & " " & rsCustomers("Business"))




The same code in ColdFusion looks like this:
<cfquery name="rsCustomers" datasource="nba_membership">

 select id, business from directory


<cfoutput query="rsCustomers">#id# #business#</cfoutput>
Both snippets do the same thing, but the ColdFusion code does it more elegantly. Its native language, CFML (ColdFusion Markup Language) uses fewer commands, and those commands make a lot more sense. It doesn't take a genius to figure out what <cfquery> and <cfoutput> do. The ASP equivalent is a little less intuitive.
This conceptual superiority is one of reasons programmers like ColdFusion so much. No one likes to screw around with intermediary objects. If I want to execute a query, let me do it. If I want to output some values, let me do it. With CF, there's not a lot of mystery about how to do something once you figure out what it is you want to do.
In the same spirit, ColdFusion Studio tries to automate the coding process as much as possible. Since it features automatic tag completion, expression builders, tag choosers, and wizards, the amount of stuff you actually have to key in is minimal. CF Studio gives you almost instant access to every command, method, property, constant, function, and variable available. This minimizes the amount of time you spend looking for information and maximizes the time you spend using it.
Built-in customization features give experienced developers even more control over their environment. Aside from the standard "customize" dialogs found in almost every IDE, CF Studio comes packed with VTML and WIZML. VTML provides a simple way for developers to customize almost every facet of CF Studio, and WIZML allows them to quickly and easily build integrated wizards. When VTML and WIZML are used together, any process that's not already streamlined can be fully efficient in a few minutes.
Once you've got your environment set up, you need a way to debug your code. CF Studio obliges with an excellent built-in debugger. It allows you to set breakpoints and watches and keeps track of the tag stack, variables, recordsets, and CF output generated during execution. With this information, you can step through an entire application and locate errors with ease.
Perhaps my favorite thing about ColdFusion is the way it makes use of custom tags. Any ColdFusion page you create can be called as a custom tag. If you have a file called list.cfm, another page can use it as the <cf_list> tag. If you have a page called messageboard.cfm, you can invoke it with the tag <cf_messageboard>. This encourages code reuse and facilitates the development of tag libraries.
Overall, ColdFusion is simple, powerful, and efficient. If I had to make up a slogan for it, it would be something like "High quality apps without all the crap." Mind you, I'm not a Macromedia fanatic, and I have no loyalty to ColdFusion. If a better tool came out tomorrow, I'd use it. But right now, that tool doesn't exist. So, if you're in the Web development game, do yourself a favor and give ColdFusion a shot.
Still not convinced? For more information, visit Webmonkey's ColdFusion collection.
Page 4 — JSP

Andrew Utter and Sharmila Pandith work with iXL, a Web consulting firm.
Being a late bloomer is not necessarily a bad thing — especially if you can benefit from the growing pains of others. Case in point: Java Server Pages (JSP). While the communities associated with other scripting languages were maturing and polishing up the finer points of their respective protocols, the people at Sun were looking at the foundations of client/server interactions and asking what could be done to improve them. Working with the Java language, they developed the Servlet API, a set of classes that bring powerful new functionality and performance capabilities to the Web-serving realm.
JSP utilizes servlets to create a dynamic scripting language where variable content, often retrieved from a database, can be imbedded within HTML. Its conceptually similar to ASP but comes with a major advantage: Where ASP uses VBScript or JScript, JSP unleashes the awesome power of the Java language. And as we'll see, because of this factor, JSP promises to outdo ASP and its other peers and reach heretofore unimagined heights of performance and extensibility.
Servlets have made great strides in the area of persistence. When a servlet is loaded into the server's memory, it generally remains there as a very compact Java object. When a server using servlets receives a request, there are no interpreters to spawn or variables to instantiate (beyond the first time). This means servlets are efficient: They stand vigilantly like the Marines, always prepared, ready to serve. Also, in addition to their efficiency, servlets are very tightly integrated with the server, which enables more sophisticated interactions with the server than is possible with CGI.
So how does this affect JSP? When a client machine requests a JSP page for the first time, the server automatically builds, compiles, and starts a background Java servlet that in turn generates an HTML page. That HTML page is sent to the client's browser for display. From then on, whenever the JSP page is accessed, the servlet is there as Java byte code in the Web server's memory, ready to query a database and serve up the HTML immediately. With ASP, the code needs to be reinterpreted for every client request, which slows down the process of page generation.
In addition, JSP brings all of the power of the Java language to bear on the client/server interaction. Portability, multithreading, extensive class libraries, object-oriented code, strong safety features, robust security measures, elegance, and extensibility are just a few of Java's advantages. For further evidence, look at how the ColdFusion people have added the JRun application server in their product to interact with JSP, servlets, and other Java technologies. They see the writing on the wall. It's a brave new Internet world out there, as we have all been told time and again. And it's a world that smells more and more like Java every day. And nothing integrates with Java like Java.
But maybe the most important point to consider when looking at JSP is the personal return on investment. When you put energy into learning something, you want the knowledge you've gained to carry you as far as it possibly can. Let's face it: We've all got plenty to do, and time for R&D is precious. But time invested on JSP is undeniably time well spent, because you are not just learning a server-side scripting language. Rather, you are learning Java, which you'll be able to leverage under a variety of circumstances to fulfill a variety of needs.
Not that you need to be a sophisticated Java programmer to use JSP. On the contrary: If you combine JSP with JavaBeans, you hardly need to be a programmer at all. Do you know a little JavaScript? That's probably enough to get you started.
All of the approaches have their strengths. But JSP, latecomer or not, is making tremendous inroads on the middle tier already. We predict that the wafting scent of server-side Java is going to prove increasingly difficult to resist.

Still not convinced? For more information, visit Webmonkey's Java collection.
Page 5 — Perl

Richard Dice is the director of software development at HBE (Hard Boiled Egg) Software.
Who am I? What do I want?
I'm a Web programming professional. I want the tools that let me do the best job for my clients and for myself. But what does this mean?
  • My clients want their work to be finished quickly.
  • They want stability.
  • They want things to be as inexpensive as possible.
  • They need the ability to change things quickly. (It's not as though every little requirement of the project is determined before the coding actually starts, you know.)
  • They want the ability to upgrade the system to currently undreamed of levels in the future.
  • I don't want to feel as though I'm doing all this work while wearing a technological straitjacket. I want to feel attached to my work and as though I'm being creative and inventive while I produce solutions. I don't want to feel that I'm fighting against a huge bulkhead of decisions that have been made for me by someone else.
So, here's my pick: the Perl programming language with the Apache (with mod_perl) Web server. It's the high-end Open Source approach.
There are some arguments out there that are already won. Perl-as-Web-programming-language is one of them.
I'm not saying that there isn't room for other Web programming languages. I respect PHP and understand why people might want to use it. ColdFusion is the best way to make the most out of a bad situation (Web programming under Windows 2000, that is), and ASP with VBScript is a good way to leverage your knowledge of Visual Basic. But for serious Web programming, Perl is the only way to go.
  • The language is powerful and full-featured, yet still very high-level and easy to program. Its learning curve is quite manageable too: Perl isn't just for the experts.
  • Perl is unparalleled for text processing — generation of HTTP headers, automatic writing of HTML — which is the essence of Web programming.
  • You can build programs, even whole systems, in Perl quickly. This means a lot to your average Web programmer, considering that your average Web customer wants his or her site the day before yesterday.
  • Since Perl is so often used for Web programming, other people have built systems that layer upon Perl. You can make use of their work to make your life even easier. More about this later....
  • Web programming isn't always just about the Web. Web systems tend to incorporate all sorts of other backend processes. Perl's CPAN collection gives you loads of modules that can handle any sort of circumstance that might crop up. You'll also find Perl's DBI module here, ready for all your Web-database integration needs.
  • What's more, Perl is open source — tested, tried, and true. It gives you freedom and security. You never have to worry that its vendor will stop supporting it. As long as Perl's the right choice for Web programming, it will move forward, and people will provide a support network for it. And as long as Perl moves forward and people provide a support network for it, it will continue to be the right choice for Web programming. This seems like a good feedback loop to me.
If Perl has won the Web language war, then Apache came to fight the Web server war ... and everyone else was a no-show. It's easy to see why things turned out this way. It's a Web server by and for webmasters. And you'd figure that webmasters know what they want to work with, right?
Apache is complete, correct, feature rich, highly configurable, and extensible. No matter what other people might tell you, this is the combination of attributes that you want in a Web server. Apache is open source software, so what I said about the benefits of OSS earlier for Perl apply here.
Although Apache is extensible, it's really better than that: It's already been extended for you. Specifically, it's been extended to work better with Perl. You can grab the mod_perl Apache module and integrate it with the core Apache Web server, and in about 20 minutes, you can boost the speed of your Perl Web programs by up to 2,000 percent. You can also take advantage of Apache's internal workings from within your Perl code.
Also, mod_perl is allied with other technologies used for building high-end websites: HTML::Embperl and HTML::Mason are two at the top of the list. The first employs an embedded-code philosophy to Web page creation, while the second is more template and component-oriented.
However you like to code your Web pages, Apache and mod_perl can help you out.
Still not convinced? For more information, visit Webmonkey's Perl/CGI collection.
Page 6 — PHP

Graeme Merrall works in New Zealand for KC Multimedia, an Internet-intranet design company.
One cannot pass comment on PHP without first passing comment on open source. The very philosophy of open source is itself one of the driving reasons behind the popularity of PHP. Many, many articles have been written and even more arguments have taken place over the position of open source in a modern, e-commerce-based Internet. Let's just say that the Internet, and e-commerce for that matter, would not be around today if it weren't for the open source model. Take, for example, programs like the NCSA and CERN Web servers, Apache, Bind, SSLeay, Perl, and yes, Linux. If you'd like to know more about the whole interconnected Web of big business, open source, and the Internet, I can thoroughly recommend In the Beginning Was the Command Line by Neal Stephenson.
On to more sanguine matters. Let's talk about why you should use PHP to create that killer website.
Perhaps the most compelling argument for PHP is its cost: Nothing. Zip. Zero. For a lot of people, that's a big deal. Their old PC can run Linux, Free BSD, or what have you; they install Apache, PHP, MySQL, and whatever editor they choose and get hacking. Total cost? Merely the time it takes to set it all up. For many, this appeals to the hacker mentality that the Internet was built on. Why pay for something when you can get something just as good or better for free? The same applies to using Perl.
The old hacker mentality also applies to PHP's coding style. PHP borrows its language style and syntax from a number of other sources, including C, Java, Perl, and others. For many people with previous programming experience, this means implementing their first Web-based application in PHP is a simple affair, as they already have an implicit understanding of how their program should go together.
PHP's open source model means extra additions to PHP are just a compile away. Sure ASP has COM objects and ColdFusion has custom tags, but you can't beat the raw speed of adding your own function to the PHP source code.
Some would argue that all these server-side scripting languages are merely for displaying information from a database on a screen, and they'd largely be right. But PHP isn't just a database-centric language. It does so much more: dynamic graphics generation, IMAP, SNMP, LDAP, XML — they're all there. Sure, Perl does all that, but a lot of people find Perl more difficult to learn and a little too top-heavy for most Web apps. And mod_perl can be a bit imposing. Speaking of databases, did I mention PHP can interface with Sybase, Oracle, Informix, Solid, Postgres, and even MSSQL?
PHP is a godsend for the smaller developer as well. PHP is so cross-platform, it's just silly. Again, for no cost, you can fully develop any application using PHP (and perhaps MySQL) on your Windows machine as though it was your production server. For many people, this solves a problem they face every day. Sure, some things don't work on the Win32 version, but you won't bump up against those until you're into advanced stuff, and by then you'll be thinking about Unix anyway. Additionally, PHP will run on just about any flavor of Unix you care to think of. You don't need to be tied down to one or two commercially based operating systems.
So what about the stuff PHP isn't good at? Well yes, PHP does have its drawbacks — everything has its strong and weak points. Commercial software is often chosen because it is commercial. A lot of companies are unwilling to entertain the idea that something free is worthwhile. They'd rather adopt a unified platform approach or go with a commercial product with commercial support. Fair enough. Their loss, I'd say!
PHP has been criticized for its lack of session handling. But this was overcome previously by the use of the PHPLIB library, and now session support has been built into PHP4. And ISAPI support, which had been lacking, is also now covered by PHP4 (plus PHP contains a generalized server API library to make it easily adaptable to other Web server APIs).
I believe there is something to be said for ASP's object-based approach. For instance, input is accomplished via the Request object. Query string data is accessed with a Request.QueryString command, form data is accessed with Request.Form, and cookie information is obtained with Request.Cookie. This allows you to create multiple instances of the same variable, each stored in a different location. This can lead to some confusion, but nevertheless, in the right hands, it can be an interesting and powerful feature. With PHP, each source of page information is essentially treated equally in that each becomes a normal variable within your script.
If you were to ask me why I'd use PHP, in ten words or less, I'd say, "Free, easy, useful, extendable, and just plain cool." 'Nuff said.
Still not convinced? For more information, visit Webmonkey's PHP collection.


바보들의 영문법 카페(클릭!!)

오늘의 메모....

시사평론-정론직필 다음 카페

바보들의 영문법 다음 카페

티스토리 내 블로그

내 블로그에 있는 모든 글들과 자료에 대한 펌과 링크는 무제한 허용됩니다.
(단, 내 블로그에 덧글쓰기가 차단된 자들에게는 펌, 트랙백, 핑백 등이 일체 허용되지 않음.)

그리고 내 블로그 최근글 목록을 제목별로 보시려면....
바로 아래에 있는 이전글 목록의 최근달을 클릭하시면 됩니다.
그러면 제목을 보고 편하게 글을 골라 보실 수 있습니다.

그리고 내 블로그내 글을 검색하시려면 아래 검색버튼을 이용하시면 됩니다.



free counters