Executing javascript on IIS server. Server-side JavaScript
JavaScript gives you the ability to create applications that run on the Internet. Client applications run in a browser, such as Netscape Navigator, and server applications run on a server, such as Netscape Enterprise Server. Using JavaScript, you can create dynamic HTML pages that process user input and manipulate data through the use of special objects, files, and relational databases data.
With LiveConnect functionality, you can enable Java and JavaScript code to communicate. From JavaScript you can instantiate Java objects and access their public methods and fields. From Java you can access JavaScript objects, methods and properties.
Netscape invented JavaScript, and JavaScript was first used in Netscape browsers.
Core, client and server JavaScript
The components of JavaScript are shown in this figure.
Figure 1.1 JavaScript language
The following sections are an introduction to JavaScript on the client and server.
JavaScript Core
Client-side and server-side JavaScript have the following elements in common:
- Keywords
- Operator syntax and grammar
- Requirements for expressions, variables and literals
- Object model (although client-side and server-side JavaScript have different sets of predefined objects)
- Predefined objects and functions such as Array, Date and Math
Client JavaScript
Web browsers such as Navigator (2.0 and above) later versions), can interpret client-side JavaScript statements embedded in an HTML page. If the browser (or client) requests such a page, the server sends the full contents of the document, including HTML and JavaScript statements, to the client over the network. The browser reads the page from top to bottom, rendering the resulting HTML and executing JavaScript statements as it finds them. This process, shown in the following figure, provides the end result to the user.
Figure 1.2 Client-side JavaScript
Client-side JavaScript statements embedded in an HTML page can respond to user events such as mouse clicks, form entries, and page navigation. For example, you can write JavaScript function to check the correctness of the information entered by the user into the form - phone number or zip code. Without transmission over the network, JavaScript embedded in an HTML page can validate the entered data and display a dialog box if the user entered incorrect data.
Different versions of JavaScript work with specific versions of Navigator. For example, JavaScript 1.2 is designed for Navigator 4.0. Some features of JavaScript 1.2 are not available in JavaScript 1.1 and therefore are not available in Navigator 3.0. For versions of JavaScript and Navigator, see JavaScript Versions.
Server-side JavaScript
Server-side JavaScript is also embedded in HTML pages. Server operators can connect to relational databases different manufacturers, provide information to sharing multiple consumers, provide access to the server's file system, or interact with other applications via LiveConnect and Java. HTML pages with server-side JavaScript can also contain client-side JavaScript.
Unlike pages written in pure client-side JavaScript, HTML pages with server-side JavaScript are compiled into executable bytecode. These executable files are run by a web server that has a JavaScript execution engine. Therefore, creating JavaScript applications is a two-step process.
In the first step, shown in , you create HTML pages (which can contain client-side and server-side JavaScript statements) and JavaScript files. You then compile all these files into a single executable file.
Figure 1.3 Server-side JavaScript in development
In the second stage, shown in , the application page is requested by the client browser. The runtime engine uses the application executable to search original page and dynamically generates the HTML page returned to the client. The machine runs server-side JavaScript statements found on the page. This may result in new HTML or JavaScript statements being added to the HTML page. The execution engine sends the resulting page over the Navigator network to the client, which runs client-side JavaScript and displays the results.
Figure 1.4 Server-side JavaScript at runtime
Unlike standard programs Common Gateway Interface (CGI) integrates all native JavaScript directly into HTML pages, speeding up development and making maintenance easier. The server-side JavaScript Session Management Service contains objects that you can use to serve data that exists between client requests, multiple clients, and multiple applications. The server-side JavaScript LiveWire Database Service provides database access objects as an interface to Structured Query Language (SQL) database servers.
JavaScript and Java
JavaScript and Java are similar, but have fundamental differences. JavaScript is similar to Java, but lacks Java's static typing and strong type checking. JavaScript mainly supports Java expression syntax and basic flow control constructs.
Unlike Java's class declaration-based compile-time system, JavaScript supports a run-time system based on a small number of data types: numeric, Boolean, and string values. JavaScript has a prototype-based object model rather than the more common class-based model. The prototype model provides the possibility of dynamic inheritance; that is, what is inherited can vary between objects. JavaScript also supports functions without special declaration requirements. Functions can be properties of objects, executed as weakly typed methods.
JavaScript is much more free-form compared to Java. You don't have to declare all variables, classes and methods. You don't have to consider which methods are public, private or protected and you don't have to implement interfaces. The return values of variables, parameters, and functions are not explicitly typed.
Java is a class-based programming language designed for fast execution and strong type checking. Strict type checking means, for example, that you cannot cast a Java integer to an object reference or access private memory by violating Java bytecodes. The Java class model means that programs consist solely of classes and their methods. Java class inheritance and strong typing typically require a tightly built hierarchy of objects. These requirements make programming in Java more complex than authoring in JavaScript.
JavaScript is descended in spirit from small, dynamically typed languages such as HyperTalk and dBASE. These programming languages are programming utilities for a wide audience because they have simplified syntax, specialized built-in functionality, and minimal requirements for creating objects.
Table 1.1 JavaScript vs. Java
| JavaScript | Java |
|---|---|
Interpreted (not compiled) by the client. | Compiled bytecodes are downloaded from the server and executed on the client. |
Object-oriented. There are no differences in object types. Inheritance occurs through the prototype mechanism, and properties and methods can be dynamically added to any object. | Based on classes. Objects are divided into classes and instances with inheritance throughout the class hierarchy chain. Classes and instances cannot have properties or methods that are added dynamically. |
Code integrated with and embedded in HTML. | Applets are different from HTML (when accessed from HTML pages). |
The data type of the variable is not declared (dynamic typing). | The data type of a variable must be declared (static typing). |
Cannot automatically record to hard disk. | Cannot automatically record to hard disk. |
Debugging in JavaScript
JavaScript allows you to create complex computer programs. As in other languages, you can make mistakes when writing scripts. The Netscape JavaScript Debugger allows you to debug your scripts. For information on using the Debugger, see the following documents:
- Netscape JavaScript Debugger 1.1- introduction to Debugger.
- Getting Started with Netscape JavaScript Debugger explains how to use the Debugger.
You can download Debugger from the given URL. The downloaded file is SmartUpdate .jar. To install Debugger, upload this .jar file to Navigator: use the procedure described in the above URL, or enter the URL to the .jar file in the location field (address bar).
Visual JavaScript
Netscape Visual JavaScript is a component-based visual development utility for the Netscape Open Network Environment (ONE) platform. It is intended primarily for use by developers who want to create platform-independent, standards-based web applications from ready-to-use components with minimal programming effort. These applications are based on HTML, JavaScript and Java.
JavaScript and the ECMA Specification
Netscape Corporation invented JavaScript, and JavaScript was first used in Netscape browsers. At the same time, Netscape is working together with ECMA (European Computer Manufacturers Association) to create a standardized international programming language based on the JavaScript core. ECMA is the international standards association for information and communications systems. This standardized version of JavaScript, called ECMAScript, works exactly the same in all applications that support this standard. Companies can use this open standard language to develop their JavaScript implementations. The first version of the ECMA standard is documented in the ECMA-262 specification.
The ECMA-262 standard is also approved by ISO (International Organization for Standards) as ISO-16262. You can find a PDF version of ECMA-262 on Netscape DevEdge Online. You can also find this specification on the ECMA website. The ECMA specification does not describe the Document Object Model (DOM), which is standardized by the World Wide Web Consortium (W3C). The DOM defines the way HTML document objects are exposed to your script.
Correlation between JavaScript and ECMA versions
Netscape works closely with ECMA to create the ECMA specification. The table shows the relationship between JavaScript versions and ECMA.
Move aside, notorious PHP! Down with Java! Old man Perl, it’s time for you to retire a long time ago. And how did you get it, poppy Ruby and Python! All these long-familiar technologies are no longer in use. But today we will look at an extremely progressive approach when... JavaScript is used to write server code.
I have an idea for a startup. Now the question is: what to write it on? Of course, there is everyone's favorite PHP - what could be easier for a website! But tell me honestly, it somehow doesn’t appeal, does it? After all, to do something worthwhile, bare PHP is not enough. You will immediately have to add AJAX so that the data is loaded unnoticed without updating the entire page, and this will not solve all the problems. You will start to think that PHP is not so good at the very moment when a lot of people rush to you at once. And all because PHP (like the vast majority of other languages in which websites are built), even in our damn twenty-first century, works according to the classic “request-response” scheme. A page request causes the web server to pick up the specified script, execute it (linearly, line by line, all your code), and return the result to the client's browser. After this, the script “dies”, and the next request will start this whole infernal machine again. What if there are a thousand such requests at the same time? The good old approach is called CGI (interface between the web server and the interpreter of the language in which the page is written). Clever add-ons like FastCGI extend the protocol, allowing you to avoid unloading the script after the first request. Thus, when the second user requests the same page, everything will be ready for him; all that remains is to execute the script with the new parameters. But all these tricks are still not the same.
What is good and what is bad
Many developers have always considered JavaScript to be just an add-on to the browser, a kind of non-language that is only suitable for managing forms and manipulating the DOM tree of a web page. Some people still think that the “java” in the name means something! 🙂 Indeed, the language is very simple. However, real programmers have long learned to create miracles with it, providing us with amazingly convenient online services that we use every day. Many of these professionals went further and, having soberly looked at the language itself and its capabilities, especially in terms of working with events, decided: what if we write a server in JavaScript? You get the opportunity to write all parts of the site in the same language: both the server part and the client page itself. Also, JS is great, just perfect for a variety of web stuff. It is very simple and at the same time flexible, which allows you to write code in different paradigms: from regular procedural to OOP mixed with a functional style. And the main thing is total asynchrony. This means that your code will not be executed sequentially, as is the case with PHP/Perl scripts, but precisely at the moment when all the data is ready for it. After all, for the web you don’t need a big one computing power- most of the time the server is waiting for events such as receiving form data, fetching from a database, or, even worse, a response to a request to another server. A regular PHP script is idle at such times, which means the entire thread is idle, preventing the server from using it for other users. In such a situation, even Nginx cannot help. With JavaScript, you simply specify which function to execute when a certain event occurs, and that's it. During this time, other code can be executed quietly. This function is called a callback, or event handler. Although writing really complex code this style is a little inconvenient, especially if your function depends on several events at once, but for this they have already come up with their own frameworks, often much more powerful and elegant than all these PHP/Ruby/Python.
What is it all about, this asynchrony?
As an example of the limitations of sequential code execution, let's look at two typical examples of code in PHP and JavaScript that do the same thing. Let's start with our favorite PHP:
$result = $db->fetchOne("SELECT user_name FROM user_accounts WHERE id = 1");
echo "My name is: " . $result. ";";
In the first line, we send a simple SQL query to the database to select a username whose id = 1. Please note: at this point the script stops, and the next line will not be executed until the request is processed by the database, and the result will not be returned to the $result variable. Yes, in our example these are thousandths of a second, but in reality the queries are much more complex, and the databases are often gigabytes in size, and there can be a couple of thousand such queries at the same time. Now let's try to write code in JS using the asynchronous style:
db.query("SELECT user_name FROM user_accounts WHERE id = 1", function(err, res)
{
if (!err) sys.log("My name: " + res);
});
sys.log("Continue execution");
Here again, a query is created to the database, but in addition to the SQL expression itself, a handler function (callback) is also passed in the query. This function will be called exactly when the response from the database arrives, and until this moment the execution of the script will in no case be stopped. For example in next line we simply print a line to the console to show that script execution continues immediately after the request is generated, without waiting for it to complete. Actually, any version of server-side JavaScript is based on the concept of events and callbacks, that is, event handlers. You can describe own events. Then the progress of the application will depend on events that arise as a result of user activity on the page (“form completed” or “new message”, etc.) or generated within the server itself (as, for example, in the case of accessing a database ). The actions that must be performed in the event of events are described within the event handler functions.
Engine, that's the question.
In short, using JavaScript not only on the client side, but also on the server side is good and even enjoyable. Another question is how can this be accomplished? Today there are four main engines that are used on servers.
Rhino- engine from Mozilla company, written in Java and supporting the latest 1.7 version of the JS standard, which also complements the language with its own extensions and objects. The main advantage of the engine is that it runs on top of the standard JVM, which means it can be used in any environment where Java runs. In other words, you can use modern web servers like jetty, but still write in your favorite JS. By the way, Rhino is used on cloud hosting from Google! But with performance it’s more difficult. It depends, on the one hand, on the engine and the technologies used there, such as JIT compilation, and on the operation of the Java machine itself. By the way, many testers who say that Rhino is very slow forget that the engine has two modes of operation: interpretation, when the script is converted into Java bytecode each time (similar to PHP), and compilation, when such conversion occurs only once, and then it is performed many times. The first mode is beneficial when you are debugging code that changes every minute, the second is more suitable for the working version of the project running under load.
SpiderMonkey- another engine from Mozilla, this time in C. By the way, this is the world’s first JS engine, written back in Netscape - today it is open and used in such popular products as Firefox, Adobe Acrobat and even in one of the online server emulators - Ultima Online games. Next, the developers heavily modified it, adding JS compilation directly into assembly code, and renamed it TraceMonkey - this is the engine used in the 3.6 branch of Firefox. SpiderMonkey is mainly used in software that is written in C/C++ and needs script language. Well-known products: Comet server APE, noSQL database CouchDB, Jaxer server platform and module for Apache mod_js.
Futhark is an engine from Opera, which, in addition to the browser, is used in their innovative Unite service (such as a built-in server in each browser), as well as on their servers serving mobile browser Opera Mini. It’s a pity that the engine is closed and is not yet used anywhere outside of Opera itself.
V8- an engine from Google that is used in Chrome and is the basis of the future Chrome OS. Today it is the coolest, fastest and powerful engine, in which the JS code is directly converted into the assembler language of the target processor, which allows it to outperform all other engines in terms of speed. In addition, Googlers use many tricks for optimization, storing compiled code in memory, optimizing it on the fly (for example, deleting code blocks that the compiler decides cannot be used at all, etc.). The most popular and fast-growing server platform is built on the basis of this engine - Node.JS.
Node.JS
Probably after the release Chrome developers We realized that such a fast engine can be successfully used on a server. The first experience was the V8cgi project, which simply made it possible to write server-side scripts that work with any web server using the standard CGI protocol. Further experiments led to the birth of the project Node.JS- a completely independent platform, which includes, in addition to the engine, a built-in server (HTTP and TCP/UDP/Unix-socket) and a basic set of libraries, and also provides completely asynchronous work with files and network devices.
The project is developing so quickly and actively that it is already ready for industrial use. This, in particular, is proven by the experience of the guys from Plurk (the Asian equivalent of Twitter), who completely transferred their comet server, originally written in Java and the solid JBoss Netty, to Node.JS and, according to reviews, they reduced memory consumption by literally gigabytes. And their scale is still the same - more than a hundred thousand simultaneous connections.
Launching an HTTP server capable of processing thousands of connections asynchronously takes just a few lines of code:
var sys = require("sys"), http = require("http");
http.createServer(function (req, res)
{
res.writeHead(200, ("Content-Type": "text/plain"));
res.end("Hello World");
)).listen(80, "127.0.0.1");
sys.puts("Server running at http://127.0.0.1:80/");
To start the server, copy the code into the example.js file and specify it when starting the node daemon:
% node example.js
Server running at http://127.0.0.1:80/
This little test is very easy to do. You can take the Apache Bench program - a very simple tool for carrying out load testing, and run it: running “ab -n 1000 -c 100 ‘http://127.0.0.1:80/’”. Thus, the benchmark will “bombard” the server with thousands of requests, using 100 simultaneous connections. On my laptop, the server withstood more than 3000 requests per second. That's a lot!
The server itself is written in C++ and quite a bit in assembly language, but most of the libraries in the distribution are developed in JavaScript. Part basic set The server includes only the basic functions, the rest is left on the shoulders of the developers, who have already written hundreds of different libraries and frameworks. However, the youth of the project makes itself felt: many modules familiar to other solutions do not yet exist, and many libraries Current version- 0.0.1, which does not give confidence in their stability. Some trivial tasks may not have a ready-to-download solution at all, but it also happens the other way around - the number of implementations, often radically different in architecture, amounts to dozens (access to MySQL database, For example). Although most libraries are written in pure JavaScript, there are also those that require module compilation to the server, which promises much more higher speed- they simply extend the standard server API.
Ready-made developments for server-side JavaScript
Of course you can write code with clean slate, which is what many good programmers do. However, many of these good programmers have created convenient frameworks and outlines for themselves, which they now constantly use and offer to everyone in the form of frameworks and specifications. If you've seriously decided to use server-side JS, then this is a great way to make your life easier.
Narwhal is a powerful solution that runs on top of many JS engines. This way, programmers don't have to worry about the differences between different servers - they can just write code.
CommonJS is an attempt to standardize the platform and provide a common API for all engines, offering a low-level API, as well as an API for connecting various ready-made modules.
JSGI (JavaScript gate interface) - a special protocol for interaction between the web daemon and server scripts in JavaScript has been developed. Alas, the specification is currently only fully supported by the Rhino project in the jetty server environment.
Features of Node.JS
The main feature of Node, in addition to complete asynchrony, is its single-threaded model. In other words, all operations are performed in the same OS thread, even if your server has a thousand concurrent users. True, it is possible to create child processes and low-level control of script execution (loading, compilation, working with assembly code, execution). To implement multithreading and use all cores modern processors It's recommended to simply download multiple copies of the application, but you can take WebWorker from the HTML5 standard and distribute the application's work across multiple child processes. Don't think that just because there is no multithreading, it's a slowdown and sucks. Remember what a web application does useful work very quickly, and most of the time it simply waits for something (data from the database, from memcached or the newfangled NoSQL database), or simply keeps it in memory open connections for Comet, so tens of thousands can be processed in one thread without resorting to clustering.
The second feature of the Node architecture is event-based. Almost every operation has callbacks, generates an event, and the user has access to the EventEmiter object, through which you can literally generate your events in one line (this is not difficult, because an event is just a line with a name, as well as a list of parameters that are passed to the handler).
Node itself is built around an EventLoop - a global event loop that checks at every tick whether the data is ready for any of the user-defined callbacks. If the data is available, code execution begins. If there is no more code left, we wait for the next call. The loop is executed outside of JS, but in the engine itself, written in C, as a result of which this happens very, very quickly (on the order of hundreds of thousands of times per second). Something like an endless loop. In addition to this, the server has a very efficient garbage collector (GC) built into it, so even thousands of connections do not cause memory overflow and crash the server. Node.JS has a built-in native system for working with events.
The simplest Steaming server
Let's try to write a simple one, but at the same time useful example, which will give the user in real time useful information without reloading the page. Here's an idea for our application - take new data that is added to a text log and display it in real time on a web page:
var sys = require("sys"), net = require("net"), spawn = require("child_process").spawn, http = require("http");
sys.puts("nMy process PID: " + process.pid + "n");
var tail = spawn("tail", ["-f", "/var/log/nginx/access.log"]);
// specify the names of the logfile
sys.puts("Start tailing");
tail.stdout.addListener("data", function (data)
( sys.puts(data);
//duplicate it to our console
});
http.createServer(function(req,res)
{
res.sendHeader(200,("Content-Type": "text/plain"));
tail.stdout.addListener("data", function (data) ( res.write(data); ));
)).listen(80);
Using the spawn() function, we create a child process of the tail utility, which, in fact, reads new data that appears in the logfile. The process runs only once during server startup. Actually, our task is to catch moments when the tail command will output new data from the log file and broadcast the output to a web page for each connected client. To do this, we will monitor the occurrence of the data event (the appearance of new data) for the variable to which the tail utility process is running, and display them on the page using the write() command. This way the connection will remain open for every HTTP request. That's all. Monitoring process activity is not so easy for a regular web application, but costs nothing for a non-blocking architecture Node.JS and event-based execution logic. All we have to do is run the script: “node tail.js error.log” and open http://localhost:80 in the browser. The page will display all messages that appear in the error.log file.
That's the end of the fairy tale
Now, when choosing something to write another web 2.0 application on, where not only beautiful client code, but also something needs to be done on the server, you are overcome by one sad thought that everyone has already invented and written before you. The same languages as ten years ago, the same libraries, protocols and servers. PHP has been around for so many years now, Perl is generally gray, Python is on everyone’s lips, and Ruby has become boring. Writing for the web has become a chore - look at how your friends are sitting and wondering what to do with the 25 MB monster Zend-framework. Do you want something new, to be at the forefront of progress, to create something that everyone will write on later, but now only enthusiastic hackers and Zen programmers looking for themselves know? Look at the JavaScript in the server, it's just made for this. Very simple, powerful, not yet bogged down in a ton of libraries and frameworks. Problems that cannot be solved with PNR at all, based on Node.JS can be solved in literally ten lines. And perhaps this kind of programming will finally bring the lost feeling of pleasure from development!
WWW
- Materials on NodeJS: groups.google.com/group/nodejs
- Russian-language website and forum: forum.nodejs.ru
- Information about server side JS: en.wikipedia.org/wiki/Server-side_JavaScript
- A good beginner's guide to Node.JS: www.slideshare.net/the_undefined/nodejs-a-quick-tour
- Presentation: introduction to Node.JS: nodejs.org/jsconf.pdf
INFO
Most, if not all, Node.JS libraries and projects are concentrated on Github, so if a module you need isn't there, look for it there.
Node.js: Server-side JavaScript
Duration 27:19:05
The course is designed for web developers with experience developing in JavaScript. During the course, you will develop the server part for a corporate application - an internal system for interaction between employees. Fictional corporate website. News, chat, admin panel and user settings - you will need to implement all this during training.
After completing the course, you will learn
Develop in JavaScript in the Node.js environment.
JavaScript is now used and how server language development. The Node.js environment allows any developer familiar with JavaScript to begin developing the server side for applications of any complexity. Starting with the basics, we'll cover the most important areas of Node.js throughout the course.
Use WebSocket technology and the socket.io library.
Real-time applications are now practically standard. There is no need for page reloads, and it doesn’t matter whether you need to write a simple chat or a highly loaded service. Sockets will help set up data exchange between client and server at incredible speed.
Expand finished project on hosting.
Classic hosting is not suitable for applications developed in the Node.js environment. We will learn how to deploy your application directly from the git repository with maximum comfort on the most popular suitable platforms.
Test your code.
Code testing is another very important point, which cannot be ignored, especially when writing the server part of the application. Writing tests for existing code will increase its reliability, and test-driven development virtually eliminates the possibility of critical errors in your application in the future.
Apply server-side rendering practices.
Far from being a fad, server-side rendering is often a vital part of your application. In some cases, client rendering makes SEO promotion simply impossible, and if you want to achieve maximum application speed with huge quantities visits, then server rendering is definitely your choice.
Use the Express.js and Koa.js frameworks in development.
In the Node.js environment, in addition to modules and plug-in libraries, there are two great frameworks that greatly facilitate the development process. Moreover, some of the included libraries are written specifically for frameworks. We will look at the two most popular and well-known frameworks for development in the Node.js environment.
Carry out authentication and authorization, correctly store personal data.
There is practically no place for anonymity on the modern web, and user identification is an extremely important point. The personal data received must be stored securely and not used unnecessarily. We'll look at best practices and additional libraries that make this part of your applications easier and more reliable.
Work with relational and non-relational databases using Node.js.
When developing the server part of the application, special attention should be paid to working with data. Selecting a database for a project is an extremely important process, so we will look at the most commonly used database types. For the example of non-relational databases, MongoDB will be used, for the example of relational databases, PostgreSQL will be used.
On the server (IIS) for the following reasons:
Transfer of skills - we would like to use JavaScript and jQuery on the server and not use for example VB Script./classic asp. .Net framework/Java etc. are excluded because of this.
Improved search/availability options. We'd like to be able to use jQuery as our templating system, but it's not safe for search engines and users with disabled - if we cannot selectively run this code on the server.
In IIS and Windows Server there is a significant investment so change is not an option.
I know you can run jScript in IIS using the Windows Script Host, but I'm not sure about the scalability and process involved with this. I'm also not sure if this will have access to the DOM.
Here's a diagram that hopefully explains the situation. I was wondering if anyone has done anything like this?
EDIT: I'm not looking for a critique of web architecture, I just want to know if there are any options for manipulating the DOM of a page before it is sent to the client using javascript. Jaxer is one such product (without IIS). Thank you.
57 answers
Idea reuse Client-side JS on a server might be tempting, but I'm not sure jQuery itself would be ready to run in a server-side environment.
You will need to define a global context for jQuery in some way, initializing the window, document, username, location, etc. I'm not sure if this is doable.
Also, as Cheeso noted, Active Server Pages is a very outdated technology, having been replaced by Microsoft's ASP.Net at the beginning of the century. I used to run a deprecation system using ASP 3.0 for over a year and it was a pain. The most wonderful pastime is debugging: you are unlikely to find anything for this purpose today and will have to weaken beautiful errors like in the IIS log:
error "800a9c68"
User defined or object error
However, I can confirm that I was able to reuse client and server JScript. But this was code I wrote that I knew would be used on the server.
JScript runs in IIS using ASP. Active server pages.
It was first available in 1996.
Eventually ASP.NET was introduced as a successor. But ASP is still supported.
However, there is no DOM for the page.
You may have to rethink your architecture a bit.
I think the only viable solutions you're likely to find anywhere near production-ready involve putting IIS before Java. There are two browser environments that I know of that are coded for Java:
If you want something pure-IIS/MS, I think your observation of a WindowsScript host and/or something like half-abandoned JScript.NET is probably about as close as you get, as well as a port (which you will probably have to start) with something like Env-js or HTMLUnit.
Also, I don't know if you've seen the list of server-side solutions on Wikipedia:
Finally... you could probably write a usable jQuery-like library in any language that already has some kind of DOM library and first-class functions (or, failing that, eval). See for example pQuery for Perl (http://metacpan.org/pod/pQuery). This will give you the benefits of jQuery style for document manipulation. The transfer of skills is great and JavaScript has a wonderful confluence of very nice features, but on the other hand, developers who care about learning multiple languages are also great, and it's not a single nice language.
What exactly do you mean by
Figure 2.1 Architecture of a client-server application environment in JavaScript
The three layers are:
- WWW clients (such as Netscape Navigator clients): This layer provides the application with a cross-platform end-user interface. This layer may also contain some application logic, such as data validation rules implemented in client-side JavaScript. Clients can be inside or outside the proxy server corporate network.
- Netscape WWW server/DB client: This layer consists of a Netscape server with JavaScript enabled. It contains application logic, handles security, and controls access to the application for multiple users using server-side JavaScript. This layer allows clients both within and outside the scope of the proxy to access the application. The WWW server also works as a client with any installed server DB.
- Database servers: This layer consists of SQL database servers, usually running on high-performance workstations. It contains everything database data, metadata and referential integrity rules necessary for the application to work. This layer is usually within the reach of a corporate network proxy server and can provide a security layer in addition to that of the WWW server. Netscape Enterprise Server supports the use of database servers: ODBC, DB2, Informix, Oracle and Sybase. Netscape FastTrack Server only supports ODBC. For more information about the LiveWire Database Service, see Part 3, "LiveWire Database Service."
The JavaScript client environment runs as part of the WWW clients, and the JavaScript server environment runs as part of the Netscape web server with access to one or more database servers. shows in more detail how the JavaScript server framework and the applications built for it are built into the Netscape web server.
System requirements
To develop JavaScript applications, taking advantage of both client- and server-side JavaScript, you need the right environment for development and publishing. In general, it is recommended to develop applications on a system separate from the publishing server because development consumes a lot of resources (connection ports, bandwidth, CPU time, and memory). Development may also disrupt end-user applications that have already been published.
Wednesday JavaScript development comprises:
- Utilities for authorization and compilation of JavaScript applications. These utilities are usually located on the developer's machine.
- Development machines with a web server to run JavaScript applications under development.
- Publishing machines with web server for publishing developed applications. End users access applications located on this server.
Required utilities:
- A browser that can run JavaScript, such as Netscape Navigator, included with Netscape Communicator.
- A JavaScript application compiler, such as the Netscape web server compiler.
- An editor such as Emacs or Notepad.
Publishing and publishing machines require the following software:
- Web servers;
- JavaScript execution engines, such as the Netscape web server engine.
- The ability to configure your server to run JavaScript applications, as is done in the JavaScript Application Manager that comes with Netscape web servers.
Additionally, if your application uses the JavaScript LiveWire Database Service, you will need:
- The program is a relational database server on your database server machine. See your database server documentation. In some cases, you will need to install a web server and a database server on the same machine. For server-side JavaScript specific requirements, see Chapter 10, "Configuring the Database."
- Database client and network software on your web server machine. If you are using the same machine as both a database server and a web server, typical database client software is usually already installed when you install the database server. Otherwise, you need to make sure that the database client is installed on the same machine as the web server so that you can access the database as a client. About client requirements software See additional documentation from the database provider.
Configuration Information
This section covers configuration information for using server-side JavaScript. For more information on setting up a database to work with the LiveWire Database Service, see Chapter 10, “Database Configuration.”
Connecting Server JavaScript
To run JavaScript applications on your server, you must enable the JavaScript execution engine in your Server Manager by clicking Programs and then selecting Server JavaScript. After the prompt "Activate the JavaScript application environment" appears select Yes and click OK. You will also be asked about restricting access to the Application Manager. For more information see
NOTE: If you do not enable the JavaScript execution engine, JavaScript applications will not be able to run on this server.
To use both servlets and LiveWire, you need to enable server-side JavaScript before connecting Java. Both can be enabled via the Administration Server's program menu. If you modify the classpath in obj.conf, your changes will be lost if you enable/disable server-side JavaScript or Java from the Administration Server's program menu. An alternative to editing the classpath directive in obj.conf is to set the CLASSPATH environment variable on Unix or set the CLASSPATH variable in the System settings on Windows NT. If you need to edit obj.conf directly, save the original file just in case. In Enterprise Server 4.0, you must add CLASSPATH info to the JVM configuration files (jvm12.conf for Solaris and NT) through the Enterprise Administration Server interface.
Once you activate the JavaScript application environment, you are required to stop and restart your web server so that the associated environment variables started to act. If you don't do this, JavaScript applications that use the LiveWire Database Service will not work.
Application Manager protection
Application Manager provides control over JavaScript applications. Due to its special capabilities, you must protect it from unauthorized access. If you do not restrict access to the Application Manager, anyone can add, remove, change, start and stop applications on your server. This, of course, can lead to undesirable consequences.
You (the JavaScript application developer) must have access rights to use the Application Manager on the developer server, since you use it to work with the application during development. Your web server administrator, however, may not grant you such rights on the developer server .
If you enable the JavaScript execution engine in the Server Manager, the prompt will ask you whether to restrict access to the Application Manager. Select Yes and click OK. (Yes is the default.) Anyone attempting to access the Application Manager will then be required to enter the Server Manager username and password to be able to use the Application Manager and the dbadmin sample application. For additional information, see the administrator's guide for your web server.
If your server does not use Secure Sockets Layer (SSL), the Application Manager username and password are sent unencrypted over the network. By intercepting this data, you can gain access to the Application Manager. If you use the same password for your admin server, the hacker will gain control of that server as well. Therefore, it is recommended not to use Application Manager outside of a proxy unless you are using SSL. For information on how to connect SSL to the server, see the administrator's guide for your web server.