Danev| MFinance| JFW| Mail| MobilePark| HandyFx| TopShop| Dantest     
JFrameworkWeb SearchDownloadNewslettersFirm Profile

  Menu


    What is a Framework
    Framework Objectives
    Developing a Framework

    Architecture
    J2EE App Architecture
    Physical Architecture

    App Building Approaches
    Structuring Web App
    Components Manager
    Object Relational Mapping  

    Online Documentation

    Glossary

    News
    Download
    Message Board
    Contacts

  Summary

  A framework is a set of common and prefabricated software building blocks that programmers can use, extend or customize for specific computing solutions. With frameworks developers do not have to start from scratch each time they write an application. Frameworks are built from collection of objects so both the design and code of the framework may be reused.

 



Structuring Web App   
 You Are Here: Home > Structuring Web App


Separating Presentation from Logic

To implement the Frintier Application Building Approach, we have to follow and to adapt a recommended structure for Web applications, called structured interactions.


MVC Model 2.

The figure illustrates how Frintier must implement the major elements of a structured interaction and their relationships in the recently very popular MVC Model 2.

An arrow leading from one component to another indicates that the first component uses (invoke methods on) the second component. Each of the component types indicated has an assigned role in Web applications. However, these roles are not black and white. In an ideal environment, the components allow a perfect separation of skills and roles. The component's role description should be taken as a guideline rather than an absolute. The guidelines are designed to help support an efficient and effective development process, not to limit creativity or increase development overhead.

Essentially, the interaction is divided into a number of components that closely follow the classical model-view-controller (MVC) structure for applications.

This structure allows different skills and tools to be used for different elements of the application and for the development sequence of the various parts to be largely decoupled.

The idea of this structure is that servlets process HTTP requests and coordinate the rest of the application elements. The primary application logic is separated into business components outside the servlet and independent of the details of HTTP access.

Generally, JSPs should not contain application logic.

The normal flow of control that occurs in the processing of an HTTP request with a structured interaction is:

1. The HTTP request arrives and is dispatched to the appropriate servlet. Possibly this redirection could be done through the JSP.

2. The servlet moderates the call on one or more business components with the appropriate parameters to perform the logic of the request.

3. The business components implement the business logic and may leverage relational database access, connectors, or the Web application infrastructure to perform its computations.

4. Based on the results of the computation the servlet places some of the results of the computation into the session or execution context so that it can be picked up by the next interaction.

5. The servlet either selects and invokes a JSP or does an HTTP redirection to another structured interaction (5'1).

6. The dynamic content on the selected page is filled in from the request and session context. This may leverage:
o Formatting/persistent components,
o Other JSP pages;

7. The next HTML page is ready and sent to the client



Components of a structured interaction

o Servlets - Servlets provide the coordination between the programming and content elements of an application. Servlets should generally be implemented as dispatchers with a set of customizable properties that can be adjusted for different application configurations.

o Java server pages (JSPs) - JSPs expect the servlet to provide data in the request context that is ready, after formatting, to be inserted into an HTML page. In general, the role of the JSP page is to make the final decision about the format and content of the response to an end user request.
JSP pages are intended to focus on presentation not business logic, and therefore, it is important that JSP development not require advanced programming skills in normal cases. JSPs are not intended to modify any result information.

o Formatting/persistent components - components that format various types of dynamic content for use in Java server pages. These help to simplify JSPs so that they can generally be constructed without requiring programming skills. They also provide a single point of change for formatting decisions that span the application.

o Business components - business components are components that implement the business logic and may leverage relational database access, connectors, or the Web application infrastructure to perform its computations. It is common for a servlet to invoke several business components to accomplish one application step as seen by an end user. Each component has a set of input properties (which may have pre-configured values), a set of output properties (which may, also, have a set of pre-configured values), and a perform method. The Framework's programming model should provide for two categories of business components - general and Enterprise Java Bean based.
1. General components are business components that are not EJBs and do not run inside EJB container. Might be written not only in Java. They may leverage database access, any of the Framework connectors, external business components, and even the EJB. The general components may leverage transactions in external resource managers such as relational databases, but may not directly participate (with recoverable resources) in the transactions or initiate transactions that span multiple resource managers.
2. Enterprise Java Bean (EJB) based components are components constructed according to the conventions and requirements of the EJB specification and leveraging EJB containers, EJB enabled RDB access, and/or EJB enabled connectors. EJB-based components can initiate transactions, participate in the transactions, and leverage transactions that span multiple resource managers (subject to the ability of those resource managers to participate in multi-party transactions). EJB-based components can be distributed across multiple servers using remote method call technology and can be accessed directly from clients via remote method call technology.

The business components should be given any information they need from the HTTP request explicitly (by setting appropriate input properties) so that they are isolated from the form and details of the HTTP request.



Roles in Development of a Structured Web Application

The J2EE Architecture and the MVC structure of the Web application allows different skills and tools to be used for creating the different elements of the application.

This separation of the roles is expressed on the following figures:


Roles based on J2EE Architecture.


Roles based on the MVC Model 2



Description of Roles

The Web Designer is responsible for :
o the design of the Web pages and the Web pages content. This is a separate role and in some cases the Web Designer may be from the client side. In this way the model of the presentation part is delivered by the client.

The Presentation Logic Developer is responsible for:
o Browser interaction with the application;
o Specification, design and development of presentation logic including JSPs;
o Specification and design of the interface between the Presentation and the Business tiers.

The Business Logic Developer is responsible for:
o Specification, design and development of business logic (computations and results that must be provided to the presentation tier);
o Specification and design of the interface between the Business tiers and the Enterprise Information System tier (the Data Model and the selected database);
o Support of the interface between the Presentation and the Business tiers.

The Data Model Developer is responsible for:
o Specification, design and development of Data Model and data model implementation on the selected DBMS;
o Support of the interface between the Data Model and the Business tiers.



2002 Frontior Technologies. All Rights Reserved.
QWave.com QBioscan.com QSART.com QANS.com QMedical.com AutonomicTest.com QHRV.com QAthlete.com Medeia.com Dantest.com 06.23.17