LUẬN văn MẠNG máy TÍNH xây dựng hệ thống thông tin hợp tác ứng cho lĩnh vực hàng không

 Quản lý thông tin các dịch vụ mà các hãng hàng không cung cấp: tìm vé, đặt vé, trả vé, đổi vé…  Quản lý dữ liệu chung giữa các hệ thống: các hành trình bay.. Vì thế, hệ thống thông ti

Trang 3

NHẬN XÉT CỦA GIÁO VIÊN HƯỚNG DẪN

………

Trang 4

NHẬN XÉT CỦA CÁN BỘ PHẢN BIỆN

………

Trang 5

LỜI CẢM ƠN



Việc làm chung đề tài luận văn này thật sự là một cơ duyên với chúng tôi

vì ban đầu chúng tôi không định làm với nhau và làm đề tài này Nhưng từ khi tìm hiểu sâu hơn và bắt tay vào thực hiện thì chúng tôi luôn cảm thấy thích thú

và cố gắng cùng nhau thực hiện tốt nó bằng tất cả sự đam mê, sức lực của mình

Nhìn lại những kỳ niên luận trước đã cho chúng tôi rất nhiều kinh nghiệm hữu ích, nhưng đứng trước một vấn đề mới, một thách thức mới lần này, chúng tôi không thể nào tự giải đáp những vướng mắc của mình nếu như không có sự giúp đỡ tận tình của Thầy Nguyễn Phú Trường Qua trang giấy nhỏ, chúng tôi xin được chân thành nói lời cảm ơn Thầy: “Cảm ơn Thầy đã ân cần dìu dắt chúng em

từ những buổi đầu bỡ ngỡ cho đến nay đã hoàn thành trọn vẹn đề tài!”

Chúng tôi cũng xin được cảm ơn các Thầy: Lê Quyết Thắng, Nguyễn Công Huy, Cù Vĩnh Lộc, Võ Đình Duy thuộc khoa CNTT và TT, đã cho chúng tôi những lời tư vấn quý báu về đề tài và hướng phát triển của nó Và sâu sắc nhất, chúng tôi xin được gửi lời biết ơn đến gia đình, những người luôn đứng sau ủng

hộ, động viên chúng tôi, và tạo điều kiện để chúng tôi có thể hoàn thành bước khó khăn nhất này

Khoảng thời gian mười lăm tuần không đủ dài để chúng tôi làm đề tài này tốt hơn nhưng chúng tôi đã hoàn thành được những mục tiêu đề ra và học được thêm nhiều điều bổ ích Ngoài việc tiếp cận phân tích và tìm hiểu những điểm hay của những hệ thống sẵn có, chúng tôi còn tạo ra được một hệ thống mô phỏng lại của riêng mình Nói chung, về chuyên môn, chúng tôi đã tích lũy được phần nào kiến thức bổ ích Nhưng bên cạnh kết quả cuối cùng là chương trình demo

và quyển báo cáo mà chúng tôi đã rất vất vả bên nhau mới có được, những xung đột nhỏ, những nụ cười và những buổi cơm trưa ăn cùng nhau thực sự là chuỗi ngày giúp chúng tôi hiểu thêm về kỹ năng sống và tình bạn Xin được cảm ơn tất

cả mọi người! Cảm ơn kỳ luận văn này đã làm cho cuộc sống chúng tôi thêm thú

vị và ý nghĩa hơn!

Nguyễn Hữu Hậu

Trang 6

MỤC LỤC

NHẬN XÉT CỦA GIÁO VIÊN HƯỚNG DẪN i

NHẬN XÉT CỦA CÁN BỘ PHẢN BIỆN iv

LỜI CẢM ƠN v

MỤC LỤC vi

KÝ HIỆU VÀ VIẾT TẮT ix

TÓM TẮT x

ABSTRACT x

TỪ KHÓA xi

CHƯƠNG 1 TỔNG QUAN 1

1.1 Đặt vấn đề 1

1.1.1 Đặt vấn đề 1

1.1.2 Định nghĩa vấn đề 1

1.2 Lịch sử giải quyết vấn đề 2

1.3 Mục tiêu đề tài 2

1.4 Phạm vi của đề tài 2

1.4.1 Phạm vi chức năng 2

1.4.2 Phạm vi triển khai 2

1.5 Phương pháp nghiên cứu 3

1.5.1 Hướng giải quyết 3

1.5.2 Kế hoạch thực hiện 3

1.5.3 Phân công công việc 4

CHƯƠNG 2 CƠ SỞ LÝ THUYẾT 10

2.1 XML 10

2.1.1 Giới thiệu XML 10

2.1.2 Cây XML (XML Tree) 10

2.1.3 Cú pháp XML 11

2.1.4 Những phần tử XML 12

2.1.5 Những thuộc tính XML 13

2.1.6 Xác nhận hợp lệ XML 15

2.2 XML schema 15

2.2.1 Giới thiệu XML Schema 15

2.2.2 Tại sao sử dụng XML Schema 16

Trang 7

2.2.3 Sử dụng XML Schema thế nào 16

2.3 SOAP 17

2.3.1 Giới thiệu giao thức SOAP 17

2.3.2 Cú pháp thông điệp SOAP 18

2.3.3 Các phần tử trong thông điệp SOAP 19

2.4 WSDL 23

2.4.1 Giới thiệu WSDL 23

2.4.2 Tài liệu WSDL 23

2.4.3 WSDL porttype 25

2.4.4 Gắn kết WSDL 27

2.5 Dịch vụ Web 27

2.5.1 Giới thiệu Dịch vụ Web 27

2.5.2 Những phần tử nền tảng của Dịch vụ Web 28

2.5.3 Tại sao sử dụng Dịch vụ Web 28

2.6 Bảo mật 29

2.6.1 Giới thiệu tiêu chuẩn mã hóa tiên tiến 29

2.6.2 Giới thiệu giải thuật băm MD5 29

2.6.3 Giới thiệu HMAC 33

2.7 Mô hình MVC 34

2.7.1 Giới thiệu mô hình MVC 34

2.7.2 Php FrameWork dựa trên MVC 35

2.8 Dữ liệu chuẩn 36

CHƯƠNG 3 NỘI DUNG VÀ KẾT QUẢ NGHIÊN CỨU 37

3.1 Thu thập thông tin 37

3.1.1 Thông tin cung cấp cho HTTTHT 37

3.1.2 Thông tin xuất ra từ HTTTHT 38

3.2 Thiết kế các mô hình 38

3.2.1 Xây dựng mô hình hoạt động chung của hệ thống 38

3.2.2 Thiết kế mô hình xử lý DFD 46

3.2.2.1 DFD cấp 0 46

3.2.2.2 DFD cấp 1 47

3.2.2.3 DFD cấp 2 48

3.3 Xây dựng các hệ thống 52

3.3.1 Giả lập các hệ thống hãng hàng không 52

Trang 8

3.3.1.1 Mô hình mức quan niệm (CDM) 52

3.3.1.2 Mô hình mức vật lý (PDM) 53

3.3.1.3 Các bảng dữ liệu 54

3.3.1.4 Mô tả các dịch vụ cung cấp 60

3.3.2 Xây dựng Cooperation Management System 61

3.3.2.5 Thiết kế website cho Cooperation Managerment System 68

3.3.3 Xây dựng Controller System 70

3.3.4 Thiết kế website cho virtual airlines 73

3.4 Giới thiệu sản phẩm 75

3.5 Thảo luận kết quả 94

KẾT LUẬN VÀ ĐỀ NGHỊ 95

Kết luận 95

Hướng phát triển 95 PHỤ LỤC I Yêu cầu phần cứng I Hướng dẫn cài đặt I TÀI LIỆU THAM KHẢO III

Trang 9

KÝ HIỆU VÀ VIẾT TẮT

HTTTHT: Hệ Thống Thông Tin Hợp Tác

HTTTTV: Hệ Thống Thông Tin Thành Viên

HHKTV: Hãng Hàng Không Thành Viên

IATA: International Air Transport Association

CDM: Conceptual Data Model

PDM: Physical Data Model

DFD: Data Flow Diagram

HMAC: Hash Message Authentication Code

Trang 10

TÓM TẮT

Luận văn nghiên cứu về công nghệ Dịch vụ Web (Web Services) để xây dựng

hệ thống thông tin hợp tác cho ngành hàng không Với mục đích liên kết các hệ thống hãng hàng không để mở rộng mạng lưới các chuyến bay, chúng tôi thiết kế một hệ thống trung gian để cộng tác dữ liệu từ các hệ thống hãng hàng không Trong luận văn chúng tôi tập trung vào các vấn đề chính sau:

1) Xây dựng mô hình hoạt động cho hệ thống thông tin hợp tác trong ngành hàng không

2) Thể hiện hai chức năng tìm vé và đặt vé trên hệ thống thông tin hợp tác

ABSTRACT

This thesis studies about Web Service technology for building the cooperation information system in aeronautic In order to link the aeronautics’ system to extend the flight network, we build an intermediate system to co-operate data from the aerounautic’s system In the dissertation, we focus on 2 main problems:

1) Designing the operational model of the aeronautical corporation information system

2) Performing 2 functions: searching and booking tickets on the cooperation information system

Trang 11

TỪ KHÓA

Hệ thống thông tin hợp tác (cooperation information system): Là một hệ

thống trung gian cho các hệ thống sẵn có (các hệ thống thông tin thành viên) Vai trò của hệ thống này là quản lý việc cộng tác dữ liệu giữa các hệ thống thông tin thành viên

Hệ thống thông tin thành viên: là hệ thống sẵn có trong thực tế, hệ thống này

tham gia chia sẻ dữ liệu với của các hệ thống thông tin thành viên khác thông qua hệ thống thông tin hợp tác

Hãng hàng không ảo (virtual airline): là một tổ chức chuyên bán vé cho các

hãng hàng không trong liên minh

Liên minh hàng không: là một tổ chức trong lĩnh vực hàng không, bao gồm

các thành viên là các hãng hàng không Hiện tại trên thế giới có ba liên minh hàng không lớn: Star alliance, SkyTeam, One world

Hành trình: là một chuỗi các chuyến bay nối tiếp nhau đưa hành khách đến

một nơi nào đó

Lịch biểu chuyến bay (schedule): là những chuyến bay được các hãng hàng

không thiết lập trước

Controller System: là một hệ thống con của hệ thống thông tin hợp tác Hệ

thống này là trung tâm tiếp nhận mọi yêu cầu từ các thành viên trong liên minh, điều hướng xử lý và thực hiện những thao tác xử lý Sau đó, hệ thống trả về kết quả theo yêu cầu tương ứng

Cooperation Management System: là một hệ thống con của hệ thống thông

tin hợp tác Hệ thống có vai trò là quản lý mọi thông tin của các hệ thống thông tin thành viên

Trang 12

DANH MỤC HÌNH

Hình 2.6.2.a Sơ đồ vòng lặp chính MD5

Hình 2.6.2.b Sơ đồ một vòng lặp MD5

Hình 2.6.3.a Nguyên tắc sinh mã xác nhận

Hình 2.7.1.a Sơ đồ hoạt động cơ bản của mô hình MVC

Hình 2.7.2.a Mô hình MVC ứng dụng trong PHP

Hình 3.2.1.a Mô hình hoạt động hệ thống thông tin hợp tác

Hình 3.2.1.b Mô tả tiến trình tìm vé

Hình 3.2.1.c Mô tả tiến trình đặt vé

Hình 3.2.1.d Mô tả quá trình tạo dữ liệu gửi

Hình 3.2.1.e Mô tả quá trình xác thực dữ liệu

Hình 3.2.1.f Mô tả cơ chế xác thực dữ liệu

Hình 3.2.2.1.a DFD cấp 0

Hình 3.2.2.2.a DFD cấp 1

Hình 3.2.2.3.a Phân rã ô xử lý Manage Cooperation

Hình 3.2.2.3.b Phân rã ô xử lý Manage reports

Hình 3.2.2.3.c Nhóm ô xử lý tìm vé

Hình 3.2.2.3.d Nhóm ô xử lý đặt vé

Hình 3.2.2.3.e Nhóm ô xử lý thanh toán

Hình 3.2.2.3.f Nhóm ô xử lý trả vé

Hình 3.2.2.3.g Nhóm ô xử lý thay đổi hành trình bay

Hình 3.3.1.1.a Mô hình mức quan niệm của hệ thống hàng không

Hình 3.3.1.2.a Mô hình mức vật lý của hệ thống hãng hàng không

Hình 3.3.2.1.a Mô hình mức quan niệm của Cooperation Management System Hình 3.3.2.2.a Mô hình mức vật lý của hệ thống hãng hàng không

Hình 3.3.2.5.a Sơ đồ trang web quản trị

Hình 3.3.2.5.b Giao diện trang chủ website quản trị

Hình 3.3.3.1.a Mô hình mức quan niệm của hệ thống Controller

Hình 3.3.3.2.a Mô hình mức vật lý của hệ thống Controller

Hình 3.4.a Lưu đồ giải thuật phương thức book

Hình 3.4.b Lưu đồ phương thức getLinkBookingList

Hình 3.4.c Lưu đồ giải thuật phương thức insertToTicket

Hình 3.4.d Lưu đồ giải thuật phương thức insertToMFTicket

Hình 3.4.e Mô tả Dịch vụ book ở Controllers_System trong tập tin WSDL

Hình 3.4.g Mô tả Dịch vụ getKey trong tập tin WSDL

Hình 3.4.h Lưu đồ giải thuật phương thức getListOfAirlineID

Hình 3.4.i Mô tả Dịch vụ getListOfAirline trong tập tin WDSL

Hình 3.4.j Lưu đồ giải thuật phương thức getServedSchedule:

Hình 3.4.k Hình mô tả Dịch vụ getSchedule ở các hãng airline

Hình 3.4.l Lưu đồ giải thuật phương thức Book

Hình 3.4.m Hình mô tả Dịch vụ book được cài đặt ở các hãng airline

Hình a: Sơ đồ trao đổi dữ liệu nhau thông qua hệ thống trung gian

Hình b: Sơ đồ trao đổi dữ liệu nhau thông qua hệ thống trung gian

Trang 13

đề đặt ra trong thực tế đòi hỏi phải có sự hợp tác với nhau để chia sẻ dữ liệu vì mục đích chung, lợi ích chung cho các chủ thể của hệ thống và yêu cầu ngày càng cao của người dùng Việc chia sẻ dữ liệu qua lại giữa các hệ thống thông tin cần có sự tham

gia của một hệ thống trung gian - hệ thống thông tin hợp tác Hệ thống này được

xây dựng để quản lý các thành viên tham gia (các HTTTTV), dữ liệu chia sẻ và đảm bảo việc trao đổi dữ liệu được an toàn

Hiện nay trên thế giới có rất nhiều hãng hàng không đang hoạt động giúp cho hành khách có thể đi lại tiện lợi và tiết kiệm nhiều thời gian Tuy nhiên, hành khách vẫn thấy khó khăn mỗi khi phải bay quá cảnh nhiều chuyến vì phải truy cập nhiều website của từng hãng hàng không độc lập để tìm những chuyến bay và tự sắp lịch mới có thể đi đến nơi mình mong muốn Yêu cầu đã được đặt ra cho ngành hàng không là cần có sự liên kết các hãng lại để đơn giản hóa việc tìm hành trình hợp lý

cho hành khách Đề tài luận văn: Xây dựng hệ thống thông tin hợp tác ứng dụng cho lĩnh vực hàng hàng không là một ví dụ minh họa cho việc xây dựng một HTTTHT

cho liên minh hàng không để giải quyết vấn đề nêu trên

1.1.2 Định nghĩa vấn đề

Vì các hệ thống thông tin hoạt động độc lập cho nên dữ liệu của các hệ thống

đó cũng được lưu trữ độc lập với cách thức và cấu trúc khác nhau Chúng ta cần xây dựng một hệ thống trung gian để thu thập dữ liệu từ các hệ thống ấy, sau đó xử lý chúng và phục vụ cho người dùng Trong ngành hàng không, những dữ liệu phân tán

đó là các lịch bay, HTTTHT sẽ nối kết các chuyến bay lại thành những hành trình phù hợp với yêu cầu của hành khách

Việc trao đổi dữ liệu giữa hệ thống sẵn có phải dựa vào giao thức, cơ chế trên một nền tảng công nghệ nhất định Trong thực tế, các hệ thống sẵn có thường không đồng nhất về dữ liệu cũng như nền tảng công nghệ và ngôn ngữ HTTTHT cần phải giải quyết những vấn đề tương thích này Ngoài ra, việc trao đổi dữ liệu giữa các hệ thống phải đảm bảo an toàn Tức là dữ liệu trao đổi phải đảm bảo tính toàn vẹn, chống phủ nhận và bảo mật

HTTTHT trong ngành hàng không phải đảm bảo cung cấp các chức năng sau:

 Quản lý thông tin các HHKTV tham gia vào liên minh hàng không

 Quản lý thông tin các dịch vụ mà các hãng hàng không cung cấp: tìm vé, đặt vé, trả vé, đổi vé…

 Quản lý dữ liệu chung giữa các hệ thống: các hành trình bay

 Thể hiện được các tính năng mới: tìm hành trình, đặt vé cho hành trình…

Trang 14

1.2 LỊCH SỬ GIẢI QUYẾT VẤN ĐỀ

Hiện nay, trên thế giới có ba liên minh hàng không lớn là: Star Alliance, SkyTeam, One World Việc thành lập các liên minh đã mang lại nhiều lợi ích cho hành khách và cho các HHKTV

Các liên minh hàng không đã thể hiện rất tốt chức năng nối chuyến, tạo ra nhiều sự lựa chọn cho hành khách để đi đến nơi nào đó Hệ thống còn đảm bảo việc tìm các hành trình cho hành khách có sự ưu tiên về chi phí thấp nhất

Để gia nhập vào liên minh hàng không, các hãng hàng không thành viên phải đáp ứng được các yêu cầu: tiêu chuẩn dịch vụ khách hàng, mức độ an toàn và tuân thủ công nghệ Việc gia nhập liên minh phải thông qua các thủ tục, các hãng hàng không cung cấp thông tin của mình qua thủ tục đó

1.3 MỤC TIÊU ĐỀ TÀI

Đề tài chúng tôi nghiên cứu hướng đến các mục tiêu chính sau:

 Thể hiện được hai chức năng tìm hành trình bay và đặt vé trên website của hãng hàng không và website của công ty chuyên bán vé

 Xây dựng ứng dụng web cho việc cấu hình thông tin liên quan đến các hãng hàng không thành viên

 Việc trao đổi dữ liệu qua lại giữa các hệ thống cần phải đảm bảo an toàn

1.4 PHẠM VI CỦA ĐỀ TÀI

1.4.1 Phạm vi chức năng

Sự thành lập các liên minh hàng không có nhiều mục đích Tuy nhiên, trong

phạm vi đề tài chúng tôi chỉ quan tâm đến mục đích là mở rộng mạng lưới các hành

trình bay Chúng tôi sẽ xây dựng một hệ thống có hai chức năng chính là quản lý

thành viên trong liên minh và tương tác với hành khách

Quản lý thành viên trong liên minh: chức năng này dành cho người quản trị hệ thống trong liên minh hàng không, được thể hiện thông qua giao diện website người quản trị Người quản trị sẽ có một tài khoản để đăng nhập vào trang quản trị Tại đây

họ có thể cấu hình các thành viên trong liên minh thông qua các chức năng con của trang quản trị

Hệ thống tương tác với hành khách: hành khách có thể sử dụng các chức năng như tìm hành trình, đặt vé cho hành trình trên giao diện của website liên minh hàng không hay website của hãng hàng không

1.4.2 Phạm vi triển khai

Các hệ thống hãng hàng không trong thực tế sẽ không đồng nhất về dữ liệu

Vì thế, hệ thống thông tin hợp tác cần phải tích hợp tất cả các quy định về chia sẻ dữ liệu của từng hãng hàng không Mặt khác, các hệ thống hãng hàng không trong thực

tế cũng không đồng nhất về công nghệ, có thể các hệ thống cũ vẫn còn đang sử dụng công nghệ RMI, CORBA, DCOM… Với mục đích tái sử dụng lại hệ thống sẵn có, thì hệ thống thông tin hợp tác cần phải giao tiếp được với các hệ thống sẵn có ấy Tuy

Trang 15

nhiên, trong phạm vi đề tài chúng tôi sẽ giả lập các hệ thống sẵn có, cho nên mặc định

là các hệ thống sẵn có sẽ đồng nhất về dữ liệu và đồng nhất về công nghệ Vấn đề giải quyết việc không đồng nhất về dữ liệu và công nghệ sẽ nằm trong hướng mở rộng của đề tài

1.5 PHƯƠNG PHÁP NGHIÊN CỨU

1.5.1 Hướng giải quyết

- Tiến hành nghiên cứu đặc điểm của các hệ thống thông tin hiện tại: các hệ thống liên minh hàng không, các hệ thống hãng hàng không

- Xây dựng hệ thống thông tin hợp tác

- Kiểm thử hệ thống

- Cải tiến hệ thống

1.5.2 Kế hoạch thực hiện

Quy trình thực hiện Thời gian Mô tả quy trình

Khảo sát 2 tuần Tìm kiếm các nguồn thông tin

về liên minh hàng không trên mạng

Tìm kiếm các nguồn dữ liệu chuẩn trong ngành hàng không

Vào các trang web của các hãng hàng không để đặt vé

Phân tích và thiết kế 6 tuần Dựa vào các thông tin khảo

sát được phân tích cơ chế hoạt động chung của hệ thống Xác định các công nghệ cần sử dụng trong triển khai hệ thống

Thiết kế mô hình hoạt động chung cho hệ thống thông tin hợp tác

Thiết kế các mô hình CDM, PDM, DFD cho hệ thống thông tin hợp tác

Viết tài liệu cụ thể cho việc cài đặt hệ thống

Cài đặt 6 tuần Tiến hành cài đặt hệ thống

theo mô hình và theo tài liệu

cụ thể

Kiểm thử 2 tuần Kiểm thử sự hoạt động của hệ

thống

Trang 16

Báo cáo 4 tuần Viết quyển báo cáo cuối cùng

cho đề tài và báo cáo trước hội đồng

1.5.3 Phân công công việc

Bước khảo sát

STT Công việc Mô tả Ngày

khởi động dự kiến

Ngày khởi động thực tế

Số ngày thực tế

Người thực hiện

skyteam.

com, abay.vn, vietname airlines.c

hệ thống đáp ứng cho người dùng

2 Tìm kiếm các

dữ liệu chuẩn

Tham khảo nguồn dữ liệu chuẩn của các hiệp hội IATA, ICAO…

Có được dữ liệu theo chuẩn IATA(IATA code)

Bước phân tích và thiết kế

Trang 17

Viết tài liệu cho

mô hình hoạt động đã

mô tả cụ thể các dịch vụ được cài đặt trên từng hệ thống con

chữ ký

số, phong

bì số và giao thức chuẩn SSL, HMAC

cơ chế an toàn trong trao đổi

dữ liệu

Trang 18

ứng dụng vào hệ thống cho việc

an toàn trong trao đổi dữ liệu

Có được giải thuật nối chuyến bay

Bước cài đặt

an ninh trong trao đổi dữ liệu ở bước phân tích thiết kế

tả dịch vụ

đã lập ở bước

Trang 19

hãng hàng

không

phân tích thiết kế

tả dịch vụ

đã lập ở bước phân tích thiết kế

tả dịch vụ

tả và giải thuật cho việc tìm hành trình

tả dịch vụ

đã lập ở bước

Trang 20

phân tích thiết kế

rk đã xây dựng

Hoàn thành

Bước kiểm thử

Trang 21

của liên minh

Trang 22

CHƯƠNG 2 CƠ SỞ LÝ THUYẾT

Trong đề tài, chúng tôi có sử dụng các ngôn ngữ nền tảng của Dịch vụ Web như: XML, XML Schema, WSDL và giao thức SOAP, sẽ được giới thiệu lần lượt dưới đây

2.1 XML

2.1.1 Giới thiệu XML

XML được thiết kế để truyền tải và lưu trữ dữ liệu

- XML là viết tắt của cụm từ eXtensible Markup Language

- XML là một ngôn ngữ đánh dấu tương tự như HTML

- XML được thiết kế để mang theo thông tin, không để hiển thị thông tin

- Các thẻ của XML không được định nghĩa trước Chúng phải tự định nghĩa

Dòng đầu tiên là khai báo XML Nó định nghĩa XML version 1.0 và sử dụng

mã hóa ISO-8859-1 = Latin-1/West European character set Dòng tiếp theo mô tả một nút gốc của tài liệu <note> Bốn dòng kế tiếp định nghĩa những phần tử con của nút

gốc: to, from, heading, body.Và dòng cuối cùng cho biết là kết thúc của nút gốc

</note>

- Khuôn dạng tài liệu XML là một cấu trúc cây:

Trang 23

Tài liệu XML phải chứa đựng một phần tử gốc (root element) Nút gốc này là cha của những phần tử khác Những phần tử (element) trong một tài liệu XML tạo nên một cây Cây bắt đầu từ gốc và nhánh cho đến cấp thấp nhất của cây Tất cả các phần tử đều có thể có phần tử con của nó

Một tập hợp cha, con và anh em được dùng để diễn tả mối quan hệ giữa các phần tử Phần tử cha có những đứa con Những con trên cùng một mức được gọi là anh em (siblings) Tất cả những phần tử có thể chứa nội dung văn bản và các thuộc tính như HTML

- Thẻ XML thì phân biệt hoa thường:

Những thẻ XML phân biệt hoa thường Thẻ <Letter> sẽ khác thẻ <letter>

Thẻ mở và đóng phải được viết tương ứng giống nhau

<Message>This is incorrect</message>

<message>This is correct</message>

- Phần tử XML phải được lồng nhau đúng đắn:

Trong XML, tất cả những phần tử phải được lồng nhau đúng đắn trong những phần tử khác

This text is bold and italic

Trong ví dụ trên, “lồng nhau đúng đắn” chỉ đơn giản là từ thẻ được mở ra trong thẻ nó phải được đóng lại bên trong thẻ 

- Những tài liệu XML phải có phần tử gốc:

Tài liệu XML phải chứa một phần tử làm cha của tất cả các phần tử còn lại Phần tử này được gọi là phần tử gốc

- Thuộc tính của XML phải nằm trong cặp dấu nháy (đơn hoặc kép):

Trong XML, giá trị của thuộc tính phải luôn nằm trong cặp dấu nháy

Quan sát hai tài liệu XML phía dưới Tài liệu đầu là sai cú pháp, tài liệu thứ hai đúng cú pháp

Trang 24

Lỗi của tài liệu XML đầu tiên là do giá trị của thuộc tính date không nằm trong cặp dấu nháy

Tham chiếu những thực thể (thay thế một vài ký tự đặc biệt):

Một vài ký tự có ý nghĩa đặc biệt trong XML

Nếu chúng ta đặt một ký tự như “<” trong một XML nó sẽ gây ra lỗi bởi vì trình phân tích sẽ nghĩ nó là bắt đầu của một phần tử mới Ví dụ như:

<message>if salary < 1000 then </message>

Để tránh trường hợp này, thay thế ký tự “<” với một thực thể tham chiếu:

<message>if salary < 1000 then</message>

Có 5 tham chiếu thực thể được định nghĩa lại trong XML:

- Chú thích trong XML:

Cú pháp để viết chú thích trong XML thì giống như trong HTML

<! Đây là một chú thích >

- Khoảng trắng được giữ lại trong XML:

Với XML các khoảng trắng sẽ không bị xóa

XML lưu trữ dòng mới như là LF (Line Feed)

2.1.4 Những phần tử XML

Một tài liệu XML chứa đựng nhiều phần tử

Một phần tử XML là bất cứ những gì nó chứa đựng từ lúc mở thẻ mở cho tới lúc mở thẻ đóng

Trang 25

- Quy cách đặt tên XML (XML Naming Rules):

Những phần tử XML phải theo quy luật đặt tên sau:

 Tên có thể chứa những ký tự, số và những ký tự khác

 Tên không thể bắt đầu bởi số hoặc là dấu chấm câu

 Tên không thể bắt đầu bởi từ xml (hoặc là XML hoặc là Xml)

 Tên không thể chứa khoảng trắng

Bất cứ tên nào cũng có thể dùng được, không có những từ được quy định sẵn

 Những ký tự unicode là hợp lệ nhưng cũng không nên dùng vì có thể nhà cung cấp phần mềm chúng ta đang dùng không hỗ trợ chúng

- Các phần XML dễ dàng mở rộng để mang nhiều thông tin hơn nếu tài liệu

có thay đổi trong tương lai vì trình phân tích vẫn nhận dạng lại được những thẻ cũ

2.1.5 Những thuộc tính XML

Trang 26

Thuộc tính thường cung cấp thông tin nhưng thông tin đó không là một phần của dữ liệu Trong ví dụ dưới, loại file không liên quan gì đến dữ liệu, nhưng có thể quan trọng cho phần mềm để thao tác với phần tử

<file type="gif">computer.gif</file>

- Thuộc tính XML phải được đặt trong cặp dấu nháy

Giá trị của thuộc tính phải luôn luôn được đặt trong cặp dấu nháy Ví dụ:

<gangster name='George "Shotgun" Ziegler'>

Hoặc có thể dùng các thực thể thay thế ký tự đặc biệt:

<gangster name="George "Shotgun" Ziegler">

Trong ví dụ đầu tiên sex là một thuộc tính Trong ví dụ sau, sex là một phần

tử Cả hai trường hợp đều cung cấp thông tin giống nhau

Không có luật quy định khi nào dùng thuộc tính hay là dùng phần tử nhưng trong XML nên tránh dùng thuộc tính thay vào đó hãy dùng phần tử

- Tránh dùng thuộc tính XML:

Một số bất lợi là:

 Thuộc tính thì không thể chứa những dữ liệu khác nhau (phần tử có thể)

 Thuộc tính thì không thể chứa cấu trúc cây (phần tử có thể)

 Thuộc tính không dễ mở rộng (nếu thay đổi ở tương lai)

Thuộc tính khó đọc và khó điều chỉnh Sử dụng phần tử cho dữ liệu Sử dụng thuộc tính cho thông tin mà nó không liên quan tới dữ liệu

- Thuộc tính cho siêu dữ liệu:

Đôi khi tham chiếu ID được gán cho những phần tử Những ID này có thể dùng để xác định những XML phần tử Ví dụ dưới tập trung vào đó:

<messages>

<note id="501">

<to>Tove</to>

<from>Jani</from>

Trang 27

XML với cú pháp đúng gọi là đúng dạng (Well Formed XML)

XML được xác nhận tính hợp lệ theo DTD gọi là hợp lệ (Valid XML)

2.2.1 Giới thiệu XML Schema

Một XML Schema mô tả một cấu trúc của một tài liệu XML

Ngôn ngữ XML Schema cũng được gọi như XML Schema Definition (XSD) Mục đích của một XML Schema là để định nghĩa những khối (block) XML đúng đắn cũng giống như DTD

- Một XML Schema:

 Định nghĩa những phần tử mà chúng có thể xuất hiện trong một tài liệu

 Định nghĩa các thuộc tính có thể xuất hiện trong tài liệu

 Định nghĩa những phần tử nào là phần tử con

 Định nghĩa thứ tự của những phần tử

 Định nghĩa số lượng của những phần tử con

 Định nghĩa một phần tử là rỗng hay có thể chứa văn bản

 Định nghĩa kiểu dữ liệu cho những phần tử và thuộc tính

 Định nghĩa các giá trị mặc định và giá trị cố định cho những phần tử hoặc thuộc tính

- XML Schema là người thừa kế của DTD:

Chúng ta thấy rằng XML Schema sớm được sử dụng trong hầu hết các ứng dụng Web như một sự thay thế cho DTD

- Dưới đây là một số nguyên nhân:

 XML Schema thì dễ mở rộng cho sự bổ sung ở tương lai

 XML Schema giàu có và mạnh hơn DTD

 XML Schema được viết trong XML

 XML Schema hỗ trợ nhiều kiểu dữ liệu

 XML Schema hỗ trợ nhiều không gian tên

Trang 28

- XML Schema là một khuyến nghị của W3C:

XML Schema trở thành một khuyến nghị của tổ chức W3C từ ngày 2 tháng 5 năm 2001

2.2.2 Tại sao sử dụng XML Schema

- XML Schema hỗ trợ nhiều loại dữ liệu

Một điều hết sức tuyệt vời của XML Schema là hỗ trợ cho nhiều kiểu dữ liệu

- Với sự hỗ trợ cho nhiều dữ liệu này:

 Sẽ dễ hơn để mô tả nội dung cho phép

 Dễ xác thực tính chính xác của dữ liệu hơn

 Dễ làm việc với dữ liệu từ CSDL hơn

 Dễ định nghĩa những hạn chế dữ liệu hơn (restrictions on data)

 Dễ định nghĩa những mẫu dữ liệu hơn (data paterns)

 Dễ dàng hơn trong việc chuyển đổi dữ liệu từ những kiểu dữ liệu khác nhau

- XML Schema sử dụng cú pháp XML:

- Một sức mạnh tuyệt vời nữa của XML Schema là nó được viết bằng XML Một vài lợi ích của XML Schema được viết bằng XML:

- XML Schema bảo mật dữ liệu liên lạc:

Khi dữ liệu được gửi từ người gửi đến người nhận, sẽ rất cần thiết để hai bên

có thể nhận được dữ liệu như mong đợi Với XML Schema, người gửi có thể mô tả

dữ liệu trong cách người nhận sẽ hiểu

- XML Schema dễ dàng mở rộng:

Vì nó được viết bằng XML, chúng ta có thể:

 Sử dụng lại Schema của chúng ta trong những Schema khác

 Tự tạo kiểu dữ liệu của chúng ta từ những kiểu chuẩn

 Liên hệ tới nhiều Schema trong một tài liệu

- Đúng dạng (Well-formed) thì chưa đủ

Dù tài liệu đã đúng dạng nó vẫn có thể chứa nhiều lỗi Và những lỗi này có thể gây ra hậu quả nghiêm trọng

2.2.3 Sử dụng XML Schema thế nào

Tài liệu XML có thể có một tham chiếu tới một DTD hoặc một XML Schema

- Một tài liệu XML đơn giản:

Quan sát tài liệu "note.xml" đơn giản dưới đây:

Trang 29

Ví dụ dưới đây là một XML Schema tên "note.xsd" nó định nghĩa những phần

tử của tài liệu XML trên (“note.xml”)

<xs: element name="to" type="xs:string"/>

<xs: element name="from" type="xs:string"/>

<xs: element name="heading" type="xs:string"/>

<xs: element name="body" type="xs:string"/>

</xs:sequence>

</xs:complexType>

</xs: element >

</xs:schema>

- Một tham chiếu tới một XML Schema:

Tài liệu XML trên có một tham chiếu tới một XML Schema:

2.3.1 Giới thiệu giao thức SOAP

Việc trao đổi, liên lạc giữa các ứng dụng thông qua mạng Internet rất quan trọng trong việc phát triển ứng dụng Ngày nay, sự liên lạc ấy thường sử dụng lời gọi thủ tục từ xa (Remote Procedure Calls - RPC) giữa các đối tượng như DCOM và CORBA nhưng giao thức HTTP không được thiết kế để thực hiện việc đó Lời gọi thủ tục từ xa gặp vấn đề ở tính tương thích và bảo mật bởi vì các tường lửa (firewalls)

và các máy chủ proxy (proxy servers) thường chặn dòng giao thông này

Một cách tốt hơn để giao tiếp giữa các ứng dụng là thông qua giao thức HTTP

vì HTTP được hỗ trợ bởi tất cả những trình duyệt và các máy chủ SOAP được tạo ra

để thực hiện chức năng này

Trang 30

SOAP cung cấp một cách giao tiếp giữa các ứng dụng chạy trên những hệ điều hành khác nhau, những công nghệ khác nhau và ngôn ngữ lập trình khác nhau

- SOAP là viết tắt của cụm từ Simple Object Access Protocol (giao thức đơn giản để truy cập đối tượng)

- SOAP là một giao thức liên lạc

- SOAP là sự liên lạc giữa các ứng dụng

- SOAP là định dạng cho việc gửi thông điệp

- SOAP liên lạc thông qua mạng Internet

- SOAP là một nền tảng không phụ thuộc

- SOAP là một ngôn ngữ độc lập

- SOAP dựa vào nền tảng XML

- SOAP đơn giản và dễ dàng mở rộng phát triển

- SOAP cho phép chúng ta vượt qua tường lửa

- SOAP là một khuyến nghị của tổ chức W3C

2.3.2 Cú pháp thông điệp SOAP

Những khối của thông điệp SOAP (SOAP Building Blocks):

- Một thông điệp SOAP (SOAP message) là một tài liệu XML thông thường, chứa những phần tử sau:

 Một phần tử bao (Envelope element) để xác định tài liệu XML như một thông điệp SOAP

 Một phần tử đầu trang (Header element) chứa thông tin đầu trang

 Một phần tử thân (Body element) chứa đựng phần gọi (call) và thông tin trả về (response) từ Dịch vụ Web

 Một phần tử lỗi (Fault element) chứa những lỗi và trạng thái của thông tin

Tất cả những thông tin được khai báo mặc định trong không gian tên mặc định dành cho SOAP envelope

Dưới đây là một vài cú pháp quan trọng:

 Một thông điệp SOAP phải được mã hóa bằng XML

 Một thông điệp SOAP phải sử dụng không gian tên dành cho Envelope

 Một thông điệp SOAP phải dùng không gian tên Encoding

 Một thông điệp SOAP không được chứa đựng một sự tham chiếu DTD

 Một thông điệp SOAP không được chứa đoạn xử lý lệnh XML

- Bộ khung thông điệp SOAP (Skeleton SOAP messgage)

<?xml version="1.0"?>

<soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

Trang 31

Không gian tên xmls:soap

Chú ý không gian tên xmls:soap trong ví dụ trên, nó luôn luôn có giá trị:

"http://www.w3.org/2001/12/soap-envelope"

Thuộc tính encodingStyle:

Thuộc tính encodingStyle được dùng để định nghĩa kiểu dữ liệu sử dụng trong

tài liệu, Thuộc tính này có thể xuất hiện ở bất cứ phần tử nào của thông điệp SOAP,

và thiết lập giá trị cho nội dung chính nó cùng tất cả phần tử con

Trang 32

Phần tử chứa những thông tin bổ sung như thông tin xác thực (authentication), chi trả (payment),

Nếu phần tử đầu trang hiện diện, nó phải là phần tử con đầu tiên trong một phần tử bao

Lưu ý: Tất cả những con của phần tử đầu trang phải có không gian tên rõ ràng

Ví dụ trên chứa đựng một đầu trang với phần tử "Trans", một thuộc tính

"mustUnderstand" với giá trị 1, và một giá trị của 234

- Thuộc tính mustUnderstand:

Thuộc tính mustUnderstand của SOAP có thể dùng để chỉ đầu trang là bắt

buộc hay là bổ sung để xử lý

- Nếu chúng ta thêm mustUnderstand = "1" cho một phần tử con nào của phần

tử đầu trang thì đối tượng nhận xử lý thông điệp phải nhận ra được phần tử con đó Nếu không phần tử con đó sẽ bị hỏng khi thực thi đầu trang

Trang 33

đến điểm dừng cuối cùng Thay vào đó, nó được chỉ định gửi cho một hay nhiều điểm dừng trong đường đi thông điệp

Thuộc tính encodingStyle được dùng để định nghĩa kiểu dữ liệu sử dụng trong

tài liệu Thuộc tính này có thể xuất hiện trên bất cứ phần tử SOAP nào và nó sẽ có hiệu lực đến nội dung của nó và tất cả những phần tử con

Thông điệp SOAP không có mã hóa mặc định

Cú pháp: soap:encodingStyle="URI"

- Phần tử thân:

Phần tử thân là một phần tử quan trọng, chứa nội dung thật sự của thông điệp SOAP đến điểm dừng cuối cùng của thông điệp Các phần tử con của nó có thể có không gian tên

Ví dụ trên yêu cầu giá của những quả táo Chú ý phần tử m:GetPrice và Item

ở trên là những phần tử được chỉ định thêm Chúng không phải là những phần của thông điệp SOAP

Một thông điệp SOAP phản hồi có thể thấy như sau:

<?xml version="1.0"?>

<soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

Trang 34

soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Body>

<m:GetPriceResponse xmlns:m="http://www.w3schools.com/prices"> <m:Price>1.90</m:Price>

</m:GetPriceResponse>

</soap:Body>

</soap:Envelope>

- Phần tử lỗi:

Phần tử lỗi là phần tử bổ sung, được dùng để chỉ ra lỗi thông điệp

Nếu một phần tử lỗi xuất hiện, nó phải xuất hiện như là một phần tử con của thân thông điệp Một phần tử lỗi có thể xuất hiện một lần trong thông điệp SOAP Phần tử lỗi có những phần tử con như sau:

Phần tử Mô tả

<faultcode> Một mã xác định lỗi

<faultstring> Người đọc có thể hiểu được lỗi

<faultactor> Thông tin về người làm xuất hiện lỗi

<detail> Giữ thông tin fault chỉ định liên quan đến phần tử thân [NHH2]

Các mã lỗi thông điệp SOAP:

VersionMissmatch Tìm thấy một không gian tên lỗi của phần tử bao

MusUnderstand Một phần tử con đầu tiên của phần tử đầu trang với thuộc tính

mustUnderstand ='1' nhưng không được hiểu Client Thông điệp không đúng dạng hoặc đã chứa thông tin sai

Server Có lỗi ở Server vì vậy thông điệp không được thực thi

- Gắn kết HTTP (SOAP HTTP Binding):

Giao thức HTTP:

HTTP liên lạc thông qua TCP/IP Một HTTP client kết nối đến một HTTP server qua giao thức TCP Sau đó thiết lập một kết nối Client có thể gửi một thông HTTP request đến server

Trang 35

Cú pháp: Content-Type: MIMEType; charset=character-encoding

Một tài liệu WSDL chỉ là một tài liệu XML đơn giản

Nó chứa đựng một tập định nghĩa để mô tả Dịch vụ Web

Cấu trúc của tài liệu WSDL:

Phần tử Mô tả

Trang 36

<types> Một hộp chứa định nghĩa kiểu dữ liệu được dùng bởi Dịch vụ

Web

<message> Một kiểu định nghĩa của dữ liệu được truyền

<portType> Một tập hợp các operations (các chức năng) hỗ trợ bởi một hoặc

Một tài liệu WSDL cũng có thể chứa những phần tử khác, như những phần tử

mở rộng (extension elements) và một phần tử dịch vụ (service element) sẽ làm cho

nó có mặt trong một nhóm các định nghĩa của nhiều Dịch vụ Web trong một tài liệu WSDL

Trang 37

Mỗi một thông điệp có thể bao gồm một hoặc nhiều phần nhỏ Những phần đó

có thể so sánh với những tham số khi gọi một hàm trong ngôn ngữ lập trình truyền thống

- WSDL types:

Phần tử <types> định nghĩa kiểu dữ liệu được dùng trong Dịch vụ Web

Cho nhiều nền tảng trung lập, WSDL sử dụng cú pháp XML Schema để định nghĩa kiểu dữ liệu

Operation "getTerm" có một thông điệp đầu vào được gọi là "getTermRequest"

và một thông điệp đầu ra gọi là "getTermResponse"

Những phần tử <message> định nghĩa những phần (part) của mỗi thông điệp

và những kiểu dữ liệu liên quan

So sánh với chương trình truyền thống, glossaryTerms là một thư việc hàm,

"getTerm" là một hàm "getTermRequest" là một tham số đầu vào, và getTermResponse như là một tham số trả về

2.4.3 WSDL porttype

Phần tử <portType> là phần tử WSDL quan trọng nhất

Phần tử <portType> định nghĩa một Dịch vụ Web, operation có thể thực hiện

và thông điệp có thể gọi

Trang 38

Request-response Operation có thể nhận request và có thể trả về một

<part name="term" type="xs:string"/>

<part name="value" type="xs:string"/>

Trang 39

Phần tử gắn kết (binding) có 2 thuộc tính -name và type

Thuộc tính name (chúng ta có thể dùng bất cứ tên nào chúng ta muốn) định

nghĩa tên của gắn kết, thuộc tính kiểu trỏ đến cổng (port) cho gắn kết, trong trường

hợp này là cổng "glossaryTerms"

Phần tử soap:binding có 2 thuộc tính: style và transport

Thuộc tính style có thể là “rpc” hoặc là “document” Trong trường hợp này chúng ta sử dụng document Thuộc tính transport định nghĩa giao thức SOAP sẽ sử dụng Trong trường hợp này chúng ta dùng HTTP

Phần tử operation định nghĩa mỗi operation được portType cho thấy

Với mỗi operation tương ứng SOAP action được định nghĩa Chúng ta phải

mô tả đầu vào (input) và đầu ra (output) được mô tả như thế nào Trong trường hợp

này chúng ta dùng “literal”

2.5 DỊCH VỤ WEB

2.5.1 Giới thiệu Dịch vụ Web

Dịch vụ Web có thể chuyển ứng dụng thành ứng dụng Web

Trang 40

Dịch vụ Web được ấn bản, tổ chức và sử dụng trực tiếp trên Web

- Dịch vụ Web là nhiều phần tử ứng dụng nhỏ

- Dịch vụ Web liên lạc bằng cách sử dụng những giao thức mở

- Dịch vụ Web là tự mô tả và tự diễn giải

- Dịch vụ Web có thể được tìm ra sử dụng UDDI

- Dịch vụ Web có thể được sử dụng bởi những ứng dụng khác

- XML là nền tảng của Dịch vụ Web

Nền tảng cơ sở của Dịch vụ Web là XML và HTTP

XML cung cấp một ngôn ngữ nó có thể được dùng bởi những nền tảng khác nhau và những ngôn ngữ lập trình khác nhau và vẫn có thể diễn tả những thông điệp

 UDDI được dựa trên Universal Description, Discovery and Integration

 UDDI là một thư mục để lưu trữ thông tin về Dịch vụ Web

 UDDI là một thư mục của giao diện Dịch vụ Web mô tả bởi WSDL

 UDDI liên lạc bằng SOAP

 UDDI được xây dựng trong nền tảng Net của Microsoft

2.5.3 Tại sao sử dụng Dịch vụ Web

Khả năng cộng tác có độ ưu tiên cao nhất:

Khi tất cả những nền tảng chính có thể truy cập Web sử dụng trình duyệt Web Những nền tảng khác nhau không thể tương tác với nhau, để những nền tảng này làm việc với nhau, những ứng dụng Web được phát triển

Dịch vụ Web mang ứng dụng Web sang một mức độ mới

Bằng việc sử dụng Dịch vụ Web, ứng dụng của chúng ta có thể công bố chức năng của nó hoặc thông điệp đến mọi nơi trên thế giới

Dịch vụ Web sử dụng XML để mã hóa và giải mã dữ liệu và SOAP để vận chuyển nó (sử dụng những giao thức mở)

- Dịch vụ Web có hai kiểu sử dụng:

 Sử dụng lại những thành phần ứng dụng có sẵn

Có những ứng dụng được sử dụng thường xuyên

Dịch vụ Web có thể cung cấp những ứng dụng nhỏ như: chuyển đổi tiền tệ, dự báo thời tiết hoặc cả chuyển đổi ngôn ngữ

 Kết nối với phần mềm tồn tại sẵn

Dịch vụ Web có thể giúp giải quyết vấn đề tích hợp bằng cách cho những ứng dụng khác nhau một cách liên kết dữ liệu của họ

Định dạng
Số trang	111
Dung lượng	3,21 MB