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

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. 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. 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. Đ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]: 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. QoS broker tìm kiếm các service cung cấp dịch vụ trong thư mục UDDI. Sau đó, QoS broker thực thi việc thương lượng chất lượng dịch vụ như các mô tả dưới đây: Web Service QoS broker so sánh các QoS của các Service Provider với các yê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 đó. 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 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. Đá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. 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. 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 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.  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. 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 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. 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à 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]. 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 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 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”. 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. 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. Các thành phần của biểu đồ Timing Diagram 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). 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 :. 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. Minh họa các trạng thái được thể hiện trong biểu đồ Timing Diagram 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, 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 đó. 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. 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. 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. 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. 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