trongduc_dt
New Member
Download Luận văn Bảo mật trong môi trường lưới với tiếp cận hướng tác tử
MỤC LỤC
MỤC LỤC. 1
LỜI NÓI ĐẦU . 3
LỜI CẢM ƠN . 4
DANH MỤC CÁC KÝ HIỆU, CHỮVIẾT TẮT. 5
DANH MỤC HÌNH VẼ. 6
Chương 1. Tổng quan tính toán lưới, bảo mật trên môi trường lưới . 8
1.1. Tính toán lưới . 8
1.1.1. Giới thiệu vềtính toán lưới . 8
1.1.2. Lợi ích của tính toán lưới . 10
1.1.3. Các vấn đềcơbản của một lưới . 12
1.1.4. Kiến trúc lưới . 14
1.2. Các khái niệm cơbản vềbảo mật . 15
1.2.1. Một sốthuật ngữcơbản. 15
1.2.2. Mã hóa thông tin sửdụng khóa. 16
1.2.3. Mã hóa đối xứng . 17
1.2.4. Mã hóa công khai . 18
1.2.5. Chữký điện tử. 19
1.2.6. Giấy chứng nhận điện tửvà Nhà chứng nhận thẩm quyền. 21
1.3. Cơchếbảo mật trong môi trường lưới. 25
1.4. Các chính sách bảo mật trong môi trường lưới. 28
1.5. Giới thiệu vềhạtầng bảo mật lưới GSI . 30
1.5.1. Cơsởhạtầng khóa công khai . 30
1.5.2. Bảo mật mức thông điệp và mức giao vận. 31
1.5.3. So sánh hiệu năng của bảo mật mức thông điệp với mức giao vận. 32
1.5.4. Giấy ủy nhiệm . 34
1.5.5. Sự ủy quyền. 35
1.5.6. Chứng thực . 35
1.5.7. Ứng dụng của GSI. 36
Chương 2. An toàn bảo mật trong Globus Toolkit 4 . 37
2.1. Giới thiệu vềGT4 . 37
2.1.1. GT4, OGSA và WSRF. 37
2.1.2. Giới thiệu chung vềdịch vụweb . 40
2.1.3. WSRF - nền tảng tài nguyên dịch vụweb . 48
2.1.4. Kiến trúc Globus Toolkit 4 . 53
2.2. Các thành phần bảo mật trong GT4 . 55
2.3. Ví dụminh họa: cài đặt bảo mật trong GRAM. 57
Chương 3. Ứng dụng công nghệtác tửtrong tính toán lưới . 61
3.1. Tác tử. 61
3.1.1. Khái niệm tác tử. 61
3.1.2. Hệ đa tác tử. 66
3.1.3. Truyền thông giữa các tác tử. 73
3.2. Tiềm năng ứng dụng công nghệtác tửtrong lưới. 76
3.3. Các hướng tiếp cận tích hợp công nghệtác tửtrong lưới. 77
3.4. Hướng triển khai công nghệtác tửtrong hệthống BKGrid2006 . 79
3.4.1. Kiến trúc hệthống BKGrid2006. 79
3.4.2. Xây dựng các tác tửgiúp đơn giản hóa việc thương lượng sửdụng dịch vụ. 81
Chương 4. Xây dựng môđun bảo mật trong BKGrid 2006 . 84
4.1. Yêu cầu cần thiết xây dựng môđun quản trịngười dùng. 84
4.2. Kiến trúc môđun quản trịngười dùng. 86
4.3. Thiết kếchi tiết. 89
4.3.1. Nhà chứng nhận thẩm quyền . 89
4.3.2. Thành phần Quản lý giấy ủy nhiệm . 91
4.3.3. Thành phần Quản lý ánh xạngười dùng. 91
4.3.4. Tích hợp với các chức năng quản lý người dùng cơbản . 92
4.3.5. Đảm bảo an toàn cho môđun quản trịngười dùng. 93
4.4. Tích hợp vào hệthống BKGrid 2006. 94
4.5. Hướng dẫn sửdụng . 95
4.6. Triển khai thửnghiệm . 97
4.6.1. Cấu hình triển khai . 97
4.6.2. Kết quảtriển khai . 99
Chương 5. Kết luận . 102
5.1. Kết quả đạt được . 102
5.2. Hướng phát triển . 103
TÀI LIỆU THAM KHẢO.
Để tải bản Đầy Đủ của tài liệu, xin Trả lời bài viết này, Mods sẽ gửi Link download cho bạn sớm nhất qua hòm tin nhắn.
Ai cần download tài liệu gì mà không tìm thấy ở đây, thì đăng yêu cầu down tại đây nhé:
Nhận download tài liệu miễn phí
này là một thuận lợi lớn khi ta phát triển các ứng dụng trên Internet, bởi
vì các tường lửa và proxy trên Internet không làm đảo lộn các truyền
41
thông của HTTP (không giống như CORBA gặp phiền toái với vấn đề
tường lửa).
Tuy nhiên, dịch vụ web có một số nhược điểm, đó là:
- Trước hết, việc truyền toàn bộ dữ liệu bằng XML rõ ràng là không hiệu
quả bằng việc sử dụng mã nhị phân. Để có được tính khả chuyển, nó đã
phải đánh đổi bằng tính hiệu quả.
- Thiếu tính linh động: Hiện tại dịch vụ web là không linh động, khi
chúng chỉ cho phép một số dạng triệu gọi dịch vụ cơ bản. CORBA có
thể cho phép lập trình viên nhiều cách cung cấp dịch vụ hơn như là dịch
vụ vĩnh viễn (persistency), thông báo (notifications), quản lý vòng đời
(lifecycle management).
Ở phần sau, ta sẽ thấy cách mà dịch vụ lưới bổ sung các nhược điểm trên
của dịch vụ web. Tuy nhiên, có một đặc điểm quan trọng để phân biệt dịch vụ
web với các công nghệ tính toán phân tán khác. Trong khi các công nghệ như
CORBA, EJBs hướng vào các hệ thống tính toán phân tán phụ thuộc chặt
(highly-coupled distributed systems), khi mà client và server phải phụ thuộc
vào nhau, dịch vụ web lại thích hợp cho các hệ thống phân tán không phụ
thuộc (losely- coupled systems), khi mà client có thể không biết gì về dịch vụ
web cho tới khi nó triệu gọi các dịch vụ Web. Các hệ thống phân tán phụ
thuộc là lý tưởng cho các ứng dụng Intranet, nhưng lại có hiệu suất thấp trên
môi trường Internet. Điều này giải thích tại sao dịch vụ web thích hợp hơn đối
với các ứng dụng trên Internet nói chung và các ứng dụng trên môi trường
lưới nói riêng.
2.1.2.1. Một triệu gọi dịch vụ web điển hình
Để hiểu rõ hơn về hoạt động của dịch vụ web, hãy theo dõi các bước để
triệu gọi một dịch vụ web.
42
Hình 2.3. Một triệu gọi dịch vụ web điển hình
1. Như đã đề cập trước đó, một client có thể không biết gì về dịch vụ web
mà nó định triệu gọi. Bởi vậy, bước đầu tiên là tìm một dịch vụ web
đáp ứng các đòi hỏi của nó. Ví dụ, nếu quan tâm tới một dịch vụ web
cung cấp thông tin về thời tiết của các thành phố của Mỹ, ta có thể tìm
nó qua bộ đăng ký và khai phá dịch vụ UDDI.
2. Bộ đăng ký UDDI sẽ trả lời cho chúng ta biết server nào cung cấp dịch
vụ mà ta yêu cầu.
3. Khi đã biết về vị trí của dịch vụ web, nhưng vẫn chưa biết triệu gọi
dịch vụ đó như thế nào. Chúng ta phải yêu cầu dịch vụ web mô tả thông
tin về chính nó để biết chính xác cách nào cần triệu gọi.
4. Dịch vụ web sẽ trả lời bằng một ngôn ngữ gọi là WSDL.
5. Cuối cùng, chúng ta đã biết dịch vụ web nằm ở đâu và triệu gọi nó như
thế nào. Quá trình triệu gọi được thực hiện bởi một ngôn ngữ gọi là
43
SOAP. Do đó, trước tiên ta phải gửi một yêu cầu SOAP (SOAP
request) để lấy thông tin về thời tiết.
6. Dịch vụ Web sẽ trả lời với một đáp ứng SOAP (SOAP response) chứa
thông tin về thời tiết mà ta yêu cầu. Nó có thể là một thông báo lỗi nếu
yêu cầu SOAP của chúng ta không đúng.
2.1.2.2. Kiến trúc dịch vụ web:
Hình 2.4. Kiến trúc dịch vụ web
- Tầng xử lý dịch vụ (Process): tầng này có thể bao gồm nhiều dịch vụ
web. Ví dụ. khả năng khám phá dịch vụ (thuộc về tầng này của kiến
trúc) cho phép tìm một dịch vụ web cụ thể từ một tập các dịch vụ web.
- Tầng mô tả dịch vụ (Description): một trong những đặc điểm thú vị của
dịch vụ web là nó có khả năng tự mô tả về mình, về những thao tác mà
nó có thể cung cấp, tham số vào ra,… Điều này được thực hiện bằng
ngôn ngữ mô tả dịch vụ web (Web Service Description Language –
WSDL).
- Tầng triệu gọi dịch vụ (Invocation): tầng này chịu trách nhiệm gọi dịch
vụ web giữa client và server sau khi đã nắm được vị trí và cách
triệu gọi. SOAP (Simple Object Access Protocol) sẽ được sử dụng để
thông báo cho phía client biết quy cách đưa một yêu cầu đến server và
quy cách của kết quả trả về.
Khai phá, kết hợp, …
WSDL
Web Services Description Language
Giao thức triệu gọi phổ biến là SOAP
nhưng về lý thuyết có thể sử dụng các
giao thức khác
Giao thức truyền thông phổ biến là HTTP,
nhưng về lý thuyết có thể sử dụng các
giao thức khác
44
- Tầng vận chuyển (Transport): tầng này trực tiếp gửi các gói tin giữa 2
phía server và client. Giao thức được sử dụng là HTTP (HyperText
Transfer Protocol).
2.1.2.3. Địa chỉ của dịch vụ web
Các dịch vụ web được xác định bằng các định danh tài nguyên thống
nhất URIs (Uniform Resource Identifiers) tương tự như URL (Uniform
Resource Locator). Chẳng hạn dịch vụ cung cấp thông tin dự báo thời tiết có
địa chỉ URI như sau:
Địa chỉ này giống như một trang web. Tuy nhiên, dịch vụ web được sử
dụng bởi các phần mềm. Nếu người dùng gõ một địa chỉ dịch vụ web URI
vào trong trình duyệt, ta sẽ nhận được một thông báo lỗi. Thực tế, hầu hết các
chương trình ta viết sẽ nhận về URI của dịch vụ web như một tham số dòng
lệnh.
2.1.2.4. Một ứng dụng dịch vụ web
Việc triệu gọi dịch vụ web được thực hiện qua client stub. Vì vậy, trong
lược đồ triệu gọi ở phần trước (hình 2.4), client thường không phải thực hiện
tất cả các bước trong một triệu gọi đơn. Hơn thế nữa, client stub còn có thể
được sinh tự động dựa trên mô tả WSDL của dịch vụ web.
Hình 2.5. Client và server stub được sinh ra từ file WSDL
45
Như vậy thứ tự các sự kiện bên phía client liên quan đến sử dụng dịch
vụ web là như sau:
- Xác định một dịch vụ web đáp ứng các yêu cầu thông qua UDDI.
- Thiết lập mô tả WSDL của dịch vụ web.
- Phát sinh stubs ngay sau đó, cho chúng vào ứng dụng của chúng ta.
- Ứng dụng sẽ sử dụng stubs tại mỗi thời điểm nó triệu gọi dịch vụ web.
Mô hình lập trình phía server cũng rất đơn giản, ta không cần viết
một chương trình server phức tạp, tự động thông dịch các yêu cầu SOAP và
đưa ra các đáp ứng SOAP. Chúng ta đơn giản chỉ cài đặt tất cả các chức năng
cho dịch vụ web của chúng ta, sau đó sinh ra một server stub (hay còn được
gọi là skeleton). Server stub sẽ chịu trách nhiệm thông dịch các yêu cầu, đưa
chúng tới cho dịch vụ thực thi. Nó cũng có thể tự động sinh ra mô tả WSDL,
hay các ngôn ngữ mô tả khác (IDL trên CORBA). Việc thực thi phía server và
server stubs được quản lý thông qua một thành phần gọi là trình chứa dịch vụ
web (Web Service container), bảo đảm các yêu cầu HTTP cho dịch vụ web
được trực tiếp tới server stub.
Giả sử rằng chúng ta đã định vị được dịch vụ web, và phát sinh client
stubs từ mô tả WSDL. Ngoài ra, các lập trình viên phía server cũng phải phát
sinh server stubs. Các bước liên quan tới triệu gọi một dịch vụ web được mô
tả như hình 2.6.
Hình 2.6. Chi tiết một triệu gọi dịch vụ web điển hình
46
1. Bất cứ khi nào ứng dụng client cần triệu gọi dịch vụ web, nó sẽ gọi
client stub. Client stub sẽ chuyển triệu gọi địa phương ('local
invocation') vào trong một yêu cầu SOAP phù hợp. Quá trình này được
gọi là marshaling hay serializing.
2. Yêu cầu SOAP
Download miễn phí Luận văn Bảo mật trong môi trường lưới với tiếp cận hướng tác tử
MỤC LỤC
MỤC LỤC. 1
LỜI NÓI ĐẦU . 3
LỜI CẢM ƠN . 4
DANH MỤC CÁC KÝ HIỆU, CHỮVIẾT TẮT. 5
DANH MỤC HÌNH VẼ. 6
Chương 1. Tổng quan tính toán lưới, bảo mật trên môi trường lưới . 8
1.1. Tính toán lưới . 8
1.1.1. Giới thiệu vềtính toán lưới . 8
1.1.2. Lợi ích của tính toán lưới . 10
1.1.3. Các vấn đềcơbản của một lưới . 12
1.1.4. Kiến trúc lưới . 14
1.2. Các khái niệm cơbản vềbảo mật . 15
1.2.1. Một sốthuật ngữcơbản. 15
1.2.2. Mã hóa thông tin sửdụng khóa. 16
1.2.3. Mã hóa đối xứng . 17
1.2.4. Mã hóa công khai . 18
1.2.5. Chữký điện tử. 19
1.2.6. Giấy chứng nhận điện tửvà Nhà chứng nhận thẩm quyền. 21
1.3. Cơchếbảo mật trong môi trường lưới. 25
1.4. Các chính sách bảo mật trong môi trường lưới. 28
1.5. Giới thiệu vềhạtầng bảo mật lưới GSI . 30
1.5.1. Cơsởhạtầng khóa công khai . 30
1.5.2. Bảo mật mức thông điệp và mức giao vận. 31
1.5.3. So sánh hiệu năng của bảo mật mức thông điệp với mức giao vận. 32
1.5.4. Giấy ủy nhiệm . 34
1.5.5. Sự ủy quyền. 35
1.5.6. Chứng thực . 35
1.5.7. Ứng dụng của GSI. 36
Chương 2. An toàn bảo mật trong Globus Toolkit 4 . 37
2.1. Giới thiệu vềGT4 . 37
2.1.1. GT4, OGSA và WSRF. 37
2.1.2. Giới thiệu chung vềdịch vụweb . 40
2.1.3. WSRF - nền tảng tài nguyên dịch vụweb . 48
2.1.4. Kiến trúc Globus Toolkit 4 . 53
2.2. Các thành phần bảo mật trong GT4 . 55
2.3. Ví dụminh họa: cài đặt bảo mật trong GRAM. 57
Chương 3. Ứng dụng công nghệtác tửtrong tính toán lưới . 61
3.1. Tác tử. 61
3.1.1. Khái niệm tác tử. 61
3.1.2. Hệ đa tác tử. 66
3.1.3. Truyền thông giữa các tác tử. 73
3.2. Tiềm năng ứng dụng công nghệtác tửtrong lưới. 76
3.3. Các hướng tiếp cận tích hợp công nghệtác tửtrong lưới. 77
3.4. Hướng triển khai công nghệtác tửtrong hệthống BKGrid2006 . 79
3.4.1. Kiến trúc hệthống BKGrid2006. 79
3.4.2. Xây dựng các tác tửgiúp đơn giản hóa việc thương lượng sửdụng dịch vụ. 81
Chương 4. Xây dựng môđun bảo mật trong BKGrid 2006 . 84
4.1. Yêu cầu cần thiết xây dựng môđun quản trịngười dùng. 84
4.2. Kiến trúc môđun quản trịngười dùng. 86
4.3. Thiết kếchi tiết. 89
4.3.1. Nhà chứng nhận thẩm quyền . 89
4.3.2. Thành phần Quản lý giấy ủy nhiệm . 91
4.3.3. Thành phần Quản lý ánh xạngười dùng. 91
4.3.4. Tích hợp với các chức năng quản lý người dùng cơbản . 92
4.3.5. Đảm bảo an toàn cho môđun quản trịngười dùng. 93
4.4. Tích hợp vào hệthống BKGrid 2006. 94
4.5. Hướng dẫn sửdụng . 95
4.6. Triển khai thửnghiệm . 97
4.6.1. Cấu hình triển khai . 97
4.6.2. Kết quảtriển khai . 99
Chương 5. Kết luận . 102
5.1. Kết quả đạt được . 102
5.2. Hướng phát triển . 103
TÀI LIỆU THAM KHẢO.
Để tải bản Đầy Đủ của tài liệu, xin Trả lời bài viết này, Mods sẽ gửi Link download cho bạn sớm nhất qua hòm tin nhắn.
Ai cần download tài liệu gì mà không tìm thấy ở đây, thì đăng yêu cầu down tại đây nhé:
Nhận download tài liệu miễn phí
Tóm tắt nội dung tài liệu:
cho truyền thông điệp, điềunày là một thuận lợi lớn khi ta phát triển các ứng dụng trên Internet, bởi
vì các tường lửa và proxy trên Internet không làm đảo lộn các truyền
41
thông của HTTP (không giống như CORBA gặp phiền toái với vấn đề
tường lửa).
Tuy nhiên, dịch vụ web có một số nhược điểm, đó là:
- Trước hết, việc truyền toàn bộ dữ liệu bằng XML rõ ràng là không hiệu
quả bằng việc sử dụng mã nhị phân. Để có được tính khả chuyển, nó đã
phải đánh đổi bằng tính hiệu quả.
- Thiếu tính linh động: Hiện tại dịch vụ web là không linh động, khi
chúng chỉ cho phép một số dạng triệu gọi dịch vụ cơ bản. CORBA có
thể cho phép lập trình viên nhiều cách cung cấp dịch vụ hơn như là dịch
vụ vĩnh viễn (persistency), thông báo (notifications), quản lý vòng đời
(lifecycle management).
Ở phần sau, ta sẽ thấy cách mà dịch vụ lưới bổ sung các nhược điểm trên
của dịch vụ web. Tuy nhiên, có một đặc điểm quan trọng để phân biệt dịch vụ
web với các công nghệ tính toán phân tán khác. Trong khi các công nghệ như
CORBA, EJBs hướng vào các hệ thống tính toán phân tán phụ thuộc chặt
(highly-coupled distributed systems), khi mà client và server phải phụ thuộc
vào nhau, dịch vụ web lại thích hợp cho các hệ thống phân tán không phụ
thuộc (losely- coupled systems), khi mà client có thể không biết gì về dịch vụ
web cho tới khi nó triệu gọi các dịch vụ Web. Các hệ thống phân tán phụ
thuộc là lý tưởng cho các ứng dụng Intranet, nhưng lại có hiệu suất thấp trên
môi trường Internet. Điều này giải thích tại sao dịch vụ web thích hợp hơn đối
với các ứng dụng trên Internet nói chung và các ứng dụng trên môi trường
lưới nói riêng.
2.1.2.1. Một triệu gọi dịch vụ web điển hình
Để hiểu rõ hơn về hoạt động của dịch vụ web, hãy theo dõi các bước để
triệu gọi một dịch vụ web.
42
Hình 2.3. Một triệu gọi dịch vụ web điển hình
1. Như đã đề cập trước đó, một client có thể không biết gì về dịch vụ web
mà nó định triệu gọi. Bởi vậy, bước đầu tiên là tìm một dịch vụ web
đáp ứng các đòi hỏi của nó. Ví dụ, nếu quan tâm tới một dịch vụ web
cung cấp thông tin về thời tiết của các thành phố của Mỹ, ta có thể tìm
nó qua bộ đăng ký và khai phá dịch vụ UDDI.
2. Bộ đăng ký UDDI sẽ trả lời cho chúng ta biết server nào cung cấp dịch
vụ mà ta yêu cầu.
3. Khi đã biết về vị trí của dịch vụ web, nhưng vẫn chưa biết triệu gọi
dịch vụ đó như thế nào. Chúng ta phải yêu cầu dịch vụ web mô tả thông
tin về chính nó để biết chính xác cách nào cần triệu gọi.
4. Dịch vụ web sẽ trả lời bằng một ngôn ngữ gọi là WSDL.
5. Cuối cùng, chúng ta đã biết dịch vụ web nằm ở đâu và triệu gọi nó như
thế nào. Quá trình triệu gọi được thực hiện bởi một ngôn ngữ gọi là
43
SOAP. Do đó, trước tiên ta phải gửi một yêu cầu SOAP (SOAP
request) để lấy thông tin về thời tiết.
6. Dịch vụ Web sẽ trả lời với một đáp ứng SOAP (SOAP response) chứa
thông tin về thời tiết mà ta yêu cầu. Nó có thể là một thông báo lỗi nếu
yêu cầu SOAP của chúng ta không đúng.
2.1.2.2. Kiến trúc dịch vụ web:
Hình 2.4. Kiến trúc dịch vụ web
- Tầng xử lý dịch vụ (Process): tầng này có thể bao gồm nhiều dịch vụ
web. Ví dụ. khả năng khám phá dịch vụ (thuộc về tầng này của kiến
trúc) cho phép tìm một dịch vụ web cụ thể từ một tập các dịch vụ web.
- Tầng mô tả dịch vụ (Description): một trong những đặc điểm thú vị của
dịch vụ web là nó có khả năng tự mô tả về mình, về những thao tác mà
nó có thể cung cấp, tham số vào ra,… Điều này được thực hiện bằng
ngôn ngữ mô tả dịch vụ web (Web Service Description Language –
WSDL).
- Tầng triệu gọi dịch vụ (Invocation): tầng này chịu trách nhiệm gọi dịch
vụ web giữa client và server sau khi đã nắm được vị trí và cách
triệu gọi. SOAP (Simple Object Access Protocol) sẽ được sử dụng để
thông báo cho phía client biết quy cách đưa một yêu cầu đến server và
quy cách của kết quả trả về.
Khai phá, kết hợp, …
WSDL
Web Services Description Language
Giao thức triệu gọi phổ biến là SOAP
nhưng về lý thuyết có thể sử dụng các
giao thức khác
Giao thức truyền thông phổ biến là HTTP,
nhưng về lý thuyết có thể sử dụng các
giao thức khác
44
- Tầng vận chuyển (Transport): tầng này trực tiếp gửi các gói tin giữa 2
phía server và client. Giao thức được sử dụng là HTTP (HyperText
Transfer Protocol).
2.1.2.3. Địa chỉ của dịch vụ web
Các dịch vụ web được xác định bằng các định danh tài nguyên thống
nhất URIs (Uniform Resource Identifiers) tương tự như URL (Uniform
Resource Locator). Chẳng hạn dịch vụ cung cấp thông tin dự báo thời tiết có
địa chỉ URI như sau:
Địa chỉ này giống như một trang web. Tuy nhiên, dịch vụ web được sử
dụng bởi các phần mềm. Nếu người dùng gõ một địa chỉ dịch vụ web URI
vào trong trình duyệt, ta sẽ nhận được một thông báo lỗi. Thực tế, hầu hết các
chương trình ta viết sẽ nhận về URI của dịch vụ web như một tham số dòng
lệnh.
2.1.2.4. Một ứng dụng dịch vụ web
Việc triệu gọi dịch vụ web được thực hiện qua client stub. Vì vậy, trong
lược đồ triệu gọi ở phần trước (hình 2.4), client thường không phải thực hiện
tất cả các bước trong một triệu gọi đơn. Hơn thế nữa, client stub còn có thể
được sinh tự động dựa trên mô tả WSDL của dịch vụ web.
Hình 2.5. Client và server stub được sinh ra từ file WSDL
45
Như vậy thứ tự các sự kiện bên phía client liên quan đến sử dụng dịch
vụ web là như sau:
- Xác định một dịch vụ web đáp ứng các yêu cầu thông qua UDDI.
- Thiết lập mô tả WSDL của dịch vụ web.
- Phát sinh stubs ngay sau đó, cho chúng vào ứng dụng của chúng ta.
- Ứng dụng sẽ sử dụng stubs tại mỗi thời điểm nó triệu gọi dịch vụ web.
Mô hình lập trình phía server cũng rất đơn giản, ta không cần viết
một chương trình server phức tạp, tự động thông dịch các yêu cầu SOAP và
đưa ra các đáp ứng SOAP. Chúng ta đơn giản chỉ cài đặt tất cả các chức năng
cho dịch vụ web của chúng ta, sau đó sinh ra một server stub (hay còn được
gọi là skeleton). Server stub sẽ chịu trách nhiệm thông dịch các yêu cầu, đưa
chúng tới cho dịch vụ thực thi. Nó cũng có thể tự động sinh ra mô tả WSDL,
hay các ngôn ngữ mô tả khác (IDL trên CORBA). Việc thực thi phía server và
server stubs được quản lý thông qua một thành phần gọi là trình chứa dịch vụ
web (Web Service container), bảo đảm các yêu cầu HTTP cho dịch vụ web
được trực tiếp tới server stub.
Giả sử rằng chúng ta đã định vị được dịch vụ web, và phát sinh client
stubs từ mô tả WSDL. Ngoài ra, các lập trình viên phía server cũng phải phát
sinh server stubs. Các bước liên quan tới triệu gọi một dịch vụ web được mô
tả như hình 2.6.
Hình 2.6. Chi tiết một triệu gọi dịch vụ web điển hình
46
1. Bất cứ khi nào ứng dụng client cần triệu gọi dịch vụ web, nó sẽ gọi
client stub. Client stub sẽ chuyển triệu gọi địa phương ('local
invocation') vào trong một yêu cầu SOAP phù hợp. Quá trình này được
gọi là marshaling hay serializing.
2. Yêu cầu SOAP