ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ




Nguyễn Thị Bình Giang


CÔNG NGHỆ WEB SERVICE VÀ ỨNG DỤNG ĐỂ
XÂY DỰNG KIẾN TRÚC HƯỚNG DỊCH VỤ

LUẬN VĂN THẠC SĨ











Hà Nội – 2009
3

MỤC LỤC

LỜI CẢM ƠN Error! Bookmark not defined.
MỤC LỤC 3
BẢNG KÝ HIỆU CÁC CHỮ VIẾT TẮT 5
DANH MỤC CÁC BẢNG 6
DANH MỤC CÁC HÌNH 7
MỞ ĐẦU 8
CHƢƠNG 1. TỔNG QUAN VỀ WEB SERVICE 11
1.1. Các công nghệ hỗ trợ trƣớc web service 11
1.2. Web service là gì. 12
1.3. Lợi ích của việc sử dụng web service 14
1.4. Kiến trúc tổng quan của web service 14
CHƢƠNG 2. CÁC CÔNG NGHỆ NỀN TẢNG CỦA WEB SERVICE 16
2.1. XML 16
2.1.1. Khái niệm về XML 16
2.1.2. Các quy tắc cú pháp của XML 16
2.1.3. XML có định dạng tốt (Well-formed XML) 18
2.1.4. XML đúng đắn (Valid XML) 18
2.1.5. Không gian tên (Namespaces) 22
2.1.6. Tên viết tắt (Qualified Names - QNames) 24
2.1.7. CDATA 25
2.1.8. Trình diễn dữ liệu XML trên web 25
2.2. SOAP 26
2.2.1. Đặc trƣng của SOAP 26
2.2.2. Cấu trúc một thông điệp (Message) theo dạng SOAP 27
2.2.3. SOAP trong HTTP 38
2.3. WSDL 40
2.4. UDDI 42
4






2.5. Hoạt động chung của một web service 43
CHƢƠNG 3. ỨNG DỤNG WEB SERVICE ĐỂ XÂY DỰNG KIẾN TRÚC HƢỚNG
DỊCH VỤ 48
3.1. Tổng quan về kiến trúc hƣớng dịch vụ 48
3.1.1. SOA là gì? 48
3.1.2. Các lợi ích của SOA: 49
3.1.3. Khi nào sử dụng SOA ? 49
3.1.4. Mối quan hệ giữa web service và kiến trúc hƣớng dịch vụ (SOA) 50
3.2. Bài toán ứng dụng công nghệ Web Service trong xây dựng kiến trúc hƣớng
dịch vụ 51
3.2.1. Mô tả hoạt động của web service 51
3.2.2. Đặc tả về các hệ thống giao tiếp 52
3.2.3. Đặc tả về giao diện kết nối 55
CHƢƠNG 4. THỰC NGHIỆM 57
4.1 Thực nghiệm 57
4.1.1. Giao dịch vấn tin tài khoản (Account Inquiry) 57
4.1.1. Giao dịch cập nhật số dƣ tài khoản (Balance Update) 59
4.2. Đánh giá kết quả thực nghiệm 61
KẾT LUẬN 67
TÀI LIỆU THAM KHẢO 68


5






BẢNG KÝ HIỆU CÁC CHỮ VIẾT TẮT
STT
Tên viết tắt
Tên đầy đủ
1.
CORBA
Common Object Request Broker Architecture
2.
DCOM
Distributed Component Object Model
3.
DLL
Dynamic Link Library
4.
ESB
Enterprise Service Bus
5.
FTP
File Transfer Protocol
6.
HTTP
Hypertext Transfer Protocol
7.
RMI
Remote Method Invocation
8.
RPC

Remote Procedure Call
9.
SMTP
Simple Mail Transfer Protocol
10.
SOA
Service – Oriented Architecture
11.
SOAP
Simple Object Access Protocol
12.
UDDI
Universal Description, Discovery, and
Integration
13.
WSDL
Web Service Definition Language
14.
XML
eXtensible Markup Language


6





DANH MỤC CÁC BẢNG


Bảng 2.1: Các thành phần logic của web service 43
Bảng 4. 1: Bảng mô tả chi tiết các trƣờng trong phần header của thông điệp 57
Bảng 4.2: Bảng mô tả chi tiết các trƣờng trong phần dữ liệu của thông điệp gửi đi 58
Bảng 4.3: Bảng mô tả chi tiết các trƣờng trong phần dữ liệu của thông điệp trả về 58
Bảng 4. 4: Bảng mô tả chi tiết các trƣờng trong phần dữ liệu của thông điệp gửi đi 59
7





DANH MỤC CÁC HÌNH


Hình 1.1: Kiến trúc của Web Service 15
Hình 2.1: Mô hình trình diễn dữ liệu XML trên Web 26
Hình 2.2: SOAP với các giao thức HTTP, SMTP, và Raw TCP/IP 27
Hình 2.3: Cấu trúc của thông điệp SOAP 28
Hình 2.4: SOAP message path 31
Hình 2.5: Message path của thông điệp SOAP purchase-Order 32
Hình 2. 6: Mô hình hoạt động của SOAP 38
Hình 2.7: Thông điệp yêu cầu của SOAP 39
Hình 2.8: Thông điệp hồi đáp của SOAP 40
Hình 2.9: Cấu trúc của WSDL 40
Hình 2.10: Các thành phần logic của web service 45
Hình 2.11: Biểu đồ ca sử dụng của web service 46
Hình 2.12: Biểu đồ tuần tự 46
Hình 3.1: Mô hình SOA phát triển lên từ mô hình đối tượng 510
Hình 3.2: Mô hình kết nối giữa 2 hệ thống 52
Hình 3.3:Mô hình kiến trúc SOA cho ngân hàng của IBM 53

Hình 3.4:Hệ thống theo kiến trúc SOA sử dụng công nghệ WS 55
Hình 3.5: Thông điệp theo định dạng ABCS 55
Hình 3.6: File đặc tả các trường trong header 56
Hình 4.1: Thông điệp gửi đến 58
Hình 4.2: Thông điệp sau khi được thêm header và chuyển sang định dạng của hệ
thống core 58
Hình 4.3: Thông điệp gửi đến 60
Hình 4.4: Giao diện luông xử lý thông điệp 61
Hình 4.5:Thao tác với file đặc tả WSDL 61
Hình 4.6: Luồng xử lý tại nút Inquiry 62
Hình 4.7: Giao diện làm việc với môi trường coding 62
Hình 4.8: Đoạn lập trình các thao tác làm việc với core 63
Hình 4.9: Giao diện web service 64
Hình 4.10: Giao diện đăng ký web service với UDDIRegistry 64
Hình 4.11:Thử nghiệm với thông điệp đầu vào của giao dịch Vấn tin TK 64
Hình 4.12:Kết quả trả về 65
8





MỞ ĐẦU
Tích hợp dữ liệu (Data Integration) là qui trình trao đổi dữ liệu giữa các hệ
thống quản lý thông tin kinh doanh để đƣa ra đƣợc thông tin đầy đủ nhằm phục vụ
mục đích quản trị. Khi hai ứng dụng (Applications) trao đổi dữ liệu dựa trên thông tin
của các qui trình định sẵn, chúng ta gọi là tích hợp ứng dụng (Enterprise Application
Integration hay là EAI). Thông thƣờng khi triển khai phần mềm, doanh nghiệp đều gặp
phải vấn đề khó khăn là làm sao để dữ liệu từ các phần mềm khác nhau (về mặt kiến
trúc và định nghĩa dữ liệu), phục vụ cho các mục đích của các bộ phận nghiệp vụ khác

nhau đƣợc tập trung về hệ thống quản lý tài chính trung tâm, nhằm đáp ứng những nhu
cầu thông tin quản lý để ban lãnh đạo kịp thời ra quyết định. Trong bối cảnh cạnh
tranh ngày càng khốc liệt hiện nay, các doanh nghiệp đang phải đối mặt những đối thủ
khổng lồ, với hệ thống thông tin tích hợp hiện đại và chính xác thì nhu cầu tích hợp
càng bức thiết cho bất cứ doanh nghiệp nào muốn đứng vững trên thị trƣờng[4].
Trong quá trình hình thành doanh nghiệp, các doanh nghiệp quản lý phần mềm
thƣờng theo nhu cầu tự phát, thiếu tính chiến lƣợc – Các phần mềm chủ yếu là do
doanh nghiệp mua hoặc tự phát triển để đáp ứng đƣợc nhanh nhất các yêu cầu về quản
lý và nghiệp vụ. Khi có nhu cầu cao hơn, doanh nghiệp lại tiếp tục phát triển các phần
mềm mới hoặc nâng cấp các phần mềm hiện có để nhằm thỏa mãn những nhu cầu
khác nhau. Dần dà, doanh nghiệp nhận ra mình đang sở hữu rất nhiều phần mềm, mỗi
phần mềm chỉ thỏa mãn đƣợc một nhu cầu nào đó, nhƣng các phần mềm này lại không
chia sẻ dữ liệu với nhau, hoặc phối hợp với nhau một cách thiếu đồng bộ. Đến thời
điểm hiện nay những hệ thống nhƣ vậy bộc lộ quá nhiều khuyết điểm do nhiều nguyên
nhân khách quan cũng nhƣ chủ quan nhƣ sau [3]:
- Các phần mềm thiếu một kiến trúc và chuẩn dữ liệu đồng nhất.
- Các phần mềm thiếu cơ sở đồng nhất về hạ tầng.
- Do doanh nghiệp phát triển nhanh chóng, số lƣợng giao dịch tăng làm ảnh
hƣởng đến hoạt động của phần mềm mà mục đích chỉ sử dụng cho các giao dịch
đơn lẻ.
- Có quá nhiều phần mềm nhỏ lẻ, khó quản lý, chi phí cho đội ngũ quản lý và bảo
trì phần mềm rất lớn.
- Việc báo cáo định kỳ đòi hỏi sự phối hợp và trao đổi dữ liệu giữa các phòng
ban, do đó Ban điều hành chậm nhận đƣợc báo cáo về tình hình hoạt động của
doanh nghiệp, gây chậm trễ trong việc ra quyết định.
- Việc quản lý sẽ trở nên khó kiểm soát nếu doanh nghiệp có nhiều chi nhánh
hoặc bộ phận trong nƣớc và nƣớc ngoài, hay công ty muốn chuyển đổi thành
tập đoàn hay công ty đa quốc gia.
Để khắc phục các điểm yếu trên, doanh nghiệp thƣờng chọn một trong hai giải pháp:
9






1. Chọn mua một phần mềm hoàn toàn mới, có tất cả chức năng cần thiết cho
việc quản lý tổng thể với chi phí phần mềm và chi phí triển khai, bảo trì cao với sự
chuyển đổi dữ liệu phức tạp.
2. Xác định một phần mềm tích hợp trung tâm (Central Integration Hub), liên
kết đồng bộ dữ liệu từ các hệ thống đơn lẻ về hệ thống tích hợp này, sau đó gửi dữ liệu
đã đƣợc cập nhật trực tuyến đến các hệ thống khác.
Gần đây, một số doanh nghiệp lớn trong nƣớc bắt đầu chuyển sang mua và triển
khai các phần mềm ERP đã đƣợc sử dụng nhiều trên thế giới nhƣ của Oracle, SAP,
Sun System , các phần mềm chuyên biệt cho hệ thống khách sạn, bảo hiểm, ngân
hàng, bệnh viện với chi phí đầu tƣ lên đến vài trăm nghìn hoặc vài triệu USD. Không
phải tất cả những doanh nghiệp này đều đã nghĩ đến bài toán Tích hợp hệ thống. Họ đã
chọn nhiều phần mềm khác nhau để triển khai. Có công ty đã chọn Oracle cho kế toán
tài chính; SAP cho phân hệ CRM; Solomon cho kho bãi và phân phối[4]. Triển khai
nhƣ thế có lợi là sẽ sử dụng đƣợc tất cả thế mạnh của mỗi phần mềm, nhƣng việc tích
hợp các hệ thống này trong tƣơng lai sẽ là một bài toán khó cho bất kỳ một đội ngũ IT
mạnh mẽ nào.
Trƣớc thực trạng trên ta thấy đƣợc bài toán tích hợp ứng dụng trong các hệ
thống là bài toán mà bất kỳ doanh nghiệp nào cũng có thể gặp phải, tuy nhiên, việc sử
dụng công nghệ nào để có thể tích hợp giữa các hệ thống lại là một bài toán khác. Nếu
trƣớc đây, ngƣời ta thƣờng đề cập đến nhiều công nghệ khác nhau nhƣ COM
(Common Object Manifest), CORBA (Common Object Request Broker Architecture),
RMI (Remote Method Invocation), RPC (Remote Procedure Call) đƣợc dùng để gọi
đối tƣợng từ xa thì những năm gần đây, thuật ngữ ―Web service‖ đƣợc rất nhiều ngƣời
nhắc đến nhƣ là một giải pháp lý tƣởng cho bài toán tích hợp doanh nghiệp. Và khi
nhắc đến Web Service, ngƣời ta thƣờng coi đó là một trong những cách thức hiệu quả

để xây dựng kiến trúc hƣớng dịch vụ SOA (Service Oriented Architecture) – một trong
những kiểu kiến trúc đƣợc đánh giá là có khả năng đem lại cho doanh nghiệp một kiến
trúc linh hoạt và khả chuyển.
Bài luận văn tập trung vào hai nội dung chính là: tìm hiểu những khái niệm cơ
bản về web service, và vai trò của web service trong việc tích hợp ứng dụng và khả
năng ứng dụng của Web service trong việc xây dựng kiến trúc hƣớng dịch vụ nhƣ thế
nào.
Các phần còn lại của luận văn đƣợc cấu trúc nhƣ sau:
10





Chƣơng 1 trình bày về những khái niệm tổng quan về khái niệm Web service,
các lợi ích mà web service đem lại cũng nhƣ đƣa ra một cái nhìn chung về kiến trúc
của web service.
Chƣơng 2 trình bày về các công nghệ nền tảng của web service, bao gồm các
công nghệ nhƣ XML, SOAP, WSDL và UDDI.
Chƣơng 3 giới thiệu tổng quan về kiến trúc hƣớng dịch vụ, lợi ích của kiến trúc
này đem lại cũng nhƣ khả năng sử dụng web service để xây dựng kiến trúc này. Trong
chƣơng 3 cũng mô tả về một bài toán ứng dụng cụ thể xây dựng một web service thực
hiện việc giao tiếp giữa hai hệ thống sử dụng các định dạng thông điệp khác nhau.
Chƣơng 4 đƣa ra một số kết quả thực nghiệm thu đƣợc khi xây dựng web
service trong bài toán đã đƣợc mô tả trong chƣơng 3.

11







CHƯƠNG 1. TỔNG QUAN VỀ WEB SERVICE

1.1. Các công nghệ hỗ trợ trước web service
Sự ra đời của phƣơng pháp lập trình hƣớng đối tƣợng đã đem lại nhiều hứa hẹn
về khả năng tái sử dụng mã nguồn trên nhiều hệ thống và kiến trúc. Để giúp giảm
thiểu thời gian và công sức cho các lập trình viên, các kho mã nguồn ra đời nhằm cung
cấp các thƣ viện thực hiện các chức năng cơ bản cho lập trình viên (Ví dụ nhƣ các thƣ
viện thƣơng mại C++ chứa các phƣơng thức tao tác chuẩn trên ngày và giờ, ). Tuy
nhiên, các thƣ viện thƣơng mại này chỉ có thể cung cấp các chức năng cơ bản và các
lớp tổng quát cần thiết, còn đối với một số nghiệp vụ đặc biệt, nhƣ nghiệp vụ của ngân
hàng, đòi hỏi phải xây dựng các gói thƣ viện riêng phù hợp với từng nghiệp vụ của
mỗi công ty. Ban đầu, các công ty xây dựng các gói thƣ viện nghiệp vụ dƣới dạng các
thƣ viện liên kết động DLL (Dynamic Link Library). Các thƣ viện này chứa thông tin
cho các ứng dụng khác dùng để tạo các đối tƣợng và chỉ có thể lập trình để chạy trên
cùng một máy (nhƣ các tập tin DLL). Tuy nhiên, nếu trong một tập đoàn lớn, với yêu
cầu phải bảo trì hàng trăm ngàn máy trạm và các ứng dụng trên mỗi hệ thống, việc có
những thƣ viện này trên mỗi hệ thống sẽ gây ra rất nhiều khó khăn khi phải tiến hành
bảo trì.Do đó, việc dùng các đối tƣợng từ xa là một cách tối ƣu để sử dụng lại mã
nguồn ở mức ứng dụng trên một máy cục bộ. Các đối tƣợng từ xa là các đối tƣợng
đƣợc tạo ra ở trên một máy chủ trung tâm và có thể đƣợc truy cập từ máy trạm thông
qua mạng, kể cả Internet.Trƣớc khi web service ra đời, ngƣời ta thƣờng sử dụng ba
công nghệ dùng để gọi các đối tƣợng từ xa là RMI, DCOM (COM) và CORBA.
 RMI (Remote Method Invocation): Là phƣơng thức do công ty JavaSoft đƣa
ra và đƣợc xây dựng trên ngôn ngữ Java. RMI là các hàm thƣ viện hỗ trợ các lời gọi
phƣơng thức từ xa và trả về giá trị cho các ứng dụng tính toán phân tán. Chúng ta giả
sử rằng ngôn ngữ Java đƣợc sử dụng ở cả phía gọi và phía bên phƣơng thức đƣợc
gọi.RMI là một tập các hàm thƣ viện đơn giản vì cả 2 bên đều sử dụng cùng môt ngôn

ngữ lập trình và kiến trúc máy. Điều này sẽ làm cho vấn để triệu gọi phƣơng thức từ xa
dễ giải quyết hơn.Tuy nhiên sử dụng RMI đòi hỏi các ứng dụng của client-server phải
đƣợc viết trong ngôn ngữ Java.Các đối tƣợng trong RMI không thể giao tiếp với các
đối tƣợng không phải là đối tƣợng Java.Chính vì vậy, RMI chỉ thích hợp cho các ứng
dụng đƣợc viết trên ngôn ngữ Java[19].

12





 DCOM (Distributed Component Object Model - Mô hình Đối tƣợng Thành
phần phân tán): Đây là một sự mở rộng của COM (Component Object Model). DCOM
đƣợc phát triển bởi Microsoft cho những hệ điều hành Windows.Nó hỗ trợ những đối
tƣợng đƣợc phân tán qua một mạng gần giống nhƣ giao thức DSCOM của IBM (là
một thực thi của CORBA)[17]. Tuy nhiên DCOM chỉ dùng tốt cho hệ thống phân bố
dành cho destop khó mở rộng trong cấp độ enterprise,và các ứng dụng của DCOM chỉ
tốt trên các ứng dụng của Microsoft.

 CORBA (Common Object Request Broker Architecture): Là kiến trúc do tổ
chức OMG (Object Management Group) đƣa ra.CORBA là một trong những giao thức
đƣợc sử dụng khá phổ biến để phát triển các ứng dụng phân tán (distributed) hƣớng
đối tƣợng (object-oriented). CORBA là một chuẩn công nghiệp cho phép gọi các
phƣơng thức từ xa và nhận kết quả trả về, nhƣng không giống nhƣ RMI, nó có thể
đƣợc sử dụng khi bên phía gọi và bên phía phƣơng thức đƣợc gọi có thể sử dụng các
ngôn ngữ lập trình khác nhau, bao gồm cả trƣờng hợp là cả 2 bên đều không sử dụng
ngôn ngữ Java. CORBA sử dụng ORB (Object Request Broker) đóng vai trò nhƣ một
middleware cho việc gọi một chƣơng trình từ xa.ORB sử dụng một ngôn ngữ CORBA
IDL để định nghĩa giao diện (interface) và cái này tách biệt với sự hiện thực của một

đối tƣợng[18].Tuy nhiên các hệ thống của CORBA cũng chỉ giao tiếp đƣợc với các hệ
thống khác cùng sử dụng chuẩn CORBA.
Một đặc điểm chung của các giao thức trên đó là nó chỉ hoạt động đƣợc trên
cùngcác hệ thống sử dụng công nghệ hoặc ngôn ngữ giống nhau, chính vì vậy vấn đề
đặt ra là: Làm sao để các hệ thống phân tán đƣợc phát triển trên các công nghệ khác
nhau, đƣợc xây dựng bằng các ngôn ngữ khác nhau có thể giao tiếp với
nhau?Microsoft đã tạo ra một giao thức chuẩn dựa trên XML gọi là SOAP (Simple
Object Access Protocol – Giao thức truy cập đối tƣợng đơn giản). Giao thức này là sự
kết hợp việc lƣu trữ dữ liệu dƣới định dạng XML và một giao thức chuẩn cho phép
truyền tải dữ liệu qua Internet.Những giao thức mà SOAP thƣờng sử dụng để truyền
tải bao gồm SMTP (Simple Mail Transfer Protocol), FTP (File Transfer Protocol) và
HTTP (Hypertext Transfer Protocol).Các nhà phát triển thƣờng xem những giao thức
này nhƣ là chồng các giao thức của Web Service.Sự ra đời của web service cung cấp
khả năng chia sẻ dữ liệu giữa các ứng dụng và cơ chế giao tiếp giữa các đối tƣợng một
cách linh hoạt và dễ dàng, độc lập với ngôn ngữ phát triển, hệ điều hành và các công
nghệ mà đối tƣợng đó sử dụng[13].
1.2. Web service là gì.
Ta hãy xem một số tổ chức định nghĩa nhƣ thế nào về web service
13





Theo Tổ chức W3C [13]:
o Web service là một hệ thống phần mềm đƣợc thiết kế để hỗ trợ các tƣơng
tác từ máy này tới máy khác (machine to machine) thông qua mạng
internet.Web service là các web API có thể truy cập đƣợc thông qua
mạng Internet, và đƣợc thực hiện tại hệ thống từ xa có chứa các dịch vụ
đƣợc yêu cầu. Các hệ thống khác tƣơng tác với web service thông qua

việc sử dụng các thông điệp XML tuân theo chuẩn SOAP …
Theo IBM[15]
o ―Web service là một giao diện mô tả một tập các thao tác mà có thể truy
xuất đến các thao tác này thông qua các thông điệp dạng XML‖
Theo SUN [16]
o ―Web service là Các thành phần phần mềm có thể tự khai thác, kết hợp
với nhau để cung cấp một giải pháp cho các vấn đề/yêu cầu của ngƣời
dùng….‖
Nhƣ vậy ta có thể hiểu khái niệm Service ở đây là chỉ những ứng dụng mà mình
muốn cho bên ngoài sử dụng. Ví dụ: Chƣơng trình của bạn chỉ có 1 lớp Java đơn giản
nhƣ sau:
Class HelloWorld {
public HelloWorld()
{
super();
}
public String sayHello(String str)
{
Return ―Hello, ― + str;
}}
Khi ngƣời khác sử dụng chƣơng trình của chúng ta và họ truyền vào 1 chuỗi str,
thì chúng ta sẻ trả lại cho họ chuổi ―Hello, ― + str.Nhƣ vậy, cần phải có một cách thức
để bên ngoài có thể tƣơng tác đƣợc với chƣơng trình của chúng ta, và cách thức đó
chính là web service.
Ta có thể hình dung khái niệm về web service qua sơ đồ sau:
Client< >network< >webservice<=>myservice
14







1.3. Lợi ích của việc sử dụng web service
Việc sử dụng Web Service có những lợi ích sau[10,14]:
 Chia sẻ dữ liệu: Web Service cho phép các ứng dụng chia sẻ dữ liệu, cung
cấp khả năng gọi đến các ứng dụng khác mà không cần quan tâm đến các ứng dụng đó
đƣợc phát triển bằng ngôn ngữ nào, chạy trên hệ điều hành hoặc môi trƣờng nào, v.v…
Mặc dù các ứng dụng Web Service là độc lập với nhau, nhƣng chúng có thể liên kết
với nhau để thực hiện một công việc cụ thể. Do đó, ngƣời dùng có thể sử dụng bất kỳ
chƣơng trình phía khách nào để gọi đến các phƣơng thức của các Web Service, tƣơng
tác và lấy kết quả vềtheoyêu cầu để xử lý.
 Chi phí thấp: Web Service đƣợc xây dựng trên công nghệ XML. Nhƣ
vậy dữ liệu có thể đƣợc truyền qua các môi trƣờng và hệ điều hành khác nhau mà
không bị phụ thuộc vào các ngôn ngữ lập trình đƣợc sử dụng. Do đó, giảm đƣợc chi
phí và thời gian để xây dựng một môi trƣờng giao tiếp dữ liệu linh hoạt giữa các hệ
thống khác nhau.
 Thông tin đƣợc cập nhật thƣờng xuyên và linh hoạt: Web Service không
chỉ cho phép các hệ thống kết nối với nhau mà còn cho phép kết nối thông tin giữa
ngƣời sử dụng thông tin và các thông tin mà họ cần khai thác. Sau đó thông tin có thể
đƣợc sử dụng theo bất cứ một khuôn dạng nào mà ngƣời sử dụng thông tin mong
muốn. Ngƣời sử dụng thông tin có thể yêu cầu bất cứ thông tin nào, tại một thời điểm
bất kỳ từ địa điểm cung cấp các dịch vụ Web mà không phải đợi thông tin đƣợc
chuyển lên theo định kỳ [8].
 Lƣợng thông tin phong phú: Tăng khả năng thu thập và trao đổi thông tin
từ nhiều nguồn khác nhau thông qua việc liên kết thông tin giữa các Web Service. Do
đó, giảm đƣợc gánh nặng lƣu trữ dữ liệu tại trung tâm lƣu trữ (khả năng lƣu trữ phân
tán).
 Khả năng bảo mật cao: Các phƣơng thức của Web Service có thể yêu
cầu một số thông tin từ phía ngƣời dùng trong các yêu cầu đƣợc gửi đến cho chúng.

Các thông tin trao đổi (mô tả bằng XML) có thể đƣợc mã hóa theo chuẩn mã hóa
XML. Nếu các Web Service sử dụng các phƣơng thức trao đổi dữ liệu dƣới dạng nhị
phân (thông qua cơ chế gọi thủ tục từ xa – Remote Procedure Call), chúng sẽ đƣợc
tăng cƣờng bảo mật bởi chính các công nghệ RPC của từng nhà cung cấp dịch vụ.
1.4. Kiến trúc tổng quan của web service [20]
Web Service bao gồm nhiều tầng. Về cơ bản, đó là một cơ chế chuẩn liên quan đến
việc nhận biết, mô tả, và tìm kiếm các chức năng đƣợc cung cấp bởi một ứng dụng
15





Web Service.Kiến trúc của web service đƣợc mô tả trong hình dƣới đây:

Hình 1.1:Kiến trúc của Web Service
Trong đó bao gồm các tầng [9]:
 Tầng vận chuyển với những công nghệ chuẩn là HTTP , SMTP và JMS
 Tầng giao thức tƣơng tác dịch vụ (Service Communication Protocol) với công
nghệ chuẩn là SOAP. SOAP là giao thức nằm giữa tầng vận chuyển và tầng
mô tả thông tin về dịch vụ, SOAP cho phép ngƣời dùng triệu gọi một service
từ xa thông qua một message XML.
 Tầng mô tả dịch vụ (Service Description) với công nghệ chuẩn là WSDL và
XML.WSDL la
̀
mô
̣
t ngôn ngƣ
̃
mô ta

̉
giao tiếp va
̀
thƣ
̣
c thi dƣ
̣
a trên XML . Web
service sƣ
̉
du
̣
ng ngôn ngƣ
̃
WSDL đê
̉
truyền ca
́
c tham số va
̀
ca
́
c lo ại dữ liệu cho
các thao tác, các chức năng ma
̀
web service cung cấp.
 Tầng dịch vụ (Service):cung cấp các chức năng của service.
 Tầng đăng ký dịch vụ (Service Registry) với công nghệ chuẩn là UDDI.UDDI
dùng cho cả ngƣời dùng và ̣ SOAP server , nó cho phép đăng ký d ịch vụ để
ngƣời dùng có thể gọi thực hiện service từ xa qua mạng, hay nói cách khác

một service cần phải đƣợc đăng ký để cho phép các client có thể gọi thực hiện
Bên cạnh đó để cho các service có tính an toàn, toàn vẹn và bảo mật thông tin
trong kiến trúc web service chúng ta có thêm các tầng Policy, Security, Transaction,
Management giúp tăng cƣờng tính bảo mật, an toàn và toàn vẹn thông tin khi sử dụng
service[15].
16





CHƯƠNG 2. CÁC CÔNG NGHỆ NỀN TẢNG CỦA WEB SERVICE

2.1. XML
2.1.1. Khái niệm về XML
XML, viết tắt của chữ eXtensible Markup Language, là ngôn ngữ đƣợc tổ chức
mạng toàn cầu (W3C)định nghĩa. Trong HTML, các thẻ đƣợc định nghĩa và quy định
trƣớc, còn trong XML ngƣời dùng đƣợc phép tự do đặt tên các cặp thẻ để dùng khi
cần.Với khả năng này, XML không những cho phép mô tả cấu trúc dữ liệu văn bản mà
còn cho cả các kiểu dữ liệu khác, nhƣ hình ảnh, âm thanh.
Điểm khác biệt chính giữa HTML và XML là trong khi các cặp thẻ của HTML
chứa ý nghĩa về cách trình bày (formatting) các dữ liệu, thì các cặp thẻ của XML còn
bao hàm nội dung cả về cấu trúc vàtrình diễn của dữ liệu. Khi muốn trình bày các dữ
kiện của một trang XML theo một kiểu nào đó, phục vụ hiển thị trên các thiết bị khác
nhau, ta dùng một bảng định kiểu (Style Sheet) tƣơng ứng cho nó. Ví dụ, muốn trình
bày cùng một nội dung tài liệu XML nhƣng hiển thị trên hai thiết bị khách nhau, một
trên PC và một trên Mobile Phone (điện thoại di động), ta sẽ dùng hai Style Sheet khác
nhau, một cho PC, cái kia cho Mobile Phone.
2.1.2. Các quy tắc cú pháp của XML [2]
Các quy tắc cú pháp của XML đƣợc định nghĩa rất đơn giản nhƣng chặt chẽ

giúp cho XML dễ học và dễ sử dụng. Các tài liệu XML sử dụng các cú pháp tự mô tả
chính nó. Xét ví dụ về một tài liệu XML sau:
<?xml version="1.0" encoding="ISO-8859-1"?>
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
Dòng đầu tiên của tài liệu là dòng khai báo XML, định nghĩa phiên bản XML
và bảng mã ký tự đƣợc sử dụng trong tài liệu.Trong ví dụ này, tài liệu sử dụng đặc tả
XML phiên bản 1.0 và bảng mã ký tự IS0-8859-1 (Latin 1/Western European).Dòng
thứ hai mô tả phần tử gốc (root element). Bốn dòng tiếp theo là bốn phần tử con (child
element) của phần tử gốc và dòng cuối cùng là định nghĩa kết thúc phần tử gốc. Ta có
thể dễ dàng nhận thấy rằng, tài liệu XML này mô tả một nhắc nhở (note) từ ―Jani‖ gửi
tới ―Tove‖ do cú pháp của XML mô tả chính nó.
17





Tất cả các phần tử XML đều phải nằm trong một cặp thẻ. Ví dụ:
<p>This is a paragraph</p>
Trong ví dụ trƣớc, khai báo XML không cần phải nằm trong một cặp thẻ vì nó
không phải là một phần tử XML.
Không giống nhƣ HTML, các thẻ trong XML phân biệt chữ hoa và chữ thƣờng.
Hai thẻ <Letter> và <letter> là khác nhau và do đó các thẻ mở và thẻ đóng phải đƣợc
viết cùng một kiểu. Ví dụ:
<message>This is correct</message>

Các phần tử của XML thuộc từng cặp thẻ không đƣợc nằm xen kẽ nhau. Xét ví
dụ sau:
<name>
John Stanmore
<address>
25 King Street
</name>
</address>
Khai báo nhƣ trên là không hợp lệ do thẻ <address> nằm trong cặp thẻ <name> và
</name>, còn thẻ </address> lại nằm ngoài.
Tất cả các tài liệu XML đều phải có một cặp thẻ định nghĩa một phần tử gốc của
tài liệu. Tất cả các phần tử con của nó phải nằm trong phần tử gốc này. Tất cả các phần
tử trong XML đều có thể có một hoặc nhiều các phần tử con. Những phần tử con này
phải nằm giữa cặp thẻ định nghĩa phần tử cha. Ví dụ:
<root>
<child>
<subchild> </subchild>
</child>
</root>
Mỗi phần tử XML có thể có các thuộc tính đƣợc định nghĩa bởi cặp tên / giá trị.
Các giá trị này cần phải nằm trong dấu ngoặc kép (― ‖). Định dạng chung có dạng:
<tên_phần_tử tên_thuộc_tính = ―giá_trị‖>
Ví dụ:
<?xml version="1.0" encoding="ISO-8859-1"?>
<note date="12/11/2002">
18






<to>Tove</to>
<from>Jani</from>
</note>
Thuộc tính date của phần tử note có giá trị là ―12/11/2002‖ phải nằm trong dấu ngoặc
kép.
Không giống nhƣ HTML, trong XML, tất cả các ký tự trắng sẽ đƣợc giữ nguyên
và không bị loại bỏ khi sử dụng hay hiển thị.
Cú pháp để viết dòng chú thích trong XML cũng giống nhƣ trong HTML:
<!—- Nội dung chú thích >
2.1.3. XML có định dạng tốt (Well-formed XML)
Mặc dù số lƣợng cặp thẻ trong một tài liệu XML là không hạn chế, nhƣng mỗi tài
liệu cần phải tuân theo một số qui luật để đƣợc xem là đúng chuẩn (Well-Formed).
Nếu một trang XML không theo mẫu chuẩn thì coi nhƣ không dùng đuợc, không có
chƣơng trình xử lý nào có thể làm việc với dữ liệu bên trong nó. Do đó, khi xây dựng
một trang XML cần phải tuân theo đúng các qui luật sau:
1. Tất cả các tài liệu XML đều phải có một phần tử gốc.
2. Tất cả các phần tử phải nằm trong một cặp thẻ.
3. Tất cả các thẻ trong XML đều phân biệt chữ hoa, chữ thƣờng.
4. Các cặp thẻ không đƣợc xen kẽ nhau
5. Các giá trị của các thuộc tính phải nằm trong dấu ngoặc kép
Trang tài liệu XML tuân theo các quy luật trên (hay nói cách khác là đúng cú pháp) sẽ
đƣợc coi là Well-Formed.
2.1.4. XML đúng đắn (Valid XML)[2]
XML chứa các dữ liệu bằng cách dùng những cặp thẻ, nhƣng tự nó không đòi hỏi
các dữ liệu nào cần phải có hay chúng phải liên hệ với nhau nhƣ thế nào. Một cách để
thực hiện việc này là thêm vào phần đầu của một trang XML những qui luật mà các dữ
liệu phải tuân theo để trang XML đuợc xem là có ý nghĩa. Tập hợp các qui luật đó
đƣợc gọi là Document Type Definition (DTD). DTD phải nằm trong một định
nghĩaDOCTYPE, có cấu trúc cú pháp nhƣ sau:

<!DOCTYPE root-element [element-declarations]>
DOCTYPE đƣợc sử dụng để khai báo phần tử gốc của XML. Trong DTD, một phần tử
của XML đƣợc khai báo bằng một định nghĩa có cú pháp:
19





<!ELEMENT element-name category>
hoặc
<!ELEMENT element-name (element-content)>
Ví dụ định nghĩa kiểu dữ liệu DTD đƣợc thêm vào đầu file XML:
<?xml version="1.0" standalone="yes"?>
<! Bắt đầu DTD >
<!DOCTYPE document [
<!ELEMENT document (title, publisher_list)>
<! document children >
<!ELEMENT title (#PCDATA)>
<!ELEMENT publisher_list (publisher*)>
<! publisher children >
<!ELEMENT publisher (name, email?, homepage?,
address?, voice?, fax?)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT email (#PCDATA)>
<!ELEMENT homepage (#PCDATA)>
<!ELEMENT address (#PCDATA)>
<!ELEMENT voice (#PCDATA)>
<!ELEMENT fax (#PCDATA)>
]>

<!—- Kết thúc DTD >
<document>
<title> Publishers of the Music of New York Women
Composers </title>
<publisher_list>
<publisher>
<name> ACA - American Composers Alliance</name>
<email></email>
<homepage>
</homepage>
<address> 170 West 74th St.NYNY10023
</address>
<voice>212-362-8900</voice>
<fax>212-874-8605</fax>
</publisher>
<publisher>
20





<name>Alfred Publishing</name>
<address>15535 Morrison South Oaks CA 91403
</address>
</publisher>
</publisher_list>
</document>
DTD này qui định rằng mỗi tài liệu XML phải có một tiêu đề và một danh sách
các nhà xuất bản. Danh sách này có thể có một hay nhiều nhà xuất bản. Mỗi nhà xuất

bản bắt buộc phải có tên, còn những thành phần khác: email, homepage, address, voice,
fax với dấu ―?‖ ở phía sau có nghĩa là tùy chọn (có hoặc không). Ví dụ, nhà xuất bản
Alfred Publishing chỉ có tên và địa chỉ.Các phần tử đƣợc quy định bắt buộc phải có
kiểu là Character (#PCDATA - Parsed Character Data). Trang XML nào tuân theo
DTD đi kèm thì đƣợc gọi là đúng đắn (valid).
Tuy nhiên, DTD còn có nhiều giới hạn, thí dụ nhƣ không định nghĩa chính xác
đƣợc các kiểu dữ liệu (data type). Do đó, Microsoft đề xƣớng sơ đồ XML (XML
Schemas) với những ƣu điểm sau:
- Dễ học và dùng hơn DTD, chính sơ đồ cũng là một trang thuộc loại XML.
- Nó cho phép định nghĩa chính xác các kiểu dữ liệu (data type).
- Dùng lại đƣợc các phần tửbằng cách thừa kế (inheritance).
- Linh động, dễ thêm bớt các phần tử của sơ đồ.
Mọi sơ đồ XML đều có phần tử gốc là <Schema>, phần tử này có thể bao gồm
một số thuộc tính và đƣợc khai báo nhƣ sau:
<xs:schema xmlns:xs="
targetNamespace="">
Trong đó phần:
xmlns:xs="
xác định các phần tử và kiểu dữ liệu sử dụng trong sơ đồ này, xuất phát từ không gian
tên ― và có tiền tố là ―xs:‖. Phần:
targetNamespace=""
xác định các phần tử đƣợc định nghĩa bởi sơ đồ này, xuất phát tử không gian tên
―‖.
Các phần tử trong sơ đồ bao gồm hai loại: loại đơn giản (Simple Element) và loại
phức tạp (Complex Element). Cú pháp của một phần tử đơn giản là:
21






<xs:element name="xxx" type="yyy"/>
trong đó ―yyy‖ là kiểu dữ liệu của phần tử. Sơ đồ XML có một số kiểu dữ liệu xây
dựng sẵn bao gồm: xs:string, xs:decimal, xs:integer, xs:boolean, xs:date, xs:time.
Phần tử phức tạp là phần tử chứa các phần tử khác hay các thuộc tính. Phần tử phức
tạp có thể là phần tử rỗng:
<product pid="1345"/>
hoặc bao gồm các phần tử khác:
<employee>
<firstname>John</firstname>
<lastname>Smith</lastname>
</employee>
Phần tử phức tạp có thể chỉ chứa văn bản hoặc bao gồm cả văn bản và các phần tử
khác.
Ta có thể viết một sơ đồ để thay thế DTD nói trên nhƣ sau:
<?xml version="1.0"?>
<Schema xmlns="urn:schemas-microsoft-com:xml-data"
xmlns:dt="urn:schemas-microsoft-com:datatypes">
<ElementType name="title" content="textOnly"
dt:type="string"></ElementType>
<ElementType name="name" content="textOnly"
dt:type="string"></ElementType>
<ElementType name="email" content="textOnly"
dt:type="string"></ElementType>
<ElementType name="homepage" content="textOnly"
dt:type="string"></ElementType>
<ElementType name="address" content="textOnly"
dt:type="string"></ElementType>
<ElementType name="voice" content="textOnly"
dt:type="string"></ElementType>

<ElementType name="fax" content="textOnly"
dt:type="string"></ElementType>
<ElementType name="document" content="textOnly"
order="one">
<element type="title" minOccurs="1" maxOccurs="1">
</element>
22





<element type="publisher_list" minOccurs="1"
maxOccurs="*"></element>
</ElementType>
<ElementType name="publisher_list" content="textOnly"
order="one">
<element type="name" minOccurs="1" maxOccurs="1">
</element>
<element type="email" minOccurs="0" maxOccurs="1">
</element>
<element type="homepage" minOccurs="0" maxOccurs="1">
</element>
<element type="address" minOccurs="0" maxOccurs="1">
</element>
<element type="voice" minOccurs="0" maxOccurs="1">
</element>
<element type="fax" minOccurs="0" maxOccurs="1">
</element>
</ElementType>

</Schema>
Trong khi DTD dùng một ngôn ngữ khác thì sơ đồ đƣợc viết dƣới dạng một trang
XML. Mỗi phần tử đều có kiểu dữ liệu, có thể là string, int, number, boolean, float hay
date.
Tài liệu ở dạng sơ đồ này đƣợc lƣu dƣới dạng file XML,và đƣợc đính kèm vào
trang XML của tài liệu bằng cặp thẻ:
<document xmlns="x-schema:Schema_filename.xml">
Khi đó dữ liệu trong trang XML sẽ đƣợc kiểm tra tính đúng đắn trƣớc khi hiển thị.
2.1.5. Không gian tên (Namespaces)[11]
Có một khái niệm rất quan trọng trong XML là không gian tên. Nó cho phép sử
dụng cùng một tên của phần tửđể khai báo các kiểu dữ liệu khác nhau trong cùng một
tài liệu XML. Giống nhƣ có hai học sinh trùng tên Tuấn trong lớp học, ta phải dùng
thêm họ của hai học sinh đó để phân biệt, ví dụ ta có thể gọi là Tuấn Trần hay Tuấn Lê.
Không gian tên cung cấp phƣơng thức để tránh xung đột giữa tên các phần tử trong
XML.
Thuộc tính của không gian tên XML (xmlns) đƣợc đặt tại thẻ đầu tiên của mỗi
phần tử và có cấu trúc nhƣ sau:
23





xmlns:namespace-prefix="namespaceURI"
trong đó ―namespaceURI‖ là một chuỗi ký tự dùng để xác định một tài nguyên trên
Internet. Dạng thƣờng thấy nhất của URI là URL (Uniform Resource Locator) dùng để
xác định một địa chỉ tên miền Internet.
Ví dụ: Có một tài liệu XML nhƣ sau:
<?xml version="1.0"?>
<BookOrder OrderNo="1234">

<OrderDate>2001-01-01</OrderDate>
<Customer>
<Title>Mr.</Title>
<FirstName>Graeme</FirstName>
<LastName>Malcolm</LastName>
</Customer>
<Book>
<Title>Treasure Island</Title>
<Author>Robert Louis Stevenson</Author>
</Book>
</BookOrder>
Ta thấy có thể có sự nhầm lẫn về cách dùng phần tử <Title>, vì trong tài liệu
khai báo có hai phần tử <Title>: một dùng cho khách hàng <Customer> nói đến danh
hiệu Mr., Mrs., Dr., còn một để nói đến đề tựa của một quyển sách <Book>.
Để tránh sự nhầm lẫn này, ta có thể dùng không gian tên để nói rõ tên phần tử
con nào nằm trong phần tử cha nào. Ví dụ trên đƣợc viết lại nhƣ sau:
<?xml version="1.0"?>
<BookOrder OrderNo="1234">
<OrderDate>2001-01-01</OrderDate>
<Customer
xmlns="
<Title>Mr.</Title>
<FirstName>Graeme</FirstName>
<LastName>Malcolm</LastName>
</Customer>
<Book xmlns="
<Title>Treasure Island</Title>
<Author>Robert Louis Stevenson</Author>
</Book>
24






</BookOrder>
2.1.6. Tên viết tắt (Qualified Names - QNames)
Trong tài liệu XML ta đã sử dụng khái niệm không gian tên để phân biệt giữa các
phần tử giống nhau trong cùng một tài liệu. Tuy nhiên, vấn đề đặt ra là nếu nhƣ trong
tài liệu có nhiều các phần tử cần phân biệt, nếu vậy sẽ phải bổ sung không gian tên cho
tất cả các phần tử đó trong tài liệu. Một cách giải quyết là khai báo chữ viết tắt cho các
không gian tên ngay ở đầu tài liệu, trong phần tử gốc (tức là Document Element). Sau
đó bên trong tài liệu ta chỉ cần bổ sung tiền tố (prefix) cho các phần tử cần xác nhận
không gian tên bằng chữ viết tắt của không gian tên đó. Thành phần đó đƣợc gọi là
―Tên viết tắt‖ (QName).
Một QName bao gồm một tiếp đầu ngữ mà trƣớc đó đã đƣợc gán giá trị bằng một
URI, tiếptheo là dấu ‗:‘ và tên cục bộ.
Giả sử, nếu một QName có tiếp đầu ngữ là ‗foo‘đƣợc gán cho một URI là
― thì QName có dạng foo:barlà cách viết tắt của địa
chỉ URI:
Ví dụ:
<?xml version="1.0"?>
<BookOrder xmlns="
xmlns:cust="
xmlns:book="
OrderNo="1234">
<OrderDate>2001-01-01</OrderDate>

<cust:Customer>
<cust:Title>Mr.</cust:Title>

<cust:FirstName>Graeme</cust:FirstName>
<cust:LastName>Malcolm</cust:LastName>
</cust:Customer>

<book:Book>
<book:Title>Treasure Island</book:Title>
<book:Author>Robert Louis Stevenson</book:Author>
</book:Book>
</BookOrder>
Trong ví dụ trên các QName đƣợc sử dụng là cust và book với các URI tƣơng ứng là:
25






và
2.1.7. CDATA[2]
Khi muốn đƣa một đoạn dữ liệu vào trong một tài liệu XML mà không cần kiểm
tra tính hợp lệ của nó, ta dùng thẻ có dạng:
<![CDATA[―Đoạn dữ liệu…‖]]>
Đoạn dữ liệu có thể là một đoạn văn bản bình thƣờng, trong trƣờng hợp này, đoạn văn
bản đóng vai trò gần giống nhƣ một chú thích.Phân đoạn CDATA rất hữu dụng khi ta
đƣa một đoạn mã nào đó vào trong tài liệu XML để sử dụng cho mục đích khác sau
này.
Ví dụ:
<![CDATA[ place your data here ]]>
<SCRIPT>
<![CDATA[

function warning() {
alert(―Watch out!‖);
}
]]>
</SCRIPT>
Trong đoạn mã ở trên, trình phân tích sẽ bỏ qua nội dung nằm trong
―<![CDATA[― và ― ]]>‖ . Do đó, nội dung đó không cần phải tuân thủ theo các quy
định của một tài liệu XML chuẩn. Nó cho phép ta có thể chèn các đoạn mã lệnh vào
trong tài liệu XML.
2.1.8. Trình diễn dữ liệu XML trên web
Ban đầu ngƣời ta dùng CSS (Cascading Style Sheet), một định dạng rất thông
dụng cho các trang Web, để làm phƣơng tiện mô tả cách trình bày một trang XML.
Nhƣng sau đó ngôn ngữ bảng kiểu mở rộng(XSL -eXtensible Stylesheet Language) đã
đƣợc sử dụng.Nó chứng tỏ là một ngôn ngữ trình bày rất mạnh mẽ và uyển
chuyển.XSL đƣợc viết dƣới dạng một trang XML. Nó cũng là một ngôn ngữ lập trình
nên chẳng những cho phép biến đổi định dạng (Style) hiển thị của dữ liệu trang XML
mà còn có thể quyết định dữ liệu nào đƣợc hiển thị và hiển thị theo thứ tự nào.
Phát triển ứng dụng Web với kỹ thuật tiêu bản XSL (template XSL) giúp tách
biệt nội dung trang Web và hình thức thể hiện.Nhờ đó việc thiết kế Web trở nên dễ
26





dàng, linh động hơn, hiệu suất ứng dụng Web cũng đƣợc nâng cao hơn.
Trong hình 2.1, ta có thể thấy mô hình sử dụng và biểu diễn dữ liệu XML diễn
ra nhƣ sau: Khi ngƣời dùng kích hoạt một chức năng trên ứng dụng Web, phần xử lý
tƣơng ứng với chức năng này sẽ trả lại kết quả dƣới dạng XML cho ứng dụng Web,
kết quả này cùng với mẫu XSL tƣơng ứng sẽ đƣợc biên dịch để trở thành giao diện

hiển thị cuối cùng và gửi trả lại máy ngƣời dùng.
Người
dùng
Trả lại
Kết quả
hiển thị
Tương tác
Ứng dụng Web
Chuyển yêu
cầu đến
Bộ điều khiển
Tạo ra
Dữ liệu dạng XML
Bao
gồm
Áp dụng
dữ liệu
XML cho
Tiêu bản XSL
đã dịch

Hình 2.1: Mô hình trình diễn dữ liệu XML trên Web
2.2. SOAP
2.2.1. Đặc trƣng của SOAP
SOAP viết tắt của từ Simple Object Access Protocol.SOAP là giao thức dựa trên
XML để trao đổi thông tin trong các hệ thống phân tán. Nó cung cấp một định dạng
chung cho việc đóng gói để truyền dữ liệu XML giữa các ứng dụng trên một mạng
máy tính.
SOAP ban đầu đƣợc Microsoft cài đặt bằng cách gọi thủ tục từ xa (RPC –
Remote Procedure Call) qua giao thức HTTP.Nó cho phép các ứng dụng client có thể

dễ dàng kết nối tới các dịch vụ từ xa và gọi đến phƣơng thức tƣơng ứng. Các giao thức
khác nhƣ CORBA, DCOM, và Java RMI đều cung cấp các tính năng tƣơng tự nhƣ
SOAP, tuy nhiên do các thông điệp SOAP đƣợc viết hoàn toàn bằng XML nên nó độc
lập với mọi nền và mọi ngôn ngữ. Ví dụ một ứng dụng SOAP Java client chạy trên