DEVELOPMENT FRAMEWORK 1. GENERAL MODEL
DYNAMIC WEB SERVER LOAD BALANCING
STATIC WEB SERVER LOAD BALANCING
(APACHE , PHP)
(LIGHTTPD, REDHAT GFS )
SOAP
APPLICATION SERVER CLUSTER (JBOSS, JAVA )
GFS
JDBC
DATABASE SERVER CLUSTER (ORACLE 10G CLUSTER )
OCFS2
SAN STORAGE ORACLE DATABASE + FILE STORAGE (video, music, images, html…)
1.1. DYNAMIC WEB SERVER - Apache - PHP for program User Interface - HA: Load balancing hardware 1.2. STATIC WEB SERVER Web server for static use lighttpd for more connection, performance than Apache. It’s only configuration for http service not application as PHP…. Note: We will make and discuss solution for static web server. 1.3. APPLICATION SERVER - Web services - Action Business logic and allow reusable. - Connection Pool - HA: Clustering Catching: - Entity cache stores database objects (i.e., EJB 3.0 Entity Bean instances) and database query results - State cache stores the application state information. It helps to all the nodes in the cluster to maintain identical application state and hence makes the cluster transparent. 1.4. DATABASE SERVER - Database structure - Stored procedure: More security and reusable - HA: Clustering database Note: We will discuss Solution for Cluster Database 1.5. SAN STORAGE - Stored database for clustering - Stored static file such as video, audio, image, html, xml…
2. DEVELOPMENT MODEL PRESENTATION TIRE - WEB Server PRESENTATION UI Server Side Script PHP / HTML Template
PRESENTATION LOGIC Soap client/ XML parse
SOAP
BUSINESS LOGIC TIRE – APP Server WEB SERVICES (JBOSS/JAVA)
XML/SOAP
JDBC
DATABASE TIRE
XML, Other Services
Oracle Stored Procedure (package, procedure, function)
Oracle Data Structure (table, index, view…)
3. 3.1. Presentation Layer Base one Web Server presentation user interface 3.2. Data Access Layer 3.3. Services Layer 3.4. Database Layer
4. PRESENTATION LAYER This layer base one Web server and only use PHP and HTML template to present GUI for User 3.1 Structure product Structure of Presentation : classes crontjobs css dbaccess functions images includes js globalconf libs locales modules styles tnlibs uploads releasenote smarty smartyfiles html xml -
classes: Stored general class.
-
crontjobs: Stored cront jobs file for doing cront task. This only access by VON IP.
-
css: Folder store css file.
-
dbaccess: The folder stored class provide content for PHP. Those class access SOAP to Services layer or direct to XML files.
-
functions: Folder store function which is developed for each module.
-
images: Store images for code as bg, icon.. not stored image upload by user. The images upload by user as photo, logo.. must be stored on Stored ( see upload folder)
-
includes: This folder stored configuration for each Product. It’s diff with globalconf folder below.
-
js: The folder store javascript file for each product.
-
globalconf: Folder store configuration file as db_global_con.php, sys_global_conf.php js_global_conf.php. This folder map from stored or all productions
-
libs: Folder store system library such as smarty, adodb…. This folder map from stored and management by R&D group.
-
locales: This folder store multi language dictionary.
-
modules: This folder contain all module of product.
-
styles: Folder stored the themes of product as header, footer…
-
smarty: Folder store smarty templates and plugins for each product.
-
smartyfiles: Folder store smarty template_c and cache file
-
tnlibs: Folder store library developed by R&D team. The library use for all product.
-
uploads: The folder stored content uploaded by user as themes, images, video, music… Subfolders under this folder mapped from stored.
-
html: The folder store HTML file which generation by program for static site as tintuc…This folder was mapped from stored.
-
xml: This folder store XML file, this folder was map from stored.
-
releasenote: Folder store released note
Almost in presentation don’t change structure, It’s only change some function: - dbaccess: Not access direct to Database 3.2 High Available - Use WEB Server Load balancer 5. DATA ACCESS LAYER - Data access layer 6. SERVICE LAYER 7. DATABASE LAYER 6.1 Store Procedure We build all database task base one stored procedure -
Centralize: Easy management, monitoring, debugging and optimization database query.
-
Reusable: Can reuse with more function, modules, product… prevent duplicate code with the same function.
-
Flexible: Can use cross-platform as PHP, Java, C….
-
Security: more security
-
Khi có thay đổi database hay chỉnh sửa xử lý liên quan đến database không cần chỉnh sửa code chỉ cần sửa dưới stored.
-
Tập trung xử lý database về một mối giúp dễ dàng monitor, tuning và debug lỗi.
-
Có thể sử dụng code liên quan đến database nhiều nơi mà không cần viết lại giúp chúng ta quản lý tập trung và nhất quán, tránh duplicate code khi nhiều người cùng phát triển sản phẩm.
-
Tách biệt hai phần code PL/SQL cho Database và PHP, JavaScript cho Interface với nhau giúp chúng ta dễ dàng optimization và chuyên sâu hơn trong lập trình. Giải quyết được vần đề những câu query do developer PHP viết không tốt mà hiện chung ta đang gặp rất nhiều.
-
An toàn cao hơn: Việc đưa tất cả xử lý về stored giúp chúng ta có an toàn rất cao trành được các yếu tố sau: o Việc gọi package(stored procedure) sẽ truyền qua parameter của các đầu hàm nên sẽ tránh được sql injection, sql binding . o Phân quyền cho user_web access vao database đơn giản chỉ cần gán quyền execute trên các package. Và user_web chỉ thấy được những package này mà không thể thấy cấu trúc database. Với đặc điểm này sẽ giúp an toàn rất lơn khi chúng ta có backdoor hay bị hack thì chũng chỉ thực hiện trên các hàm này. VD: Lúc trước nếu bị hack vào có thể hacker dung lệnh sau để destroy Data của chúng ta bằng các lệnh sql. DELETE FROM members; Hay UPDATE members SET password=’123456’. Với hai câu lệnh này thì xem như dữ liệu của chúng ta sẽ sai hoàn toàn. Nhung hiên nay chung ta viết package chỉ cung cấp 2 hàm là change_password(username, password) và delete_member(member). Thì nếu có backdoor thì cũng chĩ thực hiện những hàm này và chỉ effect trên từng record một.
6.2 Database Structure 6.3 HA