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:
28
- 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.
29 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.
30
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
31
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.
32
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
33
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à
34
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
35
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