The sections in this chapter are:
A key feature differentiating web applications developed for the Netscape ONE platform is that they are primarily built using HTML, Java, and JavaScript. In addition, they follow the JavaBeans component model for the components used in the application. All of these are specifically designed to work over the Internet and help to make an application platform independent. Furthermore, an application developed for the Netscape ONE platform can incorporate information that is not written in HTML, Java, or JavaScript (such as data in existing databases or C++ code that you need for real-time processing).
Components in applications. Another key feature of web applications is that they can be segmented into components, separate functional units of code. It is, in fact, the components that are distributed over the various hardware configurations, networks, and operating systems. An application typically consists of a set of distributed components that work together over a network at run time. Only a few, small files are resident on each user's machine; the bulk is stored on a server.
Lower cost of ownership. Because a web application is stored on a server, the application requires much less memory on each user's machine than traditional software applications do. Another benefit for users is that they can do their work in one interface, the browser, instead of having to use a different interface for each database or other application they need to access. The result is a lower total cost of ownership, and simplified deployment to and support of the users. This application model also fosters incremental and ongoing improvement because components are easily replaceable as they are upgraded.
Easy to build in Visual JavaScript. Another benefit of this application model is the relative ease of writing and maintaining applications. More people can develop applications for the Netscape ONE platform because the learning curve for HTML and JavaScript is much less steep than for traditional programming languages such as C++. Application developers need only a basic knowledge of JavaScript and HTML to create many types of robust applications that easily scale to thousands of users.
Netscape's Visual JavaScript development environment simplifies development further, because application developers don't need to write HTML, JavaScript, or Java code. They need to have only basic scripting skills to use any of the numerous components that have been provided in VJS or have been created by others. Programmers who want to develop their own components can do using Netscape's Component Developer's Kit or other tools, but this involves more traditional programming skills. Thus, two distinct roles can be defined for this type of application development, the application developer who assembles existing components to create an application, and the component developer who develops new components. Both roles could be performed by the same person, of course.
Intranets and extranets. Many of you already have an Internet web site for your company. You don't need to connect your application to your web site; your company's users can run them entirely within your firewall. Such an application is said to be running on your intranet. For more information on deploying an intranet, see the DevEdge web site at http://developer.netscape.com/library/documentation/deploy.html. If some of your users are outside your firewall, you might want to make an application accessible from your Internet web site. This type of application is said to be on an extranet. Because such an application is available from outside your firewall, certain security precautions must be taken. In most ways, however, intranet applications and extranet applications are identical. You can create an application for your intranet and decide later to make it accessible to external users without major redesign work because both types of applications are based on the same standards and follow the same design rules.
Application server's role. Applications developed for the Netscape ONE platform should adhere to an application model that provides a multitier, client-server architecture. In this application model, the client is the browser and forms the first tier. The server is the second tier. If a server also provides access to remote servers, it is an application server, rather than a traditional web server, and allows access to as many tiers as needed.
Design rules. This application model calls for the following simple design rules:
An application server, such as Enterprise Server, plays a key role in the Netscape ONE platform. As the hub for processing client requests, Enterprise Server has capabilities that go beyond those of a typical web server. You can connect Enterprise Server to all the other servers you have, whether they are from Netscape or other vendors, and use it for building applications, publishing content, and deploying agents. You can use it for connecting to databases through its built-in native SQL client-server connectivity for Oracle, Informix, Sybase, and IBM DB2. Its LiveWire database connectivity service allows this and also supports Open Database Connectivity (ODBC) under Windows NT and UNIX. In addition, Enterprise Server works seamlessly with partners such as Information Builders and OpenConnect to integrate connectivity to CICS and mainframe-based applications.
At run time, requests come from the clients to the application server. The application server processes the HTML page, performing any actions required. For example, it can gather data or services from other servers, a mainframe, or other remote locations. The Netscape server products all play a role in making this application model easy to support. Other clients or servers, even those not created by Netscape, could be used by any standards-based, well-designed web applications, but Netscape ensures that every Netscape product will interact properly at run time.
Typically, after you create an application, you deploy it to a server. This allows the end users to locate it through a URL from their browsers. Specifically, this is the user scenario: A user requests an HTML page from the browser by clicking a link or typing in a URL, then the browser initiates an HTTP connection between the client and the server that hosts the page. If no server-side processing is required by the HTML page, the host server simply sends the page back to the client. Often, however, an HTML page uses server-side JavaScript or needs to make connections to other remote servers, databases, or mainframes. In that case, the server behaves as an application server, processing the server-side application logic and communicating with remote sites via the appropriate Internet-based protocols. The application server then returns the page to the client, where final formatting takes place.
Client-side processing. Figure 1.1 shows how the client and server interact when an application employs only client-side requests. In this scenario, the server acts simply as a host web server for the page and does no processing before returning it to the client. The browser does the final formatting.
Figure 1.1 Client-side processing
Server-side processing. Figure 1.2 shows how the client and server interact when an application requires server-side processing. In this scenario, the server processes requests before returning the HTML page to the client. The browser again does the final formatting.
Figure 1.2 Server-side processing
Multitier processing. Figure 1.3 shows how the client and numerous servers interact when an application requires access to a database and other remote servers. In this scenario, the application server is not simply a web server that hosts web pages but also processes requests for the application, gathering data and other resources from remote locations. This is similar to traditional client-server, three-tier architecture, but can be extended to as many tiers of servers as needed.
Figure 1.3 Application server
processing remote server logic
Extranet processing. Figure 1.4 shows the use of an extranet connecting two companies. In this scenario, the server for Company 2 processes requests coming through its firewall from Company 1. A firewall is usually a server that provides secure access to and from the Internet. Besides its connection to the Internet, Company 1 has its own intranet, not connected to its firewall server.
The URL on the HTML page in Company 1's browser simply points to a location on Company 2's extranet-designated application server, which it reaches only after passing through Company 2's firewall. The requests might require Company 2's application server to locate databases or remote servers available on its extranet; these requests would be allowed only with proper security. For more information on security, see the DevEdge web site at http://developer.netscape.com/library/documentation/security.html. When the requests are completed, Company 2's application server returns the page back through the firewall to Company 1, where its browser does the final formatting.
Figure 1.4 Extranet processing
VJS provides many types of components on its Component Palette. In VJS you don't need to edit the source code for a component before using it, you can simply drag copies of components from the Component Palette onto an HTML page and connect them. VJS generates the HTML and JavaScript source code in the background for you, although you can edit it directly if you want. The HTML and JavaScript created by VJS adheres to the pertinent specifications created by the related standards groups. For JavaScript, this group is the European Computer Manufacturers Association (ECMA) at http://www.ecma.ch. The standards group for HTML is the World Wide Web Consortium at http://www.w3.org.
Projects. VJS uses a project to contain all the HTML pages in an application, with each application in its own project. You edit your HTML pages in a Page Editor, which is an HTML page that looks much like an HTML page in a browser. Components are assembled into an application at design time; their runtime equivalents are the objects instantiated from them. Each time the component executes at run time, the component is instantiated as an object. Thus, each object is a particular instance of the component with particular characteristics that relate to that execution. Depending on actions the user has taken to affect that object at run time, it might behave differently with each execution. For instance, the object might display one name in a text field one time when the user clicks a Submit button, and another name the next time.
Inspector. An Inspector window allows you to see the properties, events, and methods for each component. VJS is able to populate the Inspector with these attributes because it can examine a component through its interface in the source code, freeing you from having to look at the source. If you want to change the component, simply enter your changes into the Inspector; you don't need to edit the source code directly.
Component Palette. The Component Palette is organized into a set of tabbed pages. The default Component Palette tabs are Form, Database, HTML, Other, and Test. The tabs reflect a grouping of components according to their use in applications. The Form tab has HTML-based and JavaScript-based components for creating forms and the UI elements usually found on them, such as text fields. The HTML tab has HTML-based components for UI elements that are not form-related, such as image files and tables. The Database tab has Java-based and JavaScript-based components for database access. The Test tab has Java-based and JavaScript-based components for testing your application before all its functionality is in place. The Other tab has Java-based and JavaScript-based components for functionality that is not database specific, such as an automatic mail sender and date display. You can add your own tabs and components to the Component Palette, if you wish.
Each component is represented on the Component Palette by an icon and a name. If you change a component on an HTML page you are assembling, you can drag it back onto a tab on the Component Palette for reuse at a later time. Also, if you want to use more than one HTML page in your application, you will probably want some elements, such as your company logo or page layout, to be consistent on each page. To do this, you can create a template HTML page that you can save and reuse as needed.
You can build many types of robust applications using the ready-made components in VJS. However, you can also use components created outside of VJS simply by importing them into the Component Palette. You can get many ready-made components on the Internet; see http://developer.netscape.com/guides/components. For components that are part of the Netscape server products, see http://developer.netscape.com/library/documentation/servers.html. You can create your own components using the Netscape Visual JavaScript Component Developer's Kit at http://developer.netscape.com/one/components/cdk.html.
An example project. Figure 1.5 shows the guestbook project in VJS, revealing the Project window, Component Palette, Inspector, and HTML page under construction. The guestbook application greets people when they visit a web site and allows them to enter comments onto a form.
Figure 1.5 An application
under development in VJS
Connection Builder. To make connections between components on a page, you simply drag a component's connection point to another component. The connection is made automatically. The Connection Builder dialog box allows you to fine tune the connection, for example, by making it two-way. The Connection Builder generates all the client-side JavaScript needed, including any LiveConnect connections for connecting to Java and, through Java, to any plug-ins you might want to incorporate. Figure 1.6 shows the Connection Builder.
Figure 1.6 The Connection
Builder
You can create three types of connections between components: a property connection, an event connection, or a direct connection. Which type of connection you choose depends on which components you use and how you want them to relate. You use a property connection to keep two components in sync. Use an event connection if you want to use a JavaScript event handler to trigger an action in one component from another. Finally, use a direct connection if you want a Java component to trigger an event in another Java component.
Testing and debugging. You can also test, debug, and deploy your application from within VJS. The Netscape JavaScript Debugger is included in VJS for debugging client-side JavaScript. To debug server-side JavaScript, use the JavaScript debugging facilities in Enterprise Server.
Database Application Wizard. The Database
Application Wizard helps you create an application that connects to a database.
Also, several custom editors help you connect to a database, make valid
SQL statements, and more.
The language a component was written in is not even very important to you as an application developer, since you don't have to write source code. However, it is helpful to understand how components of various types behave at run time so that you can use them to their best advantage. Also, you must ensure that components you use do not employ HTML or JavaScript features that your user's browser does not support.
Applications you develop for the Netscape ONE platform typically consist of HTML-based UI components you assemble on HTML pages or forms, with JavaScript connecting the components together. Java-based components are used to perform computation-intensive functions or to interact with remote services, such as the LDAP services built into the Directory Server. The architecture to support this language transparency requires only that support for the various languages be available on the end user's client and on your server. Netscape supports this by building the required runtime environments into Communicator and the Netscape servers. For instance, at run time, the JavaScript Execution Environment and the Java Runtime Environment (JRE) are both running in Communicator for client-side interpretation and in the Enterprise Server for server-side interpretation.
Java on the Netscape ONE platform. Java is a robust and versatile Internet-based language that also provides, along with the use of certificates, much of the security required for web applications. Java is, however, more than a language; the JRE provides the runtime environment for the Java code. The JRE consists of a Java Virtual Machine (VM), Java Core classes, and other supporting files. Several different companies create JREs; Netscape ships JREs on the client and server. Netscape ONE supports and integrates 100% Pure Java applets and interfaces. JavaSoft, a division of Sun Microsystems, provides the Java Developer Kit for writing, compiling, and testing Java code. If you are a component developer creating Java-based components and your code compiles with the Java Developer Kit, your component will run in any platform or OS that runs the Java Virtual Machine.
JavaBeans Component Model. Netscape has adopted the JavaBeans component model and has based the Netscape ONE platform and tools on this standard. JavaBeans, as specified in JavaSoft's JDK 1.1, are supported in both Communicator 4.x and in Enterprise Server 3.x. None of the JavaBeans-related technologies in Netscape ONE are proprietary. The JavaBeans component model is standardized by JavaSoft, at http://java.sun.com.
You don't need to know the JavaBeans component model to use components in your applications. A component model is helpful for specifying a standard way that components communicate with each other, with development environments, or with other tools. A component is code that has an interface built into it, either explicitly by the component builder or implicitly by its very design. A component based on the JavaBeans specification can be identified and inspected by a tool from outside itself. A development environment such as VJS can communicate with these components because they have a standard interface that VJS can understand.
The interface to JavaBeans components is called BeanInfo and consists of a specific set of methods, properties, and events. BeanInfo allows introspection and communication into the applet, code, or component through the events, methods, and properties, see Figure 1.7. If you develop your own components, you usually have to write a BeanInfo interface to make a piece of code adhere to the JavaBeans component model specification. However, VJS can use an applet as a JavaBean component automatically if the applet inherits from the Java Applet class. You can simply import the applet into VJS without rewriting it; you don't need to generate the BeanInfo information yourself. Furthermore, Netscape has extended the use of the JavaBeans component model to JavaScript and HTML so that JavaScript and HTML code can be treated as JavaBeans in VJS although they are not, strictly speaking, JavaBeans.
Figure 1.7 Anatomy of a JavaBean
component
You can also import and use CORBA-based JavaBeans or LDAP-based JavaBeans. CORBA-based JavaBeans are useful for legacy connectivity. CORBA (Common Object Request Broker Architecture) is standardized by the Object Management Group at http://www.corba.org. CORBA uses the IIOP networking protocol for communication between CORBA objects at run time. For an overview of CORBA, see the DevEdge web site at http://developer.netscape.com/library/wpapers/corba/index.html.
LDAP is the networking protocol (Lightweight Directory Access Protocol). LDAP components expose the LDAP services on the Directory Server as components in VJS and make it easy to access centralized user and organizational data. For more information on LDAP, see the DevEdge web site at http://developer.netscape.com/library/documentation/dirsdk/dirsdk.htm. Look for components that you can import into VJS and information on how to create components in the Component Developer's Kit at http://developer.netscape.com/one/components/cdk.html.
File Types. All the components in VJS are kept in files on your development system. If you care to examine them, the components supplied with VJS are generally kept in files that correspond to the component types. Files with the extension .jar (Java Archive) contain components written in Java. Files with the extension .jsb (JavaScript Bean) contain JavaScript components, and files with the extension .hi (HTML Interface) contain HTML components. Your deployed application will be in files with the extensions .html, .js, .class, or multimedia-related file types, such as .gif. If your application uses server-side components, a file with the extension .web is created when you compile and deploy your application. This type of file contains all the files from the project except the binary files, such as .class and .gif files.
CGI scripts still work on the Netscape ONE platform. However, using CGI scripts forces you to update your scripts by hand since they cannot be integrated directly into an application. Instead, use JavaScript whenever possible; it will make maintaining your applications much easier.