Apache Open Source Project--Turbine

1. Origins

Jetspeed is an open source portal system for the Apache Jakarta Group. It enables end users to use a variety of network resources (such as applications, data, and any other network resources) through a wide range of devices such as WAP phones, browsers and PDAs. Here, Jetspeed plays a role as a hub between information and users.

About 1999 years, Jetspeed Project and began to operate. Soon, Jetspeed's development went beyond the initial goal of the project, at a pace that no one could imagine. In the Jakarta group's own words, it says, "The only problem is, and that's beyond the scope of this project."

Now, Jetspeed has evolved into a Web application engine based on the turbine (also a masterpiece of the Jakarta Group), the Network application framework (frameworks).

1.1 Jetspeed

In a nutshell, Jetspeed is the turbine that adds the portal component. It itself is both a portlet container and a large number of utility portlets. In Jetspeed, the management of portlets is mainly done by the following two types of files:

L.. Xreg Registration Document

L.. PSML configuration file

. xreg files are generally placed in the webapp-name/web-inf/conf directory, with no limitation of file names. A portlet must be registered with a. xreg file in order to be used in jetspeed. Each portlet component is a Java class that can be instantiated by the system to output a particular Web document.

. psml files are generally placed in the WEBAPP-NAME/WEB-INF/PSML directory, with no limit to the file name: PSML Sets the display mode of the page content, such as how a page is laid out, how many columns are divided, how many panes each column can have, The contents of each pane are output by which portlet, and so on.

2. Overview

Turbine is a servlet-based Web application frameworks that enables Java developers to quickly and securely build their own web applications.

Turbine is a complete MVC application framework, consisting mainly of the following parts:

L Presentation layer: Velocity (again a masterpiece of the Jakarta Group, a Java-based template engine) or JSP

L Data layer: torque and Peers

L Control Layer: Turbine

L HTML Form Validation:intake

L Logs: Logging Service in log4j and Turbine2

L Service frameworks:turbine (in Turbine3, this part is called Fulcrum)

This article focuses on the control layers in turbine, and the rest of the sections refer to the sites mentioned in their respective documents or references.

3. Cornerstone

The turbine consists mainly of five parts, as shown in:

Let's start with a separate introduction to these five sections, and then introduce the detailed flow of turbine.

3.1 Action

The action is a module that executes a particular transaction, and Sessionvalidator in turbine is a typical action.

When a user submits an HTML form, one of the hidden fields contains information about the action that will be executed. The action mechanism makes it easier for Java developers to process user-submitted data. For example, the "Logout" transaction may be called in many places in the system, so the Logout transaction process is written as a reusable module, making the transaction easier to invoke. This reusable module is an action. Through the various actions in the system, each action processes the different information in the user data, so that the whole system is more simple and crisp, easier to write, expand and maintain.

And, turbine through the action mechanism, it can also make the program flow more flexible and changeable. For example, in the process of page processing, you can help determine which screen will be displayed later by executing a specific action. At this point, the execution results of the action can be used as a basis for future procedures.

Action is a reusable transaction component in the system, and the action mechanism enables turbine to have a flexible, clear transaction process.

3.2 Page

A page module is the first module to be executed during page generation, and it can be thought of as the coordinator and organizer between action, Layout, screen, navigation.

In general, page executes the specified action (if any) in the user's request first, and then selects and executes the layout according to the screen to be loaded later. Please note that at this point, it is possible to change which screen is executed depending on the action execution result. Also, the layout of screen may change depending on the settings of defaultlayout in the turbineresources.properties configuration file.

3.3 Screen

The screen module is essentially the "torso" of the Web page. This is where the HTML code in the Web page is generated. Screen is the most important representation (View) part of the entire turbine.

screen is called by layout.

Note: At this point, you can completely invoke various external modules, such as EJBS, to get the data to build your HTML page. You can also use JSP, or even blog to build page content ^_^.

3.4 Navigation

In general, websites have their own top & Bottom Navigation, but usually they are called headers or footer. Like screen, navigation is also called by layout.

Not just as a header or footer,navigation can also appear as a menu or tree view.

3.5 Layout

Layout is called by the page and can be considered a container for screen and navigation.

Similar to the various containers in swing and AWT, layout generally defines where each navigation, screen is displayed on the page, and plays a role in layout management.

As you can see, the encapsulation relationship between the various module objects in the turbine is roughly as follows:

From there, we can see that each element in the turbine is encapsulated with each other (encapsulation), allowing the HTML page to appear in front of us in a templated form. Why is that? The Jakarta Group explains this to us: "This is no accident, the Turbine framework is essentially an object oriented representation of the COM Ponents of an Html page. "

3.6 Loader

In addition to the five types of components mentioned above, there is another component in turbine: Loader.

Loader is responsible for dynamic loading of the above mentioned five components. These loader can keep five of the above component objects in memory to form a cache and speed up the response of the program.

Loader identifies these components through the configuration file: Turbineresources.properties. Loader is equivalent to ClassLoader in Java, and turbineresources.properties is like "Loader Classpath" to help Loader identify individual components. In this way, turbine can guarantee that our Web application will always be loaded and executed correctly.

4. Process

At this point, I believe you have the standard control of the turbine process has been clear in the chest:

In Turbine-based Web application, there is typically only one servlet (Turbine servlet) that is used to receive user requests. When the servlet receives the request, it determines which page to load by analyzing the data, and, if necessary, the page executes the specified action, and then loads the specified layout; The layout calls screen and navigation responsible for the generation of web pages.

4.1 Turbine Standard System Flow

In a common Turbine application, the Turbine servlet generally follows the following process:

1. When a new request arrives, the Turbine servlet first checks to see if the HttpSession instance exists. If there is no httpsession instance, then redirect directly to the "homepage" of this URL (the default value for this "homepage" is login screen. Of course, you can also point it at any place you want in turbineresources.properties.

During redirection, turbine also records a unique identifier for the visitor in the cookie, and if the client browser does not support Cookie,turbine activates "session tracking", which will include the user's identity information in future URLs.

2, after the user session is established, turbine will cache some of the data that is often used in the Rundata instance.

3. Next, the Turbine servlet checks to see if the user is trying to log in. The method is to check if the action defined in the request is "Loginuser" (which, of course, can still be customized in the Turbineresources.properties file). If so, execute the action. Unlike other actions, this "Loginuser" action must implement a user authentication and call the Rundata.save () method (indicating that it has passed identity verification).

4. The Turbine servlet invokes the Sessionvalidator Action regardless of whether the user is authenticated or not. Sessionvalidator action checks whether the user is logged in, updates the timestamp of the user's last logon, if any, or redirects to the login page. Here's a tip: if you want some of your pages to have rights protection, you can call Sessionvalidate Action in the layout of those pages. Or if your system does not require a login, you can replace the default version with a simple sessionvalidate action version that returns only null.

5. Next, the Turbine servlet will call "Defaultpage". "Defaultpage" starts a series of transactions: Invoke action (if any), execute layout, and so on.

6. When layout finishes processing screen and navigation, the System flow ends and the Turbine servlet returns the requested page information.

5. Rundata

See here, you may have a common question, that is: after so many layers of calls, then the user request contains the data exactly how to pass it? The answer is Rundata.

In the description of the System Flow section, we can see that Rundata logs information about a user's login or not by using the Rundata.save () method. In fact, Rundata primarily plays the role of passing parameters throughout the framework. database connections, Get/post/path_info (GPP) data, action and screen names, and document instances of the output HTML can be saved in an Rundata instance. Also, you can save information that needs to be persisted in Rundata.

It is important to note that:

Because the Rundata instance is not thread-safe, the Rundata instance is recreated on each request and is never saved to the global context.

L Only one Rundata instance may exist per request.

In addition, in Turbine2.2, Rundata has been changed from public Class 2.0 to public interface. However, the method of use does not change. Resources

1, http://jakarta.apache.org/turbine/, turbine official site.

2, http://jakarta.apache.org/turbine/fsd.html, functional specification Document.

3, http://jakarta.apache.org/jetspeed/, Jetspeed official site.

4, http://jakarta.apache.org/velocity, Velocity official site.

5, http://db.apache.org/torque/, torque official site.

6, http://jakarta.apache.org/turbine/fulcrum/howto/intake-service.html, Intake introduction.

7, http://jakarta.apache.org/log4j/docs/index.html, log4j official site.

8, http://jakarta.apache.org/turbine/fulcrum/index.html, Fulcrum official site.

9, http://www.bluesunrise.com/jetspeed-docs/, jetspeed third-party document set.

10, Li Jianhua, "Turbine exploration", "Programmer" 2003.07.

Apache Open Source Project--Turbine