Với sự phát triển nhanh phóng và phổ biến của công nghệ Web Service, Chất lượng các dịch vụ Web Service (QoS – Quality of Service) sẽ trở thành một yếu tố quan trọng trong việc đánh giá sự thành công của các nhà cung cấp dịch vụ web. QoS sẽ quyết định đến khả năng sử dụng và tính hữu ích của dịch vụ, cả hai yếu tố này đều ảnh hưởng đến tính phổ biến của một dịch vụ web. Trong phần này, chúng tôi sẽ trình bày một vài yêu cầu khác nhau của QoS cho Web Serivce, ảnh hưởng của hiệu ứng thắt cổ chai đến hiệu năng hoạt động của một Web Service, tiếp cận tới các phương pháp cung cấp chất lượng dịch vụ cho Web Service và một phương pháp đơn giản để đo lường thời gian đáp ứng của Web Services sử dụng Service Proxy[6].
Trong thời đại hiện nay, với sự phát triển mạnh mẽ của thương mại điện tử, một yêu cầu đặt ra là phải làm sao có thể tích hợp liền mạch các quy trình thương mại, các ứng dụng thương mại điện tử và các Web Service thông qua môi trường Internet. Việc đánh giá chất lượng một dịch vụ web là một thách thức lớn, vì môi trường Internet cùng các ứng dụng Web–Base ngày càng phát triển mạnh mẽ, cũng chính vì thế nên các yêu cầu về chất lượng dịch vụ cũng luôn thay đổi và không thể dự đoán theo cách tự nhiên được. Các ứng dụng với các đặc điểm và yêu cầu riêng biệt sẽ cạnh tranh nhau về tài nguyên mạng vốn đã rất hạn chế. Sự thay đổi lưu lượng thông tin trên mạng, tấn công từ chối dịch vụ, ảnh hưởng của cơ sở hạ tầng công nghệ thông tin yếu kém và vấn đề an ninh cho các ứng dụng Web-Base đã tạo ra sự cần thiết của việc đưa ra các chuẩn chất lượng cho các dịch
25
vụ trên Internet. Thông thường, khi không đáp ứng được các yêu cầu QoS là một nguyên nhân then chốt dẫn tới các giao tác có hiệu suất hoạt động rất thấp.
Với các chuẩn như SOAP, UDDI và WSDL đã được thống nhất sử dụng bởi các lĩnh vực sử dụng công nghệ Web Service – bao gồm các dịch vụ tài chính, công nghệ cao, đa phương tiện và giải trí. Tất cả các Web Service đang cần phải được gắn kết với nhau để trở thành chuẩn, QoS sẽ là một yếu tố then chốt để đánh giá sự thành công cũng như sự khác nhau về chất lượng phục vụ của các dịch vụ Web.
3.2. Các yêu cầu về chất lượng dịch vụ cho Web Service
Các yêu cầu về chất lượng dịch vụ cho Web Service phải đáp ứng được các yêu cầu dưới đây[6]
Tính có sẵn : Tính có sẵn thể hiện một khía cạnh chất lượng của dịch vụ, tính có sẵn trình bày dịch vụ có sẵn để dùng tại một thời điểm cụ thể hay không. Tính có sẵn mô tả xác suất mà dịch vụ sẵn sàng phục vụ. Trong tính có sẵn, một giá trị thời gian được dùng để mô tả liệu một dịch vụ có sẵn sàng để phục vụ hay không. Giá trị lớn hơn chỉ ra rằng dịch vụ luôn sẵn sàng để sử dụng trong khi giá trị nhỏ hơn chỉ ra không thể dự đoán được liệu dịch vụ có sẵn trong khoảng thời gian cụ thể hiện tại hay không. Thông thường, người ta thường sử dụng một đại luợng thời gian để kết hợp với tính có sẵn của một dịch vụ, đại lượng thời gian đó được gọi là TTR (Time to Repair ) - Thời gian phục hồi. TTR mô tả khoảng thời gian được dùng để phục hồi một dịch vụ web nếu có lỗi xảy ra. Thời gian phục hồi lý tưởng và được mong đợi là thời gian phục hồi có giá trị nhỏ.
Tính truy cập được : Tính truy cập được thể hiện khía cạnh chất lượng dịch vụ qua mức độ, khả năng phục vụ các yêu cầu Web Service. Nó diễn tả khả năng ước lượng bao gồm tốc độ thành công hoặc sự thay đổi thành công của một dịch vụ cụ thể trong một thời điểm. Tính truy cập được còn được thể hiện thông qua tính có sẵn của dịch vụ Web. Một Web Service có tính truy cập cao khi hệ thống triển khai
26
Web Service đó có độ mềm dẻo cao. Độ mềm dẻo tham chiếu tới khả năng phục vụ các yêu cầu một cách nhất quán mặc dù có thể có nhiều yêu cầu khác nhau cùng tồn tại trong một tập hợp các yêu cầu.
Tính toàn vẹn : Tính toàn vẹn thể hiện chất lượng dịch vụ ở cách thức mà Web Service đảm bảo sự đúng đắn chính xác trong các tương tác theo từng khía cạnh cụ thể của tài nguyên. Sự thực thi đúng đắn của các giao tác Web Service sẽ cung cấp tính đúng đắn trong các tuơng tác. Một giao tác sẽ tham chiếu tới trình tự làm việc của các thao tác được xử lý như một đơn vị công việc độc lập. Tất cả các hoạt động được hoàn thành để tạo sự thành công cho một giao tác. Khi một giao tác không được thực hiện thành công, tất cả các thay đổi sẽ được phục hồi lại trạng thái ban đầu.
Khả năng hoạt động : Khả năng hoạt động thể hiện chất lượng dịch vụ ở khía cạnh đo lường giới hạn của thông lượng và độ trễ. Giá trị thông lượng cao hơn và độ trễ thấp thể hiện một Web Service hoạt động tốt. Thông lượng trình bày số lượng yêu cầu Web Service phục vụ tại một đơn vị thời gian định kì. Đỗ trễ là thời gian xoay vòng giữa việc gửi yêu cầu và nhận các đáp ứng.
Tính tin cậy : Tính tin cậy thể hiện khả năng đảm bảo dịch vụ và chất lượng dịch vụ. Tính tin cậy được tính qua số lượng lỗi trên một tháng hay một năm. Theo hướng tiếp cận khác tính tin cậy tham chiếu đến việc phân phát đúng đắn và đảm bảo các thông điệp sẽ được gửi và nhận bởi các dịch vụ yêu cầu và các dịch vụ đáp ứng.
Tính linh động : Tính linh động thể hiện chất lượng dịch vụ ở khía cạnh Web Service có thể thích ứng với các luật, các quy tắc và khả năng kết hợp chuẩn và thiết lập các dịch vụ mức cao hơn. Web Service sử dụng một số chuẩn như SOAP, UDDI, WSDL. Sự tuân thủ ngặt nghèo các chuẩn để đảm bảo tính đúng đắn của các phiên bản (VD SOAP V1.2) bởi các nhà cung cấp dịch vụ web là một yếu tố cần thiết cho các yêu cầu đúng đắn của Web Service bởi các Web Service request.
27
Tính an toàn : Tính an toàn của Web Service thể hiện ở cơ chế bảo mật, thẩm định quyền, mã hoá thông điệp và cung cấp quyền truy cập. Các nhà cung cấp dịch vụ Web có thể có các hướng tiếp cận khác nhau để đảm bảo độ an toàn cho các dịch vụ web.
3.3. QoS cho các dịch vụ Web
QoS cho các dịch vụ web yêu cầu một vài ngôn ngữ QoS để trả lời một số các câu hỏi sau[2]:
Thời gian trễ mong chờ là bao nhiêu
Khoảng thời gian roundtrip-time chấp nhận được là bao nhiêu
Lập trình viên cần phải có khả năng hiểu được các đặc điểm QoS của Web Service trong quá trình phát triển các ứng dụng gọi dịch vụ web.
Trên lý tưởng, thì QoS cho Web Service phải có khả năng hỗ trợ nhiều kiểu ứng dụng khác nhau với các yêu cầu QoS khác nhau, các quy tắc giao tiếp khác nhau và tài nguyên máy tính khác nhau.
3.4. Điều chỉnh và thiết lập ràng buộc QoS
Dưới đây là các bước mà các Web Service phải thực hiện trong quá trình thiết lập ràng buộc QoS[2][6]:
a) Service Requestor đưa ra yêu cầu thiết lập liên kết ràng buộc bằng cách thiết lập tham chiếu tới một Web Service Interface. Những yêu cầu này chỉ chứa các quy định về QoS.
b) QoS broker tìm kiếm các service cung cấp dịch vụ trong thư mục UDDI.
c) Sau đó, QoS broker thực thi việc thương lượng chất lượng dịch vụ như các mô tả dưới đây:
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.