VanLuong.Blogspot.Com_Nguyen Duc Trung_K50CNPM by bvl91

VIEWS: 12 PAGES: 85

									     Website: http://www.docs.vn Email : lienhe@docs.vn Tel : 0918.775.368




                       ĐẠ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
                 ĐẠ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




                            i
                                    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á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 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ân
thà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, đư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 tháng 05 năm 2009
                                          Sinh viên:
                                          Nguyễn Đức Trung




                                           ii
                             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ụ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
Service được coi là một công nghệ mang đến cuộc cách mạng trong cách thức hoạt động
củ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 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 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ác
dịch vụ Web – QoS cho Web Service dựa trên mô hình tích hợp Web Service với các
Web 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ê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ỏ là 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-Agent đó.




                                          iii
                                                         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
   4.4. Các kí hiệu của biểu đồ Timing Diagram .............................................................. 34
   4.5. Các thành phần của biểu đồ Timing Diagram ...................................................... 36


                                                                 iv
      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




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



 THUẬT NGỮ                                  KHÁI NIỆM


      SOA           Service Oriented Architecture – Kiến trúc hướng dịch vụ
     Service        Các Serivice có sẵn có thể được dùng để tích hợp lên một Web
  Composition       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 được tổng hợp lên từ các Service Composition
Service Composite
                    Nhà cung cấp dịch vụ Web Service. Đây chính là các nguồn
Service Provider    cung cấp đưa ra các dịch vụ cho khách hàng sử dụng
                    Đây chính là dịch vụ ở phía người sử dụng, yêu cầu các dịch vụ
Service Consumer    đưa ra bởi 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 để lấy dịch vụ trả về cho Service
 Service Broken
                    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
      W3C
                    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



                                       vi
                                          DANH SÁCH CÁC HÌNH VẼ
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. ......................................................... 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


                                                                   vii
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
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




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



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 kinh 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 chi 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,
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 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 đượ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ê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
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ự



                                            1
đáp ứng cần thiết cho các quy trình B2B – Bussiness to Bussiness và 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 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 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, đâ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ề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 soá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 Services 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 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
       người sử dụng dịch vụ.


                                              2
    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 đến
      hiệ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ời
      gian đá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 Services
      trong 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 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. 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ộc
thờ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.




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




                                          4
                          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ấ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 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ậ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 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ì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
toà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ụ.




                                             5
     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ú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 đuợc thoả thuận về chi 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 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ề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]:

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




                                                6
2.2. 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ụng
chức năng, được xây dựng từ việc sử dụng các công nghệ chuẩn Internet [1][4]. Được
minh 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 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
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 sau
Firewall kia [1].

     Không giống như mô hình Client/Server 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ạ
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áy
tính. Tuy nhiên nguời phát triển Web Service hoàn toàn có thể đưa Web Service vào 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.



                                                    7
     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 Service 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, đô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ạng
má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ộ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 Service đều có thể truy cập các ứng dụng chức năng của
nhau.




        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 Website
HTML, 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ứ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 service nhằm thực
thi một nhiệm vụ như việc đặt mua sách, gửi thiệp mừng hoặc là đọc bản tin v..v.

                                                    8
     Web 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 thì các Application và Client sử dụng 2 công
nghệ 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 Service
trong 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].



                                               9
     Trong kiến trúc Web Service, Service Provider công bố các mô tả về các service
thô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 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 và WDS – Web-Defined Service. NASSL là một tài liệu dưới dạng chuẩn của
XML cho các service chạy trên nền Network, nó được sử dụng để chỉ ra các thông tin
hoạ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, địa
chỉ. 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 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 phân tầng của Web Service




                               Hình 4:   Web Service technology stack




                                              10
     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 Web
Service 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ôn
ngữ 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ầng
       Description, công nghệ được sử dụng ở đây chính là WSDL (Web Service
       Desciption 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ú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.




                                                11
 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ầ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 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ác
   tà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 đó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.

 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á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. 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ế 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.




                                        12
    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ộ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 chỉ ra cụ thể các thông 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
      thô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ê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.


                                          13
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 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 XML
như XML Schema và XML Namespaces dùng cho việc định nghĩa SOAP và các chức
nă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ền
Unix.




                                              14
b) RPC và 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 Procedure Call là một dạng tính toá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 là một dạng transaction cơ bản 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 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 định
tuyế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ác
transaction. 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ì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].




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


                                              15
       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 phần 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 để 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[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
        XML Namespace.

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

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



                                               16
   -    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â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 đứng phía trên tầng Network và tầng Transport. Vì thế
SOAP không quan tâm đến việc giao thứ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ườ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 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í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 (request-response-base protocol). Các SOAP request
được gửi tới HTTP server thông qua phương thức POST và HTTP Server trả lại giá trị
SOAP response thông qua các HTTP response.




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



                                                 17
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ủa IBM và Microsoft[15].

    WSDL dựa trên giao thức XML để trao đổi thông tin trong môi trườ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 động thực thi trên
      Web Service đó.

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

    WSDL là ngôn ngữ mà UDDI Sử dụng.

Các thành phần của WSDL

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


        Thành phần         Mô tả

        <type>             Định nghĩa kiểu dữ liệu được dùng trong Web Service

        <message>          Các thông điệp được sử dụng trong Web Service

        <port type>        Các thao tác được thực thi bởi Web Service

        <binding>          Các giao thức giao tiếp dùng cho Web Service

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.



                                           18
 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 đượ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:

    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

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

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




                                          19
                        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”.

   Thuộc tính style có thể là “rpc” hoặc “document”. 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 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ột thao 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”.


                                              20
     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ô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à 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.

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

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

    UDDI giao tiếp thông qua SOAP.

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

    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 có 2 phần

    Phần đăng ký của tất cả các Web Service’s metadata, bao gồm cả việc trỏ đến tài
      liệu WSDL mô tả dịch vụ[16].

    Phần thiết lập WSDL Port type định nghĩa cho các thao tác và tìm kiếm thông tin
      đăng ký.

     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 như XML, HTTP, và DNS. UDDI sử dụng WSDL để 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 thức SOAP.


                                           21
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:

    BusinessEntity

    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 Web Service. Cấu trúc này
chứa các thông tin 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ụ 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 độc lập được cung cấp
bởi business entity. Nó mô tả các thông tin về cách thức gắn kết với Web Service, định
nghĩa kiểu Web Service và phân loại danh 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 – Universally Unique 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 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.


                                               22
c) Cấu trúc dữ 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 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 để giao tiếp với Web Service. Một Business Service có thể có
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. Bất kì 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 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ặc nhiề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.

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.




                                           23
                         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ệ Web Service, 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ô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, ảnh 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
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ạ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ự đoá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, 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



                                          24
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 Service – 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
đâ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 được dùng để mô tả liệu một dịch vụ có sẵn sàng để phục vụ hay khô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ệ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ỏ.

    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 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



                                              25
   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ộ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 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á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
   đầ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 Service hoạt động tốt. Thông lượng trình bày số lượng yêu
   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 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ủa
   cá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 Web Service bởi các Web Service request.


                                        26
    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ề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. 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ỏi
sau[2]:

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

    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 của 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
      đị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:




                                           27
      - Web Service QoS broker so sánh các QoS của các Service Provider với các yêu
        cầ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ượng
        QoS.

      - Nếu quá trình 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 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ê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à:

    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ú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

                                           28
    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 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.

    Sử dụng private Wan và mạng Web Service

      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ợp
      cho các doanh nghiệp sử dụng Web Service 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 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ủa
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ã hoá 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.


                                          29
    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 để
      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ộ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 dữ 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 Service mà nó nằm
ngoài quyền điều khiển của ứng dụng Web Service, chẳng hạn như:

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

    Thời gian thực thi ứng dụng như EJB/serverlet trong máy chủ ứng dụng web.

    Back-end cơ sở dữ liệu và vượt quá khả năng hoạt độ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ể tuỳ 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



                                          30
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 traffic bằng label của
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 traffic đó mà các nhà cung cấp dịch 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 luồng 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 hoá của QoS có 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.




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

     Trong các chương trước, chúng tôi đã đề cập đến công nghệ Web Service và
phương pháp tiếp cận để cung cấp chất lượng dịch vụ cho các Web Service. Trong
chương này, chúng tôi sẽ trình bày về một loại biểu đồ UML dùng để đặc tả ràng buộc
thời gian đáp ứng của các đối tượng đó là biểu đồ UML 2.0 Timing Diagram.

4.1. Giới thiệu UML

     UML – Unified Modeling Language là ngôn ngữ dành cho việc đặc tả, hiển thị, xây
dựng và làm tài liệu của các hệ thống phần mềm. UML tạo cơ hội để viết thiết kế hệ
thống, bao gồm những khái niệm như tiến trình nghiệp vụ và chức năng hệ thống. Cụ thể
nó hữu dụng cho những ngôn ngữ khai báo, giản đồ cơ sở dữ liệu, thành phần phần mềm
có khả năng tái sử dụng[10].

     UML là một Ngôn ngữ đặc tả hình thức (formal specification language). Chúng ta
cần chú ý đến thuật ngữ “ngôn ngữ”. Ngôn ngữ ở đây không phải là ngôn ngữ giống với
ngôn ngữ tự nhiên của con người hay ngôn ngữ lập trình. Tuy nhiên, nó cũng có một tập
các quy luật xác định cách sử dụng.

     Các ngôn ngữ lập trình có một tập các phần tử và một tập các quy luật cho phép
chúng ta tổ hợp các phần tử lại với nhau để tạo ra các chương trình hợp lệ. Các ngôn ngữ
đặc tả hình thức giống như UML cũng có một tập các phần tử và một tập các quy luật
riêng. Với UML, hầu hết các phần tử của nó là các đối tượng đồ hoạ như đường thẳng,
hình chữ nhật, hình oval,… Chúng thường được đặt nhãn để cung cấp thêm thông tin. Tuy
nhiên, các phần tử đồ hoạ của UML chỉ biểu diễn các phần cần mô hình dưới dạng hình
ảnh, ta cũng có thể tạo ra một mô hình UML dưới dạng thuần dữ liệu (Giống như
CORBA và XMI DTD ). Tuy nhiên, cách biểu diễn bằng hình ảnh vẫn giúp mô hình dễ
hiểu và trực quan hơn.

     Các quy luật trong UML được mô tả trong đặc tả UML. Có ba loại quy luật: Cú
pháp trừu tượng, luật well-formedness (Luật hình thức) và ngữ nghĩa. Trong đó cú pháp


                                          32
trừu tượng được biểu diễn như các biểu đồ và ngôn ngữ tự nhiên, luật well-formedness
nằm trong ngôn ngữ ràng buộc đối tượng OCL (Object Constraint Language). Luật được
biểu diễn như biểu đồ sẽ dùng một tập các ký hiệu con của UML để xác định cách kết hợp
giữa các phần tử.

   UML được phát triển bởi Rational Rose và một số nhóm cộng tác, nó nhanh chóng trở
thành một trong những ngôn ngữ chuẩn để xây dựng hệ thống phần mềm hướng đối tượng
nhờ các lợi ích sau:

    UML cung cấp khả năng mở rộng và chuyên môn hoá để mở rộng những khái
       niệm cốt lõi.

    Độc lập với ngôn ngữ lập trình chuyên biệt, và các tiến trình phát triển.

    Cung cấp nền tảng về sự biểu biết ngôn ngữ mô hình hoá.

    Khuyến khích và hỗ trợ sự phát triển các công cụ hướng đối tượng.

    Hỗ trợ những khái niệm phát triển cấp độ cao như collaboration, framework,
       pattern and component.

    Tích hợp một cách tốt nhất với thực tiễn.

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

     Biểu đồ Timing Diaram là một biểu đồ được thêm vào cho UML 2.0, là một trong
các dạng của mẫu biểu đồ tương tác. Nó được dùng để khám phá hành vi của một hoặc
nhiều đối tượng trong suốt một khoảng thời gian được cung cấp định kì. Biểu đồ Timing
Diagram thường xuyên được sử dụng trong việc thiết kế các hệ thống nhúng, chẳng hạn
phần mềm điều khiển cho hệ thống tự thêm nhiên liệu trong xe ô tô, và đôi khi biểu đồ
Timing Diagram được sử dụng để mô tả phân tích thiết kế cho các phần mềm thương mại.

     Nhìn chung, biểu đồ Timing Diagram tương tự như biểu đồ khi ta phân tích một
mạch điện tử logic. Biểu đồ phân tích mạch điện tử ghi lại trình tự xuất hiện của các thành
phần trên mạch điện tử. Kết quả đưa ra của việc phân tích logic sẽ hiển thị thời gian mà


                                            33
tại đó các thành phần của mạch điện tử ở trong các trạng thái riêng biệt và các tín hiệu
điện tử sẽ thay đổi tức thì trong các trạng thái đó. Biểu đồ Timing Diagram thực thi công
việc tương tự cho các thành phần trong hệ thống. Trong biểu đồ Timing Diagram, các sự
kiện giống như các tín hiệu điện, và trạng thái là các trạng thái mà các thành phần được
đặt trong nó khi nó nhận một sự kiện[10][11].

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

   Biểu đồ Timing Diagram được phát triển cho các hệ thống thời gian thực: là hệ thống
phải tuân thủ theo một ràng buộc thời gian trong quá trình mà hệ thống đó thực thi. Biểu
đồ Timing Diagram được ưu thích hơn biểu đồ tuần tự ở điểm nó có một ràng buộc thời
gian bắt buộc các đối tượng phải tuân thủ chặt chẽ. Mục đích của biểu đồ Timing
Diagram được tổng hợp thành các ý chính sau:

    Biểu đồ Timing Diagram được sử dụng để trợ giúp quá trình phân tích các hành vi
      có liên quan đến thời gian thực hiện của các đối tượng, các hệ thống con.

    Nó dùng để chỉ rõ ràng buộc thời gian của các hành vi của đối tượng và các hệ
      thống con.

    Thường được sử dụng để mô hình hoá mối quan hệ giữa các đường lifeline trong
      toàn bộ quá trình tương tác mà phụ thuộc vào sự tham gia của các ràng buộc về
      thời gian

4.4. Các kí hiệu của biểu đồ Timing Diagram

     Biểu đồ Timing Diagrams là một dạng của biểu đồ tương tác, nó được thể hiện trong
các khung với các từ khoá sd và tên của các tương tác trong phần tiêu đề trên phía góc
bên trái của khung đó. Tên của các đường lifelines được viết ở bên trái của khung và có
thể chạy xuyên suốt từ trái qua phải ở phía bên trên của khung vẽ đó. Chúng ta có thể thể
hiện đầy đủ một biểu đồ Timing Diagram chỉ bằng một đường lifeline, nhằm thể hiện mục
đích của biểu đồ này đó chính là trình bày các nguyên nhân ảnh hưởng đến các tương tác
của các đường lifelines xuyên suốt qua một khoảng thời gian hơn là hiển thị việc vận

                                           34
chuyển các thông điệp giữa các đường lifeline. Khi có nhiều hơn một đường lifeline trong
biểu đồ Timing Diagram, chúng ta có thể phân tách chúng ra bởi các đường nằm ngang
nhằm thể hiện việc chuyển tương tác của các đường linelife đó[10].

Biểu đồ Timing Diagram có thể được thể hiện dưới 2 dạng.

    Biểu đồ Timing Diagram có thể được thể hiện dưới dạng “Robust Diagram”, ở
      dạng này các trạng thái được thể hiện bằng các đường thẳng, hình dưới minh hoạ
      biểu đồ Timing Diagram được thể hiện dưới dạng “robust diagram”.




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

      Trong dạng thể hiện này, các đường lifeline thể hiện các trạng thái tương đồng
   nhau một cách trực quan. Nó không thêm được bất kì ý nghĩa gì cho biểu đồ, cách thể
   hiện này chỉ đơn giản là thay đổi việc điều phối các thành thành phần được sử dụng
   cho biểu đồ timing diagram. Trong dạng thể hiện này của các đường lifeline, các trạng
   thái được liệt kê xuyên suốt trục y của biểu đồ và thời gian được thể hiện trên trục x,
   chúng ta cần chú ý rằng trong biểu đồ Timing Diagram không có một đơn vị thời gian
   cụ thể nào cho các trạng thái, tất cả việc đo lường thời gian cho các quá trình tương tác
   đều được đo trừu tượng trong một khoảng thời gian xác định cụ thể nào đó. Các đường
   nối tiếp nhau trình bày các trạng thái của các trường hợp trong từng thời điểm thời
   gian.

    Biểu đồ Timing Diagram có thể được thể hiện dưới dạng các trạng thái được trình
      bày bằng các vùng riêng biệt như Hình 14.

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

     Trong dạng thể hiện này, các đường lifeline được thể hiện bằng 2 đường bao quanh
các trạng thái. Trường hợp này các đường lifeline được gọi là các đường giá trị tổng quan,
khi các đường lifeline giao nhau nó chỉ ra rằng điểm đó là điểm chuyển tiếp giữa các
trạng thái. Dưới các đường lifeline là các ràng buộc thời gian thực hiện cho các trạng thái
được chạy xuyên suốt từ trái qua phải.

     Trong quá trình mô hình hoá, phụ thuộc vào mục đích mô hình hoá và số lượng các
trạng thái được sử dụng để chúng ta quyết định xem nên dùng dạng biểu đồ nào. Nếu chỉ
có một một đường lifeline hoặc số lượng trạng thái quá lớn thì biểu đồ dạng thứ 2 là thích
hợp còn nếu số lượng đường lifeline lớn thì biểu đồ dạng 1 nên được lựa chọn.

4.5. Các thành phần của biểu đồ Timing Diagram

4.5.1.Các trạng thái

     Trong quá trình tương tác, các thành phần có thể tồn tại trong bất cứ số lượng trạng
thái nào. Các thành phần có thể gọi là ở trong một trạng thái riêng biệt khi nó tiếp nhận
các sự kiện (chẳng hạn các thông điệp). Từ đó thành phần được nói ở trong trạng thái đó
cho đến khi một sự kiện khác xuất hiện (chẳng hạn như sự trả về của một thông điệp).




                                               36
      Các trạng thái và các điều kiện cần phải được phân biệt với các trạng thái và điều
kiện trong biểu đồ tuần tự mặc dù chúng có cùng một thao tác, chúng ta cần phải dựa trên
biểu đồ trạng thái để quyết định các đối tượng nào có thể được trình bày bởi các đường
lifeline.

      Ta có thể không cần thể hiện đầy đủ tên của các trạng thái thành phần để có thể giữ
cho kích thước của biểu đồ trong phạm vi quản lý được, mặc dù ta hoàn toàn có thể để tên
đầy đủ các trạng thái thành phần theo định dạng <tên lớp>:<tên đối tượng>.

Một số các trạng thái thành phần ta thấy xuất hiện trong biểu đồ tuần tự nhưng lại không
được đưa vào biểu đồ Timing Diagram là do nó được tạo ra và hủy trong vòng đời của
quá trình tương tác, các thành phần này nó không có liên hệ đến các trạng thái được thay
đổi và chúng không thể thêm được bất kì thông tin nào cho các thành phần.

      Trong suốt quá trình mô hình hóa, chúng ta cần phải quyết định những gì nên và
không nên đặt vào trong biểu đồ bằng cách trả lời câu hỏi : “Những thông tin cụ thể đó có
quan trọng để hiểu những gì ta đang mô hình hóa hay không” và “Liệu thêm các thông tin
đó vào có làm cho biểu đồ của ta trở nên trong sáng hơn hay không”, nếu câu trả lời là có
thì ta hãy đưa các thông tin đó vào trong biểu đồ, còn không thì không đưa các thông tin
đó vào để giữ biểu đồ trong phạm vi kiểm soát đơn giản nhất.




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


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

      Trong biểu đồ timing diagram, các thành phần thay đổi trạng thái để đáp ứng một sự
kiện. Các sự kiện có thể là các lời gọi thông điệp hoặc có thể là bất cứ thứ gì, chẳng hạn
như sự trả về của một thông điệp sau khi nó đã được gọi. Trong biểu đồ timing diagram,


                                                 37
ta không cần phân biệt rõ sự khác nhau giữa các thông điệp và các sự kiện như trong biểu
đồ tuần tự. Điều quan trọng nhất cần phải nhớ ở đây đó chính là sự kiện xảy ra như thế
nào, và cách thức nó hiển thị trên biểu đồ timing diagram để thể hiện rõ sự thay đổi trạng
thái của các thành phần[10][11].

      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 đó.




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

      Trong ví dụ trên ta thấy, sự kiện 1 được thực thi trong 1 đơn vị thời gian, và được
gọi bởi thành phần p1 và được nhận bởi thành phần p2.

      Các thông điệp ở đây có thể là các thông điệp yêu cầu và các thông điệp trả về. Các
thông điệp yêu cầu được thể hiện bằng các đường nét liền, và các thông điệp trả về được
thể hiện bằng các đường nét đứt. Các thông điệp thể hiện các giao tiếp giữa các đường
lifeline.

4.5.3.Thời gian

      Thời gian được thể hiện theo chiều từ bên trái qua phải dọc theo trục x của biểu đồ
như hình 17.




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

     Đo lường thời gian có thể thực hiện theo hai cách khác nhau: chúng ta có thể sử
dụng thời gian chính xác như hình minh họa trên nhưng ta cũng có thể sử dụng thời gian
ước lượng như hình 18.




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

     Trong biểu đồ timing diagram, thời gian t trình bày một khoảng thời gian ước lượng
khi mà ta không biết chính xác khi nào một sự kiện xảy ra, nó có thể xảy ra một cách
ngẫu nhiên để đáp ứng một thông điệp hoặc một sự kiện, nhưng thời gian t là một phương
pháp để tham chiếu tới khoảng thời gian mà ta không biết chính xác khi nào xảy ra. Với
thời gian tham chiếu t, ta có thể chỉ ra ràng buộc thời gian tại thời điểm t.

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

     Sau khi đã thêm thời gian vào biểu đồ Timing Diagram, chúng ta cần phải hiển thị
trạng thái của các thành phần theo các đơn vị thời gian đã được cung cấp. Trong biểu đồ
Timing Diagram, các đường state-line là các đường được đặt thẳng hàng với mỗi trạng



                                                 39
thái thành phần để thể hiện ràng buộc thời gian thực hiện cho các trạng thái thành phần
đó[13].

Hình dưới minh hoạ các đường state-line trong biểu đồ Timing Diagram




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

     Trong ví dụ trên, đường state-line thành phần p1 chỉ ra rằng trạng thái 1 thực thi
trong 1 đơn vị thời gian, trạng thái 2 trong 3 đơn vị thời gian, và trạng thái 3 thực hiện
trong 5 đơn vị thời gian (trước khi trở về trạng thái 1 để kết thúc quá trình tương tác).

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

     Ràng buộc thời gian mô tả một cách chi tiết yêu cầu: cần bao nhiêu thời gian để quá
trình tương tác được thực thi. Các hành động cần một số lượng thời gian nhất định để các
trạng thái thành phần cần để thực thi các lời gọi và lời trả về thông điệp. Việc đưa các
ràng buộc thời gian vào biểu đồ Timing diagram được thể hiện như hình 20 [10].




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



                                                  40
      Trong ví dụ minh hoạ trên, khoảng thời gian để thực thi sự kiện 1 phải nhỏ hơn 1 giá
trị thời gian ước lượng t, và thời gian để thành phần p2 bước vào trạng thái 4 phải diễn ra
trong vòng 5s.

Các định dạng về ràng buộc thời gian

      Ràng buộc thời gian trong biểu đồ timing diagram có thể được thể hiện bằng nhiều
cách khác nhau, bảng dưới đây thể hiện các định dạng có thể của ràng buộc thời gian cho
các sự kiện, trạng thái trong các thành phần[10].



Định dạng        Mô tả

{t…t+5s}         Khoảng thời gian để thực thi phải diễn ra trong vòng 5s hoặc nhỏ hơn.

{<5s}            Khoảng thời gian cho các sự kiện hoặc trạng thái phải nhỏ hơn 5s.

{>5s, <10s}      Khoảng thời gian cho các sự kiện hoặc trạng thái có thể lớn hơn 5s
                 nhưng bắt buộc phải nhỏ hơn 10s.

{t}              Khoảng thời gian cho các sự kiện hoặc trạng thái bắt buộc phải nhỏ hơn
                 hoặc bằng thời gian t, đây là thời gian ước lượng, và t có thể là bất cứ
                 giá trị thời gian ràng buộc nào.

{t..t*5}         Khoảng thời gian cho các sự kiện hoặc trạng thái có thể bằng giá trị t
                 nhân với 5, đây cũng là một dạng thời gian ước lượng khác.




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

     Trong ba chương trước chúng tôi đã trình bày các kiến thức nền tảng về công nghệ
Web Service, QoS cho Web Service và biểu đồ Timing Diagram. Trong chương này,
chúng tôi sẽ tiếp cận đến việc phát triển bài toán xây dựng Web Service Proxy để đo
lường thời gian đáp ứng của các Web Service Composition, và từ đó kiểm chứng ràng
buộc thời gian đáp ứng của các Web Service Composition dựa trên đặc tả của biểu đồ
UML Timing Diagram.

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

     Service Proxy về bản chất cũng là một Web Service được triển khai ở phía Client.
Service Proxy tương tự như mô hình Stub trong kiến trúc Java RMI, nó chứa các đoạn
code để chỉ rõ sự kết hợp với các Web Service interface, Service Proxy thường nằm phía
bên trong một hệ thống mạng máy tính phức tạp. Mô hình tổng quan của một hệ thống với
Service Proxy được thể hiện thông qua hình dưới đây[1]




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

     Service Proxy sẽ thực thi phương thức giống như phương thức được triển khai trên
các remote Web Service, tuy nhiên trên Service Proxy sẽ không thực hiện bất kì một thao
tác tính toán nào cả, nó chỉ có nhiệm vụ nhận các request từ phía Client rồi chuyển tiếp
các thông điệp yêu cầu đến các remote Web Service, tại remote Web Service sẽ thực thi
các thao tác tính toán trên các dữ liệu được chuyển đến đó và trả lại kết quả cho Service


                                               42
Proxy. Service Proxy nhận kết quả trả về và chuyển tiếp cho Client. Ta lấy một ví dụ để
làm sáng tỏ hơn về Service Proxy như sau: Giả sử ta có một Web Service thực hiện phép
toán cộng 2 số nguyên, trên Web Service đó phương thức công 2 số nguyên được khai
báo như sau: int add(int a, int b) khi đó trên Service Proxy cũng phải được thực thi
phương thức int add(int a, int b), tuy nhiên phương thức add trên Service Proxy lại thực
sự không thực hiện thao tác cộng 2 số nguyên mà nó chỉ có tác dụng triệu gọi đến Web
Service thực sự cung cấp phương thức cộng 2 số, truyền đối số a và b trong lời triệu gọi
đó để Remote Web Service kia thực hiện việc cộng 2 số a và b, trả lại kết quả cho Service
Proxy và từ đó Service Proxy sẽ trả về kết quả cộng 2 số cho Client.

     Khi chúng ta cần tích hợp các dịch vụ Web bên ngoài hệ thống, ta hoàn toàn có thể
liên kết trực tiếp tới các dịch vụ web đó trong code ở phía client bằng cách sử dụng một
số thư viện API. Tuy nhiên hướng tiếp cận này lại có một số vấn đề đó là, thứ nhất chúng
ta sẽ phải tạo ra một liên kết cứng giữa chương trình và các dịch vụ, thứ hai việc sử dụng
liên kết trực tiếp sẽ dẫn đến tình trạng rất khó khăn khi chúng ta muốn tái sử dụng các
dịch vụ tương tự trên các thành phần khác của ứng dụng: trong trường hợp này, chúng ta
cần phải thực thi lại các lời gọi dịch vụ, chắc chắn chúng ta hoàn toàn có khả năng tái sử
dụng lại các đoạn code tại cấp độ phương thức tuy nhiên điều đó hết sức bất tiện.

   Nếu sử dụng Service Proxy để thay thế, chúng ta có thể tách riêng phần dịch vụ ra
khỏi chương trình chính và chúng ta hoàn toàn có khả năng đưa phần dịch vụ này vào một
giao diện bên ngoài chương trình chính và có thể thực thi các nhiệm vụ hữu ích khác. Một
Service Proxy sẽ thực thi lần lượt ba thao tác yêu cầu dưới đây để thực hiện một lời gọi
phương thức tới một remote Web Service:

    Truyền đối số

    Xây dựng lời gọi Web Service

    Đọc kết quả trả về từ Remote Web Service




                                            43
Các thao tác chính của một Service Proxy có thể được minh hoạ như hình dưới đây




                          Hình 23: Minh hoạ các thao tác của Service Proxy

       Chúng ta thường sử dụng Service Proxy trong trường hợp số lượng code tích hợp
Web Service thường lớn và có thể lớn hơn trong tương lai, và tồn tại việc trùng lặp các lời
gọi tới cùng một dịch vụ trong các vị trị khác nhau của chương trình. Khi sử dụng Service
Proxy, các đoạn code của chúng ta sẽ được sắp xếp tổ chức một cách chuẩn mực, tương
đương với mỗi một dịch vụ được tổ chức trong một lớp. Chúng ta sẽ chia nhỏ các tầng kĩ
thuật và các thư viện API để truy cập tới dịch vụ từ client code và đương nhiên sẽ chia
nhỏ việc phải thay đổi các thư viện API như khi liên kết cứng giữa chương trình và dịch
vụ.

Và khi sử dụng Service Proxy chúng ta hoàn toàn có thể:

       Nhóm các dịch vụ lại bằng các kĩ thuật đóng gói, lựa chọn các thứ bậc của dịch vụ
         sử dụng bởi ứng dụng.

       Chia ra các lớp con từ một lớp trừu tượng, dẫn đến có thể cung cấp thêm các dịch
         vụ khác.

      Mỗi một lớp của Service Proxy trình bày một dịch vụ, và chúng ta có thể mô hình hoá
các dịch vụ bằng các mối quan hệ, các sự cộng tác trong biểu đồ UML.

      Thông thường thì chúng ta không phải tự viết ra Service Proxy. Service Proxy có thể
dễ dàng tự được sinh ra từ file WSDL. Ngày nay có với mỗi ngôn ngữ lập trình hỗ trợ
công nghệ Web Service đều có các công cụ đi kèm theo để tự sinh ra Service Proxy từ các
file WSDL.




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

     Để hiểu kĩ hơn về Web Service Composition, trước tiên chúng ta cần phải đề cập
đến một vấn đề đó chính là tích hợp Web Services. Vấn đề tích hợp các service có sẵn là
một phần trong kiến trúc của SOA. Ngày này việc tích hợp Web Services vẫn đang là một
chủ đề được nghiên cứu rộng rãi, và được coi là một giải pháp cho việc sử dụng lại các
service có sẵn để tạo dựng lên một Service mới tốt hơn.

Chúng ta có hai phương pháp tích hợp Web Service: Tích hợp tĩnh và tích hợp động:

    Tích hợp được coi là tĩnh nếu chúng ta kết hợp các service tại thời điểm thiết kế
      hoặc tại thời điểm cài đặt các Web Service.

    Tích hợp được coi là động nếu chúng ta kết hợp các service tại thời điểm các
      Service đang được thực thi.

     Vậy tích hợp Web Service chính là một quá trình xử lý để kết nối các Web Services
đã tồn tại để xây dựng lên một Web Service mới. Web Service mới được gọi là composite
service, còn các Web Service đã tồn tại dùng để xây dựng lên service mới thì được gọi
“Web Service Compositions”.

     Từ đó ta có thể thấy, một Web Service Composition cũng có thể là một composite
Web Service. Các Web Service Composition có thể được triển khai tại các vị trí khác
nhau, trên các nền tảng công nghệ khác nhau. Nhưng điều quan trọng ở đây là chúng ta
phải có một công nghệ chung nhất để các Web Service được tích hợp hay dùng để tích
hợp có thể giao tiếp được với nhau.




                                           45
Dưới đây ta có mô hình tích hợp Web Service




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

     Trong mô hình minh họa trên, phía client sẽ gọi các dịch vụ tới các Web Service đã
được tổng hợp thông qua file WSDL của Web Service được tổng hợp đó. Từ các
Composite Web Service sẽ xây dựng lời gọi đến các Web Service Composition, Các Web
Service Composition thực hiện các thao tác tính toán, trả lại kết quả cho Composite Web
Service. Composite Web Service tổng hợp các kết quả từ các Service thành phần và trả lại
kết quả cuối cùng cho phía Client.

     Để hiểu rõ hơn thế nào là Web Service Composition chúng tôi đưa ra một ví dụ đơn
giản sau để minh hoạ đồng thời cũng là một ví dụ dùng cho mục tiêu khoá luận đó là kiểm
chứng ràng buộc thời gian đáp ứng của các Web Service Composition: Để thực hiện một
tour du lịch, hành khách cần phải cần các dịch vụ sau: tìm kiếm khách sạn của thành phố
đích đến du lịch, tìm kiếm các chuyến bay từ thành phố xuất phát đến thành phố đến và
dịch vụ cung cấp đặt vé máy bay. Giả sử ta có 2 nhà cung cấp dịch vụ Web đưa ra 2 dịch
vụ Web Service nhằm phục vụ cho việc tìm kiếm khách sạn và tìm kiếm các chuyến bay.
Hai Web Service này nằm ở hai vị trí địa lí khác nhau, sử dụng các công nghệ để triển
khai khác nhau. Điều đó dẫn tới khi khách hàng muốn sử dụng 2 dịch vụ đó sẽ phải tìm



                                              46
kiếm tại hai website khác nhau nên sẽ không thuận tiện. Nhằm đem lại sự thuận tiện cho
khách hàng, chúng ta muốn tích hợp 2 Web Service là tìm kiếm khách sạn và tìm kiếm
máy bay đó vào một dịch vụ lớn hơn , được gọi là dịch vụ Travel-Agent. Dịch Vụ Travel-
Agent sẽ gọi đến 2 dịch vụ con là SearchHotel và SearchFlight mỗi khi có một truy vấn từ
client đến dịch vụ Travel-Agent. Vậy ở đây các Web Service SearchHotel và SearchFlight
chính là các Web Service Composition và Service Travel-Agent ở đây chính là Composite
Service. Từ đó ta thấy Web Service Composition chính là các Web Service và có thể dùng
để kết hợp với nhau tạo nên một Service lớn hơn.

Việc tích hợp các Web Service có thể phân chia thành hai loại như sau:

   a) Loại thứ nhất: Composite Service được xây dựng bằng ngôn ngữ thông thường như
      Java, C#.. Quá trình này giống như phát triển một ứng dụng từ các dịch vụ Web.
      Trong trường hợp này, ứng dụng cũng được coi là một Web Service, và tầng trung
      gian không quan tâm đến quá trình tích hợp Web Serice. Vấn đề tích hợp trở nên
      cồng kềnh, người lập trình phải chú tâm đến tiến trình xử lý mức dưới của thông
      điệp SOAP và các nghiệp vụ logic khác. Khi sử dụng phương pháp này, chỉ cần
      một thay đổi nhỏ trong composition services sẽ dấn đến sự thay đổi khá lớn của
      các Service được tổng hợp.

   b) Loại thứ hai: Sử dụng các công cụ mức cao cho việc tích hợp Web Service. Đây sẽ
      là một phương pháp hữu ích và tiện lợi cho việc tích hợp Web Service. Dưới đây
      chúng tôi sẽ đề cập đến một số công cụ được dùng cho việc tích hợp dịch vụ.

Một số chuẩn tích hợp các Web Services:

    BPEL: Được viết tắt của cụm từ The Business Process Excution Language – Đây
      là một ngôn ngữ chuyên biệt được dùng cho các quy trình thương mại và các giao
      thức tương tác thương mại. Nó thay thế XLANG và WSFL như là một chuẩn để
      tích hợp Web Service. Việc dựa trên nền tảng mô hình và cú pháp XML được cung
      cấp bởi BPEL định nghĩa sự tương tác giữa các quy trình và Web Service
      Interface. Nó chỉ định nghĩa các trạng thái logic giữa các sự tương tác và phương


                                           47
   pháp hệ thống đối với các điều kiện ngoại lệ. Các mô hình xử lý được định nghĩa
   bởi BPEL đều được dựa trên nền tảng mô hình mô tả dịch vụ WSDL. Các dịch vụ
   (được mô tả như là các thành phần trong tập hợp BPEL) được gọi/ trả lời bằng
   cách sử dụng các hành động được trình bày bởi WSDL.

 BPML : BPML cung cấp mô hình và cú pháp trừu tượng cho việc trình bày một
   cách trừu tượng và thực thi các quy trình thương mại. Sử dụng BPML, các quy
   trình thương mại, các Web Service phức tạp có thể dễ dàng được định nghĩa. Các
   quy trình trong BPML là thành phần của các hành động để thực thi một chức năng
   cụ thể nào đó. Các quy trình hướng đến sự thực thi của các hành động. BPML định
   nghĩa ra 17 kiểu hành động và 3 kiểu quy trình. Các đặc tả về BPML thường hỗ trợ
   việc nhập và tham chiếu đến việc định nghĩa dịch vụ được cung cấp bởi WSDL.
   Các chuẩn của ngôn ngữ BPML sử dụng đó là RDF và Dublin Core để trợ giúp
   ngôn ngữ BPML gần gũi với ngôn ngữ con người hơn.

 BPSS: Được viết tắt của cụm từ Business Process Specification Schema – nó là
   một chuẩn cho việc trình bày mô hình tập hợp các quy trình thương mại điện tử.
   Nó sử dụng cú pháp XML như là một thành phần trong lời gọi tới các quy trình
   thương mại có liên quan. BPSS là một chuẩn có thể được sử dụng để cấu hình các
   hệ thống thương mại nhằm hỗ trợ việc cộng tác thương mại. Tuy nhiên BPSS lại
   không hỗ trợ việc mô tả cách thức các luồng dữ liệu giữa các giao tác mà nó lại hỗ
   trợ một cách rõ ràng về chất lượng dịch vụ cho các giao tác như việc thẩm định
   quyền, biên nhận, và định thời gian timeouts.

 WSCI : Được viết tắt của cụm từ Web Service Choreography Interface – dựa trên
   nền tảng ngôn ngữ XML dùng cho việc mô tả các hành vi của Web Service trong
   việc trao đổi thông điệp dựa trên ngữ cảnh của việc cộng tác các quy trình thương
   mại hoặc các luồng công việc. Nó định nghĩa các luồng trao đổi thông điệp bởi
   Web Service bằng việc mô tả các hành vi đặc biệt. Mặc dù nó cung cấp các quy
   trình hướng thông điệp nhưng nó lại không định nghĩa ra các hành vi bên trong các



                                       48
      quy trình xử lý Web Service. Nó là một giao diện tĩnh cung cấp các thông tin chi
      tiết bởi file WSDL mô tả cách thức các hành động, các thao tác và thuộc tính của
      Web Service.

    WSCL : Được viết tắt của cụm từ Web Service Conversation Language – cho phép
      định nghĩa các hành vi bên ngoài các service bằng việc chỉ rõ mức độ giao tiếp của
      các quy trình thương mại và hỗ trợ công bố quy trình thương mại bởi Web
      Services. Các quy trình giao tiếp được định nghĩa bằng việc sử dụng cú pháp XML
      và tài liệu WSDL. WSCL cung cấp các thiết lập chi tiết cho việc giao tiếp và đưa
      ra bởi các Service Provider.

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

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

     Sau khi trình bày các khái niệm về công nghệ Web Service, QoS cho Web Service,
Service Proxy, Web Service Composition và biểu đồ Timing Diagram, bây giờ chúng tôi
sẽ vận dụng các kiến thức trên cho bài toán kiểm chứng ràng buộc thời gian đáp ứng của
các Web Service Composition, sử dụng ví dụ Travel-Agent.

     Ngày nay với sự phát triển rộng rãi của Internet cùng các công nghệ Web-base, các
ứng dụng phục vụ cho các mục đích thương mại, văn hóa và du lịch ngày càng được phát
triển rộng rãi và đa dạng. Hiện tại, song song với quá trình phát triển kinh tế, nhu cầu du
lịch của con người ngày càng trở thành một phần không thể thiếu trong cuộc sống, tuy
nhiên trong bối cảnh cuộc sống bận rộn và tấp nập như ngày nay, làm thế nào để một
khách hàng có thể thực hiện các công việc phục vụ cho việc du lịch thuận lợi nhanh chóng
thì đang là một vấn đề đặt ra. Để thực hiện một chuyến du lịch, khách hàng cần phải quan
tâm đến việc đặt phòng khách sạn, đặt vé máy bay ..v..v. Trước đây khi công nghệ
Internet chưa phát triển mạnh mẽ, các công việc như thế đòi hỏi khách hàng tốn rất nhiều
công sức và thời gian để có thể thực hiện được khâu chuẩn bị, nhưng giờ đây với sự phát


                                            49
triển của Internet cùng công nghệ Web Service, điều đó đã trở nên dễ dàng hơn rất nhiều.
Như chúng ta đã đề cập như trên, mỗi một công việc như tìm kiếm khách sạn, tìm kiếm vé
máy bay đã có các Web Service chuyên biệt được cung cấp ra bởi các nhà cung cấp dịch
vụ Web, mỗi một Web Service phục vụ cho việc tìm kiếm khách sạn, tìm kiếm máy bay
đó có thể coi là một Web Service Composition phục vụ cho Web Service Travel-Agent.
Nhưng việc lựa chọn các dịch vụ Web nào tối ưu nhất thì đó chính là một khía cạnh của
chất lượng dịch vụ(QoS cho Web Service), ở đây chúng tôi sẽ đưa ra một phương pháp
đơn giản để kiếm chứng ràng buộc thời gian đáp ứng của các Web Service Composition
nhằm kiểm tra mất bao lâu để một Web Service Composition thực hiện một yêu cầu công
việc và thời gian để thực hiện đó có đáp ứng được với tiêu chuẩn đặt ra hay không.

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

5.3.2.1.Mục tiêu bài toán

     Mục tiêu bài toán nhằm giải quyết vấn đề đo lường thời gian đáp ứng của các Web
Services sử dụng Service Proxy. Ở đây chúng ta đã có 2 Web Services đó là tìm kiếm
khách sạn dựa trên tên của thành phố đến (SearchHotel Service) và tìm kiếm chuyến bay
dựa trên tên của thành phố khởi hành và tên của thành phố đến (SearchFlight Service).
Chúng tôi sẽ xây dựng Service Proxy để triệu gọi đến 2 Web Services để lấy kết quả trả
về đồng thời đo lường thời gian đáp ứng của 2 Web Service đó. Sử dụng kết quả đáp ứng
thời gian của 2 Web Services để thực hiện kiểm chứng ràng buộc dựa trên các đặc tả bằng
biểu đồ UML Timing Diagram.

5.3.2.2.Yêu cầu bài toán

Bài toán cần phải đáp ứng được yêu cầu sau:

    Kiến trúc của chương trình phải đảm bảo là kiến trúc phân tán, thể hiện được các
      đặc điểm nổi bật của kiến trúc hướng dịch vụ.




                                           50
    Kết quả trả về của bài toán phải bao gồm đầy đủ kết quả của tìm kiếm 2 dịch vụ
         SearchHotel và SearchFlight đồng thời phải chứa cả thời gian đáp ứng khi triệu gọi
         2 Web Services đó.

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

     Một điểm chú ý khi ta sử dụng công nghệ Web Service đó là một Web Service
Composition lại có thể là một Web Service Composite của các Web Service Composition
khác, điều đó thể hiện được tính phân tán của công nghệ Web Service. Tuy nhiên ở đây
chúng ta chỉ quan tâm đến việc đo lường thời gian đáp ứng của các Web Service
Composition bằng một Service Proxy được đặt ở phía client.

     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.

     Việc trao đổi dữ liệu giữa các Web Service được sử dụng giao thức SOAP và các
thông điệp SOAP được vận chuyển thông qua giao thức HTTP. Các Web Service có thể
được triển khai bằng các ngôn ngữ lập trình thông thường như Java, C#, .NET v..v, có thể
được cài đặt trên các nền hệ điều hành khác nhau như Linux, Windows.

Ta có mô hình tổng quan của bài toán có thể được minh hoạ như hình dưới đây




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



                                                 51
     Trong mô hình trên, Client có thể là một Website, cũng có thể là một chương trình
giao diện người dùng, cũng có thể là một chương trình thể hiện dưới dạng console để triệu
gọi Service Proxy. Trên Service Proxy có chứa các đoạn code để đo lường thời gian đáp
ứng mỗi khi một Service Composition được triệu gọi, ta có thể thấy thông qua minh hoạ
bằng chiếc đồng hồ đặt trên hình vẽ của Service Proxy như hình trên.

     Trong bài toán của chúng ta sẽ gồm các đối tượng Client: Trong đối tượng Client sẽ
có các thành phần để gọi tới Service Proxy. Ở đây ta có 2 Web Services, tương đương
trong Service Proxy cũng phải chứa 2 lớp để gọi tới 2 Service đó. Hai lớp này có thể gọi
tới hai Web Services một cách song song hoặc cũng có thể gọi tuần tự, tuỳ thuộc vào mục
tiêu của người viết chương trình. Và đương nhiên trong Service Proxy chứa 2 lớp cho 2
Web Services nên trong code phía Client cũng phải chứa 2 lớp để gọi tới 2 lớp tương ứng
trong đối tượng Proxy đó. Mô tả chi tiết về cách cài đặt chương trình sẽ được thể hiện
trong “Chương 6 - Thực Nghiệm” của khoá luận này.

     Sau khi đã phân tích thiết kế của chương trình, ta thấy ở đây có hai Web Services, áp
dụng vào biểu đồ Timing Diagram để thể hiện ràng buộc thời gian đáp ứng của các Web
Services. Tương ứng với một Web Service ta có một đường Lifeline minh hoạ cho các
trạng thái thành phần của Web Service đó.

     Ta có minh hoạ đường Lifeline cho dịch vụ tìm kiếm khách sạn thể hiện trong biểu
đồ Timing Diagram như hình dưới đây:




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




                                               52
Tương tự ta cũng có hình minh hoạ đường Lifeline cho dịch vụ tìm kiếm chuyến bay




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

     Qua hình minh hoạ trên ta thấy, mỗi một đường Lifeline sẽ minh hoạ cho một Web
Service. Ở đây, mỗi một Web Services chính là một thành phần riêng biệt, trong mỗi
thành phần đó có chứa các trạng thái, các trạng thái có thể là chờ đợi, truy cập database,
trả lại kết quả v..v. Mỗi một Web Service được thực hiện trong một thời gian t nào đó, giả
sử thời gian thực hiện cho SearchFlight Service là t1, thời gian thực hiện cho
SearchHotelService là t2, và hai Web Service này được gọi tuần tự. Ta có thời gian đưa ra
để đáp ứng tiêu chuẩn QoS về thời gian cho công việc gọi hai Web Services này là t.

     Nếu : t1 + t2 ≤ t thì thời gian thực hiện triệu gọi 2 Web Service đó đáp ứng được
tiêu chuẩn QoS đưa ra.

     Ngược lại nếu t1 + t2 > t thì không thoả mãn tiêu chuẩn QoS.

     Đó chính là ý tưởng và là mục tiêu cần đạt được của khoá luận.




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

     Chương 6 xây dựng một ứng dụng cụ thể cho bài toán Travel-Agent để kiểm tra
ràng buộc thời gian đáp ứng của các Web Service Composition, và dùng kết quả đạt được
bằng thực nghiệm để mô hình hoá ràng buộc thời gian trên biểu đồ UML Timing
Diagram.

6.1. Phạm vi ứng dụng

   Trong phạm vi khoá luận này, chúng tôi chỉ chọn một ứng dụng nhỏ làm ví dụ minh
hoạ kiểm chứng ràng buộc thời gian đáp ứng của trong Web Service Composition. Ứng
dụng được chia thành các nhiệm vụ chính như sau:

    Xây dựng hai Web Services, một Web Service tìm kiếm khách sạn dựa vào tên của
      thành phố đích đến – Tên Web Service này là SearchHotel Service, một Web
      Service tìm kiếm các chuyến bay dựa trên tên của thành phố xuất phát và tên của
      thành phố đích đến. Cả 2 Web Service này đều được phát triển bằng ngôn ngữ lập
      trình Java, quá trình phát triển hai Web Service hoàn toàn thủ công, không dùng
      bất cứ một công cụ hỗ trợ nào. Cơ sở dữ liệu được dùng cho hai Web Service được
      triển khai trên hệ quản trị cơ sở dữ liệu MySQL hoàn toàn miễn phí.

    Xây dựng Service Proxy để triệu gọi tới hai Web Services kia. Trên Service Proxy
      chứa hai phương thức để triệu gọi tới hai Service Composition. Thông thường
      Service Proxy không cần phải được viết ra bởi người lập trình viên mà thường
      được tự sinh từ file WSDL của SearchFlight Service và SearchHotel Service. Tuy
      nhiên về vấn đề bản quyền, chúng tôi đã sử dụng công cụ tự sinh miễn phí trên
      Internet tại trang http://nsoftware.com, ở đây việc tự sinh ra Service Proxy cũng bị
      giới hạn về các chức năng của Service, để Service Proxy có thể thực hiện được
      bằng cách sinh từ website trên bắt buộc cần phải có các thư viện API đi kèm được
      cung cấp bởi nsoftware.com. Vì thế chúng tôi chỉ sử dụng website
      http://nsoftware.com để sinh ra các lớp và phương thức trừu tượng của Service


                                           54
      Proxy, còn quá trình phát triển lõi bên trong để triệu gọi tới các Service
      Composition và đo lường thời gian đáp ứng đều được code thủ công. Service
      Proxy cũng được phát triển trên ngôn ngữ java.

   Chương trình Client để triệu gọi tới Service Proxy là một chương trình giao diện GUI.
Cho phép người dùng chọn lựa tên thành phố đến và tên thành phố xuất phát. Từ đó
chương trình sẽ triệu gọi tới Service Proxy để lấy kết quả trả về bao gồm danh sách các
chuyến bay, danh sách các khách sạn và kết quả thời gian đáp ứng của hai Web Service
Composition.

   Để thể hiện tính độc lập với platform, ở đây chúng tôi có 3 Web Service tuy nhiên do
điều kiện có hạn nên chúng tôi sẽ triển khai tất cả các Web Service này trên môi trường
localhost tại 2 Web Server khác nhau.

    Service SearchHotel được triển khai bằng thư viện Apache-Soap, cài đặt trên môi
      trường J2EE – Java 2 Platform, Enterprise Edition. Web Server thực hiện trên cổng
      2417 Ở đây chúng tôi sử dụng thư viện Soap đính kèm vào trong môi trường J2EE.
      Trang    Admin     của   SOAP      có    thể   được   truy   cập   qua   URL     :
      http://localhost:2417/soap/admin

    Service SearchFlight được triển khai bằng thư viện Apache-Axis cài đặt trên Web
      Server Apache TomCat tại cổng 8080. Trang Admin của Axis có thể được truy cập
      qua URL : http://localhost:8080/axis/

    Service Proxy được triển khai bằng thư viện Apache-Soap, cài đặt trên Web Server
      Apache TomCat tại cổng 8080. Trang Admin của Soap trên Apache TomCat có thể
      truy cập qua URL : http://localhost:8080/soap/admin

   Ta thấy mặc dù có hai web server, nhưng chúng tôi đã bố trí tất cả các Service đều
được thực thi trên các nền Platform khác nhau. Service SearchFlight và Service Proxy
cùng được triển khai trên Apache Tomcat tại cổng 8080 nhưng chúng lại dùng 2 thư viện
API khác nhau để triển khai đó là Axis và Apache Soap. Còn Service SearchHotel thì



                                          55
được triển khai hoàn toàn trên một Web Server khác và sử dụng công nghệ khác là J2EE.
Qua đó để thấy được tính độc lập với nền của công nghệ Web Service.

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

Ta có mô hình thiết kế tổng thể của ứng dụng như sau:




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

     Người sử dụng tại Client sẽ lựa chọn thành phố xuất phát và thành phố đích đến. Tại
đây Soap engine làm nhiệm vụ tạo ra các thông điệp SOAP request gửi đến Service
Proxy. Tại Service Proxy sẽ phân ra làm 2 luồng SOAP request tiếp tục gửi đến hai Web
Service SearchFlight và SearchHotel. Sau khi gửi đi các thông điệp Soap request, Service
Proxy bắt đầu bật đồng hồ đếm thời gian để đo thời gian đáp ứng của hai Web Service
thành phần. Tại hai Web Service thành phần tiếp nhận các Soap request đó xử lý và trả lại
các thông điệp Soap response cho Service Proxy. Sau khi nhận được thông điệp Soap
response của các Service Composition, Service Proxy dừng đồng hồ đo thời gian. Đóng
gói kết quả đo lường thời gian đáp ứng vào cùng thông điệp Soap response và gửi trả lại
kết quả cho Client bao gồm kết quả tìm kiếm chuyến bay, tìm kiếm khách sạn và kèm
theo thời gian đáp ứng của từng dịch vụ.




                                               56
     Do ứng dụng khá đơn giản nên chúng tôi không sử dụng các biểu đồ phân rã chức
năng, biểu đồ lớp, biểu đồ tương tác…. Mà chỉ sử dụng biểu đồ tuần tự để thấy được thứ
tự làm việc của các thành phần trong hệ thống.




                                 Hình 27: Biểu đồ tuần tự của hệ thống

     Dựa vào biểu đồ tuần tự ta thấy tại chương trình Client sẽ có các đối tượng
ApplicationGUI, CallService1, CallService2. Đối tượng ServiceProxy đại diện cho Web
Service Proxy và hai đối tượng còn lại đại diện cho các Web Service Composition. Khi
người sử dụng nhập thông tin và click submit, dữ liệu sẽ được gửi đi lần lượt bằng 2 đối
tượng CallService1, CallService2. Trong ví dụ này chúng tôi gọi CallService1 trước, sau
khi dữ liệu được trả về cho CallService1 sẽ tiếp tục gọi đến CallService2. Sau khi có tất
cả các dữ liệu cần thiết trả về mới trả lại kết quả cho User.




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

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

   Bài toán được xây dựng dựa trên ngôn ngữ Java, để có thể thực hiện việc xây dựng và
triển khai bài toán chúng ta cần phải cài một số chương trình sau[8][12]:

    Cài đặt môi trường chạy cho Java: Cài đặt JDK -1.5 và thiết lập biến môi trường
       JAVA_HOME là : C:\Program Files\Java\jdk1.5.0_07.

    Cài đặt môi trường Web Server. Ở đây chúng ta sử dụng 2 Web Server. Trước tiên
       cài đặt bộ công cụ J2EE – Java 2 platform, Enterprise Edition. Bộ công cụ J2EE
       sau khi cài đặt sẽ có đường dẫn C:\Sun. Sau đó cài Web Server Apache Tomcat
       theo đường dẫn C:\ Webservice\tomcat.

    Cài đặt hệ quản trị cơ sở dữ liệu MySQL và thiết lập biến môi trường cho bộ kết
       nối MySQL connector. Ta cần phải thiết lập biến môi trường CLASSPATH trỏ đến
       thư mục chứa file mysql-connector-java-5.0.5.jar.

    Cài đặt Soap engine: ở đây chúng tôi sử dụng Soap engine là Apache Soap được
       cài đặt trên 2 Web Server, một Web Server được triển khai tại cổng 2417, một
       Web Server chạy tại cổng 8080. Soap engine thứ hai là Apache Axis. Lưu ý tất cả
       các Soap Engine đều được mặc định cài đặt trong thư mục C:\Webservice.

   Một điều rất quan trọng khi chúng ta cài đặt các Soap engine cần phải chú ý ở đây đó
là để các Soap engine này có thể thực hiện được cần phải chứa danh sách cách thư viện
cần thiết đó là thư viện Java Mail với file mail.jar, thư viện activation.jar, thư viện xerces
với 2 file xercesImpl.jar và xml-apis.jar – được sử dụng cho bộ phân tích cú pháp XML.
Sau khi có đầy đủ tất cả các thư viện trên chúng ta chép 2 file mail.jar và activation.jar
vào thư mục tomcat/common/lib. Sau đó chúng ta cần phải cập nhật lại biến môi trường
CLASSPATH, đây là bước rất quan trọng và không cho phép được bỏ qua. Dưới đây là
cấu hình CLASSPATH kèm theo.




                                             58
WEBSERVICE_HOME=C:\WebService

JAVA_HOME=: C:\Program Files\Java\jdk1.5.0_07

CATALINA_HOME=%WEBSERVICE_HOME%\tomcat

CATALINA_LIB=%CATALINA_HOME%\common\lib

XERCES_HOME=%WEBSERVICE_HOME%\xerces

SOAP_HOME=%WEBSERVICE_HOME%\soap

CLASSPATH=%CLASSPATH%;%SOAP_HOME%\lib\soap.jar

CLASSPATH=.;%CATALINA_LIB%\mail.jar;%CATALINA_LIB%\activation.jar;

CLASSPATH=%CLASSPATH%;%XERCES_HOME%\xercesImpl.jar;

%XERCES_HOME%\xml-apis.jar
PATH=%PATH%;%CATALINA_HOME%\bin;%JAVA_HOME%\bin

     Sau khi thiết lập biến môi trường cho Apache SOAP chúng ta phải tiến hành thiết
lập các biến môi trường cho Apache Axis.. Nếu quá trình cài đặt Apache Soap và Apache
Axis thành công thì màn hình máy tính sẽ hiển thị như sau khi ta gọi đến trang admin của
các Soap engine này.




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



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

Nếu cài đặt Apache Axis thành công ta có thể nhìn thấy giao diện trang Admin của
Apache Axis như hình dưới đây:




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



                                                 60
       Sau khi các Soap Engine đã sẵn sàng phục vụ, chúng ta hoàn toàn có thể triển khai
các Web Service để thực hiện mục tiêu bài toán.

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

       Sau khi đã cài đặt thành công các Soap engine, chúng tôi sẽ tiến hành cài đặt các
Service Composition trên các Web Server vừa được cài đặt lên.

Cài đặt Service SearchHotel

Trước tiên tiến hành cài đặt Web Service SearchHotel chạy trên môi trường J2EE tại cổng
2417.

Tệp cài đặt cho Web Service SearchHotel được chúng tôi viết trong file
SearchHotelService.java, trong file này có chứa một phương thức SearchHotel với đối số
truyền vào là một String và kết quả trả về cũng là một String. Khi Service Proxy gọi tới
SearchHotel Service, thì xâu chứa tên của thành phố đích đến được đóng gói vào thông
điệp SOAP, tại SearchHotel Service, sử dụng xâu chứa tên thành phố đích đến làm đối số
truyền vào, thực hiện thao tác tìm kiếm trong database xem có kết quả khách sạn nào
tương ứng với thành phố đích đến đó hay không.




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

       Sau đó chúng tôi tiến hành biên dịch file SearchHotelService.java thành file
HTService.SearchHotelService.class, copy file này và đặt vào trong thư mục Wapp của
J2EE     theo    đường       dẫn     sau      “C:\Sun\SDK\domains\domain1\applications\j2ee-
modulees\soap\WEB-INF\classes”.




                                                   61
       Tiếp theo để triển khai dịch vụ này trên Web Server, ta cần phải viết một tệp
deploy.wsdl để triển khai tệp đó lên web server, nội dung của file deploy.wsdl được thể
hiện qua Hình 32:




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

Nhìn vào nội dung của tệp deploy.wsdl ta thấy một số các đặc điểm sau:

    id = “urn:HTService” : Đây chính là tên của Web Service mà ta triển khai, sẽ
        được dùng để gọi trong code của Service Proxy.

    methods=”SearchHotel” : Đây chính là phương thức mà Web Service sẽ sử dụng
        để thực hiện các thao tác tính toán như tìm kiếm database, trả về kết quả.

    dd:java class=”HTService.SearchHotelService” : Đây là đường dẫn để web
        server có thể tìm kiếm được file SearchHotelService.class để thực thi công việc.

   Sau đó chúng tôi copy file deploy.wsdl này vào thư mục C:\Webservice. Mở một
console, chuyển thư mục làm việc tới thư mục C:\WebService và gõ lệnh sau để triển khai
dịch       vụ       lên      Web         Server         :       C:\Webservice    >     java
org.apache.soap.Server.ServiceManagerClient http://localhost:2417/soap/servlet/rpcrouter
deploy deploy.xml. Lệnh này nhận ba tham số truyền vào đó là URL đến máy chủ SOAP,
lệnh deploy và tập tin hợp lệ để triển khai dịch vụ trên máy chủ SOAP. Nếu quá trình

                                               62
triển khai thành công thì sẽ không có thông báo lỗi nào xuất hiện, sau đó ta có thể dùng
lệnh      C:\webservice        >       java        org.apache.soap.Server.ServiceManagerClient
http://localhost:2417/soap/servlet/rcprouter list để liệt kê danh sách các service đã được
triển khai trên máy chủ SOAP. Nếu ta thấy danh sách dịch vụ có xuất hiện tên
urn:HTService là quá trình triển khai của ta đã thành công. Ngoài ra nếu muốn gỡ bỏ dịch
vụ SearchHotel Serviece, ta hoàn toàn có thể dùng lệnh để gỡ bỏ dịch vụ bằng lệnh
C:\Webservice           >          java            org.apache.soap.Server.ServiceManagerClient
http://localhost:8080/soap/servlet/rpcrouter undeploy urn:HTService.

Ngoài việc sử dụng công cụ dòng lệnh để triển khai, gỡ bỏ, liệt kê danh sách các dịch vụ,
chúng ta còn có thể sử dụng công cụ triển khai trực quan được truy cập thông qua địa chỉ

http://localhost:8080/soap/admin




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

       Nhìn vào hình minh họa trên ta có thể thấy được danh sách các dịch vụ đã được triển
khai trên máy chủ SOAP của chúng ta. Dễ thấy dịch vụ SearchHotel Service đã được triển
khai, thể hiện của SearchHotel Service chính là “urn:HTService”.

                                                   63
Cài đặt Service SearchFlight

        SearchHotel Service đã được cài đặt trên nền J2EE, với máy chủ Soap engine chạy
trên cổng 2417 sử dụng thư viện API Apache Soap. Giờ chúng ta sẽ tiến hành cài đặt dịch
vụ SearchFlight trên Web Server Apache TomCat, tại cổng 8080, sử dụng thư viện API
Apache Axis. Đây là một thư viện hoàn toàn khác so với Apache Soap, điều đó càng minh
họa rõ hơn cho công nghệ Web Service là một công nghệ không phụ thuộc vào môi
trường cài đặt, ta hoàn toàn có thể sử dụng các công nghệ khác nhau nhưng vẫn làm cho
các Service giao tiếp được với nhau.

        Tương tự như dịch vụ SearchHotel, dịch vụ SearchFlight cũng được viết trong một
file       SearchFlightService.java.     Và       file      này         được   dịch   ra   file
SearchFlightService.SearchFlightService.class. Sau đó ta cần phải copy file này vào thư
mục C:\Webservice\tomcat\webapps\axis\WEB-INF\classes. Và để triển khai dịch vụ này,
chúng ta cần phải viết một file deploy.wsdd để triển khai dịch vụ. Nội dung của tệp
deploy.wsdd được minh họa trong hình dưới đây :




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

Trong file deploy.wsdd trên ta cần lưu ý :

        Thuộc tính service name = “SearchFlightService” : đây chính là tên của Service
          được dùng để triệu gọi, nó tương đương với thuộc tính id=”urn:HTService” trong
          file deploy.wsdl dùng để triển khai dịch vụ trên Apache Soap.




                                                64
    Thuộc tính parameter = “” value=”SearchFlightService.SearchFlightService ” :
      trỏ đến vị trí của file SearchFlightService.class để máy chủ Axis tìm kiếm và sử
      dụng.       Nó         tương          đương           với         thuộc           tính   dd:java
      class=”HTService.SearchHotelService” trên Apache Soap.

   Sau đó chúng tôi copy file deploy.wsdd này vào thư mục C:\Webservice. Mở một
console, chuyển thư mục làm việc tới thư mục C:\WebService và gõ lệnh sau để triển khai
dịch vụ lên Web Server: C:\Webservice > java org.apache.axis.Client.AdminClient
deploy.wsdd để triển khai dịch vụ. Thực chất lệnh này sử dụng thư viện trong axis nhận
tham số truyền vào là file deploy.wsdd để triển khai dịch vụ. Khi chạy lệnh thành công sẽ
có thông báo “Processing file deploy.wsdd”. Nếu muốn hủy bỏ dịch vụ, chúng ta chỉ cần
đổi tên file deploy.wsdd thành undeploy.wsdd và sửa nội dung 2 thẻ đóng mở
<deployment> trong file undeploy.wsdd thành <undeployment> và thực hiện lệnh java
org.apache.axis.Client.AdminClient undeploy.wsdd để hủy bỏ dịch vụ. Sau khi triển khai
thành công Web Service SearchFlight đã sẵn sàng phục vụ.

   Ta có thể nhìn thấy danh sách các dịch vụ đã được triển khai trong trang quản trị của
Apache Axis như hình dưới đây:




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




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

     Đây là nội dung quan trọng và là vấn đề chủ chốt để giải quyết bài toán đặt ra trong
khóa luận này. Chúng tôi sẽ triển khai Service Proxy trên web server Apache-Tomcat tại
cổng 8080 sử dụng Soap engine là Apache Soap.

     Thông thường thì Service Proxy thường không phải code cứng bởi người lập trình,
mà nó thường được tự sinh ra từ file WSDL của các Web Services mà Service Proxy triệu
gọi đến. Tuy nhiên, vì vấn đề bản quyền nên ở đây chúng tôi chỉ tận dụng được một tính
năng rất nhỏ trong việc tự sinh ra Service Proxy từ file WSDL, ở đây chỉ sinh ra tên lớp
và tên phương thức sao cho Service Proxy có thể triệu gọi tới các Service Composition.

     File mã nguồn Service Proxy được viết trong một file Proxy.java, trong file này
chúng tôi định nghĩa ra hai lớp, một lớp dùng để triệu gọi các Web Service Composition,
và một lớp khác dùng để lấy kết quả trả về khi triệu gọi tuần tự hai Web Service
Composition đó. Tương ứng với hai Web Services SearchHotel và SearchFlight, lần lượt
trong mỗi lớp chúng ta đều có 2 phương thức tương ứng để triệu gọi tới hai Web Services
đó. Dưới đây chúng tôi sẽ trình bày phương pháp tạo ra Service Proxy từ file WSDL của
dịch vụ SearchFlightService, với dịch vụ SearchHotelService cách làm cũng tương tự.

Hình dưới minh họa file WSDL của Web Service SearchFlight:




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



                                                66
        Để sinh ra Service Proxy ta chỉ cần copy nội dung file WSDL đưa vào chương trình
tự sinh, ta sẽ có Service Proxy cần thiết để gọi tới các Service Composition. Chúng tôi sử
dụng chương trình tự sinh của web-site http://nsoftware.com , sau khi đưa nội dung file
WSDL vào chương trình tự sinh của website đó, ta có phương thức cần triệu gọi đến
Service Composition là phương thức Search_Flight trong dịch vụ SearchFlight. Phương
thức Search_Flight này cần phải được triệu gọi trong lời gọi dịch vụ được code trong mã
nguồn của Service Proxy. Sau khi đã tự sinh ra các lớp và phương thức trừu tượng cho
Service Proxy, chúng ta cần phải hiệu chỉnh lại Service Proxy để có thể sử dụng trên thư
viện API apache Soap.




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

        Nhìn vào hình trên ta có thể thấy, do Service Proxy chuyển tiếp yêu cầu tới 2 Web
Services phục vụ mục đích thật, cho nên phương thức Flight của Service Proxy cũng phải
có kiểu trả về là một String và nhận đối số truyền vào là một String như mục đích yêu cầu
của Service Proxy chúng tôi đã trình bày trong phần tìm hiểu bài toán. Dễ thấy trong hình
trên,     Service   Proxy     gọi     tới    dịch      vụ     SearchFlight          tại   địa   chỉ   “
http://localhost:8080/axis/servlet/AxisServlet “ bằng việc khởi tạo ra một đối tượng url.



                                                 67
Và gọi tới phương thức Search_Flight của dịch vụ SearchFlight bằng lời gọi
call.setMethodname(“SearchFlight”).

     Mục tiêu bài toán của chúng ta đó chính là xây dựng Service Proxy để kiểm tra ràng
buộc thời gian đáp ứng của các Web Service Composition, cho nên không thể thiếu được
phần đo lường thời gian trong code Service Proxy. Một phương pháp đơn giản để đo
lường thời giap đáp ứng các Web Service Composition đó là ta chỉ cần sử dụng một đồng
hồ đếm thời gian trong khoảng thời gian thực hiện lời gọi dịch vụ.

Hình dưới đây minh họa phương pháp đo lường thời gian đáp ứng:




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

     Ta có thể thấy lời gọi đến các Service Composition được thực hiện qua phương thức

Response resp = call.invoke(url,””);

   Ý tưởng thuật toán đo lường thời gian đáp ứng trong Web Service Composition được
mô tả như sau:

    Trước khi thực hiện lời gọi tới các Services thành phần, ta bật đồng hồ đếm thời
      gian thông qua phương thức timer.start();

    Sau khi gọi phương thức và lấy kết quả trả về ta dừng đồng hồ đếm thời gian thông
      qua lời gọi phương thức timer.stop();

    Sau khi ta có thời gian bắt đầu, thời gian kết thúc, ta hoàn toàn có thể tính ra được
      thời gian đáp ứng là bao nhiêu thông qua phương thức getDifference() =
      timer.stop() – timer.start();




                                               68
      Như vậy với các Web Services khác ta đều có phương pháp đo lường thời gian
tương tự như đo lường thời gian áp dụng với SearchFlight Service.

      Việc đo lường thời gian đáp ứng đối với SearchHotel Service cũng được thực hiện
với cách tương tự như áp dụng với dịch vụ SearchFlight. Như vậy chúng ta đã có đầy đủ
một Service Proxy để đo lường thời gian đáp ứng của hai Web Services SearchHotel
Service và SearchFlight Service.

      Về việc cài đặt Service Proxy được chúng tôi viết trong 2 file. File
ServiceProxy.java chứa 2 lớp, một lớp Service chứa hai phương thức gọi dịch vụ tới hai
Web Services thành phần, một lớp ServiceProxy chứa hai phương thức để gọi lần lượt tới
hai phương thức trong lớp Service. File Timer.java là file chuyên biệt dùng để đo lường
thời gian đáp ứng của các Web Services. Trong code của file ServiceProxy chúng ta phải
import file Timer.class để có thể thực hiện việc đo thời gian đáp ứng. Chúng tôi biên dịch
hai File này ra thành 3 lớp, đó là lớp mytimer.Timer.class, test.ServiceProxy.class,
test.Service.Class,     copy            3         file       này          vào         thư     mục
C:\Webservice\tomcat\webapps\soap\WEB-INF\classes. Service Proxy được cài đặt sử
dụng Soap engine Apache Soap nên quá trình cài đặt hoàn toàn tương tự như khi chúng ta
cài đặt dịch vụ SearchHotel. Điểm khác biệt duy nhất ở đây đó là địa chỉ của
ServiceProxy    lúc   này   sẽ     là       http://localhost:8080/soap/         chứ   không   phải
http://localhost:2417/soap/ như đối với SearchHotel Service.

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

Sau khi đã có tất cả cả Web Services thành phần và Service Proxy, chúng tôi sẽ phát triển
một chương trình client đơn giản để có thể nhìn thấy kết quả đáp ứng thời gian của các
Service Composition. Để lấy kết quả trả về, chúng ta chỉ việc chọn thành phố xuất phát tại
thẻ Source, thành phố đến tại thẻ Destination và sau đó nhấn nút Search để có kết quả trả
về.

Chương trình Client được phát triển minh họa qua Hình 39:



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

     Ta thấy sau khi nhấn nút Search, kết quả của SearchHotel Service sẽ được hiển thị
trong TextField 1, kết quả tìm kiếm máy bay sẽ hiển thị trong TextField 2. Đồng thời
Service Proxy cũng trả về thời gian đáp ứng cho SearchHotel Service là 33ms, thời gian
đáp ứng của SearchFlight Service là 32ms.

     Chương trình của chúng ta đã đo lường được thời gian đáp ứng của các Web Service
Composition, giờ chúng ta sẽ kiểm chứng xem thời gian đáp ứng đó có đáp ứng được tiêu
chuẩn QoS đặt ra về thời gian hay không ?




                                            70
     Giả sử ta đặt ra quy ước về thời gian đáp ứng khi gọi tuần tự cả hai dịch vụ trong
môi trường localhost tối đa mất 60 micro giây. Ta có biểu đồ Timing Diagram cho việc
đặc tả ràng buộc thời gian đáp ứng trong Web Service Compostion như sau:




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




                                                71
     Nhìn vào biểu đồ trên ta thấy, toàn bộ quá trình thực hiện hai Web Service
Composition một cách tuần tự được giới hạn trong vòng 60micro giây, nếu thời gian vượt
quá 60micro giây thì coi như không đáp ứng được yêu cầu QoS về thời gian đặt ra. Các
thao tác tại hai Web Services như tìm kiếm cơ sở dữ liệu, trả lại kết quả trả về đều được
xác định bằng các khoảng thời gian trừu tượng minh họa bằng thời gian t vì ở đây ta
không thể biết chính xác rằng mất bao lâu để thực thi các thao tác đó, ta chỉ có thể ước
lượng được mất bao lâu để một thao tác như vậy có thể hoàn thành. Ở đây chúng ta chỉ
kiểm chứng thời gian đáp ứng của các Web Service Composition cho nên các thao tác
được thực hiện tại Client như nhập thông tin, gọi đến Service Proxy hay Service Proxy trả
lại kết quả cho Client sẽ không liên quan đến các ràng buộc thời gian của chúng ta.

     Ta có mô hình kiểm chứng được minh hoạ như sau:




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

     Với kết quả trả về bởi Service Proxy khi thực hiện quá trình triệu gọi đến hai Web
Services, ta có thời gian thực hiện tìm kiếm kết quả của SearchHotel Service là 33 micro


                                                72
giây, SearchFlight Service là 32 micro giây, do việc gọi 2 dịch vụ này được thực hiện
tuần tự nên tổng thời gian gọi dịch vụ là 65 micro giây. Trong khi đó ràng buộc QoS cho
thời gian đáp ứng của chúng ta đặt ra là tối đa cho phép 2 dịch vụ này gọi trong môi
trường localhost là 60 micro giây. Áp dụng lên mô hình kểm chứng minh hoạ ở hình 41 ta
thấy rằng t1+t2 > t (33ms + 32ms > 60ms) nên ta dẫn đến kết luận là thời gian đáp ứng
của hai Web Service Composition này chưa đáp ứng được tiêu chuẩn đã đề ra.

     Như vậy chúng ta đã xây dựng được nên một Service Proxy để kiểm tra ràng buộc
thời gian đáp ứng trong Web Service Composition, đặc tả ràng buộc thời gian đó trên biểu
đồ UML Timing Diagram. Ta hoàn toàn có thể mở rộng bài toán với một tập hợp rất
nhiều các Web Service Composition khác với phương pháp áp dụng như trên, ở đây mục
tiêu của khóa luận chỉ là kiểm tra xem thời gian đáp ứng đó có tuân thủ thời gian QoS đề
ra hay không. Ta mới kiểm tra một trường hợp, tùy vào từng ngữ cảnh mà ta có thể kết
luận liệu các dịch vụ đó có đáp ứng được với tiêu chuẩn QoS về thời gian không. Tuy
nhiên trong thực nghiệm khi chúng tôi kiểm tra các đáp ứng với nhiều truy vấn chúng tôi
thấy thời gian đáp ứng càng giảm đi đáng kể, và hầu hết các Service Composition đều đáp
ứng được với yêu cầu về ràng buộc thời gian đưa ra. Tuy nhiên để thể hiện đầy đủ thì cần
phải có các phương pháp, điều kiện ngữ cảnh khác nhau mới có thể có kết luận chính xác.
Do điều kiện hạn hẹp nên chúng tôi mới chỉ thể hiện phương pháp bài toán, để chính xác
với thực tế cần phải thể hiện bài toán trên môi trường Internet, nơi mà có rất nhiều yếu tố
ảnh hưởng tới chất lượng đáp ứng của các dịch vụ.




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


     Công nghệ Web Service ngày càng được sử dụng rộng rãi trong việc giải quyết các
bài toán liên quan đến dữ liệu phân tán. Với các ưu điểm của mình, Web Service đã
chứng tỏ được khả năng đáp ứng mạnh mẽ đối với các quy trình nghiệp vụ ngày càng
phức tạp của các tổ chức doanh nghiệp. Sự phát triển của Web Service sẽ dẫn đến nhu cầu
đánh giá chất lượng dịch vụ Web nào tốt nhất cho người sử dụng, để người sử dụng có thể
lựa chọn dịch vụ thích hợp cho mình. Việc đánh giá chất lượng các dịch vụ Web là một
đề tài rất mới mẻ và đang nhận được sự quan tâm sâu sắc của giới chuyên môn.

   Đáp ứng với mục tiêu đánh giá chất lượng phục vụ của các dịch vụ Web, khóa luận đã
đề xuất ra một phương pháp kiểm chứng ràng buộc thời gian đáp ứng trong Web Service
Composition thông qua các ràng buộc QoS về thời gian được đặc tả bằng biểu đồ UML
Timing Diagram. Sau một thời gian nghiên cứu và học hỏi, đến nay chúng tôi đã hoàn
thành khóa luận và thu được các kết quả sau đây:

    Khóa luận đã trình bày một cách tổng quát về mô hình hệ phân tán qua việc tiếp
      cận kiến trúc hướng dịch vụ SOA, đưa ra cái nhìn rõ ràng hơn về công nghệ Web
      Service, cách xây dựng và triển khai các Web Services. Nắm được các công nghệ
      chuẩn được sử dụng cho Web Service như SOAP, WSDL, UDDI, và công nghệ
      dùng để tích hợp các Web Services.

    Dựa trên các kiến thức nền tảng về công nghệ Web Service, khóa luận đã tiếp cận
      đến một hướng nghiên cứu mới đó là tìm hiểu về chất lượng các dịch vụ Web hay
      còn gọi là QoS cho Web Services.

    Khóa luận đã trình bày một dạng biểu đồ UML mới được thêm vào cho UML 2.0
      đó là biểu đồ UML Timing Diagram. Một biểu đồ dùng để đặc tả ràng buộc thời
      gian đáp ứng của các đối tượng trong một quá trình tương tác dưới sự tác động của
      các sự kiện hay thông điệp.



                                           74
    Thông qua ví dụ minh họa trong chương Thực nghiệm, khóa luận đã xây dựng
        thành công Service Proxy, được dùng để đo lường thời gian đáp ứng của các Web
        Services. Từ đó dựa trên các ràng buộc về thời gian được đặc tả bằng biểu đồ
        Timing Diagram để dẫn đến kết luận các Web Services đó có đáp ứng được tiêu
        chuẩn QoS hay không.

   Tuy nhiên do quỹ thời gian nghiên cứu hạn hẹp cũng như điều kiện kĩ thuật bị giới
hạn, khóa luận không tránh khỏi các hạn chế sau:

    Mới chỉ thực hiện việc kiểm chứng đối với các Web Services được triển khai trên
        môi trường localhost. Để gần với thực tế, bài toán cần phải được áp dụng trên môi
        trường Internet, nơi có rất nhiều yếu tố ảnh hưởng đến chất lượng phục vụ của các
        dịch vụ Web.

    Việc kiểm chứng thực hiện ở mức tổng quan đối với một tập hợp các Web
        Services. Chưa kiểm chứng ràng buộc cụ thể đối với từng thao tác trong từng Web
        Service như thao tác truy cập cơ sở dữ liệu, thao tác trả về kết quả v..v

     Trong tương lai chúng tôi sẽ tiếp tục mở rộng đề tài này theo hướng nghiên cứu và
đưa ra các giải pháp khắc phục khi các dịch vụ Web chưa đáp ứng được các tiêu chuẩn
QoS, đồng thời phát triển bài toán để đáp ứng đầy đủ cho các yêu cầu về chất lượng dịch
vụ Web như đáp ứng được tính có sẵn, tính an toàn, tính tin cậy của Web Services. Đó sẽ
là một hướng đi khá cần thiết sau này khi sử dụng công nghệ Web Service ngày càng là
một lựa chọn hoàn hảo cho các doanh nghiệp để thực hiện các nhu cầu nghiệp vụ của
mình.




                                              75
                             TÀI LIỆU THAM KHẢO

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




                                          76

								
To top