NGHIÊN CỨU MÔ HÌNH TÁC TỬ TẦNG TRUNG …repository.vnu.edu.vn/bitstream/VNU_123/15917/1/V_L0...mô tả công nghệ CC/PP, công nghệ này cung cấp một phương thức

i

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ -----------------------------------

NGUYỄN THỊ MINH KHUÊ

NGHIÊN CỨU MÔ HÌNH TÁC TỬ TẦNG

TRUNG GIAN HỖ TRỢ TÙY BIẾN

NỘI DUNG MẠNG

Ngành: Công nghệ thông tin

Chuyên ngành: Công nghệ phần mềm

Mã số: 60 48 10

LUẬN VĂN THẠC SĨ

NGƯỜI HƯỚNG DẪN KHOA HỌC:

TS. LÊ ANH CƯỜNG

Ha Nôi 2009

MỤC LỤC

ii

Lời cảm ơn ......................................................................... Error! Bookmark not defined. Lời cam đoan ..................................................................... Error! Bookmark not defined.

MỤC LỤC ............................................................................................................................ i Danh mục ký hiệu, từ viết tắt .............................................................................................. iv

Danh mục bảng .................................................................................................................... v Danh mục hình vẽ, đồ thị .................................................................................................... vi Tóm tắt ............................................................................................................................... vii

MỞ ĐẦU ................................................................................................................................. 9 1. Đặt vấn đề .................................................................................................................... 9

2. Nội dung nghiên cứu .................................................................................................. 10 3. Cấu trúc luận văn ....................................................................................................... 11

CHƢƠNG 1. NHẬN DẠNG THIẾT BỊ ...................................................................... 13 1.1. Tổng quan về độc lập thiết bị ................................................................................. 13 1.2. Các kỹ thuật nhận dạng thiết bị.............................................................................. 15

1.2.1. User Agent Request Header ........................................................................... 15

1.2.2. Accept Request Header .................................................................................. 16 1.2.3. Đặc tả khả năng thiết bị Composite Capabilities/Preferences Profile ........... 17

1.3. Kết chƣơng ............................................................................................................. 28 CHƢƠNG 2. TÁC TỬ PHẦN MỀM VÀ MÁY CHỦ PROXY ................................. 30

2.1. Tổng quan .............................................................................................................. 30

2.2. Tác tử phần mềm (Software Agent) ....................................................................... 30 2.2.1. Khái niệm ....................................................................................................... 30 2.2.2. Các loại Agent ................................................................................................ 31

2.2.3. Khả năng ứng dụng của tác tử ....................................................................... 33 2.2.4. Đánh giá một số Framework hỗ trợ Agents ................................................... 36

2.3. Proxy Server........................................................... Error! Bookmark not defined. 2.3.1. Khái niệm Proxy ............................................ Error! Bookmark not defined. 2.3.2. Tại sao ta phải cần proxy? ............................. Error! Bookmark not defined.

2.3.3. Proxy đƣợc thực hiện nhƣ thế nào? ............... Error! Bookmark not defined.

2.3.4. Một số loại Proxy Server ............................... Error! Bookmark not defined. 2.4. Kết chƣơng ............................................................. Error! Bookmark not defined.

CHƢƠNG 3. KIẾN TRÚC PROXY XỬ LÝ ĐỘNG .. Error! Bookmark not defined. 3.1. Tổng quan .............................................................. Error! Bookmark not defined.

3.2. Các mô hình xử lý dữ liệu mạng ............................ Error! Bookmark not defined. 3.2.1. Mô hình xử lý phía máy khách ...................... Error! Bookmark not defined. 3.2.2. Mô hình xử lý phía máy chủ .......................... Error! Bookmark not defined. 3.2.3. Giải pháp xử lý phía Proxy ............................ Error! Bookmark not defined.

3.3. Kiến trúc Proxy động đề xuất ................................ Error! Bookmark not defined.

3.4. Quy trình xử lý của hệ thống ................................. Error! Bookmark not defined. 3.5. Các thành phần chính trong kiến trúc .................... Error! Bookmark not defined.

3.5.1. Bộ quản lý thực thi ......................................... Error! Bookmark not defined. 3.5.2. Tác tử dịch vụ và Tác tử xử lý ....................... Error! Bookmark not defined.

3.5.3. Bộ quản lý tác tử và Bộ chứa tác tử ............... Error! Bookmark not defined. 3.5.4. Bộ xử lý và lƣu trữ thông tin khả năng thiết bị và sở thích ngƣời dùng . Error!

Bookmark not defined. 3.5.5. Bộ quản lý và lƣu trữ dữ liệu đã xử lý ........... Error! Bookmark not defined.

3.6. Kết chƣơng ............................................................. Error! Bookmark not defined. CHƢƠNG 4. THỰC NGHIỆM ................................... Error! Bookmark not defined.

4.1. Kiến trúc hệ thống thực nghiệm ............................. Error! Bookmark not defined. 4.2. Xây dựng các thành phần hệ thống ........................ Error! Bookmark not defined.

4.2.1. Tác tử dịch vụ HTTP (HTTP Service Agent) Error! Bookmark not defined.

iii

4.2.2. Tác tử chuyển mã HTML thành WML .......... Error! Bookmark not defined. 4.2.3. Tác tử chuyển mã ảnh (Image Transcoding Processing Agent) ............. Error!

Bookmark not defined. 4.2.4. CC/PP Processing .......................................... Error! Bookmark not defined.

4.3. Công nghệ và môi trƣờng xây dựng mô hình thực nghiệm .. Error! Bookmark not

defined. 4.3.1. J2EE ............................................................... Error! Bookmark not defined. 4.3.2. Eclipse ............................................................ Error! Bookmark not defined. 4.3.3. JADE .............................................................. Error! Bookmark not defined.

4.4. Kết quả thực nghiệm .............................................. Error! Bookmark not defined. 4.4.1. Hệ thống chuyển mã ảnh................................ Error! Bookmark not defined. 4.4.2. Hệ thống chuyển mã HTML sang WML ....... Error! Bookmark not defined.

4.5. Đánh giá kết quả .................................................... Error! Bookmark not defined. KẾT LUẬN ............................................................................ Error! Bookmark not defined.

1. Kết quả đạt đƣợc ........................................................ Error! Bookmark not defined.

2. Định hƣớng phát triển ................................................ Error! Bookmark not defined. TÀI LIỆU THAM KHẢO ..................................................................................................... 42

iv

Danh mục ký hiệu, từ viết tắt

Từ

viết tắt Thuật ngữ Ý nghĩa

APS Agent Proxy Server Máy chủ Proxy có sử dụng tác tử

Software Agent Tác tử phần mềm

Proxy Server Máy chủ Proxy

Transcoding Chuyển mã

Heuristic Theo kinh nghiệm

Web browser Trình duyệt web

Web Application Server Máy chủ ứng dụng web

Database Server Máy chủ cơ sở dữ liệu

Web browser Trình duyệt web

Device Independence Độc lập thiết bị

Delivery Context Phôi phối thông tin dựa trên ngữ cảnh

Server Máy chủ

PC Personal Computer Máy tính cá nhân

HTML Hypertext Markup Language Ngôn ngữ đánh dấu siêu văn bản

HTTP Hypertext Tranfer Protocol Giao thức truyền tải siêu văn bản

DP & UP Device Profile & User

Preference Hồ sơ thiết bị và sở thích người dùng

CC/PP Composite Capabilities/

Preference Profile Chuẩn Hồ sơ mô tả khả năng thiết bị do W3C cung cấp

RDF Resource Description

Framework Nền tảng mô tả tài nguyên

J2EE Java 2 Enterprise Edition Phiên bản Java dành cho các ứng

dụng doanh nghiệp

JADE Java Agent Development

Framework Nền tảng phát triển ứng dụng dựa trên Agent

WSP Wireless Secsion Protocol Giao thức phiên không dây

WAP Wireless Application Protocol Giao thức ứng dụng không dây

WAP

Gateway

Wireless Application Protocol

Gateway Proxy phục vụ cho kết nối không dây

WML Wireless Markup Language Ngôn ngữ đánh không dây

GIT GAIA Image Transcoder Bộ chuyển mã ảnh GAIA

v

Danh mục bảng

Bảng 2.1 So sánh một số hệ thống hỗ trợ Agent hiện có Error! Bookmark not

defined.

Bảng 4.1 Mô tả lớp HttpHeader ........................ Error! Bookmark not defined.

Bảng 4.2 Mô tả lớp HttpRequest ...................... Error! Bookmark not defined.

Bảng 4.3 Mô tả lớp HttpResponse .................... Error! Bookmark not defined.

Bảng 4.4 Các bộ lọc hỗ trợ trong hệ thống chuyển mã ảnh GAIA ........... Error!

Bookmark not defined.

vi

Danh mục hình vẽ, đồ thị

Hình 1.1. Nội dung tùy biến cho các thiết bị khác nhau. ................................. 14

Hình 1.2 Các thành phần của CC/PP profile .................................................... 18

Hình 1.3 Các thành phần của CC/PP profile trong XML ................................. 19

Hình 1.4 Ví dụ hoàn chỉnh về CC/PP profile ................................................... 20

Hình 1.5 Ví dụ hoàn chỉnh về CC/PP profile trong XML ................................ 21

Hình 1.6 CC/PP profile sử dụng các giá trị mặc định ...................................... 24

Hình 1.7 CC/PP profile trong XML sử dụng các giá trị mặc định ................... 25

Hình 1.8 Ghi đè một giá trị mặc định ............................................................... 26

Hình 1.9 Ghi đè một giá trị mặc định trong XML ............................................ 27

Hình 2.1 Kiến trúc hệ thống mạng có triển khai Proxy Server ................. Error!


Hình 2.2 Proxy Server cho nhiều máy khách với các dịch vụ khác nhau . Error!


Hình 2.3 Triển khai Proxy Server trong mạng cục bộ ..... Error! Bookmark not

defined.

Hình 2.4 Sử dụng Proxy Server để ẩn danh máy khách .. Error! Bookmark not

defined.

Hình 2.5 Kiến trúc hệ thống mạng dùng Dual Homed Host .. Error! Bookmark

not defined.

Hình 2.6 Kiến trúc HTTP Proxy Server ........... Error! Bookmark not defined.

Hình 2.7 Mô hình HTTP Proxy Server với chức năng đệm dữ liệu .......... Error!


Hình 2.8 Mô hình triển khai WAP Gateway .... Error! Bookmark not defined.

Hình 2.9 Trình tự thực hiện chuyển đổi tiêu đề gói tin WSP và HTTP .... Error!


Hình 2.10 Hệ thống tùy biến nội dung đáp ứng với khả năng thiết bị ...... Error!


Hình 3.1 Mô hình kiến trúc tổng thể hệ thống .. Error! Bookmark not defined.

Hình 4.2 Mô hình xử lý dữ liệu phía Client ..... Error! Bookmark not defined.

Hình 3.3 Mô hình xử lý dữ liệu phía Server ..... Error! Bookmark not defined.

Hình 3.4 Mô hình xử lý dữ liệu phía Proxy ...... Error! Bookmark not defined.

Hình 3.5 Biểu đồ của proxy chuyển mã cố định ............. Error! Bookmark not

defined.

Hình 4.6 Biểu đồ của proxy chuyển mã heuristic ............ Error! Bookmark not

defined.

Hình 3.7 Mô hình kiến trúc của Máy chủ Proxy sử dụng tác tử ............... Error!


vii

Hình 4.1 Kiến trúc tổng thể của mô hình thực nghiệm ... Error! Bookmark not

defined.

Hình 4.2 Sơ đồ các lớp xử lý giao thức HTTP . Error! Bookmark not defined.

Hình 4.3 Kiến trúc triển khai hệ thống ............. Error! Bookmark not defined.

Hình 4.4 Các thành phần và luồng xử lý chuyển tài liệu HTML về WML

........................................................................... Error! Bookmark not defined.

Hình 4.5 Hệ thống chuyển mã ảnh GAIA ........ Error! Bookmark not defined.

Hình 4.6 Sơ đồ lớp Profile ................................ Error! Bookmark not defined.

Hình 4.7 Ảnh gốc hiển thị trên trình duyệt của PC ......... Error! Bookmark not

defined.

Hình 4.8 Ảnh kết quả khi sử dụng hoặc không sử dụng APS Error! Bookmark

not defined.

Hình 4.9 Truy cập website không hỗ trợ WML Error! Bookmark not defined.

viii

Tóm tắt

Với sự phát triển của công nghệ truyền thông di động, người dùng có thể truy

cập vào Internet vào bất kỳ lúc nào và bất kỳ đâu. Các thiết bị di động này khác

nhau về khả năng tính toán, về kết nối mạng và kích thước màn hình. Cũng do

giới hạn về băng thông trong môi trường di động, các đối tượng web truyền thống

được sử dụng cho máy tính cá nhân sẽ không phù hợp cho các thiết bị di động.

Với nhu cầu truyền tải nội dung phù hợp cho thiết bị di động, tổ chức W3C đã

thành lập một nhóm làm về độc lập thiết bị. Tổ chức này đã định nghĩa thuật ngữ

“phân phối nội dung theo ngữ cảnh” (Delivery context). Phân phối nội dung theo

ngữ cảnh là một tập các thuộc tính mô tả khả năng của thiết bị truy cập và sở

thích của người dùng. Khả năng của thiết bị bao gồm nền tảng phần cứng và phần

mềm cho phép người dùng thiết bị tương tác với Web thông qua các phương tiện

tương tác (hình ảnh, âm thanh, bàn phím, giọng nói…). Máy chủ web, máy chủ

proxy, các ứng dụng thực hiện việc chuyển đổi nội dung phù hợp với thiết bị cần

phải hiểu được thông tin về khả năng của thiết bị.

Trong luận văn này, chúng tôi mô tả chi tiết ba phương pháp được sử dụng để

nhận dạng thiết bị. Với mục đích định hướng chuẩn hóa, luận văn tập trung vào

mô tả công nghệ CC/PP, công nghệ này cung cấp một phương thức chuẩn cho thiết

bị truyền khả năng thiết bị và sở thích người dùng. Mô tả thiết bị này được sử

dụng để cho các máy chủ web, máy chủ Proxy có thể tùy biến nội dung cho thiết

bị, phục vụ cho độc lập thiết bị.

Luận văn cũng đưa ra một cái nhìn tổng quan về công nghệ tác tử và máy chủ

Proxy, nghiên cứu và phân tích các điểm mạnh của hai công nghệ, tiến hành kết

hợp hai công nghệ để đề xuất một kiến trúc mô hình gọi là Agent Proxy Server

(APS) phục vụ cho việc đáp ứng nội dung Internet cho các loại thiết bị với những

khả năng và ưu tiên khác nhau.

Trong kiến trúc đề xuất, proxy có khả năng chuyển mã dữ liệu cho phù hợp

với ngữ cảnh. Kiến trúc đề xuất cũng cung cấp khả năng chuyển mã dữ liệu tùy ý

nhờ vào việc cho phép proxy có thể tải các mô đun phần mềm chuẩn từ Internet và

kết nối vào hệ thống như một plug-in. Cuối cùng, luận văn trình bày về mô hình

thực nghiệm, đưa ra một số kết quả đã đạt được, chỉ ra một số ưu và nhược điểm

của hệ thống, đồng thời đưa ra hướng phát triển tiếp theo cho hệ thống.

ix

Abstract

With the revolution of mobile communication technology, users can access the

Internet anywhere, anytime, with heterogeneous mobile devices, such as handheld

PCs, personal digital assistants (PDAs), and WAP-enabled cellular phones. These

devices are different from one another in their computing capability, network

connectivity and screen size.

Also, due to the limited bandwidth of mobile communication, the traditional

content of a web object for desktop computers might not be suitable for a mobile

device. Delivery context, as defined by the W3C Device Independence Working

Group, is a set of attributes that characterizes the capabilities of the access

mechanism and the preferences of the user. An access mechanism is a combination

of hardware (including one or more devices and network connections) and software

(including one or more user-agents) that allows a user to perceive and interact with

the Web using one or more interaction modalities (sight, sound, keyboard, voice etc.).

Web servers, Proxy Server, applications that adapt content for multiple access

mechanisms must be sensitive to delivery context.

This thesis explains three methods that web servers, proxy servers and

applications are using to recognize devices in detail. Especially, I focus on CC/PP

technology that provides a standard way for devices to transmit their capabilities and

user preferences. It was originally designed to be used when a device requests web

content via a browser so that servers and proxies can customize content to the target

device, i.e. support device independence.

This thesis also gives an overview of Agent technology and Proxy Server. This

thesis did research and analyzed strong points of two technologies and then combined

them together to propose the architecture. The proposed architecture is called Agent

Proxy Server (denoted by APS) that is used for Internet content adaptation. In this

architecture, the proxy can transform the corresponding data to the delivery context.

In addition, the proposed system architecture is designed to provide the capability

of supporting arbitrary type of data by utilizing the well-defined software modules in

which the new plug-in components can be automatically downloaded from the

Internet. Finally, this thesis shows some results that obtain from the practice,

advantages and disadvantages of the practice and the reality of the proposed

architecture.

10

MỞ ĐẦU

1. Đặt vấn đề

Ngày nay, ngành Công nghệ thông tin ngày càng phát triển, nhu cầu sử dụng

Internet ngày càng cao và đa dạng như các ứng dụng thương mại điện tử, tìm kiếm,

chia sẻ video, các ứng dụng thông minh… Người sử dụng có thể truy cập Internet qua

nhiều thiết bị khác nhau như các máy ti nh cá nhân cầm tay, thiết bị sô hô trợ ca nhân

(Personal Digital Assistants - PDAs) và điện thoại di động có hô trợ WAP [1].

Với sự phát triển đa dạng của Internet, các máy phục vụ (server) cần phải có khả

năng xử lý một khối lượng lớn thông tin yêu cầu từ các máy trạm (client) và có khả

năng chứa đựng các thông tin dùng cho tất cả các kiểu thiết bị máy trạm khác nhau.

Những thiết bị này khác nhau về khả năng tính toán, kết nối mạng, và kích thước màn

hình... Ngoài ra, vì băng thông giới hạn của truyền thông di động nên nội dung truyền

thống của một đối tượng web cho máy tính đê ba n không thể phù hợp với một thiết bị

di động. Vâ n đê đăt ra la la m thê na o đê thu đươc ca c kê t qua phu hợp với ca c “kha

năng” (capability) của mỗi loại thiết bị đó va “sở thi ch” (preference) cu a người dùng.

Việc xử lý các đối tượng web để thu được kết quả mong muốn được thực hiện ở

phía máy trạm hay máy phục vụ đều gặp phải những vấn đề đáng kể như giới hạn về

hiệu năng xử lý nếu xử lý tại máy trạm; quá tải khi có quá nhiều yêu cầu từ máy

trạm, không linh loạt với nhiều loại yêu cầu nếu xử lý tại máy phục vụ. Vì thế, mô

hình sử dụng Proxy như tâ ng trung gian đê “tiên xử ly” ca c nô i dung web trước khi tra

vê cho ca c thiêt bi được đề xuất và nghiên cứu nhiều hơn cả [3][5].

11

Giai pha p đâ u tiên đươc đưa ra la sử du ng proxy cố định (fixed proxy), chăng ha n

như với viê c chuyê n ma , proxy chuyển mã chỉ đơn thuần chuyển mã cho đầu vào thành

đầu ra mà không có bất kỳ quá trình xử lý liên quan đến ngữ cảnh nào. Một ví dụ cho

loại này là bộ chuyển đổi HTML-WML [6]. Các đặc trưng ưu việt của loại proxy

chuyển mã này là tính đơn giản trong cấu trúc và hiê u năng của hệ thống. Tuy nhiên,

hệ thống proxy chuyển mã này sẽ thiếu tính mềm dẻo và có thể không có khả năng hỗ

trợ những yêu cầu đa da ng từ nhiều kiểu thiết bị khác nhau.

Mô t gia i pha p kha c đươc đưa ra la một proxy xử ly mang tính kinh nghiệm

(heuristic proxy), chăng ha n như với viê c chuyê n ma , proxy chuyển mã có khả năng

đọc được hiện trạng về khả năng từ thiết bị kha ch và cố gắng biến đổi nội dung theo

khả năng của thiết bị [1][8]. Tuy nhiên, do proxy không có bất kỳ hiểu biết nào về việc

thông tin nào là quan trọng, nên nó khó khăn trong việc xác định chiến lược biến đổi

nội dung [9][10]. Hơn nữa, phương pháp giải quyết theo kinh nghiệm từ hệ thống

proxy chuyển mã có xu hướng đưa ra những kết quả không thể dự đoán trước.

Trong đề tài luận văn na y, chúng tôi đê xuâ t kiến trúc proxy đô ng sử dung ca c ta c

tử - Agent Proxy Server [4] - co kha năng xử ly thông tin đô ng, giu p giảm tải việc xử lý

tại các máy chủ và xử lý nhanh thông tin đô ng thời giu p “tiê n xử ly ” ca c kê t qua tra vê

từ ma y chu nhăm đưa ra ca c kê t qua phu hợp với kha năng và sở thích cu a ca c thiê t bi

kha c nhau.

Khả năng và sở thích của thiết bị được đặc tả bởi mô tả của thiết bị (device

profile). Trong kiến trúc đề xuất này, mô tả thiết bị được gửi theo yêu cầu (request) từ

phía máy trạm gửi qua proxy server đến máy phục vụ. Proxy server sẽ đón luồng trả

kết quả (response) sau khi xử lý yêu cầu về từ phía máy phục vụ. Tại proxy server, các

kết quả trả về này sẽ được xử lý dựa vào mô tả thiết bị đã được đón nhận và phân

tích trước đó. Quá trình xử lý này sẽ trả về kết quả phù hợp với thiết bị đã gửi yêu

cầu lên và được thực hiện bởi các tác tử phần mềm chuyên biệt được cài đặt sẵn

trong proxy server.

Kiến trúc đề xuất có thể thực hiện nhiều công việc khác nhau để mang lại kết quả

phù hợp với mô tả thiết bị. Khi cần xử lý một công việc chưa biết trước, proxy server

sẽ tự động tải các tác tử phần mềm phù hợp từ kho tác tử trên Internet.

2. Nội dung nghiên cứu

Trong thời gian thực hiện luận văn, chúng tôi đã nghiên cứu về mô hình tác tử

phần mềm tầng trung gian, xử lý dữ liệu tại tầng trung gian bao gồm:

12

Tìm hiểu các vấn đề lý thuyết về kiến trúc phần mềm, về các mô hình ứng

dụng trực tuyến.

Tìm hiểu các vấn đề về nhu cầu độc lập thiết bị trong thời đại phát triển công

nghệ mạng ngày nay, đồng thời nghiên cứu các kỹ thuật hỗ trợ nhận dạng thiết

bị, phục vụ cho mục đích cung cấp nội dung tùy biến với khả năng thiết bị và

mong muốn của người dùng.

Tìm hiểu công nghệ phần mềm hướng tác tử, tìm hiểu các framework đã và

đang được phát triển để hỗ trợ cho việc phát triển các ứng dụng hướng tác tử.

Tìm hiểu framework JADE trong việc phát triển ứng dụng hướng tác tử.

Nghiên cứu các vấn đề cơ sở hỗ trợ việc xử lý thông tin theo các thông tin về

khả năng của thiết bị, mà cụ thể là nghiên cứu chuẩn CC/PP, một chuẩn mô tả

khả năng của thiết bị phía client.

Đề xuất mô hình Agent Proxy Server hỗ trợ các ứng dụng trực tuyến trong việc

xử lý dữ liệu ở tầng trung gian.

Nghiên cứu và xây dựng hệ thống thực nghiệm chứng minh tính đúng đắn và

hữu ích của mô hình đề xuất.

3. Cấu trúc luận văn

Nội dung các phần còn lại của luận văn có cấu trúc chi tiết như sau:

Chương 2: Giới thiệu về vấn đề độc lập thiết bị và các kỹ thuật nhận dạng thiết bị

của W3C. Trong đó, đặc biệt chú trọng tới CC/PP (Composite Capabilities/Preferences

Profile), là một phương pháp chuẩn được cung cấp để mô tả các thiết bị về khả năng

của nó và sở thích của người dùng.

Chương 3: Trình bày các kiến thức nền tảng liên quan đến tác tử và máy chủ

proxy. Cụ thể, nội dung của chương giới thiệu về khái niệm của tác tử, các loại tác tử

và các ứng dụng của tác tử trong thực tế. Đồng thời chương này cũng đề cập đến

proxy server, các tính năng cơ bản của một proxy server và giới thiệu một số proxy

phổ biến.

Chương 4: Đề xuất mô hình Agent Proxy Server (Máy chủ Proxy sử dụng tác tử) là

một máy chủ trung gian giúp xử lý dữ liệu từ máy chủ ban đầu để cung cấp nội dung

theo đúng nhu cầu và khả năng của thiết bị phía máy khách. Trong đó proxy server đón

nhận kết quả trả về từ máy phục vụ, bóc tách thông tin rồi xử lý sao cho phù hợp với

13

mô tả thiết bị đã nhận rồi trả về cho máy trạm. Các công việc trên đều được thực hiện

bởi các tác tử chuyên biệt, nếu cần xử lý một công việc chưa biết, proxy server có thể

tự động tải các tác tử phần mềm phù hợp từ kho tác tử trên Internet.

Chương 5: Thiết kế, xây dựng và cài đặt hệ thống thực nghiệm dựa trên mô hình

đề xuất, khăng định tính hợp lý và khả thi của mô hình. Hệ thống thực nghiệm sử

dụng CC/PP để mô tả về thiết bị.

Chương 6: Đưa ra các kết luận, đánh giá những việc đã làm được và chưa làm

được trong quá trình thực hiện luận văn, và hướng nghiên cứu tiếp theo của đề tài.

14

NHẬN DẠNG THIẾT BỊ

Tổng quan về độc lập thiết bị

Với sự đa dạng hóa các thiết bị tính toán, nhu cầu về việc truyển tải nội dung phù

hợp nhất cho thiết bị đang ngày một gia tăng. Các thiết bị khác nhau yêu cầu những

định dạng nội dung khác nhau cho cùng một tài liệu. Trên thực tế, hầu hết các ứng

dụng Web hiện nay đều được các lập trình viên thiết kế phù hợp cho màn hình và

trình duyệt trên PC. Để có thể kiểm soát tốt nhất khả năng hiển thị của các ứng dụng

này trên trình duyệt của máy khách, các lập trình viên thường sử dụng cấu trúc bảng

và đặt vị trí của các đối tượng cố định tính theo đơn vị điểm ảnh (pixel) trên màn

hình. Việc thực hiện chuyển đổi các ứng dụng đó để hiển thị hiệu quả trên các thiết bị

khác nhau là một vấn đề rất phức tạp. Chính vì vậy, các lập trình viên chọn giải pháp

là sẽ tạo ra các ứng dụng khác nhau truyền tải cùng một nội dung nhưng theo những

định dạng khác nhau phù hợp cho từng thiết bị [10]. Hình 1.1 cho chúng ta biết việc

hiển thị cùng một nội dung trên các thiết bị khác nhau. Tuy nhiên, khi số lượng các

thiết bị truy cập Internet ngày càng đa dạng thì chi phí cho việc tạo và quản trị một

lượng lớn các ứng dụng kiểu này gặp phải vấn đề rất lớn về kinh tế.

15

Hình 0.1. Nội dung tùy biến cho các thiết bị khác nhau.

Bên cạnh việc truyền tải nội dung cho các thiết bị khác nhau là khác nhau, thì có

những tình huống, ngay một thiết bị cũng yêu cầu các dạng nội dung khác nhau của

cùng một tài liệu. Một ví dụ điển hình là khi một người dùng thiết bị di chuyển trong

ôtô, có thể họ muốn chuyển việc hiển thị nội dung băng dữ liệu văn bản thông thường

sang thành dạng âm thanh. Hoặc khi những người khuyết tật sử dụng thiết bị, họ cũng

yêu cầu các dạng nội dung với định dạng phù hợp nhất với họ.

Thông qua việc phân tích một số tình huống ở trên, chúng ta thấy thật sự cần thiết

của việc tạo ra các nội dung độc lập thiết bị. Độc lập thiết bị (Device Independence)

được định nghĩa là khả năng tạo ra các tài liệu và tùy biến các tài liệu đó phù hợp với

khả năng của các thiết bị yêu cầu.

Để thực hiện được ý tưởng độc lập thiết bị, tổ chức W3C đã thành lập các nhóm

nghiên cứu về độc lập thiết bị. Hiện tại, W3C có hai hoạt động chính về độc lập thiết

bị. Một nhóm nghiên cứu các phương pháp tạo ra nội dung, các phương pháp tùy biến

nội dung và hiển thị cho các thiết bị. Nhóm thứ hai hoạt động để tạo ra chuẩn CC/PP,

chuẩn mô tả khả năng thiết bị. CC/PP cung cấp một phương pháp chuẩn cho các thiết

bị truyền tải khả năng của nó và sở thích của người dùng. CC/PP được thiết kế để sử

dụng khi thiết bị yêu cầu nội dung từ máy chủ web thông qua trình duyệt. Dựa vào

16

CC/PP mà các máy chủ hoặc Proxy có thể biên tập lại nội dung được yêu cầu sao cho

phù hợp nhất với thiết bị.

Các kỹ thuật nhận dạng thiết bị

Trước khi CC/PP ra đời, các máy chủ web và các ứng dụng phán đoán khả

năng của thiết bị thông qua các thông tin của phần tiêu đề (header) trong gói tin

HTTP. Hai cách tiếp cận phổ biến được mô tả bên dưới bao gồm: User Agent

Request Header và Accept Request Header. Các cách tiếp cận này vẫn còn tồn tại

trên các thiết bị không hỗ trợ CC/PP.

User Agent Request Header

Khi các máy khách gửi một yêu cầu HTTP đến máy chủ web, các máy khách này

đưa ra thông tin về bản thân chúng thông qua thuộc tính user-agent trong phần header

của gói tin HTTP [12]. Chúng ta có một ví dụ như sau:

user-agent: Mozilla/4.04 (X11; I; SunOS 5.4 sun4m)

Thuộc tính user-agent đã được sử dụng để thực hiện việc phù hợp hóa nội dung

ngay từ những ngày đầu của World Wide Web. Ví dụ, khi thẻ frame trong html được

đưa ra. Chỉ có một số ít các trình duyệt hỗ trợ cho thẻ này. Các máy chủ web lúc đó sẽ

sử dụng thuộc tính user-agent để xác định xem có truyển tải nội dung được đặt trong

thẻ frame cho trình duyệt hay không. Tuy nhiên, hiện tại thì hầu hết các trình duyệt

đều hỗ trợ tất cả các phần tử html được đưa ra bởi W3C. Chúng ta có hai cách tiếp

cận để tạo ra nội dung phù hợp cho thiết bị dựa vào thuộc tính user-agent.

Cách tiếp cận thứ nhất là ứng dụng sẽ kiểm tra thuộc tính user-agent và tiến hành

lựa chọn nội dung phù hợp cho thiết bị. Với cách tiếp cận này thì các máy chủ phải

chứa rất nhiều phiên bản khác nhau của cùng một nội dung. Các phiên bản này sẽ

được dùng để ánh xạ đến các yêu cầu từ các thiết bị khác nhau. Nói một cách khác là

đã có một cơ chế ngầm định ánh xạ nội dung đã được phù hợp hóa (adapted) cho từng

máy khách cụ thể. Như vậy, khi máy khách là điện thoại Nokia thì máy chủ sẽ phải

lựa chọn một nội dung phù hợp, khi máy khách là PC thì máy chủ sẽ lựa chọn một nội

dung khác.

Cách tiếp cận thứ hai là chúng ta sẽ có một cơ sở dữ liệu về khả năng của thiết bị

tại máy chủ. Khi một máy khách yêu cầu nội dung từ máy chủ. Máy khách này sẽ gửi

cho máy chủ thông tin về nó thông qua user-agent. Thông tin này là thông tin để định

17

danh thiết bị. Phía server sẽ sử dụng định danh của thiết bị để truy vấn trong cơ sở dữ

liệu, tìm ra khả năng thiết bị và tiến hành các giải thuật chuyển đổi nội dung phù hợp

với khả năng của thiết bị. Các tiếp cận thứ hai là “động” hơn cách tiếp cận thứ nhất,

tuy nhiên nó vẫn phải sử dụng đến định danh của thiết bị thông qua user-agent. Cách

tiếp cận này cũng có một phần giống với cách tiếp cận CC/PP, tuy nhiên với CC/PP thì

máy chủ sẽ không phải định kỳ cập nhật lại cơ sở dữ liệu khả năng của các thiết bị

mới vì thông tin về CC/PP sẽ được gửi kèm theo yêu cầu của máy khách.

Một vấn đề khác gặp phải khi sử dụng cách tiếp cận này là user-agent chỉ ở dạng

văn bản, không theo một chuẩn hay một định dạng được định nghĩa trước nào cả,

trong khi đó mỗi nhà cung cấp trình duyệt lại đưa ra định dạng cho chuỗi dữ liệu user-

agent khác nhau, vì vậy rất khó để kiểm soát và xử lý nó.

Accept Request Header

Bên cạnh việc sử dụng User-Agent, HTTP 1.1 cung cấp thêm bốn trường trong

phần Header, phục vụ cho mục đích phù hợp hóa nội dung yêu cầu, và được gọi là các

trường đàm phán nội dung “content negociation”. Để phục vụ cho việc đàm phán nội

dung, các máy chủ phải tạo ra sẵn các dữ liệu phù hợp. Chúng sẽ phải lưu trữ ảnh của

một đối tượng ở nhiều dạng khác nhau, lưu trữ các tài liệu với nhiều bảng mã khác

nhau… Các trường này bao gồm [12]:

Accept: các loại tệp MIME đọc dược ở phía trên user-agent.

Accept-Charset: Các tập kí tự được phù hợp cho phía máy khách.

Accept-Encoding: Phương pháp mã hóa phù hợp cho phía máy khách.

Accept-Language: Ngôn ngữ mà phía máy khách có thể hiểu được.

Ví dụ:

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, Accept-Language:Fr Accept-Encoding: gzip, deflate

Để đưa thêm để đưa thêm thông tin cho các máy chủ dễ dàng xử lý hơn. Chúng ta

có thể đưa thêm một số tham số khác nữa. Chúng ta hãy xem thêm một ví dụ:

Accept-Language: Fr; q=1.0 , en; q=0.5

Với header như trên, user-agent muốn cho chúng ta biết là các tài liệu băng tiếng

pháp sẽ được ưa thích hơn là các tài liệu tiếng Anh. Về mặt lý thuyết, chúng ta có thể

hoàn toàn thực hiện được một số các chuyển đổi nội dung đơn giản dựa trên Accept

18

Request Header. Ví dụ là chúng ta có thể phân biệt được các thiết bị hỗ trợ HTML và

các thiết bị hỗ trợ WML. Tuy nhiên, một số lượng lớn các thiết bị không cung cấp đủ

và chính xác thông tin về Accept Request Header. Một số thiết bị truyền thông tin:

Accept: */*

Dòng Header này chỉ cho chúng ta biết là thiết bị có thể nhận bất kỳ tài liệu nào.

Điều này có thể tốt cho server, tốt cho nhà cung cấp nội dung; nhưng sẽ rất khó dưới

góc độ “đàm phán nội dung”.

Chúng ta có thể đưa thêm vào Header của gói tin HTTP các trường khác để phục

vụ cho mục đích phù hợp hóa nội dung. Các trình duyệt trên PC như Netscape hay các

trình duyệt trên các thiết bị như OpenWave, AvantGo, BlackBerry và PocketPC đều gửi

kèm các thông tin riêng của nó. Tuy nhiên, cách tiếp cận này không tuân theo một

chuẩn nào.

Đặc tả khả năng thiết bị Composite Capabilities/Preferences Profile

Các thiết bị di động khác nhau thường không giống nhau về phần cứng, phần

mềm, kết nối mạng, đầu vào/đầu ra và khả năng duyệt. Khả năng chuyển mã nội dung

theo năng lực thiết bị được gọi là quan tâm đến ngữ cảnh.

Năm 1999, W3C đã thành lập một nhóm làm việc về CC/PP (Composite Capabilities

/ Preferences Profile – Đặc tả khả năng, sở thích của thiết bị). Kết quả làm việc của

nhóm là đã cho ra đời một bộ khung dựa trên RDF cho việc quản lý thông tin cấu hình

thiết bị. CC/PP được mô tả trong các tài liệu: Tài liệu theo dõi các ý kiến đóng góp của

người dùng [15], Từ vựng và cấu trúc của CC/PP [13], cùng với ba tài liệu ghi chú của

W3C: Đặc tả yêu cầu và Kiến trúc CC/PP [14], CC/PP - thuật ngữ và các từ viết tắt và

giao thức trao đổi CC/PP sử dụng framework HTTP mở rộng.

CC/PP cung cấp một cơ chế chuẩn và một định dạng mô tả (Profile) để các Server

nhận biết được thông tin khả năng thiết bị băng cách thu thập Nhận dạng Profile và

các thông tin sở thích khác từ thiết bị cầm tay phía máy khách. Các máy chủ có thể

truy lục được chi tiết Profile của thiết bị từ một kho của nhà cung cấp thiết bị. Dựa trên

thông tin khả năng thiết bị nhận được, các máy chủ có thể phân phối nội dung phù hợp

tới các máy khách. CC/PP cải thiện cách máy chủ thu thập và duy trì thông tin về các

khả năng và sở thích của các máy khách.

Một mô tả CC/PP thường được xây dựng như một hệ phân cấp có hai mức:

19

Một bản mô tả (profile) có ít nhất một hoặc nhiều thành phần (components), và

Mỗi thành phần có ít nhất một hoặc nhiều thuộc tính (attributes).

Các thành phần của Profile

Các nhánh đầu của cây CC/PP profile mô tả các thành phần chính của máy khách.

Ví dụ về các thành phần chính là:

Nền tảng phần cứng mà phần mềm thực thi trên đó,

Nền tảng phần mềm mà các chương trình ứng dụng được cài đặt trên đó (Hệ

điều hành…), hoặc

Một ứng dụng riêng, ví dụ như trình duyệt (browser).

Một cách đơn giản, biểu diễn đồ họa phía gốc của một cây CC/PP dựa trên ba

thành phần (TerminalHardware, TerminalSoftware và TerminalBrowser) sẽ được biểu

diễn như trong hình dưới:

Hình 0.2 Các thành phần của CC/PP profile

Mã XML tương ứng có thể có nội dung như sau:

<?xml version="1.0"?>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:ccpp="http://www.w3.org/2006/09/20-ccpp-schema#"

xmlns:example="http://www.example.com/schema#">

<rdf:Description rdf:about="http://www.example.com/profile#MyProfile">

<rdf:type rdf:resource="http://www.w3.org/2006/09/20-ccpp-schema#Client-profile"/>

<ccpp:component>

<rdf:Description

rdf:about="http://www.example.com/profile#TerminalHardware">



</rdf:Description>

20

</ccpp:component>

<ccpp:component>

<rdf:Description

rdf:about="http://www.example.com/profile#TerminalSoftware">



</rdf:Description>

</ccpp:component>

<ccpp:component>

<rdf:Description

rdf:about="http://www.example.com/profile#TerminalBrowser">



</rdf:Description>

</ccpp:component>

</rdf:Description>

</rdf:RDF>

Hình 0.3 Các thành phần của CC/PP profile trong XML

Lưu ý: RDF/XML [19] chấp nhận các cú pháp khác nhau nhưng phải tương đồng

về ngữ nghĩa, được sử dụng trong CC/PP 2.0 profiles phù hợp.

Các thuôc tính của thành phần

Một hồ sơ CC/PP mô tả khả năng và sở thích của máy khách dưới dạng một số

“thuộc tính CC/PP” cho mỗi thành phần.

Mô tả của mỗi thành phần là một cây con mà các nhánh của nó có các khả năng

hoặc sở thích liên kết với thành phần đó. Mặc dù RDF có thể mô hình hóa được rất

nhiều các cấu trúc dữ liệu, bao gồm cả đồ thị tùy ý (arbitrary graphs), tuy nhiên các cấu

trúc dữ liệu phức tạp thường không được sử dụng để mô tả giá trị cho các thuộc tính

của mô tả. Một khả năng thường có thể được mô tả băng cách sử dụng một hoặc một

số ít các thuộc tính của CC/PP, mỗi thuộc tính có một giá trị đơn giản (dữ liệu nguyên

tử). Trong trường hợp đòi hỏi các giá trị phức tạp hơn, các thuộc tính này có thể được

xây dựng như là một đồ thị con của RDF. Chúng ta cũng có thể mô tả các thuộc tính

phức tạp băng cách biểu diễn nó băng các giá trị thay thế (alternative values), ví dụ:

một trình duyệt có thể hỗ trợ nhiều phiên bản của mã HTML. Một profile đặc trưng có

thể biểu diễn như sau:

21

Hình 0.4 Ví dụ hoàn chỉnh về CC/PP profile


<?xml version="1.0"?>



xmlns:ex="http://www.example.com/schema#">

<rdf:Description

rdf:about="http://www.example.com/profile#MyProfile">

<rdf:type rdf:resource="http://www.w3.org/2006/09/20-ccpp-schema#Client-profile" />

22

<ccpp:component>

<rdf:Description


<rdf:type

rdf:resource="http://www.example.com/schema#HardwarePlatform" />

<ex:displayWidth>320</ex:displayWidth>

<ex:displayHeight>200</ex:displayHeight>

</rdf:Description>

</ccpp:component>

<ccpp:component>

<rdf:Description


<rdf:type

rdf:resource="http://www.example.com/schema#SoftwarePlatform" />

<ex:name>EPOC</ex:name>

<ex:version>2.0</ex:version>

<ex:vendor>Symbian</ex:vendor>

</rdf:Description>

</ccpp:component>

<ccpp:component>

<rdf:Description


<rdf:type

rdf:resource="http://www.example.com/schema#BrowserUA" />

<ex:name>Mozilla</ex:name>



<ex:htmlVersionsSupported>

<rdf:Bag>

<rdf:li>3.2</rdf:li>

<rdf:li>4.0</rdf:li>

</rdf:Bag>

</ex:htmlVersionsSupported>

</rdf:Description>

</ccpp:component>

</rdf:Description>

</rdf:RDF>

Hình 0.5 Ví dụ hoàn chỉnh về CC/PP profile trong XML

Các giá trị mặc định

Các thuộc tính của một thành phần có thể chứa giá trị trực tiếp hoặc giá trị có thể

được xác định bởi tham chiếu đến một profile mặc định, thông qua việc sử dụng địa

chỉ URI xác định profile mặc định đó.

23

Cách sử dụng một profile mặc định được xác định bên ngoài có phần tương tự với

những ý tưởng thừa kế động. Điều này thực hiện được một số tối ưu hóa quan trọng.

Vì nó là một tài liệu riêng biệt, nó có thể năm ở một vị trí riêng biệt và có thể được

lưu trữ (cached) riêng rẽ. Điều này đặc biệt hữu ích trong các môi trường không dây,

chăng hạn như các mạng di động, ở đó các mô tả của thiết bị có thể có dung lượng

lớn, trong khi các kết nối mạng khách hàng rất chậm chạp và tốn kém. Khi sử dụng giá

trị mặc định, chỉ một phần nhỏ các giá trị thuộc tính của mô tả được gửi qua mạng.

Các giá trị mặc định cho một thành phần của một Hồ sơ CC/PP được chỉ định bởi

một thuộc tính ccpp:defaults.

Hình dưới cho ta một cái nhìn tổng quan về việc sử dụng về việc sử dụng giá trị

mặc định trong mô tả CC/PP của thiết bị ở dạng cây phân cấp, cũng như mã XML.

24

25

Hình 0.6 CC/PP profile sử dụng các giá trị mặc định


Device profile referencing defaults: <?xml version="1.0"?>




<rdf:Description



<ccpp:component>

<rdf:Description


<rdf:type


<ccpp:defaults

rdf:resource="http://www.example.com/hardwareProfile#HWDefault" />

</rdf:Description>

</ccpp:component>

<ccpp:component>

<rdf:Description


<rdf:type


<ccpp:defaults

rdf:resource="http://www.example.com/softwareProfile#SWDefault" />

</rdf:Description>

</ccpp:component>

<ccpp:component>

<rdf:Description


<rdf:type


<ccpp:defaults

rdf:resource="http://www.example.com/terminalProfile#UADefault" />

</rdf:Description>

</ccpp:component>

</rdf:Description>

</rdf:RDF>

26

Defaults for HardwarePlatform: <?xml version="1.0"?>



<rdf:Description

rdf:about="http://www.example.com/hardwareProfile#HWDefault">

<rdf:type




</rdf:Description>

</rdf:RDF>

Defaults for SoftwarePlatform: <?xml version="1.0"?>



<rdf:Description

rdf:about="http://www.example.com/softwareProfile#SWDefault">

<rdf:type


<ex:name>EPOC</ex:name>



</rdf:Description>

</rdf:RDF>

Defaults for BrowserUA: <?xml version="1.0"?>



<rdf:Description

rdf:about="http://www.example.com/terminalProfile#UADefault">

<rdf:type


<ex:name>Mozilla</ex:name>



<ex:htmlVersionsSupported>

<rdf:Bag>

<rdf:_1>3.2</rdf:_1>

<rdf:_2>4.0</rdf:_2>

</rdf:Bag>

</ex:htmlVersionsSupported>

</rdf:Description>

</rdf:RDF>

Hình 0.7 CC/PP profile trong XML sử dụng các giá trị mặc định

27

Nếu một giá trị thuộc tính được áp dụng trực tiếp đến một thành phần tài nguyên

(component resource), và cũng xuất hiện trên một tài nguyên được tham chiếu bởi

thuộc tính ccpp:defaults, giá trị áp dụng trực tiếp sẽ chiếm ưu tiên:

Hình 0.8 Ghi đè một giá trị mặc định

Trong ví dụ này, thành phần mặc định biểu thị bộ nhớ 16 Mb, nhưng giá trị này bị

ghi đè bởi thuộc tính memoryMb được áp dụng trực tiếp cho thành phần của profile. Do

đó, trong profile này, thuộc tính memoryMb có giá trị là 32.


Device profile referencing defaults: <?xml version="1.0"?>




<rdf:Description



28

<ccpp:component>

<rdf:Description


<rdf:type


<ccpp:defaults

rdf:resource="http://www.example.com/hardwareProfile#HWDefault" />

<ex:memoryMb>32</ex:memoryMb>

</rdf:Description>

</ccpp:component>

</rdf:Description>

</rdf:RDF>

Defaults for HardwarePlatform: <?xml version="1.0"?>



<rdf:Description

rdf:about="http://www.example.com/hardwareProfile#HWDefault">

<rdf:type




<ex:memoryMb>16</ex:memoryMb>

</rdf:Description>

</rdf:RDF>

Hình 0.9 Ghi đè một giá trị mặc định trong XML

Khả năng mở rông và không gian tên

CC/PP được mở rộng chủ yếu là thông qua việc giới thiệu các từ vựng

(vocabularies) thuộc tính mới.

Bất cứ ứng dụng hoặc môi trường hoạt động nào sử dụng CC/PP đều có thể định

nghĩa vốn từ vựng riêng của mình. Nếu các từ vựng được định nghĩa là có thể được

sử dụng nhiều hơn thông thường thì khả năng tương tác sẽ được nâng cao, ví dụ:

mở rộng vốn từ vựng tiêu chuẩn cho các thiết bị chuyên về hình ảnh, hoặc thiết bị tin

nhắn băng giọng nói, hoặc các thiết bị truy cập không dây, v.v. Theo đó, đặc tả này

định nghĩa một số từ vựng cốt lõi của các tính năng được áp dụng nhiều, như áp dụng

cho tác nhân in ấn và hiển thị. Từ vựng cốt lõi này được dựa trên đặc tả IETF

specification RFC2534 [20], và phục vụ như một ví dụ về cách các từ vựng thuộc tính

CC/PP có thể được định nghĩa. Một ví dụ khác là đặc tả UAProf 2.0 của OMA [21].

29

Một hồ sơ CC/PP bất kỳ có thể sử dụng các điều khoản trích ra từ một số tùy ý

các từ vựng khác nhau, do đó, việc tái sử dụng không hạn chế các điều khoản từ một

vốn từ vựng hiện có sẽ hữu ích hơn là định nghĩa các tên mới để nhận biết cùng một

thông tin. Mỗi từ vựng được liên kết với một không gian tên XML, như là các tên mô

tả cho các cấu trúc RDF và CC/PP cơ bản.

Các không gian tên XML[22] định nghĩa một ký hiệu cho các mẫu tên liên kết

thuận tiện với các arbitrary URIs [23]. Những cú pháp biểu đồ RDF không sử dụng

đặc biệt các không gian tên, nhưng XML serializations của một đồ thị RDF thì lại thực

hiện điều đó. W3C cũng sử dụng các tiền tố không gian tên khi trình bày RDF trong ký

hiệu đồ thị được mô tả ở trên.

Mặc dù các tên của không gian tên được xác định bởi các tham chiếu URI, nhưng

không bắt buộc phải có sẵn một giản đồ (schema) tại URI đó, dù trong thực tế, thường

mong muốn răng một schema tương ứng tồn tại ở địa chỉ URI được sử dụng để xác

định một không gian tên.

Các giao thức truyền CC/PP

Hiện tại có ba giao thức được xây dựng để truyền CC/PP, bao gồm: CC/PP-ex, W-

HTTP và WSP. Cả ba giao thức đều có những đặc điểm chung. Chúng đều gửi thông

tin về CC/PP dưới hai dạng: tham chiếu đến mô tả (reference profiles) hoặc đính kèm

mô tả (profile diffs). Việc truyền CC/PP dưới dạng tham chiếu thì máy khách sẽ gửi

cho máy chủ một địa chỉ (URI) của tài liệu CC/PP. Máy chủ sẽ sử dụng URI để truy

vấn đến mô tả của thiết bị. Việc truyền CC/PP dưới dạng đính kèm thì máy khách sẽ

gửi một đoạn dữ liệu XML mô tả khả năng thiết bị kèm với yêu cầu dịch vụ. Đoạn dữ

liệu XML này có thể năm trong hoặc ngoài tiêu đề của gói tin tùy theo từng giao thức.

Kết chương

Các nhà sản xuất thiết bị, người dùng thiết bị và các nhà cung cấp nội dung có

những nhu cầu và mong đợi khác nhau khi tiếp cận với các nội dung thông tin trên

Web. Các nhà sản xuất luôn cố gắng tạo ra sự khác biệt giữa các sản phẩm của họ với

thị trường băng cách đưa thêm rất nhiều khả năng và sự hỗ trợ cho thiết bị của họ, tuy

nhiên có rất ít nhà cung cấp nội dung tạo ra các nội dung phục vụ cho những khả năng

và hỗ trợ đó một cách độc lập. Người sử dụng muốn truy cập cùng một nội dung từ

nhiều thiết bị. Khi khả năng của thiết bị khác nhau, người dùng mong muốn truy cập

30

được nội dung đã được tùy biến cho phù hợp với khả năng của thiết bị. Độc lập thiết

bị là một hướng nghiên cứu và cũng có thể coi là công nghệ để thực hiện được công

việc đó. Độc lập thiết bị giúp cho các nhà sản xuất nội dung truyền tải được nội dung

phù hợp nhất cho người dùng thông qua việc mô tả khả năng của thiết bị.

Trong chương này, chúng tôi đã trình bày về nhu cầu của độc lập thiết bị, và các

phương pháp, kỹ thuật nhận dạng thiết bị. Và chúng ta cũng đã đi tìm hiểu sâu về

chuẩn CC/PP, chuẩn mô tả khả năng thiết bị. CC/PP hiện tại đang được rất nhiều các

hãng sản xuất phần cứng và phần mềm lớn quan tâm và cũng xây dựng. CC/PP sẽ là

yêu tố quan trọng hàng đầu trong việc thực hiện độc lập thiết bị.

31

TÁC TỬ PHẦN MỀM VÀ MÁY CHỦ PROXY

Tổng quan

Công nghệ hướng tác tử là một trong những hướng nghiên cứu thu hút nhiều sự

quan tâm nhất từ những năm 90 đến nay với những đặc điểm rất thích hợp cho việc

phát triển các ứng dụng phân tán. Chương này của luận văn điểm lại những khái niệm

cơ bản về tác tử phần mềm đồng thời đề cập đến những loại ứng dụng phù hợp với

mô hình tác tử đã và đang được nghiên cứu và phát triển trên thế giới. Luận văn cũng

tiến hành xem xét và đánh giá các framework hỗ trợ phát triển ứng dụng dựa trên tác

tử.

Với sự phát triển của các kiến trúc mạng sử dụng Proxy Server, nhu cầu tích hợp

các dịch vụ và chức năng cho Proxy Server cũng ngày một tăng cao, đặc biệt là trong

môi trường di động. Trong chương này, chúng tôi cũng đưa ra khái niệm về Proxy

Server, phân tích một số nhu cầu cần thiết phải sử dụng Proxy Server, đồng thời cũng

phân tích chi tiết hai loại Proxy Server được sử dụng phổ biến hiện nay bao gồm:

HTTP Proxy Server và WAP Gateway.

Tác tử phần mềm (Software Agent)

Khái niệm

Sẽ thật không dễ dàng khi đi tìm một khái niệm chính xác cho tác tử (Agent), bởi

nó là một khái niệm vô cùng rộng lớn, bao hàm nhiều vấn đề.

32

Để có thể hiểu rõ hơn về tác tử, ở đây ta nên thu hẹp phạm vi của tác tử, đó là tác

tử phần mềm: “Đó là một thực thể phần mềm, hoạt động theo sự uỷ quyền của các tác

tử khác, của người điều khiển, hỗ trợ con người và tác động đến những hành vi của

họ. Nó có khả nǎng tự động, thực hiện tiên đoán, phản ứng và một số khả nǎng như

tự học, tự di chuyển, hoạt động theo kiểu cộng tác”. Ta có thể coi đây là một mô hình

tác tử cơ sở [4].

Thuâ t ngữ Agent la môt thuâ t ngữ trừu tượng trong công nghê phân mê m, đo la

môt y tưởng, mô t kha i niê m, mô t thuâ t ngữ như kiê u OOP (Object – Oriented

Programming: Lâ p tri nh hướng đôi tượng) bao gô m phương thức (methods), ha m

(functions) va đô i tượng (Objects). Đi nh nghi a vê Agent cho ta mô t ca ch nhi n nhâ n

thuâ n tiên va ma nh me vê thực thê phâ n mê m phức ta p với đây đu ca c ứng xử với hê

thô ng. Nê u như ca c đôi tượng đươc đăc trưng băng ca c phương thức va thuô c ti nh thi

Agent la i đươc đăc trưng băng ca c cư xử cua no với môi trường.

Có 2 lớp Agent chính: tĩnh (static) và di động (mobile). Sự khác nhau giữa hai lớp

này là:

Tác tử tĩnh (Static agent): thực thi trên hệ thống nơi nó bắt đầu sự thực thi

[4][9]. Một static agent thu được các thông tin từ hệ thống khác băng cách sử

dụng các cơ chế truyền thông có sẵn như Remote procedure call (RPC-gọi thủ

tục từ xa). Điều này khác với một quy trình tĩnh (static processes) trong một hệ

thống mà trong đó mã của static agent được tải về từ mạng theo yêu cầu, ngược

lại các quy trình tĩnh có mã riêng được lưu trữ cục bộ trong hệ thống.

Tác tử di động (Mobile agent): có thể ngừng hoạt động của nó trong khi nó

đang chạy trên một hệ thống, có thể di chuyển sang một hệ thống khác, và có

thể tiếp tục thực thi từ điểm ngưng.

Agent co những đăc trưng quan tro ng la : ti nh tự chu, ti nh pha n xa , ti nh chu đông va

tinh cô ng đô ng.

Các loại Agent

Ca c loa i Agent đươc phân chia băng đăc trưng cu a no va co thê chia la m ca c loa i

Agent sau.

33

Tác tử thông minh (Intelligent Agents)

Ca c nghiên cứa vê Agent thông minh la môt phâ n trong ca c nghiên cứu vê Agent

nhân ta o. Ca c kha năng cu a môt Agent thông minh như sau:

Kha năng bắt chước: đo la kha năng ca m nhâ n môi trường xung quanh va ho c

theo. Kha năng na y cu a ca c Agent thông minh co thê đươc xây dựng trên ca c tâ p

ca c phương thức gia i quyê t vâ n đê hay ca c gia i thuâ t. No co thê bao gô m ca c

khia ca nh kha c cu a Agent như kha năng phu c hô i ca c xử ly hay kha năng lưu trữ

ca c ta i nguyên

Kha năng ho c: đo la kha năng ca m vê ca c ứng xử va kha năng tự sa n sinh ra ca c

cư xử kha c từ cư xử đa co cua đô i tượng.

Từ kha i niê m trên người ta co n quan tâm đê n kha i niê m Intelligent Interface Agent,

đo la kha i niê m vê ti nh ta c tử trong giao diê n cu a người du ng, la kha năng tâ n du ng tô i

đa kha năng cu a ca c giao diê n với người sử dung, điê u na y la m na y sinh mô t sô câu ho i

liên quan đê n vâ n đê na y như la : vâ n đê na o trong giao tiê p cu a người sử dung câ n

đươc quan tâm nhâ t? Ca c giao tiê p cu a người sử dung tham chiê u đê n ca c vâ n đê na o?

Tác tử tư chu (Autonomous Agent)

Agent tự chu la ca c Agent co kha năng tự tô n ta i đô c lâ p, co kha năng ra quyê t đinh

đôc lâ p, kha năng thực hiê n ca c ha nh đô ng tho a ma n mu c tiêu cu a chi nh no theo những

ca m nhâ n đươc từ môi trường. Tât ca ca c phâ n mê m agent đêu đươc con người xây

dựng nhăm mu c tiêu gia m sa t ca c ha nh đô ng va hoa n thiê n kha năng ứng xử cua no ,

đông thời cu ng co kha năng cho no dừng ha nh đô ng trong trường hợp câ n thiê t.

Agent phân tán (Distributed agents)

Đây la ca c Agent co kha năng hoa t đô ng trong nhiê u môi trường xử ly kha c nhau,

co kha năng chia se tinh toa n, co kha năng đươc triê n khai trong hê thô ng phân phô i va

tự linh đô ng.

Tác tử di đông (Mobile Agents)

Tác tử di động la môt thực thê phân mê m tô n ta i trong môi trường phâ n mê m. No

thừa hưởng mô t sô đăc ti nh cu a mô t tác tử. Mô t Tác tử di động bao gô m ca c mô hình

sau: mô hình tác tử (agent model), mô hình vòng đời (life-cycle model), mô hình tính

34

toán (computational model), mô hình bảo mật (security model), mô hình truyền thông

(communication model) va mô hình điều hướng (navigation model). Trong đi nh nghi a

vê tác tử di động, chu ng ta câ n quan tâm đê n môi trường phâ n mê m ma tác tử di động

đo tôn tai.

Môi trường tác tử di động đươc đi nh nghi a la môt hê thô ng phâ n mê m đươc phân

phô i trong mô t ma ng ma y tinh. Trong môi trường đo , tác tử di dộng đươc triê n khai với

đây đu ca c thuô c ti nh cu a no. No co thê bao gô m ca c chương tri nh tương thi ch, ca c cơ

chê truy nhâ p, lưu trữ ta i nguyên.

Khả năng ứng dụng của tác tử

Các tác tử phần mềm (Software agents) được sử dụng trong nhiều lĩnh vực khác

nhau trong viễn thông. La Porta [17] đề cao tính năng của hai dịch vụ truyền thông điệp

hai chiều và các dịch vụ truyền thông cá nhân (Personal Communication services (PCS))

băng cách tận dụng các tác tử tĩnh (static agents) và các tác tử di động (mobile agents)

theo thứ tự định sẵn.

Băng cách sử dụng một static agent như một cổng vào ra (gateway) giữa các

trang nhớ (pager), kiến trúc của các pager có thể vẫn đơn giản trong khi thu

được các khả năng truyền thông điệp song công đầy đủ (full-duplex).

Các mobile agents được sử dụng trong các hệ thống PCS (hệ thống dịch vụ

truyền thông cá nhân) để duy trì trạng thái của người dùng hiện tại, như thiết bị

của người dùng và hiện trạng dịch vụ của nó. Khi một người dùng cuối chuyển

từ một cell đến một cell khác, vì agent là di động nên nó có thể tự động theo

người dùng đến cell mới và vẫn duy trì được trạng thái của người dùng.

Các agents cũng được sử dụng trong việc quản trị mạng. Phương thức này làm

giảm không những lưu lượng mạng, mà còn giảm tải điện toán trên hệ thống quản lý,

vì các tính toán cần thiết được phân phối giữa các phần tử mạng. Phương thức thứ

hai là việc sử dụng các mobile agent, trong đó hệ thống quản trị gửi một mobile agent

đến mỗi phần tử mạng, khi trở về hệ thống quản trị, mobile agent sẽ báo cáo kết quả.

Như có thể thấy từ những ví dụ trên, software agents, ở cả hai dạng là tĩnh và di

động, có thể được sử dụng thành công trong các lĩnh vực viễn thông khác nhau. Do đó,

35

hoàn toàn có khả năng kết nối các tính năng proxy với các tác tử phần mềm (software

agents)

Trên thực tế, tác tử và các hệ tác tử còn có khả năng ứng dụng thành công trong

rất nhiều lĩnh vực khác nhau. Vác ứng dụng này rất phong phú về cả số lượng, chất

lượng cũng như rất đa dạng về chủng loại: Từ các hoạt động quản lý sản xuất đến

việc xử lý thông tin, sự xuất hiện của tác tử và các hệ tác tử đã làm cho việc quản lý,

xử lý thông tin dễ dàng hơn, và đạt được nhiều kết quả khả quan hơn. Dưới đây

chúng ta sẽ xem xét những ứng dụng tiêu biểu thể hiện sự ưu điểm của giái pháp sử

dụng tác tử cho những miền ứng dụng khác nhau.

Ứng dụng trong quản lý sản xuất

Quá trình sản xuất được đặc trưng bởi nhiều tham số thay đổi như dạng và số

lượng sản phẩm, giới hạn thời gian, khả năng của máy móc… thể hiện công việc thực

tế và các điều kiện thực tế của xưởng sản xuất. Để đồng bộ và quản lý quá trình

phức tạp như vậy, hệ thống quản lý được xây dựng dưới dạng một hệ các tác tử cộng

tác. Mỗi xưởng và mỗi thành phần của xưởng được biểu diễn bởi một tác tử. Từng

tác tử có kế hoạch và khả năng của mình tương ứng với kế hoạch và khả năng của

từng thành phần riêng biệt trong phân xưởng. Các tác tử tương tác với nhau giống

như mối quan hệ giữa các cá thể trong phân xưởng, do đó phản ánh được thực tế hoạt

động của các cá thể trong xưởng sản xuất. Từ các tác tử mức trên, công việc được

phân chia xuống các tác tử mức dưới và xuống tới từng vị trí công việc tùy thuộc vào

khả năng. Kết quả thực hiện được báo cáo lại cho tác tử mức trên để theo dõi và điều

chỉnh phù hợp. Điều này diễn ra giống như mô hình quản lý thực tế của các xưởng

sản xuất, do đó từ mô hình này ta có thể xem xét, dự đoán hoạt động sản xuất của

xưởng. Ngoài ra, công nghệ tác tử còn được sử dụng trong việc lập kế hoạch sản

xuất, hỗ trợ thiết kế sản phẩm, quản lý robot trong công nghiệp.

Ứng dụng trong quản lý luồng công việc

Nhiệm vụ của hệ thống quản lý quá trình và luồng công việc là đảm bảo các phần

việc khác nhau của một quá trình được thực hiện bởi các nhân viên và bộ phận thích

hợp vào thời gian cần thiết. Trong giải pháp sử dụng tác tử, mỗi nhân viên hay một bộ

phận trong quá trình làm việc tương ứng với một tác tử, các tác tử sẽ thương lượng

với nhau về các điều kiện, khả năng, yêu cầu của chúng, phản ứng với môi trường để

36

hoàn thành công việc của mình. Từ đó xây dựng được một hệ thống quản lý luồng

công việc thích hợp nhất, tối ưu nhất để áp dụng trong thực tế.

Tác tử thu thập và quản lý thông tin

Do lượng thông tin dư thừa trên Internet là rất lớn và ngày càng tăng lên, nên

người sử dụng thông tin gặp khó khăn trong hai vấn đề sau:

Vấn đề lọc thông tin: Hàng ngày người sử dụng nhận được một lượng thông

tin lớn từ Internet dưới dạng các tin nhắn, email, các báo điện tử. Trong đó chỉ

có một phần nhỏ các thông tin là có giá trị và cần được quan tâm, còn lại phần

lớn trong số đó là những thông tin thừa, vô giá trị và đôi khi còn là những thông

tin gây “nhiễu”. Việc xác định xem đâu là những thông tin có giá trị, cần được

quan tâm mất rất nhiều thời gian và công sức, đôi khi lại đưa ra những kết quả

không như ý muốn.

Vấn đề thu thập thông tin: Mặc dù mạng Internet chứa một lượng thông tin

khổng lồ nhưng không phải lúc nào chúng ta cũng có thể tìm được những

thông tin mà chúng ta mong muốn. Khi có nhu cầu về thông tin cụ thể, người sử

dụng khó tìm thấy thông tin mà họ quan tâm do lượng thông tin trên mạng là

quá lớn.

Tác tử thông tin là loại tác tử được xây dựng để giải quyết hai vấn đề trên. Một

ví dụ điển hình là hệ thống Tác tử quản lý hộp thư cá nhân, chứa các tác tử có nhiệm

vụ lọc và phân loại thư điện tử. Tác tử này có khả năng thực hiện các thao tác gán giá

trị ưu tiên, xóa, chuyển tiếp thư, sắp xếp và lưu trữ thư điện tử. Trong giai đoạn đầu,

tác tử ghi lại hành động của người sử dụng và thông tin về thư như người gửi, người

nhận, tiêu đề thư và từ khóa. Những thông tin này sau đó được sử dụng để dự đoán

hành động khi có thư mới tới. Nếu hành động được dự đoán với độ chính xác cao thì

tác tử sẽ gợi ý cho người sự dụng hoặc tự động thi hành luôn.

Tác tử giao diện

Thông thường trong tương tác giữa người và máy tính, giao diện đóng vai trò thụ

động và chỉ phản xạ khi có yêu cầu từ người dùng. Một chương trình chỉ thực hiện

khi người sử dụng gõ một lệnh, chọn một mục, hay nhấp chuột vào menu tương ứng.

Tác tử giao diện cho phép thay đổi phương pháp giao tiếp này băng cách làm cho máy

37

tính trở nên chủ động. Căn cứ vào hành động của người sử dụng, tác tử giao diện có

thể chủ động thực hiện một số thao tác hay đưa ra những gợi ý.

Ứng dụng tác tử và trí tuệ phân tán

Trong tự động hóa công nghiệp cũng như trong nhiều lĩnh vực ứng dụng điều

khiển và giám sát khác như các hệ thống giao thông vận tải, các hệ thống phân phối

năng lượng và các hệ thống viễn thông, xu hướng điều khiển phân tán đã trở thành tất

yếu. Các hệ thống cần được điều khiển ngày càng có qui mô lớn và mức độ phức tạp

hơn, rất nhiều hệ thống thể hiện tính bất định và mô hình thay đổi, đòi hỏi phải có sự

phân chia thành các hệ thống con để có thể dễ làm chủ. Các hệ thống con này có một

nhiệm vụ riêng và phải có sự hợp tác với nhau trong việc giải quyết nhiệm vụ chung

của toàn hệ thống. Vì thế, kiến trúc phần mềm điều khiển và giám sát trong hệ thống

cũng phải có tính chất như vậy, có nghĩa là phải được phân tán thành các thành phần

mềm tương đối độc lập nhưng có khả năng hợp tác cho một mục đích chung của hệ

thống. Thêm vào đó, các phần mềm này phải có khả năng thay thế con người trong

điều khiển hệ thống với các thông số luôn biến động. Yêu cầu đó dẫn đến phải xây

dựng được một phần mềm có tính tự động điều khiển, thích nghi với sự biến động

của môi trường hoạt động, và có khả năng tương tác với nhau. Việc ứng dụng trí tuệ

nhân tạo phân tán là một trong những hướng nghiên cứu mới, hứa hẹn nhiều kết quả

khả quan. Trong nhiều năm gần đây, tác tử (agent) và đa tác tử (multi-agent) được coi

là các công nghệ trọng tâm của trí tuệ nhân tạo phân tán, thu hút được sự quan tâm

của đông đảo giới nghiên cứu trong lĩnh vực công nghệ thông tin. Việc ứng dụng công

nghệ tác tử vào các hệ thống trí tuệ nhân tạo đã thu được nhiều kết quả to lớn.

Đánh giá một số Framework hỗ trợ Agents

Các hệ thống được lựa chọn để khảo sát ở đây bao gồm Aglets, Voyager, Mole,

Zeus và JADE. Cả năm môi trường này đều sử dụng Java để hỗ trợ phát triển ứng

dụng, nhưng mỗi hệ thống có những đặc thù riêng. Trong phần này, luận văn đưa ra

đánh giá tổng quan về Aglets, Voyager, Mole và Zeus dựa trên những tìm hiểu sơ bộ

về chúng. Phần giới thiệu về JADE sẽ được trình bày ở chương 5.

38

Aglets

Aglets được xây dựng và phát triển bởi D.B.Lange và IBM Tokyo Research

Laboratory. Hiện nay, bộ Aglets Software Development Kit (ASDK) do IBM phát triển

đã dừng lại ở phiên bản 1.1 Beta3 trên nền JDK1.1. Phiên bản mới nhất của ASDK là

2.0.2 do SourceForge phát triển trên nền JDK1.3. Aglets là một hệ thống Java mobile

agent hỗ trợ các khái niệm thi hành tự trị và định tuyến động trên lộ trình của nó. Có

thể xem aglets như là một khái quát hóa và mở rộng của applet và servlet. Aglet server

là chương trình cung cấp một môi trường thực thi và một máy ảo Java cho aglet hoạt

động. Ngoài ra, Aglet server cũng sử dụng một trình quản lý để tiếp nhận và kiểm soát

aglet một cách an toàn.

Aglet API là bộ thư viện bao gồm các hàm chuyên biệt dành cho việc phát triển

agent. Nhờ vào Aglet API, khả năng nổi tiếng của Java là “viết một lần, thi hành bất cứ

đâu” được viết lại là “viết một lần, lưu hành bất cứ đâu”. Một khi aglets được tạo ra,

nó sẽ chạy trên mọi máy có hỗ trợ Aglet API mà không quan tâm đến nguồn gốc hệ

điều hành và phần cứng bên dưới hay nguồn gốc cụ thể của Aglet API được cài trên

máy đang chạy.

Trong mô hình đối tượng aglets, một aglets là một đối tượng di động có luồng

kiểm soát riêng của nó, làm việc theo sự kiện và liên lạc với các agent khác băng cách

truyền thông điệp. Aglets có một cơ chế định danh duy nhất và toàn cục dựa trên URL.

Aglets hỗ trợ cơ chế di động yếu (weak- mobility). Các aglets giao tiếp với nhau một

cách đồng nhất, và độc lập với vị trí lưu trú thông qua đối tượng proxy. Suốt chu kỳ

sống, các aglets sẵn sàng bắt những sự kiện (clone, mobility, persistence) phát sinh

trong môi trường để có phản ứng thích hợp. Agent có thể giao tiếp đồng bộ hoặc

không đồng bộ thông qua các loại thông điệp: synchronous, one-way, hay future reply.

Aglets sử dụng ATP (Agent Transfer Protocol) cho việc di chuyển và giao tiếp. Aglets

sử dụng 2 loại mẫu thiết kế chính là chủ-tớ (Master-Slave) và hành trình (Itinerary)

cho việc di chuyển của các agent.

Aglets là một trong những platform được sử dụng nhiều nhất để phát triển các hệ

thống mobile agent. Một số đề án thực hiện với Aglet có thể kể đến là TabiCan

(http://www.tabican.ne.jp) - chợ điện tử chuyên bán vé máy bay và tour du lịch trọn gói

- Cps720 (Artificial Intelligence Topics with Agent) tại đại học Ryerson University, Mỹ,

http://www.tabican.ne.jp/

39

Acme – Hệ thống hỗ trợ Sales Order Processing trong việc mua bán chứng khoán, của

Đại học Loughborough, Anh.

Voyager

Voyager là một môi trường thương mại hỗ trợ phát triển các ứng dụng agent

được hãng Object Space phát triển từ giữa năm 1996. Voyager đã trải qua nhiều lần

nâng cấp và thay đổi từ phiên bản 1.0 cho đến bây giờ là phiên bản 4.5. Tháng 03 năm

2002 sản phẩm Voyager được nhượng lại cho Recursion Software, một công ty chuyên

về các sản phẩm viết trên C++ và Java để đảm bảo cho việc phát triển Voyager sau

này. Các phiên bản từ 1.0 đến 3.3 Voyager được phân phối cho các nhà phát triển như

một freeware. Hiện tại Voyager đã có phiên bản 4.5 Evaluation hoàn toàn tương thích

với JDK1.3, JDK1.2 và JDK1.1. Phiên bản này bao gồm 6 sản phẩm, trong đó sản

phẩm chính yếu dùng cho các ứng dụng mobile agent là Voyager ORB Professional.

Voyager sử dụng ngôn ngữ lập trình Java với cú pháp chuẩn để tạo dựng các đối

tượng ở xa một cách rất dễ dàng, cho phép các đối tượng này trao đổi thông điệp với

nhau, và di chuyển các đối tượng giữa các máy tính có hỗ trợ môi trường Voyager.

Voyager hỗ trợ mạnh về tính di động với khả năng mang toàn bộ mã chương trình và

dữ liệu di chuyển từ máy ảo Java này sang máy ảo Java khác nếu các máy ảo có hỗ trợ

Voyager. Trạng thái hoạt động của agent cũng sẽ được bảo toàn và tiếp tục thực thi tại

nơi agent đến.

Một trong những đặc điểm nổi trội khác của Voyager là tính phổ quát. Các

chương trình viết trong Voyager có thể trao đổi thông tin hai chiều với các chương

trình viết băng SOAP, CORBA, RMI và DCOM. Các dạng thông tin được trao đổi có

thể là các lời gọi hàm từ xa, các dịch vụ đặt tên, dịch vụ thư mục. Voyager có thể

được xem là một cửa ngõ, một cầu nối làm cho các chương trình theo chuẩn khác trở

nên liên thông với nhau. Hơn nữa, tất cả các chương trình và đối tượng có thể được

tổ chức thành một không gian chung, nhờ vậy việc liên lạc sẽ trở thành mối liên hệ

một - nhiều một cách tự động.

Phiên bản 4.5 của Voyager đã được bổ sung thêm các tính năng rất quan trọng hỗ

trợ cho các chuẩn dịch vụ Web. SOAP và WSDL cũng đã được phát triển trong phiên

bản này giúp cho các nhà phát triển có khả năng triển khai các ứng dụng truy cập tới

40

các dịch vụ Web từ xa và các chương trình Voyager có thể truy cập nhau thông qua các

dịch vụ Web.

Thế mạnh thật sự của Voyager năm ở sự đơn giản và dễ dùng. Sự “trong suốt”

hay cách mà Voyager che dấu các kỹ thuật lập trình phân tán phức tạp đã làm cho việc

xây dựng các ứng dụng mobile agent trở nên dễ dàng hơn rất nhiều. Việc tích hợp các

công nghệ mới và các chuẩn mới vào cùng một sản phẩm tạo cho Voyager sự hấp dẫn

rất riêng biệt.

Mole

Mole là hệ thống Mobile Agent được xây dựng với ngôn ngữ Java tại đại học

Stuttgart (CHLB Đức). Phiên bản đầu tiên (Release 1.0) đã hoàn thành vào năm 1995,

năm 1997 phiên bản Release 2.0 được hoàn thành, bản Release 3.0 được hoàn tất vào

năm 1998 và đề án đã kết thúc với kết quả là môi trường ổn định để xây dựng ứng

dụng theo mô hình agent trên các hệ phân tán.

Được xây dựng trên Java, Mole có khả năng thực thi trên tất cả các môi trường có

hỗ trợ JDK1.1.x (Jdk1.1.7 và Jdk1.1.8), sử dụng giao thức TCP/IP trong quá trình giao

tiếp. Mole hỗ trợ di chuyển yếu (weak migration).Để thực hiện giao tiếp giữa các agent

Mole sử dụng các cơ chế truyền thông điệp, gọi hàm từ xa RPCs và cơ chế đặc trưng

của Mole là session, badge. Ngôn ngữ giao tiếp giữa các agent được Mole hỗ trợ là

KQML. Việc trao đổi dữ liệu giữa các agent được thực hiện theo nghi thức TCP/IP.

Mole cho phép đa tiểu trình/agent và quản lý tài nguyên và lập lịch các tiểu trình trong

hệ thống thông qua bộ lập lịch trung tâm MCP. Khả năng bảo mật của Mole được

đánh giá khá tốt trong các hệ thống agent. Mole tuân theo mô hình bảo mật sandbox

của java. Agent trong hệ thống Mole được chia làm hai loại: user agent và system agent.

User agent là những agent di động được kích hoạt bởi người dùng và không thể truy

cập trực tiếp tài nguyên hệ thống. Ngược lại, system agent (service agent) - được khởi

động bởi người quản trị - không có tính di động và được phép truy cập tài nguyên hệ

thống.

Môi trường Mole phù hợp cho phát triển những ứng dụng trong các lĩnh vực:

Truyền thông, ứng dụng thuộc lĩnh vực hệ thống thông tin điện tử. Một số ứng dụng

dược phát triển trên môi trường Mole: AIDA - Infrastructure for Mobile Agents, ASAP,

ATOMAS, FESTIVAL (Mole office, Mole shopping), HAWK.

41

Với hệ thống mã nguồn mở của Mole, ta có thể tiến hành cải tiến, nâng cấp những

chức năng hiện có,và bổ sung những chức năng mới như các chức năng về công cụ hỗ

trợ lập trình agent để Mole trở thành hệ thống agent hiện đại hỗ trợ tốt cho việc phát

triển các ứng dụng dựa theo mô hình agent.

ZEUS

Zeus là môi trường do British Telecommunication phát triển để hỗ trợ xây dựng

các hệ thống đa tác tử. Ngoài các tính năng thông thường trong việc tạo lập và quản lý

các agent, Zeus đặc biệt chú trọng việc hỗ trợ một phương pháp luận và một bộ công

cụ mạnh để phát triển ứng dụng đa agent trên môi trường phân tán.

Zeus định nghĩa một phương pháp luận để phân tích, thiết kế, triển khai hệ thống

và còn kèm theo các công cụ cho phép người phát triển có thể bắt lỗi hệ thống cũng

như phân tích sự thực hiện của mình. Hai giai đoạn phân tích và thiết kế được miêu

tả chi tiết trong nhưng chưa được hỗ trợ bởi các công cụ. Zeus Toolkit hỗ trợ hai giai

đoạn cài đặt và bảo trì Zeus toolkit qua các công cụ Zeus Agent Generator và Zeus

Agent Visualiser. Zeus cung cấp nhiều Editor để định nghĩa agent và các thuộc tính của

agent. Code Generator sẽ tự động phát sinh mã nguồn cho agent từ những thuộc tính

đã đặc tả.

Hai đặc tính quan trọng của các Zeus agents là tính tự trị và cộng tác. Bộ phận

Planner trong mỗi agent sẽ hỗ trợ agent thể hiện tính tự trị. Khả năng thương lượng

và cộng tác giữa các agent cũng được Zeus tích hợp vào trong toolkit thông qua một

thư viện các giao thức, cùng các chiến lược thương lượng và cộng tác. Do có mã

nguồn mở, người dùng có thể thêm vào thư viện này các chiến lược riêng phù hợp với

ứng dụng của mình.

Các Zeus agent truyền thông theo point-to-point socket TCP/IP với mỗi message là

một chuỗi các kí tự mã ASCII. Ngôn ngữ truỵền thông Zeus sử dụng là FIPA ACL

(http://www.fipa.org). Nhăm cung cấp khả năng “hiểu” lẫn nhau cho các agent, Zeus

cung cấp các công cụ cho việc định nghĩa các ontology-cơ sở khái niệm chung cho

cộng đồng agent.

Các agent của Zeus được phân tán qua mạng và có thể thực hiện các tác vụ đồng

thời. Chính vì thế, việc quản lý các agent cũng là một vấn đề mà môi trường đặt ra.

Visualiser của Zeus cung cấp các công cụ để kiểm tra các quan hệ giao tiếp giữa các

http://www.fipa.org/

42

agent, trạng thái tác vụ những agent đang thực hiện và trạng thái bên trong của agent.

Đồng thời, Zeus Statistic Tool cho phép người dùng so sánh các thống kê khác nhau về

cộng đồng agent, chăng hạn những loại thông điệp nào agent đã gửi và tỉ lệ là bao

nhiêu, một cách trực quan dưới những dạng đồ thị khác nhau. Cũng nhăm quản lý

agent, Zeus cung cấp những agent tiện ích như Agent Name Server hoạt động như một

Yellow Page, Facilitator như một White Page, Visualiser và Database Proxy.

Một hạn chế của Zeus là tuy được liệt kê vào một trong những môi trường mobile

agent nhưng hiện hướng nghiên cứu về tính di động của Zeus chỉ mới ở bước đầu,

chưa được cài đặt. Do đó mà tính bảo mật của Zeus cho các agent hầu như không có.

Điều này có thể sẽ được khắc phục trong các phiên bản sau.

Zeus đã và đang được triển khai trong một số ứng dụng như Agent Based Work-

flow Management, PTA:PersonalTravel Assistance, Personal Computer Manufacture,

Agent Electronic Commerce, Network Management, Home Shopping.

So sánh các hệ thống Aglet, Mole, Voyager và Zeus

Về mặt lý thuyết, mô hình tác tử phần mềm có nhiều ưu điểm hứa hẹn cho việc

phát triển một thế hệ các ứng dụng phân tán mới. Tuy nhiên, những nghiên cứu trong

lĩnh vực tác tử phần mềm đa số tập trung phát triển các hệ thống agent hỗ trợ khả

năng di động và những tính năng của các môi trường này như tính an toàn, cơ chế tự

di chuyển của agent, cơ chế giao tiếp giữa các agent… Bảng 3.1 so sánh các hệ thống

hỗ trợ Agent hiện đang được sử dụng ở các vấn đề bao gồm: Sự hỗ trợ các đặc tính

cơ bản của Agent, khả năng giao tiếp, cộng tác, phương pháp luận và công cụ hỗ trợ

phát triển hệ thống đa tác tử.

Các vấn đề kỹ thuật: Thực hiện cơ chế đi động, bảo đảm an toàn, nâng cao

tốc độ thi hành, và chuẩn hoá công nghệ là những khó khăn đồng thời là các thách

thức chủ yếu của mô hình tác tử:

43

Thực hiện tính năng di động: Một số hệ thống về nguyên tắc hỗ trợ tính di

động của agent, nhưng trong thực tế hoặc chưa hỗ trợ, hoặc chỉ hỗ trợ di độ

TÀI LIỆU THAM KHẢO

[1]. C.-Y. Chang, M.-S. Chen, and B.-H. Huang. “An H.323 Gatekeeper Prototype:

Design, Implementation, and Performance”. IEEE Transactions on Multimedia,

2004.

[2]. A. Maheshwari, A. Sharma, A. Ramamritham, and K. Shenoy. TranSquid:

“Transcoding and Caching Proxy for Heterogenous E-Commerce

Environments”. Research Issues in Data Engineering: Engineering E-

Commerce/E-Business Systems, 2002.

[3]. B. Knutsson, H. Lu, and J. Mogul. “Architecture and Pragmatics of Server-

Directed Transcoding”. In the 7th International Workshop on Web Content

Caching and Distribution, 2002.

[4]. B. Thai and A. Seneviratne, “The use of Software Agents as Proxies”,

Proceedings of the Fifth IEEE Symposium on Computers & Communications

(ISCC'00), IEEE 2000

[5]. H. Bharadvaj, A. Joshi, and S. Auephanwiriyakul. “An Active Transcoding Proxy

to Support Mobile Web Access”. In the 17th IEEE Symposium on Reliable

Distributed Systems, 1998.

[6]. H.-L. Yang. “Design and Implementation of an HTML-WML Translator”.

Master Thesis Computer Science Department NTHU, 1999.

[7]. R. Mohan, J. R. Smith, and C. S. Li. “Adapting Multimedia Internet Content for

Universal Accesses”. IEEE Trans. on Multimedia, 1(1), 1999.

[8]. R. Han, P. Bhagwat, R. Lamaire, T. Mummert, V. Perret, and J. Rubas. Dynamic

“Adaptation in an Image Transcoding Proxy for Mobile Web Browsing”. IEEE

Personal Communication, 5(6), 1998.

[9]. S. Chandra, A. Gehani, C. Ellis, and A. Vahdat. “Transcoding Characteristics of

Web Images”. In Multimedia Computing and Networking (MMCN-01), 2001

[10]. Sunam Pradhan and Arkady Zaslavsky, “A Smart Proxy for a Next Generation

Web Services Transaction”, 6th IEEE/ACIS International Conference on

Computer and Information Science (ICIS 2007), IEEE 2007

44

[11]. W3C Working group, “Device Independence Principles”, September 2003,

http://www.w3.org/TR/di-princ/

[12]. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-

Lee, “Hypertext Transfer Protocol -- HTTP/1.1”, W3C/MIT, June 1999,

http://www.w3.org/Protocols/rfc2616/rfc2616.html

[13]. W3C, “Composite Capabilities/Preference Profiles (CC/PP): Structure and

Vocabularies 2.0”, April 2007, http://www.w3.org/TR/CCPP-struct-vocab2/

[14]. W3C, “Composite Capabilities/Preference Profiles: Requirements and

Architecture”, July 2000, http://www.w3.org/TR/CCPP-ra/

[15]. W3C, “Composite Capability/Preference Profiles (CC/PP) A user side

framework for content negotiation”, http://www.w3.org/TR/NOTE-CCPP/

[16]. OMA/WAP Forum UAProf Specification

http://www1.wapforum.org/tech/documents/WAP-248-UAProf-20011020-a.pdf

[17]. La Porta T, Ramjee R, Woo T, Sabnani K, “Experiences with Network-based

User Agents for Mobile Applications”, Mobile Networks and Applications

3(1998), p.123-141

[18]. T. Berners-Lee, R. Fielding, L. Masinter, U.C. Irvine, “Uniform Resource

Identifiers: Generic Syntax”, RFC 2396, http://www.ietf.org/rfc/rfc2396.txt

[19]. Dave Beckett, Brian McBride; “RDF/XML Syntax Specification (Revised)”; World

Wide Web Consortium Recommendation 10 February 2004:

http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/

[20]. L. Masinter, D. Wing, A. Mutz, K. Holtman; “RFC 2534: Media Features for

Display, Print, and Fax”; IETF Request for Comments: ftp://ftp.isi.edu/in-

notes/rfc2534.txt

[21]. User Agent Profile version 2.0 (2006); OMA specification; available at

http://www.openmobilealliance.org/release_program/docs/UAProf/V2_0-

20060206-A/OMA-TS-UAProf-V2_0-20060206-A.pdf

[22]. Tim Bray, Dave Hollander, Andrew Layman, Richard Tobin, “Namespaces in

XML (Second Edition)”, World Wide Web Consortium Recommendation 16

August 2006: http://www.w3.org/TR/2006/REC-xml-names-20060816

[23]. T. Berners-Lee, R. Fielding, L. Masinter; “RFC 2396: Uniform Resource

Identifiers (URI): Generic Syntax”; IETF Request for Comments:

ftp://ftp.isi.edu/in-notes/rfc2396.txt

[24]. GAIA Image Transcoder, http://gaia-git.sourceforge.net

http://www.w3.org/TR/di-princ/

http://www.w3.org/Protocols/rfc2616/rfc2616.html

http://www.w3.org/TR/CCPP-struct-vocab2/

http://www.w3.org/TR/CCPP-ra/

http://www.w3.org/TR/NOTE-CCPP/

http://www.ietf.org/rfc/rfc2396.txt

http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/



http://www.openmobilealliance.org/release_program/docs/UAProf/V2_0-20060206-A/OMA-TS-UAProf-V2_0-20060206-A.pdf



http://www.w3.org/TR/2006/REC-xml-names-20060816


http://gaia-git.sourceforge.net/

45

Documents

NGHIÊN CỨU MÔ HÌNH TÁC TỬ TẦNG TRUNG …repository.vnu.edu.vn/bitstream/VNU_123/15917/1/V_L0...mô tả công nghệ CC/PP, công nghệ này cung cấp một phương thức