HTTP is stateless HTTP is called a stateless protocol because each command is executed independently, without any knowledge of the

commands that came before it. This is the main reason that it is difficult to implement Web sites that react intelligently to user input. This shortcoming of HTTP is being addressed in a number of new technologies, including ActiveX, Java, JavaScript and cookies. SERVLET ENGINE Servlets are supported in nearly all web servers, from Apache to Zeus. Some web servers support servlets right out of the box. We call this type of server a Standalone Servlet Engine. Other web servers require a third-party plug-in to support servlets. We call the servlet-enabling plug-in an Add-on Servlet Engine. Finally, if you want to write your own server with servlet support, you can use what's called an Embeddable Servlet Engine. A standalone servlet engine is a server that includes built-in support for servlets. Such an engine has the advantage that everything works right out of the box. One disadvantage, however, is that you have to wait for a new release of the web server to get the latest servlet support. An add-on servlet engine functions as a plug-in to an existing server--it adds servlet support to a server that was not originally designed with servlets in mind. Add-on servlet engines have been written for many servers including Apache, Netscape's FastTrack Server and Enterprise Server, Microsoft's Internet Information Server and Personal Web Server, O'Reilly's WebSite, Lotus Domino's Go Webserver, StarNine's WebSTAR, and Apple's AppleShareIP. This type of engine acts as a stopgap solution until a future server release incorporates servlet support. A plug-in also can be used with a server that provides a poor or outdated servlet implementation. An embeddable engine is generally a lightweight servlet deployment platform that can be embedded in another application. The application becomes the true server. A JSP embeddable engine provides support for JSP in a web server that already supports servlets. ActiveX control ActiveX control is a control using Microsoft ActiveX technologies. An ActiveX control can be automatically downloaded and executed by a Web browser. ActiveX is not a programming language, but rather a set of rules for how applications should share information. Programmers can develop ActiveX controls in a variety of languages, including C, C++, Visual Basic, and Java. An ActiveX control is similar to a Java applet. Unlike Java applets, however, ActiveX controls have full access to the Windows operating system. This gives them much more power than Java applets, but with this power comes a certain risk that the applet may damage software or data on your machine. To control this risk, Microsoft developed a registration system so that browsers can identify and authenticate an ActiveX control before downloading it. Another difference between Java applets and ActiveX controls is that Java applets can be written to run on all platforms, whereas ActiveX controls are currently limited to Windows environments. Related to ActiveX is a scripting language called VBScript that enables Web authors to embed interactive elements in HTML documents. An ActiveX control is a component program object that can be re-used by many application programs within a computer or among computers in a network. The technology for creating ActiveX controls is part of Microsoft's overall ActiveX set of technologies, chief of which is the Component Object Model (COM). ActiveX controls can be downloaded as small programs or animations for Web pages, but they can also be used for any commonly-needed task by an application program in the latest Windows and Macintosh environments

In general, ActiveX controls replace the earlier OCX (Object Linking and Embedding custom controls). An ActiveX control is roughly equivalent in concept and implementation to the Java applet. An ActiveX control can be created in any programming language that recognizes Microsoft's Component Object Model. The distributed support for COM is called the Distributed Component Object Model (DCOM). In implementation, an ActiveX control is a dynamic link library (DLL) module. An ActiveX control runs in what is known as a container, an application program that uses the Component Object Model program interfaces. This reuseable component approach to application development reduces development time and improves program capability and quality. Visual Basic and C++ are commonly used to write ActiveX controls.

Difference between ActiveX DLL and ActiveX Exe ActiveX DLLs and ActiveX EXEs are almost exactly the same in the ways they are built and used. In both cases, you build one or more classes that applications can use to do something. The big difference lies in where they are used. An ActiveX DLL's code is executed within the main program's address space. It behaves as if the class was created within the main program's code. Because the code lies inside the program's address space, calling methods is very fast. An ActiveX EXE's code is run in a separate process. When the main program calls an ActiveX EXE's method, the system marshals the call to translate the parameters into the ActiveX EXE's address space, calls the method, translates the results back into the main program's address space, and returns the result. This is slower than running an ActiveX DLL's method inside the main program's address space. Because of the difference in speed, an ActiveX DLL is almost always preferable. The reason ActiveX EXEs are useful is they can run on a different computer than the main program while an ActiveX DLL must run on the same computer as the main program. If you want to build a library of shared routines to save programming and debugging, use an ActiveX DLL because it will give you better performance. Even if you need to distribute several copies of the DLL on different computers, it will probably be worthwhile. If you want a centralized server library, use an ActiveX EXE. The EXE can sit on a central computer and work directly with that computer's resources. If you need to frequently change how the code works, you can easily change it in one place. An ActiveX DLL runs is a process server running in the same memory space as the client process. An ActiveX Exe is an out of process server which runs in its own separate memory space. An ActiveX EXE file is designed to work as an OLE server, which is nothing more than a program designed to share information with another program. It has an .EXE file extension. ActiveX DLL files are not meant to be used by themselves. Instead, these types of files contain subprograms designed to function as building blocks when creating a stand-alone program. It has a .DLL file extension. Advantages of ActiveX DLL,

1) An in-process component shares its clients address space, so property and method calls dont have to be marshaled. This results in much faster performance. Advantages of ActiveX Exe, 1) The component can run as a standalone desktop application, like Microsoft Excel or Microsoft Word, in addition to providing objects. 2) The component can process requests on an independent thread of execution, notifying the client of task completion using events or synchronous call-backs. This frees the client to respond to the user. 3)If an error occurs the client processes can continue to operate. OLE (Object Linking and Embedding) OLE (Object Linking and Embedding) is Microsoft's component document technology. With OLE, you can dynamically link files and applications together. An object is a combination of data and the application needed to modify that data. You can embed objects in or link them to documents created with a different application. For instance, an Excel spreadsheet can be embedded within a Microsoft Word document using OLE. Doubleclicking the embedded spreadsheet will launch Excel and allow the user to modify the sheet. Some applications include small applets that are used to create objects. For instance, Microsoft Word includes a drawing tool (MS Draw) and a tool for manipulating characters as art (Text Art) which can be launched only via OLE. Document Object Model The Document Object Model (DOM) is an application programming interface (API) for valid HTML and wellformed XML documents. It defines the logical structure of documents and the way a document is accessed and manipulated. In the DOM specification, the term "document" is used in the broad sense - increasingly, XML is being used as a way of representing many different kinds of information that may be stored in diverse systems, and much of this would traditionally be seen as data rather than as documents. Nevertheless, XML presents this data as documents, and the DOM may be used to manage this data. With the Document Object Model, programmers can build documents, navigate their structure, and add, modify, or delete elements and content. Anything found in an HTML or XML document can be accessed, changed, deleted, or added using the Document Object Model, with a few exceptions - in particular, the DOM interfaces for the XML internal and external subsets have not yet been specified. What the Document Object Model is, The DOM is a programming API for documents. It is based on an object structure that closely resembles the structure of the documents it models. For instance, consider this table, taken from an XHTML document: <table> <tbody> <tr> <td>Shady Grove</td> <td>Aeolian</td> </tr> <tr> <td>Over the River, Charlie</td> <td>Dorian</td> </tr> </tbody>

</table> A graphical representation of the DOM of the example table, with whitespaces in element removed, is: An example of DOM manipulation using ECMAScript would be: // access the tbody element from the table element var myTbodyElement = myTableElement.firstChild; // access its second tr element // The list of children starts at 0 (and not 1). var mySecondTrElement = myTbodyElement.childNodes[1]; // remove its first td element mySecondTrElement.removeChild(mySecondTrElement.firstChild); // change the text content of the remaining td element mySecondTrElement.firstChild.firstChild.data = "Peter"; In the DOM, documents have a logical structure which is very much like a tree; to be more precise, which is like a "forest" or "grove", which can contain more than one tree. Each document contains zero or one doctype nodes, one document element node, and zero or more comments or processing instructions; the document element serves as the root of the element tree for the document. However, the DOM does not specify that documents must be implemented as a tree or a grove, nor does it specify how the relationships among objects be implemented. The DOM is a logical model that may be implemented in any convenient manner. In this specification, we use the term structure model to describe the tree-like representation of a document. We also use the term "tree" when referring to the arrangement of those information items which can be reached by using "tree-walking" methods; (this does not include attributes). One important property of DOM structure models is structural isomorphism: if any two Document Object Model implementations are used to create a representation of the same document, they will create the same structure model, in accordance with the XML Information Set . Note: There may be some variations depending on the parser being used to build the DOM. For instance, the DOM may not contain white spaces in element content if the parser discards them. Enterprise JavaBeans (EJB) Enterprise JavaBeans (EJB) is an architecture for setting up program components, written in the Java programming language, that run in the server parts of a computer network that uses the client/server model. Enterprise JavaBeans is built on the JavaBeans technology for distributing program components (which are called Beans, using the coffee metaphor) to clients in a network. Enterprise JavaBeans offers enterprises the advantage of being able to control change at the server rather than having to update each individual computer with a client whenever a new program component is changed or added. EJB components have the advantage of being reusable in multiple applications. To deploy an EJB Bean or component, it must be part of a specific application, which is called a container. Originated by Sun Microsystems, Enterprise JavaBeans is roughly equivalent to Microsoft's Component Object Model/Distributed Component Object Model architecture, but, like all Java-based architectures, programs can be deployed across all major operating systems, not just Windows. EJB's program components are generally known as servlets (little server programs). The application or container that runs the servlets is sometimes called an application server. A typical use of servlets is to replace Web programs that use the common gateway interface (CGI) and a Practical Extraction and Reporting Language script. Another general use is provide an interface between Web users and a legacy application mainframe application and its database.

In Enterprise JavaBeans, there are two types of beans: session beans and entity beans. An entity bean is described as one that, unlike a session bean, has persistence and can retain its original behavior or state. Difference between javaBeans and Enterprise JavaBeans? 1. JavaBeans may be visible or nonvisible at runtime.For example, the visual GUI component may be a button,list box,graphic or a chart. An EJB is a nonvisual ,remote object. 2. JavaBeans are intended to be local to a single process and are primarly intended to run on the client side.Although one can develop server-side JavaBeans,it is far easier to develop them using the EJB specification instead. EJB's are remotely executable components or business objects that can be deployed only on the server. 3. JavaBeans is a component technology to create generic Java components that can be composed together into applets and applications. Even though EJB is a component technology,it neither builds upon nor extends the original JavaBean specification. 4.JavaBeans have an external interface called the properties interface, which allows a builder tool to interpret the functionality of the bean. EJBs have a dployement descriptor that describes its functionality to an external builder tool or IDE 5.JavaBeans may have BeanInfo classes,property editors or customizers. EJB's have no concept of BeanInfo classes,property editors or customizers and provide no additional information other than that described inthe deployment descriptor. 6. JavaBeans are not typed. EJBs are of two types - session beans and entity beans. 7. No explicit support exists for transactions in javaBeans. EJB's may be transactional and the EJB servers provide transactional support. 8. Component bridges are available for JavaBeans.For ex: a javabean can also be deployed as an Activex control. An EJB cannot be deployed as an ActiveX control because ActiveX controls are intended to run at the desktop and EJB's are server side components.However CORBA-IIOP compatibility via the EJB-to-CORBA mapping is defined by the OMG.