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].
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.
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
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á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.
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. (adsbygoogle = window.adsbygoogle || []).push({});
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
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 kiếm tại
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 pháp hệ thống đối
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.
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à