Web Engineering - The application of systematic, disciplined and quantifiable approaches to the cost-effective development and evolution of high-quality solutions in the World Wide Web.
The World Wide Web (Web) has become the dominant platform for ubiquitously accessible information and applications of any kind. The Web has gone far beyond presenting information of research groups as in its early beginning. Although the applications become increasingly complex, the development process still remains ad-hoc. A large gap between design models and the implementation model of the Web has been recognized to be one of the main reasons for the low acceptance of disciplined development in the Web. It becomes clear that the construction and evolution of applications for the World Wide Web requires support such as is available for traditional applications through process models, architectures, methods and principles of software engineering.
Client Side Technology
The Client Side Technology is a base topic for topics describing a Technology which is used on the Client side of a scenario based on the Client/Server-Model.
o XML
o HTML
o Active X controls
o applet
Server –side Technology
Server-side scripting is a web server technology in which a user's request is verified by running a script directly on the web server to generate dynamic web pages. It is usually used to provide interactive web sites that interface to databases or other data stores. This is different from client-side scripting where scripts are run by the viewing web browser, usually in JavaScript. The primary advantage to server-side scripting is the ability to highly customize the response based on the user's requirements, access rights, or queries into data stores.
From a security point of view, server-side scripts are never visible to the browser as these scripts are executed on the server and emit HTML corresponding to user's input to the page.
When the server serves data in a commonly used manner, for example according to the HTTP or FTP protocols, users may have their choice of a number of client programs (most modern web browsers can request and receive data using both of those protocols). In the case of more specialized applications, programmers may write their own server, client, and communications protocol, that can only be used with one another.
(Server Side Includes) [1]: These are extended comment tags inserted into a static HTML page to include other pages (templates), variables, and also execute external programs and include them in the input. Any static HTML file defined with a special extension (commonly “.shtml”) forces a properly configured Web server to parse the file before sending and replace the special tags with the appropriate content. This is perhaps the simplest model of server-side scripting but surprisingly, it is the essential mechanism of server-side scripting.
1. CGI (Common Gateway Interface) [2]: This is a mechanism that instructs a properly configured Web server to execute a specific file and send the output of the execution instead of sending it "as-is" to the client. Any program (shell scripts, DOS batch files, C programs, Perl) can be executed through this mechanism. Information about the request, the query string and any form parameters are sent as environment variables to the executed program. Any output by the executed program is sent directly back to the browser. It should be noted that the program is responsible for generating all headers. The most commonly used language for CGI was Perl, due to its powerful text-handling capabilities.
Perl [3]: This is an interpreted language characterised by its intuitive text handling, loose type-checking, associative arrays, handy loop constructs and simple file and environment handling. It was the most popular server-side scripting language for many years and it supports a modular expansion system [4]. A Perl script can be executed through the Perl Interpreter from the CGI interface (see above) or through a Web server extension that embeds the Perl Interpreter in the Web Server processes (in-process). For example, see CGI above. Its main drawback is that it pre-dates the Web and it is difficult to lay out HTML in the code.
2. PHP (Hypertext Preprocessor) [5]: I like to describe this as a cross between Perl, C++ and SSI. This language was developed specifically for Web server-side scripting and its utility has made it one of the most popular server-side scripting languages. As opposed to Perl, it is embedded into a fully laid out HTML page and gives complete control over HTTP request, response, cookie and session. It contains more robust type-checking (if required) and can be programmed in an object-oriented way. It is most commonly executed in-process and its biggest drawback is the lack of memory persistence of business objects. Pages identified by certain extensions (commonly .phtml, .php, .php3) are parsed by the Web server and passed on to the PHP plugins that passes the content back to the Web server. It follows the same directory structure as HTML static pages and images and is thus very easy to program and maintain. It has an extensive library and API system and some third-party vendors (Zend etc.) offer accelerators for PHP that show considerable performance improvement for complex application.
ASP (Active Server Pages) [6]: This is the Microsoft page-centric solution. It only runs on the IIS (Internet Information Server) although third party implementations on other platforms are available, making it less proprietary than Cold Fusion below. Like other page-centric languages, it embeds dynamic constructs into HTML pages:>
3. Cold Fusion [7]: This is a Macromedia page-centric solution.These special tags (in red below) make it very powerful and combined with Macromedia Web Authoring tools, make it the choice of many corporations. However, it is proprietary:
4. JSP/Servlets [8]: This is standards-based, popular, hybrid and out-of-process -- based on Java and J2EE standards[9] . Although JSPs are page-centric at author-time, they are not parsed by a web server-plugin. They are compiled into servlets and deployed in a separate Web Container. The Web server communicates with the web container using sockets. Most web containers implement a simple web server built into them which are usually not as robust and scalable as the leading Web servers but are good for testing and debugging.
Servlets : Servlets are script-centric and are regular Java programs. The compilation of JSPs into servlets gives us the best of both worlds (author-time page-centric and compiled out-of-process) and both of these have access to the full suite of Java libraries and APIs. The web container also defines sophisticated authorisation, authentication and URL mapping techniques that make this an enterprise-level Web development platform. Due to its being out of process, session objects and business objects can be cached and re-used by multiple HTTP requests.