Nghiên cứu xây dựng ứng dụng học tiếng anh theo nhu cầu người học trên mobile

LỜI CẢM ƠN
Để hoàn thành chương trình học và viết đồ án tốt nghiệp này, em đã nhận
được sự hướng dẫn, giúp đỡ nhiệt tình của các thầy cô trường Đại học Công nghệ
Thông tin và Truyền thông.
Trước tiên em xin gửi lời cảm ơn đến quý thầy cô trường Đại học Công
nghệ Thông tin và Truyền thông, đặc biệt là các thầy cô Bộ môn Công nghệ phần
mềm đã tận tình dạy bảo em trong suốt thời gian học tập tại trường.
Em xin gửi lời biết ơn sâu sắc đến Th.S Tô Hữu Nguyên, người thầy đã
cho em định hướng, tận tình chỉ bảo em trong quá trình học tập, tạo điều kiện cho
em hoàn thành các lần thực tập, đặc biệt là đồ án này.
Mặc dù có nhiều cố gắng để hoàn thiện đồ án bằng tất cả năng lực của
mình, tuy nhiên không thể tránh khỏi sự thiếu sót, rất mong nhận được những
đóng góp quý báu của quý thầy cô và các bạn.

Thái Nguyên, ngày 17 tháng 06 năm 2012
Sinh viên thực hiện
TRỊNH THỊ TRÀ LY

1


LỜI CAM ĐOAN
Tôi xin cam đoan đồ án là công trình nghiên của cá nhân, không sao chép
của bất cứ ai. Nội dung lí thuyết trong đồ án có sự tham khảo và sử dụng của một
số tài liệu, thông tin đã được đăng tải trên các tác phẩm, tạp trí và các trang web
theo danh mục tài liệu của đồ án. Các số liệu, và các kết quả trong đồ án là trung
thực.

Thái Nguyên, ngày 17 tháng 06 năm 2012.
Sinh viên thực hiện
TRỊNH THỊ TRÀ LY

2


NHIỆM VỤ ĐỒ ÁN
Đồ án tập trung nghiên cứu và xây dựng ứng dụng nhằm hỗ trợ mọi người
học tiếng anh dựa trên ngữ cảnh và chủ đề mà người dùng mong muốn trên
mobile. Từ đó giúp người dùng học và hiểu tiếng anh dễ dàng hơn. Vì vậy nội
dung đồ án bao gồm các nội dung chính sau:
-

Kiến thức nền tảng về J2ME.

-

Kiến thức về công nghệ Web Service.

-

Xây dựng mô hình nội dung các bài học tiếng anh.

-

Cài đặt và thử nghiệm chương trình.

3


MỤC LỤC

4


DANH MỤC HÌNH

5


ĐẶT VẤN ĐỀ
Học ngoại ngữ đang là vấn đề quan tâm của rất nhiều tầng lớp, đặc biệt là
tầng lớp học sinh, sinh viên. Trong bối cảnh hội nhập quốc tế của Việt Nam, việc
học ngoại ngữ là rất cần thiết cho mỗi con người và tiếng anh được rất nhiều
người lựa chọn. Vấn đề đặt ra là cần một phương pháp học đạt hiệu quả cao nhất.
Theo cách học truyền thống thì người học sẽ học trên sách vở là chủ yếu, tuy
nhiên trong thời đại hiện nay, thời đại của công nghệ thông tin, thì việc học
không chỉ dừng lại ở đó. Việc áp dụng các thành quả công nghệ vào việc học
đang được phổ biến trong mọi tầng lớp. Người học có thể học qua truyền hình,
qua máy tính, học trực tuyến qua mạng internet. Đặc biệt với sự phát triển rất
nhanh của thiết bị di động hiện nay thì việc học tập trên điện thoại di động được
quan tâm. Đây chính là những lí do em lựa chọn đề tài “Nghiên cứu xây dựng
ứng dụng học tiếng anh theo nhu cầu người học trên thiết bị di động”.
Đề tài hướng đến các mục tiêu:
-

Tìm hiểu, xây dựng ứng dụng trên điện thoại di động (j2me).

-

Tìm hiểu công nghệ webservice.

-

Xây dựng thí điểm ứng dụng học tiếng anh theo nhu cầu người học
trên thiết bị di động.

6


CHƯƠNG I: NỀN TẢNG J2ME
1.1. Giới thiệu khái quát về nền tảng JavaTM 2

Hình 1.1: Các phiên bản của Java.
Java có các phiên bản sau:
J2EETM (Nền tảng Java 2, phiên bản doanh nghiệp- Java TM 2 Platform,
Enterprise Edition): java 2 phiên bản doanh nghiệp để chạy trên các máy chủ lớn
với sức mạnh xử lý và dung lượng bộ nhớ lớn.
J2SETM (Nền tảng Java 2, phiên bản chuẩn – Java TM 2 Platform, Standard
Edition): Java 2 phiên bản chuẩn được dùng chạy trên các máy tính cá nhân và
laptop với số MB bộ nhớ. Các máy tính này mặc dù không mạnh bằng các máy
chủ lớn song chúng vẫn mạnh hơn nhiều so với các thiết bị di động.

7


J2METM (Nền tảng Java 2, phiên bản thu nhỏ- Java TM 2 Platform, Micro
Edition): java 2 phiên bản thu nhỏ là một phiên bản rút gọn của java cho các thiết
bị di động giới hạn về bộ nhớ và bộ xử lí. Có 2 phiên bản của J2ME:
-

Phiên bản dựa trên CDC (cấu hình thiết bị kết nối Connected Device

Configuration).

-

Phiên bản dựa trên CLDC (cấu hình thiết bị kết nối giới hạn Connected
Limited Device Configuration).

Ta chỉ xét phiên bản CLDC, phiên bản J2ME này dành cho các thiết bị có
bộ nhớ giới hạn như điện thoại di động. (Nói chung cho các thiết bị di động hoạt
động bằng nguồn pin). Phiên bản này của Java cần ít bộ nhớ hơn phiên bản CDC.
J2ME được thiết kế để chạy trên các điện thoại di động có cấu hình tối
thiểu như sau:
Bộ nhớ tổng cộng : 128-512KB.
Bộ xử lí: 16-32bit.
Tốc độ xử lí: 8-32 MHz.
Nặng lượng: giới hạn, hoạt động bằng pin.
Băng thông: giới hạn, khoảng 9600 bps.
1.2. J2ME
1.2.1. Khái quát các lớp J2ME
Mục tiêu của J2ME là cho phép người lập trình viết các ứng dụng độc lập
với thiết bị di động, không cần quan tâm đến phần cứng thật sự. Để đạt được mục
tiêu này, J2ME được xây dựng bằng các tầng (layer) khác nhau để giấu đi việc
thực hiện phần cứng khỏi nhà phát triển.
Các tầng của J2ME được xây dựng trên CLDC. Mỗi tầng ở trên tầng
hardware là tầng trừu tượng hơn cung cấp cho lập trình viên nhiều giao diện lập
trình ứng dụng (API- Application Program Interface) thân thiện hơn.
Hình sau minh họa các tầng của J2ME:
8

Hình 1.2: Các tầng của CLDC J2ME.
Tầng thiết bị phần cứng (Device hardware layer)
Đây chính là thiết bị di động thật sự với cấu hình phần cứng của nó về bộ
nhớ và tốc độ xử lí. Dĩ nhiên thật ra nó không phải là một phần của J2ME nhưng
nó là nơi xuất phát. Các thiết bị di động khác nhau có thể có các bộ xử lí khác
nhau với các tập mã lệnh khác nhau. Mục tiêu của J2ME là cung cấp một chuẩn
cho tất cả các loại thiết bị di động khác nhau.
Tầng máy ảo Java (Java Virtual Machine Layer)
Khi mã nguồn Java được biên dịch, nó được chuyển đổi thành mã
bytecode. Mã bytecode này sau đó được chuyển thành mã ngôn ngữ máy của
thiết bị di động. Tầng máy ảo Java bao gồm KVM (K Virtual Machine) là bộ
biên dịch mã bytecode có nhiệm vụ chuyển mã bytecode của chương trình Java
thành ngôn ngữ máy để chạy trên thiết bị di động. Tầng này cung cấp một sự
chuẩn hóa cho các thiết bị di động để ứng dụng J2ME sau khi đã biên dịch có thể
hoạt động trên bất kì thiết bị di động nào có J2ME KVM.
Tầng cấu hình (Configuaration Layer)
Tầng cấu hình của CLDC định nghĩa giao diện ngôn ngữ Java (Java
Lauguage interface) cơ bản để cho phép chương trình Java chạy trên thiết bị di
động. Đây là một tập các API định nghĩa lỗi của ngôn ngữ J2ME. Lập trình viên
9


có thể sử dụng các lớp và phương thức của các API này tuy nhiên các API hữu
dụng hơn được chứa trong tầng hiện trạng (profile layer).
Tầng hiện trạng (Profile Layer)
Tầng hiện trạng hay MIDP cung cấp tập các API hữu dụng hơn cho lập
trình viên. Mục đích của hiện trạng là xây dựng trên lớp cấu hình và cung cấp
nhiều thư viện ứng dụng hơn. MIDP định nghĩa các API riêng biệt cho thiết bị di
động. Cũng có thể có các hiện trạng và các API khác ngoài MIDP được dùng cho
ứng dụng. Ví dụ có thể có hiện trạng PDA định nghĩa các lớp và phương thức

hữu dụng cho việc tạo các ứng dụng PDA (lịch, sổ hẹn, sổ địa chỉ...). Cũng có thể
có một hiện trạng định nghĩa các API cho việc tạo các ứng dụng Bluetooth. Thực
tế, các hiện trạng kể trên và tập các API đang được xây dựng. Chuẩn hiện trạng
PDA là đặc tả JSR-75 và chuẩn bluetooth API là đặc tả JSR-82 với JSR là viết tắt
của Java Specification Request.
1.2.2. MIDlet
Các ứng dụng J2ME được gọi là các MIDlet (Mobile Imformation Device
applet).
Một MIDlet là một lớp Java mở rộng của lớp trừu tượng
java.microedition.midlet.MIDlet

và thực thi các phương thức startApp(),

pauseApp(), và destroyApp().
Hình sau thể hiện bộ khung yêu cầu tối thiểu cho một ứng dụng MIDlet.

10


Hình 1.3: Bộ khung MIDlet

1) Phát biểu import
Các phát biểu import được dùng để include các lớp cần thiết từ các thư
viện CLDC và MIDP.
2) Phần chính của MIDlet
MIDlet được định nghĩa như một lớp mở rộng MIDlet. Trong ví dụ này
MIDletExample là bắt đầu của ứng dụng.
3) Hàm tạo (Contructor)
Hàm tạo chỉ được thực thi một lần khi MIDlet được khởi tạo lần đầu tiên.
Hàm tạo sẽ không được gọi lại trừ khi MIDlet thoát ra và sau đó khởi động lại.

4) startApp()
Phương thức startApp() được gọi bởi bộ quản lí ứng dụng khi MIDlet
được khởi tạo, và mỗi khi MIDlet trở về từ trạng thái tạm dừng. Nói chung, các
biến toàn cục sẽ được khởi tạo lại trừ hàm tạo bởi vì các biến đã được giải phóng
trong hàm pauseApp(). Nếu không thì chúng sẽ không được khởi tạo lại bởi ứng
dụng.
5) pauseApp()
Phương thức pauseApp() được gọi bởi bộ quản lí ứng dụng mỗi khi ứng
dụng cần được tạm dừng (ví dụ trong trường hợp tin nhắn đến hoặc có cuộc gọi).
Cách thích hợp để sử dụng pauseApp() là giải phóng tài nguyên và các biến để
dành cho các chức năng khác trong điện thoại trong khi MIDlet được tạm dừng.
Cần lưu ý rằng khi nhận cuộc gọi đến hệ điều hành trên điện thoại di động có thể
dừng KVM thay vì dừng MIDlet. Việc này không được đề cập trong MIDP mà
đó là do nhà sản xuất quyết định sẽ chọn cách nào.
6) destroyApp()
Phương thức destroyApp() được gọi khi thoát MIDlet (ví dụ khi nhấn nút
exit trong ứng dụng). Nó chỉ đơn thuần là thoát MIDlet. Nó không thật sự xóa
11


ứng dụng khỏi điện thoại di động. Phương thức destroyApp() chỉ nhận một tham
số Boolean. Nếu tham số này là true, MIDlet được tắt vô điều kiện. Nếu tham số
là false, MIDlet có thêm tùy chọn từ chối thoát bằng cách ném ra một ngoại lệ
MIDletStateChangeException.
Tóm tắt các trạng thái khác nhau của MIDlet:
-

Tạo (Created) => Hàm tạo MIDletExample() được gọi 1 lần.

-

Hoạt động (Active) => Phương thức startApp() được gọi khi chương
trình bắt đầu hay sau khi tạm dừng.

-

Tạm dừng (Paused ) => Phương thức pauseApp() được gọi. Có thể
nhận sự kiện timer.

-

Hủy (Destroyed ) => Phương thức destroy() được gọi.

Chu kì sống của MIDlet (MIDlet lifecycle)
Sơ đồ sau biểu diễn chu kì sống của MIDlet:

Hình 1.4: Chu kì sống của MIDlet.
Khi người dùng yêu cầu khởi động ứng dụng MIDlet, bộ quản lí ứng dụng
sẽ thực thi MIDlet (thông qua lớp MIDlet). Khi ứng dụng thực thi, nó sẽ được
xem là đang ở trạng thái tạm dừng. Bộ quản lí ứng dụng gọi hàm tạo và hàm
startApp(). Hàm startApp() có thể được gọi nhiều lần trong suốt chu kì sống của

12


ứng dụng. Hàm destroyApp() chỉ có thể gọi từ trạng thái hoạt động hay tạm
dừng.
Lập trình viên cũng có thể điều khiển các trạng thái của MIDlet:
-

resumerRequest(): Yêu cầu vào chế độ hoạt động. Ví dụ khi MIDlet
tạm dừng, và một sự kiện timer xuất hiện.

-

notifyPaused(): cho biết MIDlet tự nguyện chuyển sang trạng thái tạm
dừng. Ví dụ khi đợi một sự kiện timer.

-

notifyDestroyed(): sẵn sàng để hủy. Ví dụ nhấn nút Exit.

1.2.3. Đồ họa (Graphic)
Các lớp MIDlet cung cấp 2 mức đồ họa: đồ họa mức thấp và đồ họa mức
cao. Đồ họa mức cao dùng cho văn bản hay form. Đồ họa mức thấp dùng cho các
ứng dụng trò chơi yêu cầu phải vẽ lên màn hình.
Cả hai lớp đồ họa mức thấp và mức cao đều là lớp con của lớp
Displayable. Trong MIDP, chỉ có thể có một lớp displayable trên màn hình tại
một thời điểm. Có thể định nghĩa nhiều màn hình nhưng một lần chỉ một màn
hình được hiển thị.
-

Đồ họa mức cao (Hight Level Graphics): là lớp con của lớp Screen. Nó
cung cấp các thành phần như text box, form, list, và alert. Ta ít điều
khiển sắp xếp các thành phần trên màn hình. Việc sắp xếp thật sự phụ
thuộc vào nhà sản xuất.

-

Đồ họa mức thấp là lớp con của lớp Canvas. Lớp này cung cấp các

phương thức đồ họa cho phép vẽ lên màn hình hay vào một bộ đệm
hình cùng với các phương thức xử lí sự kiện bàn phím. Lớp này dùng
cho các ứng dụng trò chơi cần điều khiển về màn hình.

Hình sau biểu diễn hai mức đồ họa:

13


Hình 1.5: Hai mức đồ họa.
Hình sau biểu diễn lớp phân cấp đồ họa:

Hình 1.6: Phân cấp lớp đồ họa.

14


Form có thể là kiểu đồ họa hữu dụng nhất của các lớp Screen vì nó cho
phép chứa nhiều item khác nhau. Nếu sử dụng các lớp khác (TextBox, List) thì
chỉ có 1 item được hiển thị bởi vì chúng đều là đối tượng Displayable và do chỉ
có thể có một đối tượng Displayable được hiển thị tại một thời điểm. Form cho
phép chứa nhiều item khác nhau (DateField, TextField, ImageItem,
ChoiceGroup...).
1.2.3.1. Đồ họa mức cao
Là lớp con của lớp Screen.
1) TextBox
Lớp TextBox cho phép người dùng nhập và soạn thảo văn bản. Lập trình
viên có thể định nghĩa số kí tự tối đa, giới hạn loại dữ liệu nhập và hiệu chỉnh nội
dung của textbox. Kích thước thật sự của textbox có thể nhỏ hơn yêu cầu khi
thực hiện thực tế. Kích thước thật sự của textbox có thể lấy bằng phương thức

getMaxSize().
2) List
Lớp List là 1 Screen chứa danh sách các lựa chọn chẳng hạn như các radio
button. Người dùng có thể tương tác với list và chọn một hay nhiều item.
3) Alert
Alert hiển thị một màn hình pop-up trong một khoảng thời gian. Nói
chung nó dùng để cảnh báo hay báo lỗi. Thời gian hiển thị có thể được thiết lập
bởi ứng dụng. Alert có thể được gán các kiểu khác nhau như alarm, confirmation,
error, info, warming, các âm thanh tương ứng sẽ được phát ra.
4) Form và các Form Item
Form là lớp trừu tượng hữu dụng nhất của lớp Screen bởi vì nó cho phép
chứa nhiều item trên cùng 1 màn hình.
Các Item này có thể là DateField, TextField, StringItem, ImageItem,
ChoiceGroup, ...
15


Mỗi item là 1 lớp con của lớp Item.
-

StringItem: là một chuỗi hiển thị mà người dùng không thể hiệu chỉnh,
tuy nhiên cả nhãn và nội dung của item này có thể điều chỉnh bởi ứng
dụng.

-

ImageItem: item này chứa tham chiếu đến một đối tượng Image phải
được tạo trước đó.

-

TextField: item này cho phép người dùng nhập vào văn bản. Nó có thể
có giá trị khởi tạo, kích thước tối đa và ràng buộc kiểu nhập liệu. Kích
thước thật sự có thể nhỏ hơn yêu cầu do giới hạn của thiết bị di động.

-

DateField: item này cho phép người dùng nhập thông tin ngày tháng
và thời gian. Có thể xác định giá trị khởi tạo và chế độ nhập ngày
tháng (DATE), thời gian (TIME), hoặc cả hai.

-

ChoiceGroup: cung cấp 1 nhóm các Radio button hay checkbox cho
phép lựa chọn đơn hay lựa chọn nhiều.

-

Gauge: cung cấp một hiển thị âm thanh của một giá trị số học. Gauge
có thể có tính tương tác hoặc không. Nếu một gauge là tương tác thì
người dùng có thể thay đổi giá trị của tham số gauge và ngược lại.

-

Ticker: một màn hình có thể có một Ticker là một chuỗi văn bản chạy
liên tục trên màn hình. Hướng và gốc tọa độ là do thực tế quy định.
Nhiều màn hình có thể chia sẻ cùng 1 ticker.

1.2.4. Lập trình mạng
1.2.4.1. Khung mạng CLDC tổng quát (Generic CLDC Networking

Framework)
Mạng cho phép client di động gởi và nhận dữ liệu đến server. Nó cho
phép thiết bị di động sử dụng các ứng dụng như tìm kiếm CSDL, trò chơi trực
tuyến...

16


Trong J2ME, mạng được chia làm 2 phần. Phần đầu tiên là khung được
cung cấp bởi CLDC và phần hai là giao thức thật sự được định nghĩa trong các
hiện trạng.
CLDC cung cấp một khung tổng quát để thiết lập kết nối mạng. Ý tưởng
là nó đưa ra một khung mà các hiện trạng khác nhau sẽ được sử dụng. Khung
CLDC không định nghĩa giao thức thật sự. Các giao thức sẽ được định nghĩa
trong các hiện trạng. Hình sau biểu diễn cách mà khung mạng CLDC làm việc:

Hình 1.7: Khung mạng CLDC tổng quát.
Kết nối mạng được xây dựng bằng phương thức open() của lớp Connector
trong CLDC. Phương thức open() nhận một tham số đầu vào là chuỗi. Chuỗi này
dùng để xác định giao thức.
Định dạng của chuỗi là:
Protocol:address;parameters
CLDC chỉ xác định tham số là một chuỗi nhưng nó không định nghĩa bất
kì giao thức thật sự nào. Các hiện trạng có thể định nghĩa các giao thức kết nối
như HTTP, socket, cổng truyền thông, datagram,... Phương thức open() trả về
một đối tượng Connector. Đối tượng này sau đó có thể đóng vai trò là một giao
thức xác định được định nghĩa trong hiện trạng.
Connector.open(“:<address>;”);
17

MIPD chỉ hỗ trợ giao thức HTTP:
Ví dụ: Connector.open(“”);
1.2.4.2. Các lớp giao diện kết nối (Connector Interface Class)
Dẫn xuất từ lớp Connector là nhiều lớp giao diện con cung cấp khung kết
nối mạng. Các giao diện khác nhau để hỗ trợ các loại thiết bị di động khác nhau.

Hình 1.8: Các lớp kết nối
Sau đây là mô tả các giao diện kết nối được định nghĩa trong CLDC
-

StreamConnectorNotifier: giao diện này được dùng khi đợi một kết
nối phía server được thiết lập. Phương thức acceptAndOpen() bị chặn
cho đến khi client thiết lập kết nối.

-

DatagramConnector: kết nối datagram cung cấp kiểu truyền thông gói
không trung thực. Datagram chứa gói dữ liệu và địa chỉ. Chuỗi địa chỉ
có định dạng như sau: datagram:[//{host}]:{port}. Nếu tham số host
được xác định thì datagram mở kết nối ở chế độ client. Nếu tham số
host không được xác định thì datagram được mở ở chế độ server
18


-

Giao diện InputConnection: giao diện này dùng để thực hiện một
luồng nhập tuần tự dữ liệu chỉ đọc.

-

Giao diện OutputConnection: giao diện này dùng để thực hiện một
luồng xuất dữ liệu chỉ viết.

-

Giao diện StreamConnection: giao diện này là kết hợp của cả hai giao
diện InputConnection và OutputConnection. Nó dùng cho các thiết bị
di động có truyền thông hai chiều.

-

Giao diện ContentConnection: giao diện này mở rộng giao diện
StreamConnection và thêm vào các phương thức getType(),
getEncoding(), getLength(). Nó cung cấp cơ sở cho giao diện
HttpConnection của MIDP.

-

Giao diện HttpConnection: giao diện này được định nghĩa trong
MIDP và mở rộng giao diện ContentConnection của CLDC. Giao diện
này cung cấp các phương thức thiết lập một kết nối HTTP.

1.2.4.3. Kết nối HTTP
Hiện trạng MIDP hỗ trợ kết nối HTTP phiên bản 1.1 thông qua giao diện
HttpConnection. Hỗ trợ GET, POST, HEAD của HTTP. Yêu cầu GET được
dùng để lấy dữ liệu từ server và đây là phương thức mặc định. Yêu cầu POST
dùng để gửi dữ liệu lên server. Yêu cầu HEAD tương tự như GET nhưng không
có dữ liệu trả về từ server. Nó có thể dùng để kiểm tra tính hợp lệ của 1 địa chỉ

URL.
Một kết nối HTTP có thể ở một trong 3 trạng thái khác nhau: Thiết lập
(set up), kết nối (connected), hay đóng (close). Trong trạng thái thiết lập, kết nối
chưa được tạo.
Phương thức setRequestMethod() và setRequestProperty() chỉ có thể được
dùng trong trạng thái thiết lập. Chúng được dùng để thiết lập phương thức yêu
cầu và thiết lập thuộc tính HTTP. Khi sử dụng một phương thức yêu cầu gửi dữ
liệu đến hay nhận dữ liệu về từ server sẽ làm cho kết nối chuyển từ trạng thái

19


thiết lập sang trạng thái kết nối. Gọi phương thức close() sẽ làm cho kết nối
chuyển sang trạng thái đóng.

Hình 1.9: Các trạng thái kết nối http.
1.2.4.4. Các đặc điểm của kết nối HTTP bằng J2ME
Một yêu cầu từ phía client gồm 3 phần: phương thức request, header, và
phần body.
Các phương thức yêu cầu:
HttpConnection hỗ trợ 3 phương thức request: GET, POST, HEAD. Cả 3
phương thức thông báo cho server biết client cần truy vấn 1 thông tin. Phương
thức GET và POST khác nhau ở cách thông tin truy vấn được gửi lên server.
Chúng ta có thể chỉ định rõ phương thức sử dụng trong HttpConnection
bằng hàm setRequestMethod().
Sử dụng GET, phần thân của yêu cầu được đưa chung vào trong URL.
Điều này được gọi là URL encoding.
Với phương thức POST, thông tin truy vấn không được ghép vào vùng
URL mà được chuyển lên server trong vùng BODY của gói tin HTTP. Phương
thức POST có 2 ưu điểm so với GET là :

20


-

Phương thức POST không giới hạn kích thước vùng dữ liệu gửi lên
server.

-

POST gửi dữ liệu theo 1 dòng riêng nên không thể hiện thông tin cho
người dùng thấy trong URL.

HEAD là một phương thức gần giống với GET. Client gửi dữ liệu lên
server và đính kèm nó với URL. Tuy nhiên, trong gói tin hồi đáp của server cho
gói tin dạng HEAD này sẽ không có vùng BODY. HEAD được dùng chủ yếu để
lấy thông tin về một tài nguyên nào đó trên server, do đó trong gói tin trả lời
chúng ta thực chất không cần nội dung của file trên.
Thông tin Header:
Phần thứ 2 của một gói tin yêu cầu từ client là phần header. Giao thức
Http định nghĩa hơn 40 trường header. Một số trường thông dụng như Accept,
Cache-Control, Content-Type,... Các Header được đặt giá trị bằng hàm
setRequestProperty() .
Phần thân body:
Dữ liệu được chuyển từ client lên server thông qua phần body của gói tin
request. Như đã đề cập, GET gộp phần body vào URL còn POST gửi phần body
trong 1 stream riêng biệt.
Khi client đã đóng gói một gói tin gồm phương thức yêu cầu, phần header,
phần body và gửi đến server, server có trách nhiệm phân tích gói tin, xử lí và hồi
đáp client. Phần hồi đáp của server cũng gồm 3 phần: status line, header, body.

Status line:
Phần status line cho biết kết quả của gói tin yêu cầu từ phía client. Trong
HttpConnection, chúng ta có hơn 35 mã status hồi đáp. HTTP chia các mã hồi
đáp này thành 5 mục lớn:
-

1xx – Thông tin.

-

2xx – Mã báo thành công.

-

3xx – Chuyển hướng.
21


-

4xx - Lỗi từ phía client.

-

5xx - Lỗi từ phía server
CHƯƠNG II: CÔNG NGHỆ WEB SERVICE

2.1. Định nghĩa
Một Web Service được định nghĩa là một tập các phương thức có thể được
định vị thông qua địa chỉ URL, các phương thức này được công bố trên hệ thống

mạng và được dùng như những khối cơ bản để xây dựng một ứng dụng phân tán
(Trích sách: Developing XML Web Service using Microsoft Visual Studio
.NET). Nói một cách đơn giản hơn, Web Service là tập hợp các phương thức có
thể được các ứng dụng khác triệu gọi từ xa (RPC- Remote Procedure Call) để
hình thành nên 1 hệ ứng dụng phân tán.
2.2. Hoạt động của Web Service

Hình 2.1 Hoạt động của Web Service
Một ứng dụng Web Service thường bao gồm 2 phần: client và server.
Client và server sẽ giao tiếp với nhau theo giao thức HTTP: ứng dụng
client sẽ gửi những lời gọi hàm đến server thông qua các gói tin HTTP request và

22


kết quả thực thi hàm sẽ được server hồi đáp thông qua các gói tin HTTP
response.
SOAP:
SOAP- Simple Object Access Protocol
Các thông điệp sẽ được định dạng theo chuẩn giao thức SOAP. Đây thực
chất cũng chỉ là một ngôn ngữ được định nghĩa bên trên ngôn ngữ XML có sẵn.
WSDL:
WSDL- Web Service Definition Language
Đây là file XML chứa các định nghĩa về các hàm trong Web Service
tương ứng. Các nhà phát triển ứng dụng sẽ phải dựa vào nội dung file này để biết
Web Service hỗ trợ những hàm nào và những tham số tương ứng, kết quả trả về
như thế nào.
Nếu chúng ta phát triển Web Service trong môi trường J2ME thì không
nhất thiết phải hiểu rõ cấu trúc về file WSDL, vì trong bộ công cụ Wireless
Toolkit của Sun đã cung cấp sẵn công cụ Stub Generator. Chức năng của bộ công

cụ này là đọc file WSDL và phát sinh ra những lớp java tương ứng cho nhà phát
triển ứng dụng.
UDDI:
UDDI- Universal Description, Discovery, and Integration.
Đây là công cụ giúp cho những nhà phát triển Web Service công bố những
thông tin về Web Service của mình cho cộng đồng các nhà phát triển ứng dụng.
Người dùng sẽ dựa vào những thông tin này để sử dụng Web Service trong ứng
dụng riêng của mình để tạo thành một hệ ứng dụng phân tán.
Mối quan hệ giữa các thành phần SOAP, WSDL, UDDI có thể được mô tả
như sau:

23


Hình 2.2: Mối quan hệ giữa các thành phần của Web Service.

Một ứng dụng Web Service client cần sử dụng một Web Service được đặt
tại một nơi nào đó trên hệ thống mạng. Trước tiên, client này sẽ truy vấn đến các
mẫu tin UDDI, có thể theo tên, loại hay một thông tin riêng biệt nào đó. Khi đã
xác định được Web Service cần tìm, client có thể lấy thông tin về địa chỉ của tài
liệu WSDL của Web Service này dựa trên mẫu tin UDDI. Tài liệu WSDL sẽ mô
tả cách thức liên lạc với Web Service, định dạng của gói tin truy vấn và phản hồi
theo cũng được mô tả bằng XML schema. Dựa vào những thông tin này client có
thể tạo những gói tin SOAP tương ứng để liên lạc với server.
2.3. Ưu điểm của Web Service
Web Service có nhiều ưu điểm hơn so với những mô hình ứng dụng phân
tán khác. Ưu điểm này được cấu thành bởi chính những thành phần tạo nên Web
Service.
-

Khả năng vượt firewall:

Web Service hoạt động trên nền giao thức HTTP nên cũng sử dụng luôn
port 80 dành cho web. Đây là một ưu điểm rất lớn của Web Service đối với các
phương thức gọi hàm từ xa khác; với các hình thức cũ hơn chúng ta thường phải
dùng các port tự quy định dẫn đến không thể hoạt động được ở một số tổ chức vì
quản trị mạng không cho phép vượt qua firewall. Web Service sử dụng port
“well- known” 80, đây là port hầu như tất cả các firewall đều cho phép đi qua
nên Web Service có thể hoạt động ở mọi nơi.
-

Hoạt động trên đa môi trường:
24


Web Service dựa trên nền công nghệ XML, tài liệu XML hiện nay được
hỗ trợ bởi tất cả các hệ điều hành, kể cả trên môi trường di động (vì chỉ là những
file text đơn thuần). Do đó Web Service có thể hoạt động trên mọi môi trường,
được hỗ trợ bởi hầu như mọi ngôn ngữ lập trình. Tuy nhiên chúng ta cũng phải
trả giá cao về điều này: do truyền dữ liệu dưới dạng text nên độ trễ của Web
Service sẽ cao và băng thông chiếm dụng cũng nhiều hơn so với các hình thức
chuyển dữ liệu nhị phân.
-

Tính linh hoạt, dễ chuyển đổi:

Web Service chỉ đơn thuần chuyển dữ liệu mà không kèm những tag định
dạng ngôn ngữ HTML. Đấy là ưu điểm của Web Service so với các trang web
thông thường. Khi cần thêm hay bớt một chức năng của Web Service đó đơn
thuần là thêm hay bớt 1 hàm, chúng ta không phải xây dựng lại giao diện như với

các trang web. Các client khi nhận được tín hiệu sẽ tùy ứng vào năng lực của
mình mà thể hiện thông tin hợp lí, điều này làm Web Service thực sự linh hoạt
hơn trang web. Ngoài ra việc không truyền đi các dữ liệu định dạng làm giảm đi
chi phí đáng kể trên đường truyền so với trang web.
2.4. Các thành phần chính của Web Service
Web Service dựa vào khá nhiều công nghệ bên dưới như HTTP, XML,
SOAP,... Mỗi công nghệ nêu trên đều có phạm vi ứng dụng khá sâu rộng và đòi
hỏi nhiều thời gian tìm hiểu cũng như trình bày. Báo cáo chỉ xin giới thiệu những
nét cơ bản và sơ lược về các công nghệ chính. Việc trình bày nhằm mục đích
cung cấp cái nhìn khái quát hơn về Web Service.
2.4.1. SOAP
SOAP (Simple Object Access Protocol) là một giao thức đơn giản nhằm
mục đích trao đổi thông tin trong môi trường ứng dụng phân tán. SOAP dựa trên
nền công nghệ XML và bao gồm 2 thành phần:
-

Một “bì thư” (envelop) để quản lí các thông tin mở rộng và mang tính
điều khiển.

-

Một chuẩn mã hóa quy định cách thể hiện thông tin trong envelop.
25