Component Object Model 1. COM (Component Object Model) enables software components to communicate.

COM is used by developers to create re-usable software components, link components together to build applications, and take advantage of Windows services. COM objects can be created with a variety of programming languages. Object-oriented languages, such as C++, provide programming mechanisms that simplify the implementation of COM objects. The family of COM technologies includes COM+, Distributed COM (DCOM) and ActiveX Controls. The Component Object Model (COM) is a software architecture that allows applications to be built from binary software components. COM is the underlying architecture that forms the foundation for higher-level software services, like those provided by OLE. These services provide distinctly different functionality to the user. However they share a fundamental requirement for a mechanism that allows binary software components, derived from any combination of pre-existing customers' components and components from different software vendors, to connect to and communicate with each other in a well-defined manner. This mechanism is supplied by COM, a software architecture that does the following: a. Defines a binary standard for component interoperability b. Is programming-language-independent c. Is provided on multiple platforms (Microsoft Windows, Windows 95, Windows NT, Apple Macintosh, and many varieties of UNIX) d. Provides for robust evolution of component-based applications and systems e. Is extensible by developers in a consistent manner f. Uses a single programming model for components to communicate within the same process, and also across process and network boundaries g. Allows for shared memory management between components h. Provides rich error and status reporting i. Allows dynamic loading and unloading of components

2.

3.

4.

COM Solves the Component Software Problem COM addresses the four basic problems associated with component software: Basic component interoperability Versioning Language independence Transparent cross-process interoperability Basic Interoperability and Performance These are provided by COM's use of vtables to define a binary interface standard for method calling between components. Calls between COM components in the same process are only a handful of processor instructions slower than a standard direct function call and no slower than a compile-time bound C++ object invocation. Versioning A good versioning mechanism allows one system component to be updated without requiring updates to all the other components in the system. Language Independence Components can be implemented in a number of different programming languages and used from clients that are written using completely different programming languages. Again, this is because COM, unlike an object-oriented programming (OOP) language, represents a binary object standard, not a source code standard. This is a fundamental benefit of a component software architecture over object-oriented programming languages. Objects defined in an OOP language typically interact only with other objects defined in the same language. This necessarily limits their reuse. At the same time, an OOP language can be used in building COM components, so the two technologies are actually quite complementary. COM can be used to "package" and further encapsulate OOP objects into components for widespread reuse, even within very different programming languages. Transparent Cross-Process Interoperability It would be relatively easy to address the problem of providing a component software architecture if software developers could assume that all interactions between components occurred within the same process space. In fact, other proposed system object models do make this basic assumption. Local and Remote Transparency COM is designed to allow clients to transparently communicate with components regardless of where those components are running, be it the same process, the same machine, or a different machine. This means that there is a single programming model for all types of COM components, not only for clients of those COM components but also for the servers of those COM components. Distributed Component Object Model(DCOM)

DCOM (Distributed Component Object Model) is a set of Microsoft concepts and program interfaces in which client program object s can request services from server program objects on other computers in a network. DCOM is based on the Component Object Model (COM), which provides a set of interfaces allowing clients and servers to communicate within the same computer (that is running Windows 95 or a later version).

For example, you can create a page for a Web site that contains a script or program that can be processed (before being sent to a requesting user) not on the Web site server but on another, more specialized server in the network. Using DCOM interfaces, the Web server site program (now acting as a client object ) can forward a Remote Procedure Call ( RPC ) to the specialized server object, which provides the necessary processing and returns the result to the Web server site. It passes the result on to the Web page viewer. Model View Controller Architecture(MVC) 1. 2. Model View controller is a classical design pattern used in applications who needs a clean separation between their business logic and view who represents data. MVC design pattern isolates the application logic from the user interface and permitted the individual development, testing and maintenance for each components. This design pattern is divided into three parts.

a. b. c.

Model- This component manages the information and notify the observers when the information changes. It represents the data when on which the application operates. The model provides the persistent storage of data, which manipulated by the controller. View- The view displays the data , and also takes input from user. It renders the model data into a form to display to the user. there can be several view associated with a single model. It is actually representation of model data. Controller- The controller handles all request coming from the view or user interface. The data flow to whole application is controlled by controller. It forwarded the request to the appropriate handeler. Only the controller is responsible for accessing model and rendering it into various UIs.

JSP Processing

1. 2. 3.

The web server needs a JSP engine ie. container to process JSP pages. The JSP container is responsible for intercepting requests for JSP pages. A JSP container works with the Web server to provide the runtime environment and other services a JSP needs. It knows how to understand the special elements that are part of JSPs.

Following diagram shows the position of JSP container and JSP files in a Web Application.

JSP Processing: The following steps explain how the web server creates the web page using JSP: As with a normal page, your browser sends an HTTP request to the web server. The web server recognizes that the HTTP request is for a JSP page and forwards it to a JSP engine. This is done by using the URL or JSP page which ends with .jsp instead of .html. The JSP engine loads the JSP page from disk and converts it into a servlet content. This conversion is very simple in which all template text is converted to println( ) statements and all JSP elements are converted to Java code that implements the corresponding dynamic behavior of the page. The JSP engine compiles the servlet into an executable class and forwards the original request to a servlet engine. A part of the web server called the servlet engine loads the Servlet class and executes it. During execution, the servlet produces an output in HTML format, which the servlet engine passes to the web server inside an HTTP response. The web server forwards the HTTP response to your browser in terms of static HTML content. Finally web browser handles the dynamically generated HTML page inside the HTTP response exactly as if it were a static page. All the above mentioned steps can be shown below in the following diagram:

The JSP engine checks to see whether a servlet for a JSP file already exists and whether the modification date on the JSP is older than the servlet. If the JSP is older than its generated servlet, the JSP container assumes that the JSP hasn't changed and that the generated servlet still matches the JSP's contents. This makes the process more efficient than with other scripting languages (such as PHP) and therefore faster. So in a way, a JSP page is really just another way to write a servlet without having to be a Java programming wiz. Except for the translation phase, a JSP page is handled exactly like a regular servlet

Standard Actions in JSP The JSP specification defines a few standard action elements, listed in Table 3-2. Action element Description

<jsp:useBean>

Makes a JavaBeans component available in a page

<jsp:getProperty> Gets a property value from a JavaBeans component and adds it to the response <jsp:setProperty> Sets a JavaBeans component property value <jsp:include> <jsp:forward> <jsp:param> <jsp:plugin> Includes the response from a servlet or JSP page during the request processing phase Forwards the processing of a request to servlet or JSP page Adds a parameter value to a request handed off to another servlet or JSP page using <jsp:include> or <jsp:forward> Generates HTML that contains the appropriate browser-dependent elements (OBJECT or EMBED) needed to execute an applet with the Java Plug-in software