1. Trang chủ
  2. » Luận Văn - Báo Cáo

Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition

87 827 0
Tài liệu đã được kiểm tra trùng lặp

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 87
Dung lượng 1,65 MB

Nội dung

Tài liệu tham khảo công nghệ thông tin Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition

Trang 1

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



Nguyễn Đức Trung

XÂY DỰNG SERVICE PROXY ĐỂ KIỂM CHỨNG RÀNG BUỘC

THỜI GIAN TRONG WEB SERVICE COMPOSITION

KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY

Ngành : Công Nghệ Thông Tin

HÀ NỘI, 2009

Trang 2

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



Nguyễn Đức Trung

XÂY DỰNG SERVICE PROXY ĐỂ KIỂM CHỨNG RÀNG BUỘC

THỜI GIAN TRONG WEB SERVICE COMPOSITION

KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY

Ngành : Công Nghệ Thông Tin Cán bộ hướng dẫn: TS Trương Ninh Thuận

HÀ NỘI, 2009

Trang 3

LỜI CẢM ƠN

Em xin gửi lời cảm ơn sâu sắc nhất đến TS Trương Ninh Thuận, người thầy đã cho

em định hướng, tận tình chỉ bảo em những ý kiến quý báu về công nghệ Web Service, cáckiến thức về chất lượng dịch vụ Web Thầy đã giúp đỡ em rất nhiều và đi cùng em trongsuốt thời gian thực hiện khoá luận Thầy chỉ cho em cách tiếp cận, nghiên cứu một côngnghệ mới, cách tìm ra những giải pháp cho vấn đề mắc phải

Em xin chân thành cảm ơn quý Thầy Cô và các bạn đã giúp đỡ em trong nhữngnăm học qua Em xin cảm ơn Bộ môn Công nghệ phần mềm, Khoa Công nghệ thông tin,Trường Đại Học Công Nghệ, Đại Học Quốc Gia Hà Nội đã tạo điều kiện thuận lợi cho emtrong suốt quá trình học tập và làm khoá luận này

Đề tài “Xây dựng Service Proxy để kiểm chứng ràng buộc thời gian trong Web Service Composition ” là một đề tài khá mới mẻ, lại được hoàn thành trong quỹ thời gian

hạn hẹp nên khó tránh khỏi những khiếm khuyết Em mong nhận được những góp ý chânthành từ thầy cô giáo và các bạn để đề tài có thể được mở rộng và nghiên cứu kỹ hơn, đưavào trong thực tiễn ngành công nghệ thông tin hiện nay

Hà Nội, ngày 15 tháng 05 năm 2009

Sinh viên:

Nguyễn Đức Trung

Trang 4

TÓM TẮT KHOÁ LUẬN

Ngày nay cùng với sự phát triển mạnh mẽ của môi trường Internet, các ứng dụngtriển khai trên nền Web ngày càng được phát triển rộng rãi và phong phú Đồng thời đicùng sự phát triển mạnh mẽ của nền kinh tế thị trường là nhu cầu áp dụng công nghệthông tin vào trong các quy trình thương mại ngày càng trở nên phổ biến và là điểm mấuchốt để các tổ chức doanh nghiệp giải quyết công việc của mình Sự ra đời của WebService được coi là một công nghệ mang đến cuộc cách mạng trong cách thức hoạt độngcủa các dịch vụ B2B – Business to Bussiness và B2C – Bussiness to Customer Giá trị cơbản của dịch vụ Web dựa trên việc cung cấp các phương thức theo chuẩn trong việc truycập đối với hệ thống đóng gói và kế thừa Các phần mềm được viết bởi những ngôn ngữlập trình khác nhau và chạy trên các nền tảng khác nhau có thể sử dụng Web Service đểchuyển đổi dữ liệu thông qua mạng Internet

Nội dung của khóa luận đưa ra một cái nhìn tổng quát về công nghệ Web Service,phân tích và tìm hiểu các thành phần chuẩn được sử dụng trong công nghệ Web Service,

đi vào nghiên cứu kiến trúc về Web Service Từ những kiến thức thu được về công nghệWeb Service, khóa luận đi đến một hướng tiếp cận mới đó là tìm hiểu về chất lượng cácdịch vụ Web – QoS cho Web Service dựa trên mô hình tích hợp Web Service với cácWeb Service Composition Từ các kiến thức về chất lượng các dịch vụ Web, khóa luận sẽtìm hiểu về một khía cạnh chất lượng dịch vụ Web đó là kiểm chứng ràng buộc thời gianđáp ứng của các Web Service Composition và mô hình hóa các ràng buộc thời gian trênbiểu đồ UML Timing Diagram

Để minh họa cho việc kiểm chứng ràng buộc thời gian đáp ứng của các WebService Composition, chúng tôi đã tiến hành xây dựng một ứng dụng nhỏ là Web ServiceTravel-Agent và tiến hành đo lường thời gian đáp ứng của các Service Composition hợpthành lên Web Service Travel-Agent đó

Trang 5

MỤC LỤC

CHƯƠNG 1: ĐẶT VẤN ĐỀ 1

1.1 Bối cảnh 1

1.2 Mục tiêu khóa luận 2

1.3 Cấu trúc khóa luận 3

CHƯƠNG 2: CÔNG NGHỆ WEB SERVICE 5

2.1 Kiến trúc hướng dịch vụ SOA 5

2.1.1 Khái niệm kiến trúc hướng dịch vụ SOA 5

2.1.2 Nguyên tắc thiết kế của SOA 6

2.2 Công nghệ Web Service 7

2.2.1 Tổng quan về Web Service 7

2.2.2 Kiến trúc Web Service 9

2.2.3 Các công nghệ của Web Service 13

CHƯƠNG 3: QoS CHO WEB SERVICE 24

3.1 Chất lượng dịch vụ Web Service – QoS cho Web Service 24

3.2 Các yêu cầu về chất lượng dịch vụ cho Web Service 25

3.3 QoS cho các dịch vụ Web 27

3.4 Điều chỉnh và thiết lập ràng buộc QoS 27

3.5 Hiệu ứng thắt cổ chai trong quá trình thực thi của Web Service 28

3.6 Đánh giá hiệu năng giao thức SOAP 29

3.7 Phương pháp tiếp cận để cung cấp chất lượng dịch vụ cho Web Service 30

CHƯƠNG 4: BIỂU ĐỒ TIMING DIAGRAM 32

4.1 Giới thiệu UML 32

4.2 Tổng quan về biểu đồ Timing Diagram 33

4.3 Mục đích của biểu đồ Timing Diagram 34

Trang 6

4.5.1 Các trạng thái 36

4.5.2 Các sự kiện và các thông điệp 37

4.5.3 Thời gian 38

4.5.4 Các đường State-Line 39

4.5.5 Ràng buộc thời gian 40

CHƯƠNG 5: BÀI TOÁN NGHIÊN CỨU 42

5.1 Tìm hiểu về Service Proxy 42

5.2 Tìm hiểu về Web Service Composition 45

5.3 Bài toán kiểm chứng ràng buộc thời gian đáp ứng của các Web Service Composition 49

5.3.1 Giới thiệu bài toán 49

5.3.2 Mục tiêu và yêu cầu của bài toán 50

5.3.3 Phân tích bài toán 51

CHƯƠNG 6: THỰC NGHIỆM 54

6.1 Phạm vi ứng dụng 54

6.2 Thiết kế ứng dụng 56

6.3 Cài đặt, xây dựng và triển khai ứng dụng 58

6.3.1 Cài đăt chương trình 58

6.3.2 Xây dựng và triển khai các Web Services thành phần 61

6.3.3 Xây dựng và triển khai Service Proxy 66

6.3.4 Phát triển chương trình client và thực nghiệm 69

CHƯƠNG 7: KẾT LUẬN 74

Trang 7

DANH SÁCH CÁC THUẬT NGỮ VÀ KHÁI NIỆM

SOA Service Oriented Architecture – Kiến trúc hướng dịch vụ

Service

Composition

Các Serivice có sẵn có thể được dùng để tích hợp lên một Web Service lớn hơn Hoặc là một Web Service thành phần chuyên biệt phục vụ cho một nhiệm vụ

Service Composite Web Service được tổng hợp lên từ các Service CompositionService Provider

Nhà cung cấp dịch vụ Web Service Đây chính là các nguồn cung cấp đưa ra các dịch vụ cho khách hàng sử dụng

Service Consumer

Đây chính là dịch vụ ở phía người sử dụng, yêu cầu các dịch vụđưa ra bởi Service Provider

Service Broken

Nơi chấp nhận các yêu cầu đưa ra bởi Service Consumer, liên

hệ với Service Provider để lấy dịch vụ trả về cho Service Consumer

W3C

Viết tắt của Word Wide Web Consortium – là một tổ chức lập

ra các chuẩn cho các công nghệ chạy trên nền Internet, đặc biệt

là Word Wide Web

QoS Quality of Service - Chất lượng dịch vụ

Message request Thông điệp yêu cầu

Message response Thông điệp đáp ứng

DANH SÁCH CÁC HÌNH VẼ

Trang 8

Hình 2: Web Service cung cấp một tầng trừu tượng giữa ứng dụng client và ứng dụng

cần gọi tới 8

Hình 3: Mô tả cơ chế hoạt động của Web Service 9

Hình 4: Web Service technology stack 10

Hình 5: TCP/IP network model 11

Hình 6: Mô tả cấu trúc của một thông điệp XML 14

Hình 7: Mô tả cấu trúc của một thông điệp SOAP 15

Hình 8: Mô tả thông điệp SOAP faults 16

Hình 9: Mô tả việc trao đổi thông điệp SOAP thông qua giao thức HTTP 17

Hình 10: Mô tả thành phần binding trong tài liệu WSDL 20

Hình 11: Minh họa ví dụ của một tài liệu WSDL 20

Hình 12: Minh họa cấu trúc dữ liệu businessService 22

Hình 13: Biểu đồ Timing Diagram dưới dạng “Robus Diagram” 35

Hình 14: Biểu đồ Timing Diagram dưới dạng mở rộng 36

Hình 15: Minh họa các trạng thái được thể hiện trong biểu đồ Timing Diagram 37

Hình 16: Minh họa các sự kiện và thông điệp trong biểu đồ Timing Diagram 38

Hình 17: Minh họa thể hiện thời gian trong biểu đồ Timing Diagram 39

Hình 18: Thời gian ước lượng trong biểu đồ Timing Diagram 39

Hình 19: Minh họa các đường state-line trong biểu đồ Timing Diagram 40

Hình 20: Minh họa các ràng buộc thời gian trong biểu đồ Timing Diagram 40

Hình 21: Minh hoạ mô hình Web Service với Service Proxy 42

Hình 22: Minh họa mô hình tích hợp Web Service 46

Hình 23: Minh hoạ mô hình tổng quan bài toán Travel-Agent 51

Hình 24: Minh hoạ đường Lifeline cho SearchHotel Service 52

Hình 25: Minh hoạ đường Lifeline cho SearchFlight Service 53

Hình 26: Minh họa thiết kế tổng thể của ứng dụng 56

Hình 27: Biểu đồ tuần tự của hệ thống 57 Hình 28: Minh họa giao diện Admin của apache soap trên Web Server tại cổng 2417 59

Trang 9

Hình 29: Minh họa giao diện Admin của apache soap trên Web Server tại cổng 8080 60

Hình 30: Minh họa trang Admin của Apache Axis trên Web Server tại cổng 8080 60

Hình 31: Code kết nối database trong file SearchHotel Service 61

Hình 32: Nội dung của tệp deploy.wsdl 62

Hình 33: Danh sách các dịch vụ liệt kê trên web site soap engine 63

Hình 34: Nội dung file deploy.wsdd 64

Hình 35: Các dịch vụ được liệt kê trên trang quản trị của Axis 65

Hình 36: Nội dung file WSDL của dịch vụ SearchFlightService 66

Hình 37: Code Service Proxy goi tới SearchFlightService 67

Hình 38: Minh họa đo lường thời gian đáp ứng 68

Hình 39: Minh họa test chương trình 70

Hình 40: Biểu đồ Timing Diagram mô tả ràng buộc thời gian của WSComposition 71

Hình 41: Minh hoạ mô hình kiểm chứng ràng buộc thời gian đáp ứng 72

Trang 10

vụ đòi hỏi xử lý các vấn đề liên quan đến dữ liệu phân tán, xử lý các thông tin khác nhau

do nhiều tổ chức nắm giữ Đã có nhiều kiến trúc phần mềm được đưa ra nhưng chưa đủmạnh để giải quyết được vấn đề này Sự ra đời của kiến trúc phần mềm hướng dịch vụ đã

mở ra một hướng đi mới trong việc giải quyết các loại bài toán này

Kiến trúc SOA định nghĩa một kiểu kiến trúc cho việc xây dựng các hệ thống phântán theo hướng dịch vụ, tức là hệ thống được phân tách thành các module chương trình,

và các module này được phát triển độc lập, các module sử dụng các công nghệ khác nhaunhưng vẫn có thể giao tiếp được với nhau Một công nghệ tiêu biểu nhất cho kiến trúchướng dịch vụ là công nghệ Web Service Với công nghệ Web Service, mỗi Service ở đây

là một module có thể thực hiện các công việc khác nhau, ta có thể tổng hợp các Servicethành phần lại để cùng thực hiện một công việc lớn, đó được gọi là công nghệ tích hợpWeb Service, khi đó mỗi Service thành phần được gọi là một Service Composition Sự rađời của công nghệ Web Service đã đem lại rất nhiều lợi thế cho việc chia sẻ tài nguyênqua mạng, trợ giúp xây dựng các hệ thống phân tán đồng thời đáp ứng được tính mềm dẻocần thiết, hệ thống có thể dễ dàng chấp nhận những thay đổi lớn so với thiết kế ban đầu

mà vẫn đảm bảo cho vấn đề nâng cấp và bảo trì sau này Web Service đem đến đầy đủ sự

Trang 11

đáp ứng cần thiết cho các quy trình B2B – Bussiness to Bussiness và B2C – Bussiness toCustomer, chính vì thế Web Service hiện tại đang là một thuật ngữ đang được nhắc đếnrất nhiều và ngày càng được sử dụng rộng rãi.

Tuy nhiên Web Service là một công nghệ triển khai thông qua môi trường Internetcho nên vấn đề về chất lượng các dịch vụ Web cũng là một vấn đề đáng lưu tâm, chính vìthế đã xuất hiện các tiêu chuẩn chất lượng dịch vụ cho Web Service – QoS cho WebService Một khía cạnh về QoS cho Web Service đó là thời gian đáp ứng của các dịch vụWeb, đây là một vấn đề rất đáng quan tâm vì Web Service là một kiến trúc phần mềmphân tán, cho nên thường có một sự liên kết giữa các dịch vụ với nhau Khi thời gian đápứng của một dịch vụ quá lâu có thể dẫn đến ảnh hưởng tới các dịch vụ khác Mặt khác khi

có nhiều nhà cung cấp dịch vụ Web thì khi đó sẽ có nhiều sự lựa chọn của khách hàngtrong việc tìm và sử dụng dịch vụ Web tốt nhất cho mình Trên môi trường Internet,người sử dụng trước tiên sẽ quan tâm nhất đến vấn đề thời gian, thời gian đáp ứng củamột dịch vụ Web nhanh hay chậm sẽ quyết định đến sự thành công hay không của nhàcung cấp dịch vụ Web đó Việc kiểm soát thời gian đáp ứng của các dịch vụ Web là mộtkhía cạnh rất rộng, cho nên ở phạm vi khóa luận này chúng tôi đề cập đến việc kiểmchứng ràng buộc thời gian đáp ứng của việc tích hợp các Web Services có đáp ứng đượcvới tiêu chuẩn QoS về thời gian hay không

1.2.

Mục tiêu khóa luận

Để thực hiện các vấn đề nêu ra như trên, khoá luận sẽ lần lượt trình bày những kiến thức cần thiết để giải quyết yêu cầu của bài toán đặt ra

Khóa luận sẽ tập trung vào một số các vấn đề sau:

 Tìm hiểu khái quát về kiến trúc hướng dịch vụ SOA, đi sâu tìm hiểu công nghệWeb Service, kiến trúc và các thành phần sử dụng cho Web Service

 Tìm hiểu Service Proxy, một dạng Web Service đặc biệt được triển khai ở phía

Trang 12

 Tiếp cận đến vấn đề về chất lượng các dịch vụ Web, các yếu tố ảnh hưởng đếnhiệu năng hoạt động của Web Service Đi vào tìm hiểu việc đo lường thời gian đápứng của các Web Service Composition sử dụng Service Proxy.

 Nghiên cứu về biểu đồ UML Timing Diagram, mô hình hóa các ràng buộc thờigian đáp ứng của Web Service Composition trên biểu đồ UML Timing Diagram

 Đề xuất phương pháp kiểm chứng tự động thời gian đáp ứng của các Web Servicestrong một ứng dụng sử dụng sự tích hợp các Web Services với các ràng buộc màbiểu đồ UML Timing Diagram mô tả

1.3.

Cấu trúc khóa luận

Các phần còn lại của khóa luận bao gồm các phần sau:

Chương 2 đưa ra cái nhìn tổng quát về công nghệ Web Service, tìm hiểu về các

thành phần chuẩn được sử dụng trong công nghệ Web Service, kiến trúc Web Service vàquy trình hoạt động của một Web Service

Chương 3 tiếp cận đến vấn đề chất lượng dịch vụ Web Xem xét các yêu cầu về

chất lượng cho Web Service, các yếu tố ảnh hưởng đến hiệu năng hoạt động của WebService và một vài phương pháp đơn giản để cung cấp chất lượng dịch vụ Web

Chương 4 trình bày về biểu đồ mới được thêm vào trong UML 2.0 đó là biểu đồ

Timing Diagram Tìm hiểu về mục đích biểu đồ, các thành phần sử dụng trong biểu đồTiming Diagram và từ đó sử dụng biểu đồ Timing Diagram để đặc tả cho các ràng buộcthời gian của các Web Service Composition

Chương 5 phân tích bài toán “Xây dựng Service Proxy để kiểm chứng ràng buộc

thời gian đáp ứng trong Web Service Composition”, nghiên cứu về Service Proxy,Service Composition và công nghệ tích hợp Web Service

Trang 13

Chương 6 xây dựng một ví dụ minh hoạ cho bài toán kiểm chứng, dựa vào các kết

quả thu được từ ví dụ minh hoạ để thực hiện mục tiêu của khóa luận đó là kiểm chứngxem các kết quả thu được có đáp ứng được tiêu chuẩn đề ra hay không

Chương 7 đánh giá kết quả khóa luận đã đạt được và nêu ra hướng phát triển trong

tương lai cho đề tài này

Trang 14

CHƯƠNG 2: CÔNG NGHỆ WEB SERVICE

Chương 2 đề cập đến công nghệ Web Service, đưa ra khái niệm căn bản về kiến trúc hướng dịch vụ SOA, đi sâu vào tìm hiểu công nghệ Web Service, các công nghệ được sử dụng cho Web Service, kiến trúc của Web Service và các lợi ích khi sử dụng công nghệ này

2.1.

Kiến trúc hướng dịch vụ SOA

2.1.1.Khái niệm kiến trúc hướng dịch vụ SOA

SOA - viết tắt của thuật ngữ Service Oriented Architecture (kiến trúc hướng dịch vụ)

là “Khái niệm về hệ thống trong đó mỗi ứng dụng được xem như một nguồn cung cấpdịch vụ” [9]

Dịch vụ là yếu tố then chốt trong SOA Có thể hiểu dịch vụ như là hàm chức năng(module phần mềm) thực hiện quy trình nghiệp vụ nào đó, một cách cơ bản, SOA là tậphợp các dịch vụ kết nối mềm dẻo với nhau (nghĩa là một ứng dụng có thể nói chuyện vớimột ứng dụng khác mà không cần biết các chi tiết kĩ thuật bên trong), có giao tiếp (dùng

để gọi hàm dịch vụ) được định nghĩa rõ ràng và độc lập với nền tảng hệ thống, và có thểtái sử dụng SOA là cấp độ cao hơn của phát triển ứng dụng, chú trọng đến quy trìnhnghiệp vụ và dùng giao tiếp chuẩn để giúp che đi sự phức tạp của kĩ thuật bên dưới

Thiết kế SOA tách riêng phần thực hiện dịch vụ (phần mềm) với giao tiếp gọi dịch

vụ Điều này tạo nên một giao tiếp nhất quán cho ứng dụng khách sử dụng dịch vụ bấtchấp công nghệ thực hiện dịch vụ Thay vì xây dựng các ứng dụng đơn lẻ và đồ sộ, nhàphát triển sẽ xây dựng các dịch vụ có tính linh hoạt có thể triển khai và tái sử dụng trongtoàn bộ quy trình nghiệp vụ Điều này cho phép tái sử dụng phần mềm tốt hơn, cũng nhưtăng sự linh hoạt vì nhà phát triển có thể cải tiến dịch vụ mà không làm ảnh hưởng đếnClient sử dụng dịch vụ

Trang 15

Thực ra khái niệm SOA không hoàn toàn mới, DCOM và CORBA cũng có kiến trúctương tự Tuy nhiên các kiến trúc cũ ràng buộc các thành phần với nhau quá chặt, ví dụcác ứng dụng phân tán muốn làm việc với nhau phải đạt đuợc thoả thuận về chi tiết tậphàm API, một thay đổi mã lệnh trong thành phần COM sẽ yêu cầu những thay đổi tươngứng đối với mã lệnh truy cập thành phần COM này.

Ưu điểm quan trọng nhất của SOA là khả năng kết nối mềm dẻo (nhờ sự chuẩn hoágiao tiếp) và tái sử dụng Các dịch vụ có thể được sử dụng với trình Client chạy trên nềntảng bất kì và được viết bởi ngôn ngữ bất kì

2.1.2.Nguyên tắc thiết kế của SOA

SOA dựa trên hai nguyên tắc thiết kế quan trọng [17]:

 Mô-đun: đó là tách các vấn đề lớn thành nhiều vấn đề nhỏ hơn

 Đóng gói : Che đi dữ liệu và lô-gic trong từng mô-đun đối với các truy cập từ bênngoài

Hai tính chất này sẽ dẫn đến đặc điểm thiết kế của kiến trúc SOA đó là các dịch vụtương tác với nhau qua các thành phần giao tiếp, tuy nhiên các dịch vụ đó vẫn hoạt độngđộc lập với nhau, chia sẻ các lược đồ dữ liệu cho nhau và tuân thủ các chính sách của kiếntrúc chung nhất

Trang 16

Công nghệ Web Service

2.2.1.Tổng quan về Web Service

Web Service là gì: Web Service là một giao diện truy cập mạng đến các ứng dụngchức năng, được xây dựng từ việc sử dụng các công nghệ chuẩn Internet [1][4] Đượcminh hoạ trong hình dưới đây

Hình 1: Web Service cho phép truy cập tới các code ứng dụng sử dụng chuẩn công nghệ Internet

Thuật ngữ Web Service diễn tả một cách thức tích hợp các ứng dụng trên nền weblại với nhau bằng cách sử dụng các công nghệ XML, SOAP, WSDL, và UDDI trên nềntảng các giao thức Internet với mục tiêu tích hợp ứng dụng và truyền thông điệp XMLđược sử dụng để đánh dấu dữ liệu, SOAP được dùng để truyền dữ liệu, WSDL được sửdụng để mô tả các dịch vụ có sẵn và UDDI được sử dụng để liệt kê những dịch vụ nàohiện tại đang có sẵn để có thể sử dụng Web Service cho phép các tổ chức có thể trao đổi

dữ liệu với nhau mà không cần phải có kiến thức hiểu biết về hệ thống thông tin đứng sauFirewall kia [1]

Không giống như mô hình Client/Server truyền thống, chắng hạn như hệ thốngWebserver/webpage, Web Service không cung cấp cho người dùng một giao diện đồ hoạnào, Web Service đơn thuần chỉ là việc chia sẻ các dữ liệu logic và xử lý các dữ liệu đóthông qua một giao diện chương trình ứng dụng được cài đặt xuyên suốt trên mạng máytính Tuy nhiên nguời phát triển Web Service hoàn toàn có thể đưa Web Service vào mộtgiao diện đồ hoạ người dùng (chẳng hạn như là một trang web hoặc một chương trìnhthực thi nào đó) để có thể cung cấp thêm các chức năng đặc biệt cho người dùng

Trang 17

Web Service cho phép các ứng dụng khác nhau từ các nguồn khác nhau có thể giaotiếp với các ứng dụng khác mà không đòi hỏi nhiều thời gian coding, do tất cả các quátrình giao tiếp đều tuân theo định dạng XML, cho nên Web Service không bị phụ thuộcvào bất kì hệ điều hành hay ngôn ngữ lập trình nào Ví dụ, chương trình viết bằng ngônngữ Java cũng có thể trao đổi dữ liệu với các chương trình viết bằng Perl, các ứng dụngchạy trên nền Windows cũng có thể trao đổi dữ liệu với các ứng dụng chạy trên nềnLinux Công nghệ Web Service không yêu cầu phải sử dụng trình duyệt và ngôn ngữHTML, đôi khi Web Service còn được gọi là Application Services

Xét theo một khía cạnh khác, nếu các ứng dụng có thể truy cập thông qua mạngmáy tính bằng việc sử dụng các giao thức như HTTP, XML, SMTP hoặc Jabber thì đóchính là Web Service

Như Hình 1 và Hình 2 đã minh họa , Web Service là một Application Interface đượcđặt giữa Application Code và người sử dụng các code đó Nó có thể được ví như mộttầng trừu tượng, phân tách giữa platform và ngôn ngữ lập trình, nó mô tả cách thức màcác application code được triệu gọi như thế nào Điều này có nghĩa nếu bất kì một ngônngữ lập trình nào hỗ trợ Web Service đều có thể truy cập các ứng dụng chức năng củanhau

Hình 2: Web Service cung cấp một tầng trừu tượng giữa ứng dụng client và ứng dụng cần gọi tới.

Ngày này, Web Service có thể được triển khai trên Internet dưới dạng một WebsiteHTML, chính vì thế, các Application Service cần phải có một cơ thế cho việc công bố,quản lý, tìm kiếm và phục hồi nội dung được người sử dụng truy cập thông qua giao thứcchuẩn HTTP và định dạng dữ liệu HTML Các ứng dụng Client ( như Web Browser) cần

Trang 18

Web Service cung cấp tính trừu tượng cho các giao diện chuẩn, cho nên sẽ khôngnảy sinh ra bất kì vấn đề gì trong quá trình tương tác khi các service được viết trên java

và trình duyệt được viết bằng C++, hoặc các service được triển khai trên Unix trong khicác trình duyệt lại được triển khai trên Windows Web Service cho phép giao tiếp giữacác platform khác nhau có thể hoạt động cùng nhau theo nguyên tắc tạo ra một platformtrung gian có liên quan

Tính tương thích (Inteoperability) là một lợi thế vô cùng mạnh mẽ của Web Service,thông thường, các công nghệ Java và công nghệ của Microsoft rất khó có thể tích hợpđược với nhau , nhưng với Web Service thì các Application và Client sử dụng 2 côngnghệ trên hoàn toàn có khả năng tương tác với nhau thông qua Web Service

Rất nhiều nhà cung cấp ứng dụng như IBM và Microsoft đều đã hỗ trợ Web Servicetrong các sản phẩm của họ IBM hỗ trợ Web Service thông qua gói WebSphere, Tivoli,Lotus và DB2 và Microsoft với NET cũng đã hỗ trợ Web Service

2.2.2 Kiến trúc Web Service

2.2.2.1 Mô tả cơ chế hoạt động của Web Service

Hình 3: Mô tả cơ chế hoạt động của Web Service.

Cơ chế hoạt động của Web Service yêu cầu phải có 3 thao tác đó là : Find, Public,Bind[1]

Trang 19

Trong kiến trúc Web Service, Service Provider công bố các mô tả về các servicethông qua Service Registry Service Consumer tìm kiếm trong các Service Registry để tìm

ra các service mà họ cần sử dụng Service Consumer có thể là một người hoặc cũng có thể

là một chương trình

Kĩ thuật mô tả dịch vụ là một trong những thành phần chủ chốt của kiến trúc WebService Các thông tin mô tả đầy đủ nhất về kiến trúc Web Service được thể hiện tronghai tài liệu riêng biệt, đó là NASSL – Network Accessible Service SpecificationLanguage và WDS – Web-Defined Service NASSL là một tài liệu dưới dạng chuẩn củaXML cho các service chạy trên nền Network, nó được sử dụng để chỉ ra các thông tinhoạt động của Web Service, chẳng hạn như danh sách các service, các mô tả về service,ngày hết hạn của service và các thông tin liên quan đến các Service Provider, như tên, địachỉ Tài liệu WDS là một tài liệu mang tính đáp ứng đầy đủ cho tài liệu NASSL Khi takết hợp hai tài liệu này với nhau ta sẽ có được sự mô tả một cách đầy đủ về các dịch vụ đểcho phía yêu cầu dịch vụ có thể dễ dàng tìm kiếm và gọi các dịch vụ đó

2.2.2.2.Kiến trúc phân tầng của Web Service

Hình 4: Web Service technology stack

Trang 20

Mô hình kiến trúc phân tầng của Web Service tương tự với mô hình TCP/IP được sửdụng để mô tả kiến trúc Internet.

Hình 5: TCP/IP network model

Các tầng truyền thống như Packaging, Description, và Discovery trong mô hình WebService Stack là những tầng cung cấp khả năng tích hợp và cần thiết cho mô hình ngônngữ lập trình trung lập

Tầng Discovery : Tầng Discovery cung cấp cơ chế cho người dùng khả năng lấy

các thông tin mô tả về các Service Provider Công nghệ được sử dụng tại tầng này

đó chính là UDDI – Universal Description, Discovery and Integration

Tầng Desciption : Khi Web Service được thực thi, nó cần phải đưa ra các quyết

định về các giao thức trên các tầng Network, Transport, Packaging mà nó sẽ hỗ trợtrong quá trình thực thi Các mô tả về dịch vụ sẽ đưa ra phương pháp để làm thếnào mà các Service Consumer có thể liên kết và sử dụng các service đó Tại tầngDescription, công nghệ được sử dụng ở đây chính là WSDL (Web ServiceDesciption Language) – Ngôn ngữ mô tả Web Service Ngoài ra, ít phổ biến hơn,chúng ta còn có 2 ngôn ngữ khác được định nghĩa bởi tổ chức W3C đó là ngôn ngữmôt tả tài nguyên - W3C’s Resource Desciption Framework (RDF) và ngôn ngữđánh dấu sự kiện DARPA Cả hai ngôn ngữ này đều có khả năng cung cấp việc mô

tả Web Service mạnh hơn ngôn ngữ WSDL tuy nhiên do tính phức tạp của chúngnên không được phát triển rộng rãi Chúng tôi sẽ đề cập đến ngôn ngữ WSDL mộtcách cụ thể hơn trong phần “Các công nghệ của Web Service ” tại chương 2 củakhóa luận này

Trang 21

Tầng Packaging : Việc thực hiện vận chuyển các dữ liệu Web Service được thực

hiện bởi tầng Transport, tuy nhiên trước khi được vận chuyển, các dữ liệu cần phảiđược đóng gói lại theo các định dạng đã định trước để các thành phần tham gia vào

mô hình Web Service có thể hiểu được, việc đóng gói dữ liệu được thi bởi tầngPackaging Việc đóng gói dữ liệu bao gồm các công việc định dạng dữ liệu, mãhóa các giá trị đi kèm dữ liệu đó và các công việc khác

Các dữ liệu có thể được đóng gói dưới dạng các tài liệu HTML, tuy nhiên với cáctài liệu HTML thường không thuận tiện cho yêu cầu này bởi vì HTML chỉ có ưuđiểm trong việc thể hiện dữ liệu hơn là trình bày ý nghĩa dữ liệu đó XML là mộtđịnh dạng cơ bản nhất cho việc trình bày dữ liệu, bởi vì XML có thể được sử dụng

để trình bày ý nghĩa dữ liệu được vận chuyển, và hơn thế nữa, hiện tại đa số cácứng dụng chạy trên nền Web-Base đều hỗ trợ các bộ phân tích cú pháp XML.SOAP là công nghệ chủ yếu được sử dụng tại tầng này, nó là một giao thức đónggói dữ liệu phổ biến dựa trên nền tảng XML Chúng ta sẽ đề cập sâu hơn đến giaothức đóng gói dữ liệu SOAP trong phần “Các công nghệ của Web Service ” trongchương 2 của khóa luận này

Tầng Transport : Tầng Transport có vai trò đảm nhiệm việc vận chuyển các Web

Service Message, tại đây bao gồm một vài dạng công nghệ khác nhau cho phép cácgiao tiếp trực tiếp giữa các Application – to – Application dựa trên tầng Network.Mỗi công nghệ bao gồm các giao thức như tcp, http, smtp và jabber v.v

Việc lựa chọn giao thức vận chuyển được dựa trên mỗi nhu cầu giao tiếp của cácWeb Service ví dụ: với giao thức HTTP là một giao thức vận chuyển khá phổ biếnđược sử dụng cho các ứng dụng Web-Base, nhưng nó không cung cấp cơ chế giaotiếp bất đối xứng Jabber, xét trên phương diện khác, nó không phải là một chuẩnnhưng có khả năng cung cấp tốt các kênh giao tiếp bất đối xứng

Trang 22

Tầng Network : Tầng Network trong công nghệ Web Service chính xác giống

tầng Network trong mô hình giao thức TCP/IP Nó cung cấp khả năng giao tiếp cơbản, định địa chỉ và định tuyến

2.2.3.Các công nghệ của Web Service

2.2.3.1.Ngôn ngữ XML – RPC

XML : được viết tắt của cụm từ Extensible Markup Language – Ngôn ngữ đánh

dấu dữ liệu[1][3]

RPC – được viết tắt của cụm từ Remote Procedure Call – Thủ tục gọi từ xa RPC

cung cấp cho người phát triển kĩ thuật để định nghĩa ra một giao diện mà có thểđược gọi từ xa thông qua môi trường mạng máy tính Giao diện này có thể là mộthàm đơn giản nhưng cũng có thể là một thư viện API khổng lồ[1][3]

XML – RPC là một hướng tiếp cận dễ và rõ ràng nhất cho Web Service, nó cung cấpphương thức gọi một ứng dụng từ một máy tính local đến một máy tính từ xa thông quamôi trường mạng

 XML – RPC cho phép chương trình có khả năng tạo ra các hàm hoặc các thủ tụcgọi hàm thông qua mạng máy tính

 XML – RPC sử dụng giao thức HTTP để vận chuyển thông tin từ Client đếnServer

 XML – RPC sử dụng ngôn ngữ XML để mô tả các thông điệp yêu cầu và cácthông điệp đáp ứng gần gũi với ngôn ngữ tự nhiên

 XML – RPC Client chỉ ra cụ thể các thông tin về tên thủ tục, các tham biến trongthông điệp XML request, và Server trả về lỗi hoặc trả về thông điệp response trongthông điệp XML response

 Các tham số của XML-RPC đơn giản chỉ là kiểu dữ liệu và nội dung – tuy nhiêncác cấu trúc dữ liệu phức tạp như struct, array cũng được hỗ trợ bởi XML –RPC

Trang 23

2.2.3.2.Giao thức truyền thông điệp SOAP

SOAP viết tắt cho cụm từ - Simple Object Access Protocol Trong kiến trúc phântầng của Web Service, SOAP nằm ở tầng Packaging, SOAP là một giao thức đóng góicho các dữ liệu chia sẽ giữa các ứng dụng Xét về cơ bản, SOAP là XML, chính vì thếSOAP là một ứng dụng cụ thể của XML SOAP được xây dựng lên từ các chuẩn XMLnhư XML Schema và XML Namespaces dùng cho việc định nghĩa SOAP và các chứcnăng của nó[14]

Các thành phần chuẩn của SOAP

a) Thông điệp XML

Thông điệp XML đó là các tài liệu XML được dùng để trao đổi thông tin giữa cácứng dụng Nó cung cấp tính mềm dẻo cho các ứng dụng trong quá trình giao tiếp với nhau

và là một dạng cơ bản của SOAP

Các thông điệp này có thể là bất cứ thứ gì: Hóa đơn thanh toán, yêu cầu về giá cổphiếu, một truy vấn tới một công cụ tìm kiếm hoặc có thể là bất kì thông tin nào có quan

hệ tới từng thành phần của ứng dụng

Hình 6: Mô tả cấu trúc của một thông điệp XML

Bởi vì XML không phụ thuộc vào một ứng dụng cụ thể, hệ điều hành hay ngôn ngữlập trình nào, cho nên các thông điệp XML có thể sử dụng trong tất cả các môi trường.Một chương trình Windows Perl có thể tạo ra một thông điệp XML, trình bày thông điệp

đó và gửi đến cho một chương trình cài đặt bằng ngôn ngữ Java được triển khai trên nềnUnix

Trang 24

Nếu bạn sử dụng SOAP cho EDI, khi đó thông điệp XML có thể là các hóa đơnthanh toán, trả tiền thuế, hoặc các tài liệu tương tự Nếu bản sử dụng SOAP cho RPC khi

đó thông điệp XML có thể trình bày các đối số hoặc các giá trị trả về

c) Thông điệp SOAP

Thông điệp SOAP bao gồm phần tử gốc envelope bao trùm toàn bộ nôi dung thôngđiệp SOAP, và các phần tử header và body Phần tử header chứa các khối thông tin cóliên quan đến cách thức các thông điệp được xử lý như thế nào Nó bao gồm việc địnhtuyến và các thiết lập cho việc phân phối các thông điệp Ngoài ra phần tử Header còn cóthể chứa các thông tin về việc thẩm định quyền, xác minh và các ngữ cảnh cho cáctransaction Các dữ liệu thực sự được lưu trữ tại phần tử body Bất cứ thứ gì có thể trìnhbày cú pháp XML đều nằm trong phần tử body của một thông điệp SOAP[3]

Hình 7: Mô tả cấu trúc của một thông điệp SOAP

Trang 25

Tất cả các phần tử envelope đều chứa chính xác một phần tử body Thần tử body cóthể chứa các nốt con theo yêu cầu Nội dung của phần tử body là các thông điệp Nếuphần tử envelope mà chứa phần tử header, nó chỉ chứa không nhiều hơn một phần tửheader và phần tử header này bắt buộc phải là phần tử con đầu tiên của phần tử envelope.Mỗi một phần tử chứa header đều được gọi là header block Mục đích của header blockcung cấp giao tiếp các thông tin theo ngữ cảnh có liên quan đến quy trình xử lý các thôngđiệp SOAP

d) SOAP Faults

SOAP faults là một dạng thông điệp SOAP đặc biệt được dùng để thông báo lỗitrong quá trình trao đổi thông tin, SOAP faults có thể xuất hiện trong quá trình xử lý cácthông điệp SOAP[1]

Hình 8: Mô tả thông điệp SOAP faults

Các thông tin về SOAP faults được diễn tả dưới đây:

- Fault code : Các thuật toán phát hiện lỗi sẽ tự sinh ra các giá trị

dùng để phân biệt các kiểu lỗi xuất hiện Các giá trị này phải là làcác XML Qualified Name, điều đó có nghĩa là các tên của các mãlỗi chỉ có ý nghĩa duy nhất trong vùng định nghĩa XMLNamespace

- Fault string : Diễn tả các lỗi mà người dùng có thể đọc hiểu được.

Trang 26

- Fault actor : Đây là dấu hiệu nhận dạng duy nhất của các nốt xử lý

các thông điệp nơi mà các lỗi có khả năng xuất hiện

- Fault details: Được sử dụng để trình bày các thông tin cụ thể của

ứng dụng về lỗi mà nó xuất hiện Nó phải được trình bày nếu cólỗi xuất hiện trực tiếp có liên quan đến các vấn đề về phần thâncủa thông điệp Fault details có thể không cần sử dụng, tuy nhiên

sẽ cần thiết khi ta cần trình bày cụ thể về thông tin lỗi xuất hiệntrong mối quan hệ tới các phần còn lại của quy trình xử lý cácthông điệp SOAP

e) Vận chuyển SOAP

Như chúng tôi đã trình bày ở trên, SOAP được đặt ở tầng Packagingtrong kiến trúc phân tầng của Web Service, SOAP đứng phía trên tầngNetwork và tầng Transport Vì thế SOAP không quan tâm đến việc giaothức vận chuyển nào được sử dụng trong quá trình trao đổi các thôngđiệp, điều đó làm cho giao thức thực sự mềm dẻo tại bất kì môi trườngSOAP được triển khai nào Tính mềm dẻo của SOAP được thể hiện quaviệc SOAP có thể sử dụng các giao thức vận chuyển khác nhau để traođổi các thông điệp, như HTTP, FTP, SMTP, POP3, MQUERY và Jabber Hiện nay, HTTP được sử dụng phổ biến trên Internet, chính vì tínhphổ biến của nó, cho nên HTTP hiện tại đang là giao thức vận chuyểnphổ biến nhất cho việc vận chuyển các thông điệp SOAP

SOAP thông qua HTTP rất thuận tiện cho SOAP RPC trong việc gọiyêu cầu và nhận các thông điệp đáp ứng bởi vì bản chất HTTP chính làgiao thức dựa trên nền tảng gọi các yêu cầu và nhận các đáp ứng(request-response-base protocol) Các SOAP request được gửi tới HTTPserver thông qua phương thức POST và HTTP Server trả lại giá trị SOAPresponse thông qua các HTTP response

Trang 27

Hình 9: Mô tả việc trao đổi thông điệp SOAP thông qua giao thức HTTP

2.2.3.3.Ngôn ngữ mô tả Web Service - WSDL

Tổng quan về WSDL

 WSDL viết tắt của cụm từ Web Service Description Language –Ngôn ngữ mô tả Web Service WSDL ra đời dưới sự phát triển củaIBM và Microsoft[15]

 WSDL dựa trên giao thức XML để trao đổi thông tin trong môitrường tập trung hoặc phân tán

 WSDL mô tả cách thức truy cập tới Web Service và các hành độngthực thi trên Web Service đó

 WSDL là ngôn ngữ cho việc mô tả các giao diện Web Service dựatrên nền tảng XML

Trang 28

Giải thích ý nghĩa các thành phần[15]

Type : Thành phần type định nghĩa kiểu dữ liệu được sử dụng cho

Web Service Để đảm bảo tính không phụ thuộc vào platform,WSDL sử dụng cấu trúc của lược đồ XML để định nghĩa kiểu dữliệu

Message : Thành phần message dùng để định nghĩa các thành

phần dữ liệu và các thông điệp mà nó được gọi tới Mỗi thông điệp

có thể bao gồm một hoặc nhiều phần, các thành phần này có thể

so sánh với các câu lệnh của các lời gọi hàm trong các ngôn ngữlập trình truyền thống

Port Type : Đây là thành phần quan trọng nhất trong một tài liệu

WSDL Nó được sử dụng để mô tả Web Service, các thao tác đượcthực thi và các lời gọi thông điệp Thành phần port type có thểđược so sánh với các thư viện hàm (hoặc các module, các lớp )trong các ngôn ngữ lập trình

Trong thành phần <port Type>, ta thường gặp 4 kiểu thao tác được WSDL định nghĩadưới đây:

Kiểu thao tác Mô tả

One-way Thao tác này thể hiện rằng nó chỉ nhận các

lời gọi thông điệp nhưng không trả lại thôngđiệp đáp ứng

Request-response

Thao tác này bao gồm việc nhận các thôngđiệp yêu cầu và trả về các thông điệp đápứng

Trang 29

Solicit-response Thao tác này sẽ gửi đi các yêu cầu và đợi

các đáp ứngNotification Thao tác này sẽ gửi đi các yêu cầu nhưng

không đợi để nhận các đáp ứng

Binding: Thành phần này định nghĩa các định dạng thông điệp,

các mô tả cụ thể về các giao thức cho mỗi port

Hình 10: Mô tả thành phần binding trong tài liệu WSDL

Một thành phần binding thông thường bao gồm 2 thuộc tính: name

và type

Thuộc tính “name” định nghĩa tên của “binding”, và thuộc tính

“type” trỏ đến “port” của binding, trong ví dụ này port của binding là

“glossaryTerms”

Thành phần soap:binding có 2 thuộc tính là “style” và “transport”

Trang 30

thức vận chuyển thông điệp SOAP Trong ví dụ trên sử dụng giao thứcHTTP.

Hình 11: Minh họa ví dụ của một tài liệu WSDL

Trong ví dụ trên, thành phần <portType> định nghĩa

“glossaryTerm” như là tên của một Port, và “getTerm” như tên của mộtthao tác

Thao tác “getTerm” có thông điệp nhập vào gọi là

“getTermRequest” và có thông điệp xuất ra gọi là “getTermResponse”.Thành phần <message> định nghĩa các phần của mỗi thông điệp

và kiểu dữ liệu kết hợp với các thông điệp đó Nếu so sánh với các ngônngữ lập trình truyền thống, glossaryTerm có thể được coi như là mộtthư viện hàm, “getTerm” là một hàm với đối số truyền vào là

“getTermRequest” và trả lại lại kết quả là getTermResponse

2.2.3.4.Đăng ký dịch vụ UDDI

Tổng quan về UDDI

UDDI là một chuẩn dựa trên XML dùng cho việc mô tả, công bố vàtìm kiếm Web Service

Trang 31

 UDDI được viết tắt của Universal Description, Discovery andIntegration.

 UDDI là thư mục dùng cho việc lưu trữ các thông tin về WebService

 UDDI là thư mục của một giao diện Web Service được mô tả bởiWSDL

 UDDI giao tiếp thông qua SOAP

 UDDI cùng với SOAP và WSDL được xem là 3 chuẩn của WebService

 UDDI là một kỹ thuật mở đầu tiên cho phép các quy trình thươngmại điện tử có thể khám phá lẫn nhau và định nghĩa cách thứctương tác với nhau qua Internet

Mô hình dữ liệu của UDDI

UDDI bao gồm lược đồ XML, mô tả bốn kiểu cấu trúc dữ liệu dưới đây:

Trang 32

 BusinessService

 BindingTemplate

 tModel

 publisherAssertion

a) Cấu trúc dữ liệu businessEntity

Cấu trúc dữ liệu businessEntity trình bày nhà cung cấp WebService Cấu trúc này chứa các thông tin về công ty, bao gồm danhsách liên lạc, thông tin, phân biệt các tổ chức thương mại, và danh sáchcác nhà cung cấp dịch vụ web

b) Cấu trúc dữ liệu businessService

Cấu trúc dữ liệu business service trình bày một Web Service độclập được cung cấp bởi business entity Nó mô tả các thông tin về cáchthức gắn kết với Web Service, định nghĩa kiểu Web Service và phân loạidanh mục được liệt kê trong đó

Hình 12: Minh họa cấu trúc dữ liệu businessService

Chú ý rằng sử dụng dấu hiệu nhận dạng duy nhất – UniversallyUnique Identifiers trong thuộc tính BusinessKey và serviceKey Tất cảcác business entity và business service đều là dấu hiệu nhận dạng duynhất trong UDDI registries thông qua việc chỉ định UUID bởi việc đăng

ký khi thông tin được nhập vào lần đầu

c) Cấu trúc dữ liệu bindingTemplate

Trang 33

BindingTemplate là kĩ thuật mô tả của Web Service được trình bàybởi cấu trúc dữ liệu Business Service Binding template trình bày sựhoạt động thực tế của Web Service, mô tả công nghệ sử dụng để giaotiếp với Web Service Một Business Service có thể có thể có nhiềubinding template, cho nên dịch vụ phải chỉ rõ các hành động cụ thểkhác nhau trong cùng một dịch vụ.

d) Cấu trúc dữ liệu tModel

tModel là lõi trong cùng của kiểu dữ liệu, nhưng rất khó có khảnăng để có thể nắm bắt được hết tModel là chuẩn cho mô hình kĩ thuậttModel là phương pháp để mô tả một vài quy trình thương mại,dịch vụ và các cấu trúc mẫu lưu trữ trong UDDI registry Bất kì một kháiniệm trừu tượng nào đều có thể được đăng ký trong UDDI như là mộttModel Ví dụ: chúng ta có thể định nghĩa ra một kiểu cổng (port type)WSDL mới, và đồng nghĩa với đó ta có thể định nghĩa ra một tModelmới mà trình bày kiểu cổng đó trong UDDI Sau đó, ta có thể chỉ định radịch vụ thương mại mà thực thi kiểu cổng đó bằng việc kết hợp vớitModel với một business service’s binding template

e) Cấu trúc dữ liệu publisherAssertion

Đây là một cấu trúc dữ liệu quan hệ mà nó đặt sự kết hợp giữa hai hoặcnhiều cấu trúc dữ liệu businessEntity theo một kiểu quan hệ cụ thể,chẳng hạn như một công ty con hoặc một phòng ban

Cấu trúc dữ liệu pubisherAssertion bao gồm ba thành phần chính:fromkey (BusinessKey đầu tiên), toKey (bussinesskey thứ hai) vàkeyedReference

Trang 34

CHƯƠNG 3: QoS CHO WEB SERVICE

Trong chương 2 chúng tôi đã trình bày các khái niệm cơ bản về công nghệ Web Service Với sự phát triển mạnh mẽ của Internet và công nghệ Web Service, chất lượng các dịch vụ Web trở thành một vấn

đề hết sức cần thiết Trong chương 3 này, chúng tôi sẽ đề cập đến hướng tiếp cận khá mới và sẽ trở thành một xu hướng tất yếu cho các dịch vụ web trong tương lai gần, đó là Chất lượng dịch vụ Web.

3.1.

Chất lượng dịch vụ Web Service – QoS cho Web Service

Với sự phát triển nhanh phóng và phổ biến của công nghệ WebService, Chất lượng các dịch vụ Web Service (QoS – Quality of Service)

sẽ trở thành một yếu tố quan trọng trong việc đánh giá sự thành côngcủa các nhà cung cấp dịch vụ web QoS sẽ quyết định đến khả năng sửdụng và tính hữu ích của dịch vụ, cả hai yếu tố này đều ảnh hưởng đếntính phổ biến của một dịch vụ web Trong phần này, chúng tôi sẽ trìnhbày một vài yêu cầu khác nhau của QoS cho Web Serivce, ảnh hưởngcủa hiệu ứng thắt cổ chai đến hiệu năng hoạt động của một WebService, tiếp cận tới các phương pháp cung cấp chất lượng dịch vụ choWeb Service và một phương pháp đơn giản để đo lường thời gian đápứng của Web Services sử dụng Service Proxy[6]

Trong thời đại hiện nay, với sự phát triển mạnh mẽ của thương mạiđiện tử, một yêu cầu đặt ra là phải làm sao có thể tích hợp liền mạchcác quy trình thương mại, các ứng dụng thương mại điện tử và các WebService thông qua môi trường Internet Việc đánh giá chất lượng mộtdịch vụ web là một thách thức lớn, vì môi trường Internet cùng các ứngdụng Web–Base ngày càng phát triển mạnh mẽ, cũng chính vì thế nêncác yêu cầu về chất lượng dịch vụ cũng luôn thay đổi và không thể dự

Trang 35

đoán theo cách tự nhiên được Các ứng dụng với các đặc điểm và yêucầu riêng biệt sẽ cạnh tranh nhau về tài nguyên mạng vốn đã rất hạnchế Sự thay đổi lưu lượng thông tin trên mạng, tấn công từ chối dịch

vụ, ảnh hưởng của cơ sở hạ tầng công nghệ thông tin yếu kém và vấn

đề an ninh cho các ứng dụng Web-Base đã tạo ra sự cần thiết của việcđưa ra các chuẩn chất lượng cho các dịch vụ trên Internet Thôngthường, khi không đáp ứng được các yêu cầu QoS là một nguyên nhânthen chốt dẫn tới các giao tác có hiệu suất hoạt động rất thấp

Với các chuẩn như SOAP, UDDI và WSDL đã được thống nhất sửdụng bởi các lĩnh vực sử dụng công nghệ Web Service – bao gồm cácdịch vụ tài chính, công nghệ cao, đa phương tiện và giải trí Tất cả cácWeb Service đang cần phải được gắn kết với nhau để trở thành chuẩn,QoS sẽ là một yếu tố then chốt để đánh giá sự thành công cũng như sựkhác nhau về chất lượng phục vụ của các dịch vụ Web

3.2.

Các yêu cầu về chất lượng dịch vụ cho Web Service

Các yêu cầu về chất lượng dịch vụ cho Web Service phải đáp ứng được các yêu cầu dưới đây[6]

Tính có sẵn : Tính có sẵn thể hiện một khía cạnh chất lượng của

dịch vụ, tính có sẵn trình bày dịch vụ có sẵn để dùng tại một thờiđiểm cụ thể hay không Tính có sẵn mô tả xác suất mà dịch vụsẵn sàng phục vụ Trong tính có sẵn, một giá trị thời gian đượcdùng để mô tả liệu một dịch vụ có sẵn sàng để phục vụ haykhông Giá trị lớn hơn chỉ ra rằng dịch vụ luôn sẵn sàng để sửdụng trong khi giá trị nhỏ hơn chỉ ra không thể dự đoán được liệudịch vụ có sẵn trong khoảng thời gian cụ thể hiện tại hay không

Trang 36

để kết hợp với tính có sẵn của một dịch vụ, đại lượng thời gian đóđược gọi là TTR (Time to Repair ) - Thời gian phục hồi TTR mô tảkhoảng thời gian được dùng để phục hồi một dịch vụ web nếu cólỗi xảy ra Thời gian phục hồi lý tưởng và được mong đợi là thờigian phục hồi có giá trị nhỏ.

Tính truy cập được : Tính truy cập được thể hiện khía cạnh chất

lượng dịch vụ qua mức độ, khả năng phục vụ các yêu cầu WebService Nó diễn tả khả năng ước lượng bao gồm tốc độ thànhcông hoặc sự thay đổi thành công của một dịch vụ cụ thể trongmột thời điểm Tính truy cập được còn được thể hiện thông quatính có sẵn của dịch vụ Web Một Web Service có tính truy cậpcao khi hệ thống triển khai Web Service đó có độ mềm dẻo cao

Độ mềm dẻo tham chiếu tới khả năng phục vụ các yêu cầu mộtcách nhất quán mặc dù có thể có nhiều yêu cầu khác nhau cùngtồn tại trong một tập hợp các yêu cầu

Tính toàn vẹn : Tính toàn vẹn thể hiện chất lượng dịch vụ ở cách

thức mà Web Service đảm bảo sự đúng đắn chính xác trong cáctương tác theo từng khía cạnh cụ thể của tài nguyên Sự thực thiđúng đắn của các giao tác Web Service sẽ cung cấp tính đúngđắn trong các tuơng tác Một giao tác sẽ tham chiếu tới trình tựlàm việc của các thao tác được xử lý như một đơn vị công việc độclập Tất cả các hoạt động được hoàn thành để tạo sự thành côngcho một giao tác Khi một giao tác không được thực hiện thànhcông, tất cả các thay đổi sẽ được phục hồi lại trạng thái ban đầu

Khả năng hoạt động : Khả năng hoạt động thể hiện chất lượng

dịch vụ ở khía cạnh đo lường giới hạn của thông lượng và độ trễ.Giá trị thông lượng cao hơn và độ trễ thấp thể hiện một Web

Trang 37

Service hoạt động tốt Thông lượng trình bày số lượng yêu cầuWeb Service phục vụ tại một đơn vị thời gian định kì Đỗ trễ làthời gian xoay vòng giữa việc gửi yêu cầu và nhận các đáp ứng.

Tính tin cậy : Tính tin cậy thể hiện khả năng đảm bảo dịch vụ và

chất lượng dịch vụ Tính tin cậy được tính qua số lượng lỗi trênmột tháng hay một năm Theo hướng tiếp cận khác tính tin cậytham chiếu đến việc phân phát đúng đắn và đảm bảo các thôngđiệp sẽ được gửi và nhận bởi các dịch vụ yêu cầu và các dịch vụđáp ứng

Tính linh động : Tính linh động thể hiện chất lượng dịch vụ ở khía

cạnh Web Service có thể thích ứng với các luật, các quy tắc vàkhả năng kết hợp chuẩn và thiết lập các dịch vụ mức cao hơn.Web Service sử dụng một số chuẩn như SOAP, UDDI, WSDL Sựtuân thủ ngặt nghèo các chuẩn để đảm bảo tính đúng đắn củacác phiên bản (VD SOAP V1.2) bởi các nhà cung cấp dịch vụ web

là một yếu tố cần thiết cho các yêu cầu đúng đắn của WebService bởi các Web Service request

Tính an toàn : Tính an toàn của Web Service thể hiện ở cơ chế bảo

mật, thẩm định quyền, mã hoá thông điệp và cung cấp quyềntruy cập Các nhà cung cấp dịch vụ Web có thể có các hướng tiếpcận khác nhau để đảm bảo độ an toàn cho các dịch vụ web

3.3.

QoS cho các dịch vụ Web

QoS cho các dịch vụ web yêu cầu một vài ngôn ngữ QoS để trả lời một số các câu hỏisau[2]:

Trang 38

Lập trình viên cần phải có khả năng hiểu được các đặc điểm QoS của Web Servicetrong quá trình phát triển các ứng dụng gọi dịch vụ web.

Trên lý tưởng, thì QoS cho Web Service phải có khả năng hỗ trợ nhiều kiểu ứng dụngkhác nhau với các yêu cầu QoS khác nhau, các quy tắc giao tiếp khác nhau và tài nguyênmáy tính khác nhau

3.4.

Điều chỉnh và thiết lập ràng buộc QoS

Dưới đây là các bước mà các Web Service phải thực hiện trong quá trình thiết lập ràngbuộc QoS[2][6]:

a) Service Requestor đưa ra yêu cầu thiết lập liên kết ràng buộc bằng cách thiết lậptham chiếu tới một Web Service Interface Những yêu cầu này chỉ chứa các quyđịnh về QoS

b) QoS broker tìm kiếm các service cung cấp dịch vụ trong thư mục UDDI

c) Sau đó, QoS broker thực thi việc thương lượng chất lượng dịch vụ như các mô tảdưới đây:

- Web Service QoS broker so sánh các QoS của các Service Provider với các yêucầu QoS mà nó đặt ra, và sử dụng yêu cầu đó để quyết định chấp nhận QoS màcác Service Provider đưa ra hay không Quá trình này được gọi là thương lượngQoS

- Nếu quá trình thương lượng chất lượng dịch vụ thành công, các ServiceRequestor và Service Provider sẽ được thông báo rằng quá trình thương lượng đãthành công và ràng buộc QoS giữa 2 phía đã được thiết lập Từ lúc này trở đi, cácđối tượng này có thể tương tác với nhau thông qua liên kết đó

3.5.

Hiệu ứng thắt cổ chai trong quá trình thực thi của Web Service

Web Service có thể gặp phải hiệu ứng thắt cổ chai trong quá trình thực thi, nguyênnhân do giới hạn của các giao thức vận chuyển và số lượng thông điệp quá lớn Việc tin

Trang 39

tưởng vào các giao thức được chấp nhận rộng rãi như HTTP, SOAP tuy nhiên chúng vẫntồn tại các giới hạn, chính vì thế rất quan trọng để có thể hiểu và làm việc trên các giớihạn của các giao thức đó

HTTP là giao thức theo hướng cố gắng tới mức tối đa Hai vấn đề chính thường gặpphải trong cơ chế chuyển tiếp dữ liệu của HTTP là:

 Không có cơ chế đảm bảo gói tin được phân phát tới đích

 Không có cơ chế đảm bảo thứ tự đến của các gói tin

Nếu không có băng thông có sẵn, các gói tin sẽ bị loại bỏ Băng thông sẽ bị giảm sútkhi người dùng và số lượng dữ liệu trong mạng gia tăng Một số ứng dụng chỉ định đỗ trễbằng không và băng thông bằng vô cùng Theo truyền thống, ứng dụng thường sử dụngcác thông điệp đồng bộ Thông điệp đồng bộ sẽ tốt khi ứng dụng chạy trên một máy tínhđơn, khi đó các thành phần tham gia truyền thông điệp có độ trễ đo bằng đơn vị microgiây Tuy nhiên với Web Service, chúng giao tiếp thông qua Internet, điều đó có nghĩa độtrễ có thể đo bằng 10, 100 hoặc thậm chí 1000 mili giây

Dưới đây là một số phương pháp để tăng khả năng hoạt động của Web Service

 Sử dụng hàng đợi thông điệp bất đồng bộ

Ứng dụng dựa trên các dịch vụ web có thể sử dụng hàng đợi thông điệp để tăng độtin cậy nhưng lại tốn thời gian đáp ứng Các ứng dụng và Web Service có thể sửdụng hàng đợi thông điệp như Java Messaging Service – JMS hoặc IBM MQSeriercho lời gọi thông điệp Hàng đợi thông điệp cung cấp 2 điểm thuận lợi chính sau:

- Cơ chế bất đồng bộ: các Service Provider có thể phân phát các thông điệp tới cácrequestor và không yêu cầu phía requestor gửi lại thông điệp xác nhận việc nhậnthông điệp từ Service Provider

- Độ tin cậy: đảm bảo cho các thông điệp có thể phân phát một lần và chỉ

Trang 40

Sử dụng mạng riêng Wan và mạng Web Service có thể là một giải pháp thích hợpcho các doanh nghiệp sử dụng Web Service cho các nghiệp vụ quan trọng Mạngwan riêng cung cấp độ trễ mạng thấp, ít đụng độ và đảm bảo việc phân phát cácthông điệp Tuy nhiên để có được một mạng wan riêng thì chi phí cũng rất tốnkém.

3.6.

Đánh giá hiệu năng giao thức SOAP

SOAP là một giao thức chủ yếu được dùng cho Web Service Tuy nhiên hiệu năng củagiao thức SOAP lại bị giảm thiểu đi vì các nguyên nhân sau đây:

 Việc tách bỏ thành phần Soap Envelope từ một gói tin SOAP tốn nhiều thời gian

 Phân tích các thông tin XML trong thành phần SOAP envelope sử dụng bộ phântích cú pháp XML tốn nhiều thời gian

 Khả năng tối ưu hoá dữ liệu XML không cao

 Các quy tắc mã hoá thông điệp SOAP phải được thực hiện ở cả phía gửi và phíanhận thông điệp

 Tốn thêm tài nguyên máy tính để xử lý các thông điệp XML được mã hoá dướidạng nhị phân bao gồm việc mã hoá và giải mã Bộ xử lý XML phải được nạp ra

và vận chuyển đi cùng với các dữ liệu XML Điều này sẽ tốn thêm tài nguyên đểthực thi SOAP

Để giải quyết các vấn đề gặp phải khi sử dụng giao thức SOAP, chúng ta có mộtphương pháp nén dữ liệu XML

Dữ liệu XML được vận chuyển bởi giao thức SOAP Điều gì sẽ xảy ra nếu hàng trămthông điệp SOAP được vận chuyển qua web, khi đó sẽ dẫn đến tình trạng băng thôngmạng bị tăng tới giới hạn Phương pháp trình bày dữ liệu dưới dạng XML thường đem lạihiệu quả đáng kể khi một lượng lớn dữ liệu được nén dưới dạng nhị phân , trung bình hiệusuất làm việc có thể là 400% hoặc cao hơn Tuy nhiên khi dữ liệu được trình bày dưới

Ngày đăng: 23/11/2012, 15:05

Nguồn tham khảo

Tài liệu tham khảo Loại Chi tiết
[11] Simon Bennett, John Skelton, Kelunn – UML Second Edition, May - 2006 [12] Axis User’s Guide, http://ws.apache.org/axis/java , April- 2009 Link
[14] W3C School – Soap Tutorial , http://www.w3schools.com/soap , April - 2009 Link
[15] W3C School – WSDL Tutorial , http://www.w3schools.com/WSDL , April - 2009 Link
[16] W3C School – UDDI Tutorial , http://www.w3schools.com/UDDI , April - 2009 Link
[1] Doug Tidwell, James Snell, Paval Kulchelko – Programing Web Services With Soap, December 2001 Khác
[2] Daniela Malfatti - A Meta-Model for QoS-Aware Service Composition, December 2007 Khác
[3] Prentice Hall PTR – Web Service Platform Architechture: SOAP, WSDL, WS- Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More, Marth 2005 Khác
[4] Robert Englander - Java and Soap, May – 2002 Khác
[5] Ethan Cerami – Web Service Essentials Distributed Application with RPC, SOAP, UDDI &amp;WSDL, February – 2002 Khác
[6] Anbazhagan Mani, Arun Nagarajan – Understanding quality of service for Web Service, January -2002 Khác
[7] W3C Working Group – QoS for Web Service: Requirements and Possible Approaches, November – 2003 Khác
[8] Javavietnam.org – Web Service cài đặt và sử dụng, 2007 Khác
[9] Jamers P.Lawler, H.Howell-Baber, Service Oriented Architecture SOA strategy, Methodology and Technology, January- 2008 Khác
[10] Kim Hamilton, Russell Miles – Learning UML 2.0, April- 2006 Khác
[13] Marcus Cobden, Ben Humphrays, Kathryn Macarthur – Timing Diagram Plugin Support for RODIN/UML-B, December – 2007 Khác
[17] Gerhard Wiehler – Web Service and Service Oriented Architecture, February- 2004 Khác

HÌNH ẢNH LIÊN QUAN

DANH SÁCH CÁC HÌNH VẼ - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
DANH SÁCH CÁC HÌNH VẼ (Trang 8)
Hình 1:Web Service cho phép truy cập tới các code ứng dụng sử dụng chuẩn công nghệ Internet...7 Hình 2:Web Service cung cấp một tầng trừu tượng giữa ứng dụng client và ứng dụng cần gọi tới...8 Hình 3:Mô tả cơ chế hoạt động của Web Service................. - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 1 Web Service cho phép truy cập tới các code ứng dụng sử dụng chuẩn công nghệ Internet...7 Hình 2:Web Service cung cấp một tầng trừu tượng giữa ứng dụng client và ứng dụng cần gọi tới...8 Hình 3:Mô tả cơ chế hoạt động của Web Service (Trang 8)
Hình 1:Web Service cho phép truy cập tới các code ứng dụng sử dụng chuẩn công nghệ Internet - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 1 Web Service cho phép truy cập tới các code ứng dụng sử dụng chuẩn công nghệ Internet (Trang 17)
Hình 1:Web Service cho phép truy cập tới các code ứng dụng sử dụng chuẩn công nghệ Internet - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 1 Web Service cho phép truy cập tới các code ứng dụng sử dụng chuẩn công nghệ Internet (Trang 17)
Hình 3:Mô tả cơ chế hoạt động của Web Service. - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 3 Mô tả cơ chế hoạt động của Web Service (Trang 19)
Hình 3:Mô tả cơ chế hoạt động của Web Service. - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 3 Mô tả cơ chế hoạt động của Web Service (Trang 19)
Hình 6:Mô tả cấu trúc của một thông điệp XML - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 6 Mô tả cấu trúc của một thông điệp XML (Trang 24)
Hình 7:Mô tả cấu trúc của một thông điệp SOAP - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 7 Mô tả cấu trúc của một thông điệp SOAP (Trang 25)
Hình 9:Mô tả việc trao đổi thông điệp SOAP thông qua giao thức HTTP - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 9 Mô tả việc trao đổi thông điệp SOAP thông qua giao thức HTTP (Trang 28)
Hình 10:Mô tả thành phần binding trong tài liệu WSDL - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 10 Mô tả thành phần binding trong tài liệu WSDL (Trang 31)
Hình 10:Mô tả thành phần binding trong tài liệu WSDL - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 10 Mô tả thành phần binding trong tài liệu WSDL (Trang 31)
Hình 12:Minh họa cấu trúc dữ liệu businessService - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 12 Minh họa cấu trúc dữ liệu businessService (Trang 34)
Hình 13:Biểu đồ Timing Diagram dưới dạng “Robus Diagram” - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 13 Biểu đồ Timing Diagram dưới dạng “Robus Diagram” (Trang 48)
Hình 13:Biểu đồ Timing Diagram dưới dạng “Robus Diagram” - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 13 Biểu đồ Timing Diagram dưới dạng “Robus Diagram” (Trang 48)
Hình 14:Biểu đồ Timing Diagram dưới dạng mở rộng - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 14 Biểu đồ Timing Diagram dưới dạng mở rộng (Trang 49)
Hình 14:Biểu đồ Timing Diagram dưới dạng mở rộng - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 14 Biểu đồ Timing Diagram dưới dạng mở rộng (Trang 49)
Hình 15:Minh họa các trạng thái được thể hiện trong biểu đồ Timing Diagram - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 15 Minh họa các trạng thái được thể hiện trong biểu đồ Timing Diagram (Trang 50)
Hình 16:Minh họa các sự kiện và thông điệp trong biểu đồ Timing Diagram - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 16 Minh họa các sự kiện và thông điệp trong biểu đồ Timing Diagram (Trang 51)
Hình dưới minh hoạ các sự kiện và các thông điệp được đặt vào biểu đồ Timing Diagram để thể hiện sự thay đổi của các trạng thái dưới sự tác động của các sự kiện đó. - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình d ưới minh hoạ các sự kiện và các thông điệp được đặt vào biểu đồ Timing Diagram để thể hiện sự thay đổi của các trạng thái dưới sự tác động của các sự kiện đó (Trang 51)
Hình 16:Minh họa các sự kiện và thông điệp trong biểu đồ Timing Diagram - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 16 Minh họa các sự kiện và thông điệp trong biểu đồ Timing Diagram (Trang 51)
Hình dưới minh hoạ các sự kiện và các thông điệp được đặt vào biểu đồ Timing  Diagram để thể hiện sự thay đổi của các trạng thái dưới sự tác động của các sự kiện đó. - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình d ưới minh hoạ các sự kiện và các thông điệp được đặt vào biểu đồ Timing Diagram để thể hiện sự thay đổi của các trạng thái dưới sự tác động của các sự kiện đó (Trang 51)
Hình 17:Minh họa thể hiện thời gian trong biểu đồ Timing Diagram - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 17 Minh họa thể hiện thời gian trong biểu đồ Timing Diagram (Trang 52)
Hình 19:Minh họa các đường state-line trong biểu đồ Timing Diagram - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 19 Minh họa các đường state-line trong biểu đồ Timing Diagram (Trang 53)
Hình dưới minh hoạ các đường state-line trong biểu đồ Timing Diagram - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình d ưới minh hoạ các đường state-line trong biểu đồ Timing Diagram (Trang 53)
Hình 19:Minh họa các đường state-line trong biểu đồ Timing Diagram - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 19 Minh họa các đường state-line trong biểu đồ Timing Diagram (Trang 53)
Hình dưới minh hoạ các đường state-line trong biểu đồ Timing Diagram - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình d ưới minh hoạ các đường state-line trong biểu đồ Timing Diagram (Trang 53)
Hình 21:Minh hoạ mô hình WebService với ServiceProxy - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 21 Minh hoạ mô hình WebService với ServiceProxy (Trang 55)
Hình 21:Minh hoạ mô hình Web Service với Service Proxy - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 21 Minh hoạ mô hình Web Service với Service Proxy (Trang 55)
Các thao tác chính của một ServiceProxy có thể được minh hoạ như hình dưới đây - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
c thao tác chính của một ServiceProxy có thể được minh hoạ như hình dưới đây (Trang 57)
Hình 23:  Minh hoạ các thao tác của Service Proxy - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 23 Minh hoạ các thao tác của Service Proxy (Trang 57)
Dưới đây ta có mô hình tích hợp WebService - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
i đây ta có mô hình tích hợp WebService (Trang 59)
Hình 22:Minh họa mô hình tích hợp Web Service - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 22 Minh họa mô hình tích hợp Web Service (Trang 59)
Mô hình bài toán bao gồm 3 thành phần đó là phát triển 2 Web Services là SearchFlight Service và SearchHotel Service, phần thứ 2 là phát triển Service Proxy và cuối  cùng là phát triển một chương trình ứng dụng ở phía Client để triệu gọi đến Service Proxy - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
h ình bài toán bao gồm 3 thành phần đó là phát triển 2 Web Services là SearchFlight Service và SearchHotel Service, phần thứ 2 là phát triển Service Proxy và cuối cùng là phát triển một chương trình ứng dụng ở phía Client để triệu gọi đến Service Proxy (Trang 64)
Hình 23:Minh hoạ mô hình tổng quan bài toán Travel-Agent - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 23 Minh hoạ mô hình tổng quan bài toán Travel-Agent (Trang 64)
Hình 24:Minh hoạ đường Lifeline cho SearchHotelService - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 24 Minh hoạ đường Lifeline cho SearchHotelService (Trang 65)
Hình 24:Minh hoạ đường Lifeline cho SearchHotel Service - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 24 Minh hoạ đường Lifeline cho SearchHotel Service (Trang 65)
Tương tự ta cũng có hình minh hoạ đường Lifeline cho dịch vụ tìm kiếm chuyến bay - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
ng tự ta cũng có hình minh hoạ đường Lifeline cho dịch vụ tìm kiếm chuyến bay (Trang 66)
Ta có mô hình thiết kế tổng thể của ứng dụng như sau: - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
a có mô hình thiết kế tổng thể của ứng dụng như sau: (Trang 69)
Hình 26:Minh họa thiết kế tổng thể của ứng dụng - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 26 Minh họa thiết kế tổng thể của ứng dụng (Trang 69)
Hình 28:Minh họa giao diện Admin của apache soap trên Web Server tại cổng 2417 - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 28 Minh họa giao diện Admin của apache soap trên Web Server tại cổng 2417 (Trang 72)
Hình 28:Minh họa giao diện Admin của apache soap trên Web Server tại cổng 2417 - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 28 Minh họa giao diện Admin của apache soap trên Web Server tại cổng 2417 (Trang 72)
Hình 29:Minh họa giao diện Admin của apache soap trên Web Server tại cổng 8080 - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 29 Minh họa giao diện Admin của apache soap trên Web Server tại cổng 8080 (Trang 73)
Hình 29:Minh họa giao diện Admin của apache soap trên Web Server tại cổng 8080 - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 29 Minh họa giao diện Admin của apache soap trên Web Server tại cổng 8080 (Trang 73)
Hình 33:Danh sách các dịch vụ liệt kê trên website soap engine - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 33 Danh sách các dịch vụ liệt kê trên website soap engine (Trang 76)
Hình 33:Danh sách các dịch vụ liệt kê trên web site soap engine - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 33 Danh sách các dịch vụ liệt kê trên web site soap engine (Trang 76)
Hình 34:Nội dung file deploy.wsdd - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 34 Nội dung file deploy.wsdd (Trang 77)
Hình 35:Các dịch vụ được liệt kê trên trang quản trị của Axis - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 35 Các dịch vụ được liệt kê trên trang quản trị của Axis (Trang 78)
Hình 35:Các dịch vụ được liệt kê trên trang quản trị của Axis - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 35 Các dịch vụ được liệt kê trên trang quản trị của Axis (Trang 78)
Hình dưới minh họa file WSDL của WebService SearchFlight: - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình d ưới minh họa file WSDL của WebService SearchFlight: (Trang 79)
Hình dưới minh họa file WSDL của Web Service SearchFlight: - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình d ưới minh họa file WSDL của Web Service SearchFlight: (Trang 79)
Hình 37:Code ServiceProxy goi tới SearchFlightService - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 37 Code ServiceProxy goi tới SearchFlightService (Trang 80)
Hình 37:Code Service Proxy goi tới SearchFlightService - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 37 Code Service Proxy goi tới SearchFlightService (Trang 80)
Hình 39:Minh họa test chương trình - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 39 Minh họa test chương trình (Trang 83)
Hình 39:Minh họa test chương trình - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 39 Minh họa test chương trình (Trang 83)
Hình 40:Biểu đồ Timing Diagram mô tả ràng buộc thời gian của WSComposition - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 40 Biểu đồ Timing Diagram mô tả ràng buộc thời gian của WSComposition (Trang 84)
Hình 40:Biểu đồ Timing Diagram mô tả ràng buộc thời gian của WSComposition - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 40 Biểu đồ Timing Diagram mô tả ràng buộc thời gian của WSComposition (Trang 84)
Ta có mô hình kiểm chứng được minh hoạ như sau: - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
a có mô hình kiểm chứng được minh hoạ như sau: (Trang 85)
Hình 41:Minh hoạ mô hình kiểm chứng ràng buộc thời gian đáp ứng - Xây dựng service proxy để kiểm chứng ràng buộc thời gian trong web service composition
Hình 41 Minh hoạ mô hình kiểm chứng ràng buộc thời gian đáp ứng (Trang 85)

TỪ KHÓA LIÊN QUAN

TRÍCH ĐOẠN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w