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

m, 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. 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 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 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). 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]. Minh họa các ràng buộc thời gian trong biểu đồ Timing Diagram 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.  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. 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] 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 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 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.  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. Dưới đây ta có mô hình tích hợp Web Service 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 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: 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. 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 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 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. Bài toán kiểm chứng ràng buộc thời gian đáp ứng của các Web Service Composition 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 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. Mục tiêu và yêu cầu của bài toán 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. 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ụ. 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 đó. 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 Minh hoạ mô hình tổng quan bài toán Travel-Agent 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: Minh hoạ đường Lifeline cho SearchHotel Service Tương tự ta cũng có hình minh hoạ đường Lifeline cho dịch vụ tìm kiếm chuyến bay 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.  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. 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 ở đâ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 để sinh ra các lớp và phương thức trừu tượng của Service 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 : 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 : 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 : 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ì đượ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. Thiết kế ứng dụng Ta có mô hình thiết kế tổng thể của ứng dụng như sau: 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ụ. 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. 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. Cài đặt, xây dựng và triển khai ứng dụng 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. WEBSERVICE_HOME=C:\WebServiceJAVA_HOME=: C:\Program Files\Java\jdk1.5.0_07 CATALINA_HOME=%WEBSERVICE_HOME%\tomcatCATALINA_LIB=%CATALINA_HOME%\common\libXERCES_HOME=%WEBSERVICE_HOME%\xercesSOAP_HOME=%WEBSERVICE_HOME%\soapCLASSPATH=%CLASSPATH%;%SOAP_HOME%\lib\soap.jarCLASSPATH=.;%CATALINA_LIB%\mail.jar;%CATALINA_LIB%\activation.jar;CLASSPATH=%CLASSPATH%;%XERCES_HOME%\xercesImpl.jar;%XERCES_HOME%\xml-apis.jarPATH=%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. Minh họa giao diện Admin của apache soap trên Web Server tại cổng 2417 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: Minh họa trang Admin của Apache Axis trên Web Server tại cổng 8080 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. 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. 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”. 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: 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 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 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 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 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ỉ 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”. 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 : 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. 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ở trong file undeploy.wsdd thành 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: Các dịch vụ được liệt kê trên trang quản trị của Axis 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: Nội dung file WSDL của dịch vụ SearchFlightService Để 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 , 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. 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ỉ “ “ bằng việc khởi tạo ra một đối tượng url. 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: 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(); 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à chứ không phải như đối với SearchHotel Service. 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: 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 ? 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: Biểu đồ Timing Diagram mô tả ràng buộc thời gian của WSComposition 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: 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 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ụ.  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. 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. 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, , April- 2009. [13] Marcus Cobden, Ben Humphrays, Kathryn Macarthur – Timing Diagram Plugin Support for RODIN/UML-B, December – 2007. [14] W3C School – Soap Tutorial , , April - 2009. [15] W3C School – WSDL Tutorial , , April - 2009. [16] W3C School – UDDI Tutorial , , April - 2009. [17] Gerhard Wiehler – Web Service and Service Oriented Architecture, February- 2004.