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!
Bookmark not defined.
Hình 2.2 Proxy Server cho nhiều máy khách với các dịch vụ khác nhau . Error!
Bookmark not defined.
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!
Bookmark not defined.
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!
Bookmark not defined.
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!
Bookmark not defined.
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!
Bookmark not defined.
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">
<!-- TerminalHardware properties here -->
</rdf:Description>
20
</ccpp:component>
<ccpp:component>
<rdf:Description
rdf:about="http://www.example.com/profile#TerminalSoftware">
<!-- TerminalSoftware properties here -->
</rdf:Description>
</ccpp:component>
<ccpp:component>
<rdf:Description
rdf:about="http://www.example.com/profile#TerminalBrowser">
<!-- TerminalBrowser properties here -->
</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
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: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:about="http://www.example.com/profile#TerminalHardware">
<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:about="http://www.example.com/profile#TerminalSoftware">
<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:about="http://www.example.com/profile#TerminalBrowser">
<rdf:type
rdf:resource="http://www.example.com/schema#BrowserUA" />
<ex:name>Mozilla</ex:name>
<ex:version>5.0</ex:version>
<ex:vendor>Symbian</ex:vendor>
<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.
25
Hình 0.6 CC/PP profile sử dụng các giá trị mặc định
Mã XML tương ứng có thể có nội dung như sau:
Device profile referencing defaults: <?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: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" />
<ccpp:component>
<rdf:Description
rdf:about="http://www.example.com/profile#TerminalHardware">
<rdf:type
rdf:resource="http://www.example.com/schema#HardwarePlatform" />
<ccpp:defaults
rdf:resource="http://www.example.com/hardwareProfile#HWDefault" />
</rdf:Description>
</ccpp:component>
<ccpp:component>
<rdf:Description
rdf:about="http://www.example.com/profile#TerminalSoftware">
<rdf:type
rdf:resource="http://www.example.com/schema#SoftwarePlatform" />
<ccpp:defaults
rdf:resource="http://www.example.com/softwareProfile#SWDefault" />
</rdf:Description>
</ccpp:component>
<ccpp:component>
<rdf:Description
rdf:about="http://www.example.com/profile#TerminalBrowser">
<rdf:type
rdf:resource="http://www.example.com/schema#BrowserUA" />
<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:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ex="http://www.example.com/schema#">
<rdf:Description
rdf:about="http://www.example.com/hardwareProfile#HWDefault">
<rdf:type
rdf:resource="http://www.example.com/schema#HardwarePlatform" />
<ex:displayWidth>320</ex:displayWidth>
<ex:displayHeight>200</ex:displayHeight>
</rdf:Description>
</rdf:RDF>
Defaults for SoftwarePlatform: <?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ex="http://www.example.com/schema#">
<rdf:Description
rdf:about="http://www.example.com/softwareProfile#SWDefault">
<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>
</rdf:RDF>
Defaults for BrowserUA: <?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ex="http://www.example.com/schema#">
<rdf:Description
rdf:about="http://www.example.com/terminalProfile#UADefault">
<rdf:type
rdf:resource="http://www.example.com/schema#BrowserUA" />
<ex:name>Mozilla</ex:name>
<ex:version>5.0</ex:version>
<ex:vendor>Symbian</ex:vendor>
<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.
Mã XML tương ứng có thể có nội dung như sau:
Device profile referencing defaults: <?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: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" />
28
<ccpp:component>
<rdf:Description
rdf:about="http://www.example.com/profile#TerminalHardware">
<rdf:type
rdf:resource="http://www.example.com/schema#HardwarePlatform" />
<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:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ex="http://www.example.com/schema#">
<rdf:Description
rdf:about="http://www.example.com/hardwareProfile#HWDefault">
<rdf:type
rdf:resource="http://www.example.com/schema#HardwarePlatform" />
<ex:displayWidth>320</ex:displayWidth>
<ex:displayHeight>200</ex:displayHeight>
<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ỹ,
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
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