Luận văn xây dựng service proxy để kiểm chứng ràng buộc thời gian web service composition

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (34.03 MB, 85 trang )

Trang 1<div class="page_container" data-page="1">

DAI HOC QUOC GIA HA NOI TRUONG DAI HOC CONG NGHE

Ø3C% 3G

Nguyễn Đức Trung

XAY DUNG SERVICE PROXY DE KIEM CHUNG RANG BUOC

THOI GIAN TRONG WEB SERVICE COMPOSITION

KHOA LUAN TOT NGHIEP DAI HOC HE CHINH QUY Ngành : Công Nghệ Thong Tin

HÀ NỘI, 2009

</div>Trang 2<div class="page_container" data-page="2">

DAI HOC QUOC GIA HA NOI TRUONG DAI HOC CONG NGHE

Ø3C% 3G

Nguyễn Đức Trung

XAY DUNG SERVICE PROXY DE KIEM CHUNG RANG BUOC

THOI GIAN TRONG WEB SERVICE COMPOSITION

KHOA LUAN TOT NGHIEP DAI HOC HE CHINH QUY Ngành : Công Nghệ Thong Tin

Cán bộ hướng dẫn: TS. Trương Ninh Thuận

HÀ NỘI, 2009

</div>Trang 3<div class="page_container" data-page="3">

LOI CAM ON

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ác kiế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 trong suố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ông nghệ 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ững nă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

em trong suốt quá trình học tập và làm khoá luận này.

Đề tài “Xây dung Service Proxy dé kiểm chứng ràng buộc thời gian trong lWcb 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ân

thành từ thầy cô giáo và các bạn đề dé tài có thể được mở rộng và nghiên cứu kỹ hơn, đưa

vào trong thực tiễn ngành công nghệ thông tin hiện nay.

Hà Nội, ngày 15 thang 05 nam 2009 Sinh vién:

Nguyễn Đức Trung

</div>Trang 4<div class="page_container" data-page="4">

TOM TAT KHOA LUAN

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ụng triể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 đi cù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ẫu chố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 Web Scrvice được coi là một công nghệ mang đến cuộc cách mạng trong cách thức hoạt động cua cac dich vu B2B — Business to Bussiness va B2C — Bussiness to Customer. Gia tri co 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 truy

cậ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 đữ liệu thông qua mang 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ệ

Wcb 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ác

dịch vụ Web — QoS cho Web Scrvice dựa trên mô hinh tích hợp Web Service với các Web Service Composition. Tu cac 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 Scrvice Composition và mô hình hóa các ràng buộc thời gian trên biể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 Web Service Composition, chúng tôi đã tiến hành xây dựng một ứng dụng nhỏ 1a Web Service Travel-Agent và tiễn hành đo lường thời gian đáp ứng của các Service Composition hợp thành lên Web Service Travel-A gent đó.

</div>Trang 5<div class="page_container" data-page="5">

1.3. Câu e e au truc trúc khóa luậ oad d NON, NNTVVVNNNNN NNNNN NNNNN VY A AC CV VN VẢ.

CHUONG 2: CÔNG NGHỆ WEB SE. ICLE... <5 < «S2 SE SE9EE5 5 955253

1 1 2 3 5 2.1. Kién trite hwong dich vu SOA .ssccssssssssssssssssssssssssssssssssssssssssssssssssssesesssssssssseseseeee D 2.1.1. Khái niệm kiến trúc hướng dich vu SOA wssscscscsssssssssssssssesssesssssssssesssesssssseees

2.1.2. Nguyên tắc thiết kế của ,Š(Á... «se ssSs ve eveeEeeeeseesssssssesesesesesee TỐ

2.2. Công nghệ Web SẴ©FVẺCG... dc co co 6ó S S S S0 Có 0 0 606 0606060640040 0906 00096408080800080808 2.2.1. Tổng quan vé Web (Š€FFVẲC6... co << << s0 9x 3 3 Sư 3 3 9 98980808 966966 sex 2.2.2. Kiến trúc H/eb ,Š@FVỈC6...ccce c5 se s33 S9SESESeseteteseeeeeeeeeeeeeseseseseseeeeeeeesos Ủ 2.2.3. Các công nghệ của Web (S©FVỈC€...oooo so 3 9 969609 90 050566666666666666616166666 66s Ê CHƯƠNG 3: QoS CHO WEB SE: WICTE... o5 «55s S2 sSsESssssessesesessssssessssssees ⁄

3.1. Chất lượng dich vu Web Service — QoS cho Web SeFVỈC6...‹.‹.‹..c..e 24 3.2. Các yêu cầu về chất lượng dịch vụ cho Web S€FVỈC€...«scscssseseececev 25 3.3. DOS Cho CAC dich wụ WWebÙ...o o o 2ó 9 h9 9Á. KH 4c ỊM 0Á 0Á 04 0406 608904909090686 000606 22 /. 3.4. Điều chỉnh và thiết lập ràng buộc Q04Š... 5555 Sesseseseeeseseseseseseseeee 27 3.5. Hiệu ứng thắt cỗ chai trong quả trình thực thì của Web Serbice... 28 3.6. Đánh giả hiệu năng giao thức SP... 156666 6666666666666666666666664es 220) 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 DLAŒR AÌM... s55 SĂssseesetssrserssrseeseesoe 22

4.1. Giới tHiỆU ÌMÍL... co sG SG SG 2 S9 99 9 4 9 9 9Á 0Á 06 0 0000 006 060060668668969000000009066606 666 25,2 4.2. Tổng quan vé biéu dé Timing DiABFAdI... «se ss se ssseeeseeeeeeeeseseses..

4.3. Mục đích của biểu đồ Tỉming DiABTAIM... co c5 ces55ssseseseeeeseseseseseeesee Z⁄ 4.4. Cac ki hidu cha biéu dé Timing DiABF@Ii ... s55 seseseseeeeeeeesesesesesee. 4

4.5, Cac thanh phan cua biéu do Timing Diagram ceeeoeeeeằodoododeeodeằodeodeodedeodoeodoeododododoeodododoedododoeeedeodoeeeedodeoeeoeeeee 3ó

</div>Trang 6<div class="page_container" data-page="6">

4, 5.1. Cac trang thai sceeeằedđeằedeseeằseTeẴeeằedeeedodẴẲÂodẴdodedodododẴẲedeoedeododedeoedeedeodedodededeodeodeedeodeodeededededededodededededeedeododedodedeededằedededededeedodedodeodeeodeedeeedeee 36

</div>Trang 7<div class="page_container" data-page="7">

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

THUẬT NGỮ

SOA Service Composition

KHAI NIEM

Service Oriented Architecture — Kién tric hướng dịch vụ

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ụ

Web Service dugc téng hop 1én tir cac Service Composition Nha cung cap dich vu Web Service. Day chinh 1a cac nguén

cung cấp đưa ra các dịch vụ cho khách hàng sử dung

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

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 dé lay dich vu tra vé cho Service Consumer

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

Quality of Service - Chất lượng dịch vụ Thông điệp yêu cầu

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

</div>Trang 8<div class="page_container" data-page="8">

DANH SACH CAC HINH VE

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

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 8.78. PNRRRRRRRRRh. ổ

Hình 4; — Web Service technology SÍQCĂ...Ă Ăn vn 10

Hinh 6: Mô tả cấu trúc của mOt thong Giép XML vicccccccccccsssssesssvsvtssssessssscsvevsveees 14

Hinh 7: M6 ta cu tric cha một thông điệp SOAP... cv etetererersrrree 15

Hinh 8: — Mô tả thơng điệp SỐIP ƒQqHÏS... Ăn nHnH HH ưu l6

Hình 10: Mô tả thành phân binding trong tài liệu W/SDL... cà cv eveevsee 20

Hinh 12: Minh họa cấu trúc dữ liệu businessService coccccccccccccssccscscssccssssessecsesscssereseess 22 Hình 13: Biéu d6 Timing Diagram dưới dang “Robus Diagraim”... ca 35 Hinh 14: Biéu d6 Timing Diagram dui dang MG rONng.iccccccccscscscscsssssssssssststststetessvees 36 Hinh 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 18: Thời gian ước lượng trong biếu đồ Timing Diagraim... . cac: 39 Hình 19: Minh họa các đường state-line trong biểu đô Timing Diagraim... 40 Hinh 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 PFOXJ... cv và 42 Hình 22: Minh họa mơ hình tích hợp Web SGFVIC€... cv và 46 Hình 23: Minh hoạ mơ hình tổng quan bài tốn TraveÌ-Ágenf... .. cscc cv 31 Hinh 24: Minh hoa duong Lifeline cho SearchHoftel S©FVÌCG...ĂĂ c2 52 Hinh 25: Minh hoạ đường LỰclne cho SearchFlight SGFVÌC€... Ặ cà và 33

</div>Trang 9<div class="page_container" data-page="9">

Hinh 26: Hinh 27: Hinh 28: Hinh 29: Hinh 30: Hinh 31: Hinh 32: Hinh 33: Hinh 34: Hình 35: Hình 36: Hinh 37: Hinh 38: Hình 39: Hình 40: Hình 41:

Minh họa thiết kế tổng thể của ứng dụng ... cac tntnnssererrees 56

Minh họa giao diện Admin cua apache soap trén Web Server tai cong 2417.59 Minh họa giao diện Admin của apache soap trên Web Server tại cổng 8080. 60 Minh hoa trang Admin của Apache Axis trên Web Server tại cổng 8080... 60 Code kết nói database trong file SearchHotel ŠeFVÏC€... cv. 61

Danh sách các dịch vụ liệt kê trên web site SOaD €HgNnG...«+- 63 Nội dung file deDÏOV.WiSdÌỞ... .. .. 5 5n n1 S111 Y1 9111 11 vn ky và 64 Các địch vụ được liệt kê trên trang quản trị CỦA ẢXỈS...ĂằĂ cà sva 65 Nói dung file WSDL của dịch vụ SearchFlighS©TVÏCG... . cày 66 Code Service Proxy goi tới SearChFlighiS©TVÏC€... nào 67

Biểu đô Timing Diagram mô tả ràng buộc thời gian của WSComposition... 71 Minh hoạ mơ hình kiểm chứng ràng buộc thời gian đáp ứng... 72

</div>Trang 10<div class="page_container" data-page="10">

CHUONG 1: DAT VAN DE 1.1. Béi cảnh

Sự phát triển của công nghệ thông tin cho phép ứng dụng hiệu quả vào các hoạt động kính doanh, giải trị, quản lý cũng như một số lĩnh vực khoa học xã hội khác. Sự

bùng nỗ của Internet đã trở thành một điều kiện hết sức thuận lợi, đem lại hiệu suất cao

trong công việc đồng thời giảm thiểu chỉ phí cho các doanh nghiệp. Tuy nhiên các yêu câu về nghiệp vụ phức tạp trong hệ thống này dẫn đến các hệ thống phần mềm tương ứng cũng ngày càng trở nên phức tạp, cồng kènh và khó kiểm soát. Rất nhiều yêu cầu nghiệp

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ân

tá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, va cac module nay dugc phat triển độc lập, các module sử dụng các công nghệ khác nhau

như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úc

hướ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 Service

thà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ợp

Web Service, khi đó mỗi Service thành phần dugc goi la mét Service Composition. Su 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ên

qua 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ẻo

câ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

ma van dam bao cho van dé nang cap va bao tri sau nay. Web Service dem dén day du sw

</div>Trang 11<div class="page_container" data-page="11">

đáp ứng cân thiết cho các quy trình B2B — Bussiness to Bussiness va B2C — Bussiness to Customer, chính vì thế Web Service hiện tại đang là một thuật ngữ đang được nhắc đến râ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 Internet cho nên vẫn đề về chất lượng các dịch vụ Web cũng là một van dé đáng lưu tâm, chính vì

thế đã xuất hiện các tiêu chuẩn chất lượng dich vu cho Web Service — QoS cho Web

Service. 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, day la một vẫn đề rất đáng quan tâm vì Web Service là một kiến trúc phần mềm phâ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àng trong 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ủa mộ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 sốt thời gian đáp ứng của các dịch vụ Web là một

khí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ểm chứng ràng buộc thời gian đáp ứng của việc tích hợp các Web Scrvices có đáp ứng được vớ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 tốn đặt ra.

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

e 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.

e Tim hiéu Service Proxy, mdt dang Web Service dac biệt được triển khai ở phía người sử dụng dịch vụ.

</div>Trang 12<div class="page_container" data-page="12">

e Tiép cận đến vấn đề về chất lượng các dịch vụ Wcb, các yếu tố ảnh hưởng đến hiệu năng hoạt động của Web Scrvice. Đi vào tim hiểu việc đo lường thời gian đáp ung cua cac Web Service Composition su dung Service Proxy.

e Nghiên cứu về biểu đồ UML Timing Diagram, mơ hình hóa các ràng buộc thời gian đáp ứng của Web Service Composition trên biêu đồ UML Timing Diagram. e_ Đề xuất phương pháp kiểm chứng tự động thời gian đáp ứng của các Web Services

trong một ứng dụng sử dụng sự tích hợp các Web Scrvices với các ràng buộc ma 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 qt 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 Wcb Scrvice.

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 Web Service 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. Tim 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ộc thời gian của các Web Service Composition.

Chương 5 phân tích bài tố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 va céng nghé tich hgp Web Service.

</div>Trang 13<div class="page_container" data-page="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ứng xem 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.

</div>Trang 14<div class="page_container" data-page="14">

CHUONG 2: CONG NGHE 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ệ nay.

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ấp dị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 phan mềm) thực hiện quy trình nghiệp vụ nào đó, một cách cơ bản, SOA là tập hợ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ới

một ứng dụng khác mà không cần biết các chỉ tiết kĩ thuật bên trong), có giao tiếp (dùng dé 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ệ thong, 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ình

nghiệ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ất chấ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 trong tồ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 đến

Client sử dụng dịch vụ.

</div>Trang 15<div class="page_container" data-page="15">

Thực ra khái nệm SOA không hoàn toàn mới, DCOM và CORBA cũng có kiến trúc tươ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 được thoả thuận về chỉ tiết tập hà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 đẻ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ền

tả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]:

e M6-dun: dé 1a tách các vẫn đề lớn thành nhiều vẫn đề nhỏ hơn

e_ Đó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ên ngoai.

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ên trúc chung nhất.

</div>Trang 16<div class="page_container" data-page="16">

2.2. Cong nghé Web Service 2.2.1.Téng quan vé Web Service

Web Service la gi: Web Service la mét giao dién truy cap mang đến các ứng dụng chức năng, được xây dựng từ việc sử dụng các céng nghé chuan Internet [1][4]. Dugc minh hoạ trong hình dưới day.

=

Hinh 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 web lại với nhau bằng cách sử dụng các công nghệ XML, SOAP, WSDL, và UDDI trên nên tả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ào

hiệ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

đữ 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 sau

Firewall kia [1].

Khơng giống như mơ hình ClienServer truyền thống, chắng hạn như hệ thống Webserver/webpage, Web Service khéng cung cấp cho người dùng một giao diện đồ hoạ nao, Web Service don thuan chi là việc chia sẻ các đữ 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áy tính. Tuy nhiên nguời phát triển Web Service hoan toan cé thé dua Web Service vao một giao diện đồ hoạ người dùng (chẳng hạn như là một trang web hoặc một chương trình thự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.

</div>Trang 17<div class="page_container" data-page="17">

Web Service cho phép các ứng dụng khác nhau từ các nguồn khác nhau có thê giao

tiế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 Scrvice không bị phụ thuộc và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ơn ngữ 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ụng chạ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ền Linux. 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, doi khi Web Service con dugc goi la 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ạng máy tinh bằng việc sử dụng các giao thức như HTTP, XML, SMTP hoặc Jabber thi do chinh la Web Service.

Nhu Hinh 1 va Hinh 2 da minh hoa , Web Service la mét Application Interface dugc đặt giữa Application Code và người sử dụng các code đó. Nó có thể được ví như một tầ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ơn ngữ lập trình nào hỗ trợ Web Secrvice đều có thể truy cập các ứng dụng chức năng của

nhau.

Ape iiatlen cite Ayel ication dient

Potture rx ae Phut0s:9 ad lạwwax

wo 1" nx1421 ra rear 1i ˆ

Hinh 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 Website HTML, chính vì thế, các Application Service can 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ức chuẩn HTTP và định dạng dữ liệu HTML. Các ứng dụng Client ( như Web Browser) cần phải hiểu các chuẩn mà Web Service hỗ trợ để có thể tương tác VỚI các scrVice nhằm thực

</div>Trang 18<div class="page_container" data-page="18">

Wcb Service cung cấp tính trừu tượng cho các giao diện chuẩn, cho nên sẽ không nả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 khi

các trình duyệt lại được triển khai trên Windows. Web Service cho phép giao tiếp giữa các platform khác nhau có thể hoạt động cùng nhau theo nguyên tắc tạo ra một platform trung 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 thi cac Application và Client sử dụng 2 cơng nghệ trên hồn tồ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 Service trong các sản phẩm của ho. IBM hỗ trợ Web Service thông qua gói WebSphcre, Tivoli, Lotus va DB2 va Microsoft với .NET cũng đã hỗ tro Web Service.

2.2.2. Kiến trúc Web Service

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

Service registry

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 cau phai cé 3 thao tac dé 1a : Find, Public,

Bind[1].

</div>Trang 19<div class="page_container" data-page="19">

Trong kiên trúc Web Service, Service Provider công bô các mô ta vé cac service thong qua Service Registry. Service Consumer tim kiém trong cac Service Registry dé tim 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 trinh.

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 Web Service. Các thông tin mô tả đầy đủ nhất về kiến trúc Web Service được thể hiện trong

hai tài liệu riêng biệt, đó là NASSL — Network Accessible Service Specification Language va WDS — Web-Defined Service. NASSL là một tài liệu dưới dạng chuan của XML cho cac service chay trén nền Network, nó được sử dụng để chỉ ra các thông tin hoat d6ng cua Web Service, chang 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, nhu tén, địa chỉ. Tài liệu WDS là một tài liệu mang tính đáp ứng day đủ cho tài liệu NASSL. Khi ta kế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 phan tang cia Web Service

Vimy

Desc mien Pack aging Waed pert

NMetuorh

Hình 4: Web Service technology stack

</div>Trang 20<div class="page_container" data-page="20">

M6 hinh kién trac phan tang cua Web Service tuong ty véi m6 hinh TCP/IP được sử dụng để mô tả kiến trúc Internet.

Ay phason

lacs port Network

Link

Hinh 5: TCP/IP network model

Các tầng truyền thống như Packaging, Description, va Discovery trong mé hinh Web Service Stack là những tầng cung cấp kha năng tích hợp và cần thiết cho mơ hình ngơn ngữ lập trình trung lập.

e 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.

e Tang Desciption : Khi Web Service dugc 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ế

nao ma cac Service Consumer có thế liên kết và sử dụng các service đó. Tai tang Description, cơng nghệ được sử dụng ở đây chính là WSDL (Web Service Desciption Language) - Ngôn ngữ mơ tả Web Service. Ngồ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ữ mot ta tai nguyén - W3C’s Resource Desciption Framework (RDE) 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 Scrvice mạnh hơn ngôn ngữ WSDL tuy nhiên do tính phức tạp của chúng nê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ột cách cụ thể hơn trong phần “Các công nghệ của Web Service ” tại chương 2 của khóa luận này.

</div>Trang 21<div class="page_container" data-page="21">

e Tang Packaging: Viéc thuc hién van chuyén cac dt ligu 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 đữ liệu được thi bởi tầng

Packaging. 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 đữ 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ác tài liệu HTML thường không thuận tiện cho yêu cau nay boi vi HTML chi 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 dé trình bay ý 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 đóng gó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 giao thức đóng gói dữ liệu SOAP trong phần “Các công nghệ của Web Service ” trong chương 2 của khóa luận này.

e Tang Transport : Tang Transport có vai trị đảm nhiệm việc vận chuyển các Web Service Message, tai đây bao gồm một vài dạng công nghệ khác nhau cho phép các giao 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ác

Web Service. vi du: 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ế giao

tiế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ẩn

nhưng có khả năng cung cấp tốt các kênh giao tiếp bất đối xứng.

</div>Trang 22<div class="page_container" data-page="22">

e Tang Network : Tang Network trong céng nghé Web Service chinh xac giéng tang Network trong m6 hinh giao thức TCP/IP. Nó cung cấp khả năng giao tiếp cơ

RPC — được viết tắt của cum ttt Remote Procedure Call — Thu tuc 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ột

hà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ấp phươ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 qua mô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ục gọ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 đến Server.

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

XML — RPC Client chi ra cụ thể các thong tin về tên thủ tục, các tham biến trong thông điệp XML request, và Server trả về lỗi hoặc trả về thông điệp response trong thong dié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ên

các cầu trúc dữ liệu phức tạp như struct, array cũng được hỗ trợ bởi XML _RPC.

</div>Trang 23<div class="page_container" data-page="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ân

tầng của Web Service, SOAP năm ở tầng Packaging, SOAP là một giao thức đóng gói

cho các đữ 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 dung cy thé cua XML. SOAP được xây dựng lên từ các chuan XML

nhu XML Schema va XML Namespaces dung cho việc định nghĩa SOAP và các chức năng của no[ 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.

Hinh 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ền

Unix.

</div>Trang 24<div class="page_container" data-page="24">

b) RPC va EDI

Sử dụng thông điệp XML, đương nhiên SOAP có 2 ứng dụng liên quan: RPC và EDI. Thủ tục gọi hàm từ xa RPC - Remote Proccdure Call là một dạng tính tốn phân tán cơ bản, mô tả cách thức để một chương trình tạo ra một thủ tục gọi hàm hoặc phương

thức tới một máy tính khác, truyền đối số và lẫy giá trị trả về. Trao đôi tài liệu điện tử

EDI Electronic Document Interchange la mot dang transaction co ban cho quy trình thương mại, nó định nghĩa các chuẩn định dạng và thông dịch của các tài liệu, thông điệp tài chính và thương mại.

Nếu bạn sử dụng SOAP cho EDI, khi đó thơng điệp XML có thể là các hóa đơn thanh tố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 tồ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 định tuyến và các thiết lập cho việc phân phối các thơng điệp. Ngồ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ác

transaction. Các đữ liệu thực sự được lưu trữ tại phần tử body. Bất cứ thứ gì có thê trình bày cú pháp XML đều nằm trong phần tử body của một thông điệp SOAP[3].

</div>Trang 25<div class="page_container" data-page="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ếu phầ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 phan tử chứa header đều được gọi là header block. Mục đích của header block cung 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 dé thông báo lỗi trong quá trình trao đồi thơng tin, SOAP faults có thể xuất hiện trong quá trình xử lý các thơng điệp SOAP[I].

Hinh 8: M6 ta théng diép SOAP faults

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

- _ FauÏf code: Các thuật toán phát hiện lỗi sẽ tự sinh ra các giá trị dùng dé phan biét

các kiểu lỗi xuất hiện. Các giá tri nay phai 1a 14 cac XML Qualified Name, diéu dé

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 XML Namespace.

- Fault string: Dién ta cdc 16i ma ngudi ding cé thé doc hiéu dugc.

- Fault actor: Day la déu hiéu nhan dang 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.

</div>Trang 26<div class="page_container" data-page="26">

- Fault details: Duge str dung dé trinh bay c4c thong tin cu thé cua img dung 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 van đề về phần thân củ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ện

trong mỗi quan hệ tới các phần cịn lại của quy trình xử lý các thô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 Packaging trong kiến trúc phân tầng của Web Service, SOAP dimg phia trén tang Network va tang Transport. Vi thé SOAP không quan tâm đến việc giao thức vận chuyển nào được sử dụng trong q 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ường SOAP được triển khai nào. Tính mềm dẻo của SOAP được thể hiện qua việc SOAP có thể

sử dụng các giao thức vận chuyên khác nhau để trao đối các thong diép, nhu HTTP, FTP, SMTP, POP3, MQUERY va Jabber.

Hiện nay, HTTP được sử dụng phô biến trên Internet, chính vì tính phơ biến của nó, cho nên HTTP hiện tại đang là giao thức vận chuyển phô 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ọi yê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 (requesf-response-base protocol). Các SOAP request được gửi tới HTTTP server thông qua phương thức POST và HTTP Server tra lai gia tri SOAP response théng qua cac HTTP response.

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

</div>Trang 27<div class="page_container" data-page="27">

2.2.3.3.Ng6n ngit m6 ta Web Service - WSDL

Cac thanh phan cia WSDL

Một tài liệu WSDL thường bao gồm các thành phân chính sau đây:

<binding> Các giao thức giao tiép ding cho Web Service

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

e Type : Thanh phan type dinh nghia kiểu đữ 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

dé XML để định nghĩa kiểu đỡ liệu.

18

</div>Trang 28<div class="page_container" data-page="28">

e Message : Thanh phan message dung dé dinh nghia cdc thanh phan dit liéu va cdc 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.

e 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 được thự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ĩa dưới đây:

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

Notification Thao tác này sẽ gửi đi các yêu câu nhưng không đợi để

e Binding: Thanh phan nay đị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.

</div>Trang 29<div class="page_container" data-page="29">

< 449943 sa02 g SYDe= _" 9á098axV/(sx8a3 = kí 5 sme= _” 0. 2 > femartet ens en .~ ee ~-~"~wanre*

—_—= S.——...-_. = << aw eo tek Swe

A OA er oe ....e . “ˆ.hA=k 6 wr) eAae 6rd .... Assn” pe Aides be & = .... il, ri. he spe = J\a5 put =< ¢ «> ~*~ eG we

fecaprcperation scapaction hctp://example.com/getiexm

+ “eras aes

</biznding>

Hình 10: Mô tả thành phần binding trong tai ligé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” cua binding, trong vi dy nay port cua binding là “ølossary Terms”.

Thành phan soap:binding cé 2 thudc tinh 1a “style” va “transport”.

Thuộc tính style có thê là “rpc” hoặc “documenf”. Trong ví dụ trên chúng ta sử dụng “document”. Thuộc tính transport định nghĩa giao thức vận chuyên thông điệp SOAP. Trong ví dụ trên sử dụng giao thức HTTP.

Hình I1: Minh họa ví đụ của một tai 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ột thao tác.

Thao tác “getTerm” có thơng điệp nhập vào gọi là “getTermRcquesf” và có thơng điệp xuất ra gọi la “getTermResponse”.

</div>Trang 30<div class="page_container" data-page="30">

Thanh phần <message> định nghĩa các phần của mỗi thông điệp và kiểu đữ liệu kết

hợp với các thông điệp đó. Nếu so sánh với các ngơn ngữ lập trình truyền thống, glossaryTerm có thể được coi như là một thư 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à getTermResponsc. 2.2.3.4.Dang ky dich vu UDDI

T ong 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.

e UDDI dugc viét tat cia Universal Description, Discovery and Integration. e UDDI là thư mục dùng cho việc lưu trữ các thông tin về Web Service. ® UDDI là thư mục của một giao diện Web Service được mơ tả bởi WSDL. e© UDDI giao tiếp thông qua SOAP.

e UDDI cùng với SOAP và WSDL được xem là 3 chuẩn của Web Service.

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

UDDI xây dựng dựa trên các giao thức chuẩn Internet được công bố bởi W3C và

IETF nhu XML, HTTP, va DNS. UDDI sit dung WSDL dé mé tả giao diện của Web

Service. Thêm nữa tính năng độc lập với nền tảng ngôn ngữ lập trình đã được điều hợp cùng với giao thirc SOAP.

</div>Trang 31<div class="page_container" data-page="31">

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: e BusinessEntity

e BusinessService e BindingTemplate e tModel

e 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 Web Service. Câu trúc này chứa các thơng tín về cơng ty, bao gôm danh sách liên lạc, thông tin, phân biệt các tô chức thương mại, và danh sách các nhà cung câp dịch vụ wcb.

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

Câu trúc dữ liệu business service trinh bay mét Web Service déc lap dugc cung cap boi business entity. No mo ta cac thông tin về cách thức gan két voi Web Service, dinh nghĩa kiêu Web Service va phan loai danh muc dugc liệt kê trong đó.

<nene>Hello Worle Web Service</name>

<description>s friendly Web séervice</descriprion

< /businessservice

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

Chú ý rang sử dụng dấu hiệu nhận dạng duy nhat — Universally Unique Identifiers trong thuộc tính BusinessKey và serviceKey. Tất cả các business entity va business service đều là dâu hiệu nhận dạng duy nhấ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.

</div>Trang 32<div class="page_container" data-page="32">

c) Cau truc dir liéu bindingTemplate

BindingTemplate là kĩ thuật mô tả của Web Service được trình bày bởi câu trúc đữ

liệu Business Service. Binding template trình bày sự hoạt động thực té cua Web Service, mô tả công nghệ sử dụng để giao tiếp với Web Service. Mét Business Service cd thé cd

thể có nhiều binding 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ật

tModel 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. Bat ki một khái niệm trừu tượng nào đều có thể được đăng ký trong UDDI như là một tModel. 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 tModel mới mà trình bày kiểu cổng đó trong UDDI. Sau đó, ta có thể chỉ định ra dịch vụ

thương mại mà thực thi kiểu cơng đó bằng việc kết hợp với tModel với một business service’s binding template.

e) Câu trúc dữ liệu publisherAsserfion

Đây là một cẫu trúc đữ liệu quan hệ mà nó đặt sự kết hợp giữa hai hoặc nhiều cẫu trúc đữ

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 pubisherAsscrtion bao gồm ba thành phân chính: fromkey (BusinessKey đầu tiên), toKey (bussinesskey thứ hai) và keyedReferencc.

KeyReference thiết kế ra kiểu mỗi quan hệ kết hợp trong cặp thuật ngữ keyName, keyValue trong tModel. Tham chiếu duy nhất bởi tModelkey.

</div>Trang 33<div class="page_container" data-page="33">

CHUONG 3: QoS CHO WEB SERVICE

Trong chương 2 chúng tơi đã trình bày các khải niệm co ban 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 dich vu 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ệ Web Service, Chat luong 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ông củ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 đến tính phố biến của một dịch vụ web. Trong phần này, chúng tơi sẽ trình bày một vài yêu

cầu khác nhau của QoS cho Web Serivce, anh hưởng của hiệu ứng thắt cô chai đến hiệu năng hoạt động của một Web Service, tiếp cận tới các phương pháp cung cấp chất lượng dịch vụ cho Web Service và một phương pháp đơn giản để đo lường thời gian đáp ứng cua Web Services su dung 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ạch các quy trình thương mại, các ứng dụng thương mại điện tử và các Web Service thông qua môi trường Internet. Việc đánh giá chất lượng một dịch vụ web là một thách thức lớn, vì môi trường Internet cùng các ứng dụng Web-Base ngày càng phát triển mạnh mẽ, cũng chính vì thế nên các yêu cầu về

chất lượng dịch vụ cũng luôn thay đổi và khơng thể dự đốn theo cách tự nhiên được. Các ứng dụng với các đặc điểm và yêu cầu riêng biệt sẽ cạnh tranh nhau về tài nguyên mạng

vốn đã rất hạn chế. Sự thay đổi lưu lượng thông tin trên mạng, tan 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 dung Web-Base da 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

</div>Trang 34<div class="page_container" data-page="34">

vụ trên Internet. Thông thường, khi không đáp ứng được các yêu cầu QoS là một nguyên nhân then 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 Scrvice — bao gồm các dịch vụ tài chính, cơng nghệ cao, đa phương tiện và giải trí. Tất cả các Web 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

day[6]

e Tinh cé san ; 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 được dùng dé mô tả liệu một dịch vụ có sẵn sảng đề phục vụ hay không. Cá 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ệu dịch vụ có sẵn trong khoảng thời gian cụ thể hiện tại hay không. Thông thường, người ta thường sử dụng một đại luợng thời gian đề 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ời gian phục hồi có giá trị nhỏ.

e Tính fruy 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 Web Service. Nó diễn tả khả năng ước

lượng bao gôm tốc độ thành công hoặc sự thay đổi thành công của một dịch vụ cụ thể trong một thời điểm. Tính truy cập được còn được thể hiện thơng qua tính có sẵn của dịch vụ Web. Một Web Service có tính truy cập cao khi hệ thống triển khai

</div>Trang 35<div class="page_container" data-page="35">

Web Service do co d6 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ột cách nhât quán mặc dù có thê có nhiêu yêu câu khác nhau cùng tồn tại trong một tập hợp các u cầu.

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

Service dam bảo sự đúng đắn chính xác trong các tươ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 độc lập. Tất cả các hoạt động được hoàn thành để tạo sự thành công cho một giao tác. Khi một giao tác không

được thực hiện thành công, tất cả các thay đổi sẽ được phục hồi lại trạng thái ban

cầu Web 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ên một tháng hay một năm. Theo hướng tiếp cận khác tính tin cậy tham 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 va thiết lập cac dich vu muc cao hon. Web Service str dung mot 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ủa

các phiên bản (VD SOAP VI.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 Web Secrvice bởi các Web Scrvice request.

</div>Trang 36<div class="page_container" data-page="36">

e Tinh an todn : Tinh an toan cla Web Service thé hién 6 co ché bao mat, tham định quyền, mã hố thơng điệp và cung cấp quyên truy cập. Các nhà cung cấp dịch vụ Web có thể có các hướng tiếp cận khác nhau để đảm bảo độ an toàn cho các dịch vụ web.

3.3. OoS cho các dịch vụ Web

QoS cho cac 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ỏi sau[2]:

e_ Thời gian trễ mong chờ là bao nhiêu

e_ Khoảng thời gian roundtrip-time chấp nhận được là bao nhiêu

Lập trình viên cần phải có khả năng hiệu được các đặc điêm QoS cua Web Service trong 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ụng

khá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ên

má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àng buộ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ập tham chiếu tới một Web Service Interface. Những yêu cầu này chỉ chứa các quy

dinh vé QoS.

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

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

dưới đây:

</div>Trang 37<div class="page_container" data-page="37">

- Web Service QoS broker so sénh cac QoS cua cac Service Provider vci cac yéu

cầu QoS ma no dat ra, và sử dụng yêu cầu đó để quyết định chấp nhận QoS mà

các Scrvice Provider đưa ra hay không. Quá trình này được gọi là thương lượng QoS.

- Néu quá trinh thương lượng chất lượng dịch vụ thành công, các Service Requestor 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 q trình thực thi của Web Service

Wcb Service có thể gặp phải hiệu ứng thắt cổ chai trong quá trình thực thi, nguyên nhâ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 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ẫn tô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ới hạ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ặp phải trong cơ chế chuyên tiếp dữ liệu của HTTP là:

e Khong có cơ chế đảm bảo gói tin được phân phát tới dich.

e_ 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út

khi 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ụng

cá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ị micro giâ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

</div>Trang 38<div class="page_container" data-page="38">

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 Scrvice — JMS hoặc IBM MQSerier cho 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ác

requestor 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ận thô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ỉ một mà thôi.

Su dung private Wan va mang Web Service

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

kém.

3.6. Đánh giá hiệu nang giao thirc SOAP

SOAP là một giao thức chủ yếu được dùng cho Web Service. Tuy nhién hiéu nang cua giao 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ân

tí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ã hố thơng điệp SOAP phải được thực hiện ở cả phía gửi và phía nhận thơng điệp.

</div>Trang 39<div class="page_container" data-page="39">

e 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ưới

dạ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 để

thyrc 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ột phươ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ăm

thông điệp SOAP được vận chuyén qua web, khi đó sẽ dẫn đến tình trạng băng thơng mạ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ại

hiệu quả đáng kê khi một lượng lớn đữ liệu được nén dưới dạng nhị phân, trung bình hiệu

suấ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 dạng nhị phân sẽ làm tăng kích thước các thông điệp dẫn tới thời gian vận chuyển các

thông điệp sẽ bị tăng lên đáng kể . Một số ứng dụng được thiết kế nhằm hướng đến kỹ thuật tận dụng hiệu quả của việc thê hiện dữ liệu. Một phương pháp có thể giải quyết vẫn

đề trên đó là nén dữ liệu XML - đặc biệt là khi tài nguyên CPU yêu cầu cho việc nén phải

nhỏ hơn độ trễ mạng.

Một số yêu tô ánh hưởng đến khả năng hoạt động của Web Service

Đây là một sô yêu tô ảnh hưởng đên khả năng hoạt động của Web Scrvice mà nó nam ngoài quyền điều khiển của ứng dụng Web Service, chắng hạn như:

e_ thời gian đáp ứng và tính sẵn sàng của Web Server

e Thoi gian thyc thi tng dung nhu EJB/serverlet trong may chu tng dung web. e Back-end co so dit liéu va vuot qua kha nang hoat động của hệ thống.

3.7. Phương pháp tiếp cân để cung cấp chất lượng dịch vụ cho Web Service Các nhà cung câp dịch vụ trên nên web có thê tuy vào nhu câu về từng loại dịch vụ mà có phương pháp cung cấp chất lượng dịch vụ web khác nhau. Hiện tại hai phương

</div>Trang 40<div class="page_container" data-page="40">

pháp đảm bảo chất lượng dịch vụ đang được sử dụng rộng rãi đó là cân bằng tải và sử

dụng bộ nhớ đệm. Hai phương pháp này đều có khả năng thực thi tốt tại cả mức độ đó là

Web Server và các ứng dụng của Web server. Phương pháp cân bằng tải thê hiện qua mức

độ ưu tiên của lưu lượng và đảm bảo mỗi yêu cầu đều được giải quyết một cách thích hợp tuỳ vào mức độ tài nguyên đối với yêu cầu đó[6].

Các nhà cung cấp dịch vụ web có thể dựa vào mơ hình top-down để nhận dạng các luỗng yêu cầu được gửi đến, từ đó phân loại các loại Web Service trafñc bang label cua các traffic đó, bao gồm các traffic cho các dịch vụ ứng dụng khác nhau xuất phát từ các nguồn khác nhau. Dựa trên các luồng trafñc đó mà các nhà cung cấp dich vụ web đưa ra yêu cầu QoS cho từng loại traffic. Điều này sẽ giúp cho việc hiểu được khả năng yêu cầu để cung cấp một chất lượng dịch vụ tốt cho các lng traffic đồng thời có thể xây dựng

được một kế hoạch cung cấp chất lượng dịch vụ trong tương lai, ví dụ như xác định chuỗi

các yêu cầu liên tiêp đê phân cụm ra các server phục vụ.

Mỗi một yêu cầu nghiệp vụ khác nhau cũng sẽ có các yêu cầu về QoS khác nhau cho từng loại nghiệp vụ, việc dựa trên khả năng mơ hình hố của QoS co thể đảm bảo tiếp cận về mức độ QoS cho các ứng dụng và khách hàng khác nhau. Lấy ví dụ : một Web Service cung cấp các dịch vụ đa phương tiện thì thường yêu cầu QoS thiên về thông lượng tốt, tuy nhiên với các Web Service cung cấp các dịch vụ ngân hàng thì yêu cầu QoS thường thiên vê đảm bảo độ an toàn cho các transaction.

</div>