Tài liệu Nghiên cứu kiểm thử các ứng dụng web và xây dựng công cụ hỗ trợ

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ TẠ VŨ NHÂN NGHIÊN CỨU KIỂM THỬ CÁC ỨNG DỤNG WEB VÀ XÂY DỰNG CÔNG CỤ HỖ TRỢ Ngành: Công Nghệ Thông Tin Chuyên ngành: Công Nghệ Phần Mềm Mã số: 60 48 10 LUẬN VĂN THẠC SĨ NGƯỜI HƯỚNG DẪN KHOA HỌC TS.Trƣơng Ninh Thuận Hà Nội - 2010 LỜI CAM ĐOAN Tôi xin cam đoan đây là công trình nghiên cứu của riêng tôi. Các kết quả nêu trong bản luận văn này là trung thực và chưa từng được ai công bố trong bất cứ công trình nào khác. Hải Phòng, tháng 01 năm 2010 Tạ Vũ Nhân LỜI CẢM ƠN Trước hết tôi xin gửi lời cảm ơn đặc biệt nhất tới TS. Trương Ninh Thuận, Bộ môn Công nghệ phần mềm, Khoa Công nghệ thông tin, Trường Đại học Công nghệ, Đại học Quốc Gia Hà Nội, người đã trực tiếp giảng dạy, định hướng đề tài và đã tận tình hướng dẫn chỉ bảo tôi trong suốt quá trình thực hiện luận văn cao học này. Tôi xin được gửi lời cảm ơn sâu sắc tới các thầy cô giáo trong Khoa Công nghệ thông tin, Trường Đại học Công nghệ, Đại học Quốc Gia Hà Nội đã tận tình giảng dạy và truyền đạt những kiến thức, những kinh nghiệm quý báu trong suốt 2 năm học Cao học. Cuối cùng tôi xin dành một tình cảm biết ơn tới Bố, Mẹ và gia đình, những người đã luôn luôn ở bên cạnh tôi, động viên, chia sẻ cùng tôi trong suốt thời gian học cao học cũng như quá trình thực hiện luận văn cao học. DANH MỤC CÁC TỪ VIẾT TẮT Từ viết tắt Tiếng Anh EP Equivalence Partitioning EV EventValidation VS ViewState BVA Boundary Value Analysis WS Web Services WSDL Web Services Description Language XML eXtensible Markup Language SOAP Simple Object Access Protocol WBT White Box Testing BBT Black Box Testing HTTP Hyper Text Transfer Protocol DFT Data Flow Testing SUT System Under Test DANH MỤC CÁC HÌNH VÀ BẢNG Hình 1: Web Service cho phép truy cập tới các code ứng dụng sử dụng chuẩn công nghệ Internet ............................................................................................... 10 Hình 2: Web Service cung cấp một tầng trừu tượng giữa ứng dụng client và ứng dụng cần gọi tới. .................................................................................................. 11 Hình 3: Mô tả cơ chế hoạt động của Web Service. ............................................ 12 Hình 4: Web Service technology stack .............................................................. 13 Hình 5: TCP/IP network model.......................................................................... 13 Hình 7: Minh họa thiết kế tổng thể ứng dụng ..................................................... 48 Hình 8: Gọi dịch vụ SearchFlightService ........................................................... 49 Hình 9: Gọi dịch vụ SearchHotelService ............................................................ 50 Hình 10 : Ứng dụng sử dụng dữ liệu từ 2 webservice ........................................ 50 Hình 11: Công cụ kiểm thử webservice .............................................................. 51 Hình 12: Kiểm thử tự động với webservice1 SearchHotel ................................. 54 Hình 14 : Kiểm thử tự động tích hợp cả 2 webservices ...................................... 58 MỤC LỤC MỞ ĐẦU ............................................................................................................... 1 Chương 1 - CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM ................................... 4 1.1. Kiểm thử hộp trắng (WBT) ....................................................................... 4 1.2. Kiểm thử hộp đen (BBT) .......................................................................... 6 1.2.1. Kỹ thuật kiểm thử nền tảng đồ thị ...................................................... 6 1.2.2. Kỹ thuật phỏng đoán lỗi ..................................................................... 6 1.2.3. Kỹ thuật phân tích giá trị đường biên ................................................ 6 1.2.4. Kỹ thuật phân vùng tương đương (EP) .............................................. 6 1.2.5. Kỹ thuật kiểm thử so sánh .................................................................. 7 1.2.6. Kỹ thuật kiểm thử chuỗi trực giao ..................................................... 7 1.3. Lựa chọn kiểu kiểm thử cho hệ thống phần mềm ..................................... 8 Chương 2 - WEB SERVICE VÀ CÁC ỨNG DỤNG WEB ............................. 10 2.1. Giới thiệu về web service ........................................................................ 10 2.2. Kiến trúc web service .............................................................................. 12 2.2.1. Mô tả cơ chế hoạt động của web service ......................................... 12 2.2.2. Kiến trúc phân tầng của web service ............................................... 13 2.3. Các ứng dụng web ................................................................................. 15 Chương 3 - KIỂM THỬ CÁC ỨNG DỤNG WEB ............................................ 16 3.1. Một số vấn đề về kiểm thử các trang web .............................................. 16 3.1.1. Giới thiệu .......................................................................................... 16 3.1.2. Gửi một HTTP GET Request và nhận HTTP Response.................. 17 3.1.3. Gửi một HTTP-Request và nhận HTTP-Response có quyền xác thực ..................................................................................................................... 17 3.1.4. Gửi một HTTP GET Request phức tạp và nhận HTTP Response... 18 3.1.5. Nhận một HTTP Response theo từng dòng một .............................. 19 3.1.6. Gửi một HTTP POST Request tới một trang Web ASP .................. 20 3.1.7. Gửi một HTTP POST Request tới một ứng dụng Web ASP.NET .. 21 3.1.8. Xử l‎‎ý đầu vào có chứa các ký tự đặc biệt ........................................ 22 3.1.9. Lập chương trình lấy các giá trị VS và giá trị EV ........................... 24 3.1.10. Xử lý với các điểu khiển Checkbox và RadioButtonList .............. 27 3.2. Kiểm thử web services ............................................................................ 28 3.2.1. Giới thiệu .......................................................................................... 28 3.2.2. Kiểm thử một phương thức Web dùng Proxy .................................. 33 3.2.3. Kiểm thử một phương thức Web dùng Sockets ............................... 35 3.2.4. Kiểm thử một phương thức Web dùng HTTP ................................. 40 3.2.5. Kiểm thử một phương thức Web dùng TCP .................................... 41 3.2.6. Sử dụng bộ nhớ trong để lưu trữ tình huống kiểm thử .................... 43 Chương 4 - XÂY DỰNG CÔNG CỤ HỖ TRỢ KIỂM THỬ ............................ 46 4.1. Các yêu cầu cho việc kiểm thử các ứng dụng sử dụng dịch vụ web ...... 46 4.2. Xây dựng chương trình kiểm thử ứng dụng web sử dụng dịch vụ web.. 47 4.2.1. Phạm vi ứng dụng ............................................................................ 47 4.2.2. Thiết kế ứng dụng ............................................................................ 48 4.2.3. Cài đặt và triển khai ứng dụng ......................................................... 49 TÀI LIỆU THAM KHẢO ................................................................................... 61 1 MỞ ĐẦU Vào khoảng đầu những năm 60 nhu cầu sử dụng các hệ thống phần mềm, giải phóng sức lao động trí tuệ trong các hoạt động kinh doanh, quản lý, giải trí và một số lĩnh vực khoa học xã hội tăng cao. Tuy nhiên các yêu cầu về nghiệp vụ phức tạp trong các hệ thống này dẫn đến các hệ thống phần mềm tương ứng cũng ngày càng trở nên phức tạp, cồng kềnh và khó kiểm soát. Rất nhiều yêu cầu nghiệp vụ đòi hỏi xử lý các vấn đề liên quan đến dữ liệu phân tán, xử lý các thông tin khác nhau do nhiều tổ chức nắm giữ. Đã có nhiều kiến trúc phần mềm được đưa ra nhưng chưa đủ mạnh để đáp ứng được nhu cầu thực tế dẫn đến sự khủng hoảng phần mềm. Trong thời kỳ này, một số dự án phần mềm điển hình đã thất bại như: Hệ thống điều khiển hàng không; Các hệ thống phần mềm phục vụ cho ngành viễn thông, y tế,.... Theo sự phân tích thực tế, các hệ thống phần mềm rơi vào tình trạng này bởi các nguyên nhân khác nhau như[19]:  Khả năng xây dựng phần mềm cho phần cứng không theo kịp sự phát triển của phần cứng.  Khả năng xây dựng phần mềm chưa đáp ứng được nhu cầu thực tế.  Sự cạnh tranh giữa các hệ thống phần mềm về chất lượng và độ tin cậy ngày càng cao.  Nguồn nhân lực không đủ so với nhu cầu thực tế. Ngoài những nguyên nhân cơ bản trên, còn có những nguyên nhân xuất phát từ điểm yếu của hệ thống phầm mềm như:  Không có đơn vị dữ liệu chuẩn để đánh giá hệ thống.  Không xác định chính xác được chi phí xây dựng hệ thống.  Các công cụ hỗ trợ lập kế hoạch và đánh giá tự động không phù hợp.  Kế hoạch phát triển hệ thống không hợp lý tạo sức ép lớn cho người thực hiện  Quá trình quản lý tiến trình thực hiện và sự cố phát sinh không phù hợp. 2  Thiếu khả năng kiểm duyệt thiết kế và quản lý mã lệnh của hệ thống phần mềm. Để khắc phục và hạn chế được những điểm yếu này đòi hỏi dự án phần mềm phải có những quy trình nhất định, giúp chúng ta kiểm soát được tiến trình thực hiện dự án cũng như hiệu quả công việc, kết quả và hướng phát triển của dự án. Sau khi hoàn thành hệ thống phần mềm của dự án và trước khi đưa vào ứng dụng trong thực tế, hệ thống này cần phải được kiểm tra, đánh giá tính chính xác và khả năng đáp ứng yêu cầu thực tế - thuật ngữ “Kiểm thử phần mềm” bắt nguồn từ đây[9,18]. Kiểm thử phần mềm là một phương pháp kiểm soát quá trình thử nghiệm, thực hiện các chức năng trong hệ thống phần mềm theo một tập hợp các điều kiện đặt ra với mục đích tìm ra lỗi của hệ thống. Kết quả của kiểm thử phần mềm là tư liệu chứng minh hệ thống có thể đáp ứng được các yêu cầu đặt ra và ứng dụng được trong thực tế hay không? Kiểm thử phần mềm có thể nói là một phần không thể thiếu trong việc xây dựng và phát triển phần mềm. Nó cho chúng ta biết một phần mềm khi xây dựng và sử dụng có đúng với các yêu cầu mà chúng ta đặt ra hay không. Ở nước ta hiện nay ngành Công nghệ phần mềm đang phát triển mạnh mẽ, việc kiểm thử phần mềm chưa thực sự được quan tâm nhiều hoặc quan tâm nhưng không đúng cách. Việc áp dụng các công cụ tự động cho việc kiểm thử hầu như không có. Trong khi đó theo thống kê chúng ta có thể tốn 40% đến 60% thời gian dành cho việc kiểm thử. Phần lớn các công ty thường không có các tester thực sự, một số công ty có những người chuyên về kiểm thử nhưng thường làm thủ công. Vì vậy việc xây dựng các công cụ hỗ trợ kiểm thử cho chúng ta các lợi ích sau.  Mất ít thời gian hơn.  Chính xác hơn.  Hiệu quả hơn.  Tránh được các lỗi do con người gây ra do kiểm thử thủ công Với thực tế và các lợi ích trên tôi nhận thấy việc nghiên cứu và xây dựng đề tài này là cần thiết, phù hợp với tình hình hiện tại. 3 Cấu trúc của luận văn bao gồm: Chƣơng 1 Đưa ra một số kỹ thuật kiểm thử phần mềm, tìm hiểu một số ưu nhược điểm của mỗi kỹ thuật kiểm thử. Lựa chọn các kỹ thuật kiểm thử phần mềm. Chƣơng 2 Đưa ra cái nhìn tổng quát về công nghệ Web Service, tìm hiểu về các thành phần chuẩn được sử dụng trong công nghệ Web Service, kiến trúc Web Service và quy trình hoạt động của một Web Service. Tìm hiểu về ứng dụng web và xu hướng phát triển các ứng dụng. Chƣơng 3 Đưa ra một số vấn đề và cách giải quyết các vấn đề trong việc viết một công cụ hỗ trợ kiểm thử trong .Net của các ứng dụng web. Nghiên cứu các phương pháp kiểm thử web services. Chƣơng 4 Giới thiệu một bài toán Travel-Agent, mục tiêu, yêu cầu của bài toán. Xây dựng công cụ hỗ trợ kiểm thử cho bài toán. 4 Chƣơng 1 - CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM Hai kỹ thuật thường hay sử dụng để kiểm thử phần mềm:  Kiểm thử hộp trắng (WBT – White Box Testing).  Kiểm thử hộp đen (BBT – Black Box Testing). 1.1. Kiểm thử hộp trắng (WBT) WBT liên quan đến việc xem xét cấu trúc của mã lệnh. Khi biết được cấu trúc của sản phẩm, kiểm thử có thể kiểm soát được một cách chắc chắn bản chất thao tác thực hiện có theo đặc tả kỹ thuật không? Và các thành phần có được thực hiện hợp lý không? WBT có khuynh hướng bao trùm các sự kiện của các chi tiết kỹ thuật trong mã lệnh, bao gồm các kỹ thuật sau[20]:  Phân đoạn sự kiện: mỗi phân đoạn của cấu trúc điều khiển mã lệnh được thi hành theo sự phân đoạn nhỏ nhất  Phân nhánh sự kiện hoặc kiểm thử nút: mỗi nhánh trong mã lệnh được thực hiện theo mỗi hướng có thể thực hiện được theo mức nhỏ nhất.  Sự kiện điều kiện ghép: Khi có nhiều điều kiện, chúng ta không cần kiểm thử từng hướng (từng điều kiện) nhưng phải kết hợp các hướng có thể thực hiện được của điều kiện, cách thường dùng là bảng chân lý (chân trị).  Kiểm thử đường đi cơ bản: Mỗi đường đi độc lập từ đầu đến cuối trong mã lệnh trong trình tự đã được xác định trước.  Kiểm thử theo luồng dữ liệu (DFT - Data Flow Testing): phương pháp này thực hiện kiểm tra các biến đặc trưng trong mỗi tính toán có thể được thực thi, như vậy hạn chế thiết lập các đường trung gian từ đầu đến cuối mã lệnh, … đây là cơ sở trên mỗi mảnh của mã lệnh để chọn và kiểm tra.  Kiểm thử đường đi: kiểm thử đường đi là kiểm thử kiểm thử tất cả các đường đi có thể thực hiện được từ đầu đến cuối mã lệnh được định nghĩa và chuyển đổi. Kiểm thử này rất phức tạp và tốn thời gian. 5  Kiểm thử vòng lặp: bổ sung đơn vị đo lường lớn nhất, đó là chiến lược kiểm thử căn bản trong kiểm thử vòng lặp. Chiến lược này hướng tới việc kiểm thử các vòng lặp đơn, các vòng lặp ràng buộc nhau, và các vòng lặp lồng nhau. Chúng ta làm gì với WBT WBT sử dụng cấu trúc điều khiển của thiết kế các thủ tục để đưa ra các tình huống kiểm thử. Người kiểm thử có thể sử dụng phương thức WBT để đưa ra các tình huống kiểm thử mà:  Đảm bảo tất cả các đường đi độc lập trong module được thực thi ít nhất một lần.  Sử dụng tất cả các quyết định logic trong các giá trị của nó (đúng hoặc sai).  Thực thi được tất cả các vòng lặp.  Sử dụng các cấu trúc dữ liệu của nó để đảm bảo giá trị của chúng. WBT còn được gọi là kiểm thử hộp kính hoặc kiểm thử cấu trúc. Tại sao dùng WBT? Chúng ta dùng WBT vì BBT không chắc đã phát hiện được nhiều lỗ hổng của các nhược điểm trong lập trình như:  Các lỗi logic và các giả định không đúng bị đảo ngược. Lỗi này xuất hiện khi thiết kế và thực thi các hàm chức năng, các điều kiện hoặc các điều khiển.  Luồng logic của chương trình có những khác thường, nghĩa là giả định của chúng ta về luồng của điều khiển và dữ liệu có thể tạo ra các lỗi thiết kế mà nó chỉ có thể phát hiện được khi dùng kiểm thừ đường đi.  Lỗi sinh các giá trị ngẫu nhiên. Kỹ năng yêu cầu Về lý thuyết thì chúng ta cần làm trong WBT là định nghĩa tất cả các đường logic, mở rộng các tình huống kiểm thử để thực thi và đánh giá kết quả trả về… nói chung là các tình huống kiểm thử thực thi được tất cả các vấn đề trong chương trình. 6 Để thực hiện được điều này chúng ta phải nắm được chương trình, đặc tả kỹ thuật và mã lệnh được kiểm thử. Công cụ sử dụng cho WBT Một vài công cụ kiểm thử tự động cung cấp WBT như:  Công cụ dò tìm lỗ hổng bộ nhớ và lỗi run-time.  Công cụ ghi lại chính xác thời gian sử dụng ứng dụng trong khối nhất định của mã lệnh cho mục đích tìm kiếm những đoạn mã không hiệu quả.  Công cụ xác định các vùng của ứng dụng được hoặc không được thực thi. 1.2. Kiểm thử hộp đen (BBT) Với kiểm thử hộp đen, người kiểm thử không cần biết đến cấu trúc hoặc cơ chế làm việc bên trong hộp đen mà cái cần quan tâm là chức năng của nó[16,20]. 1.2.1. Kỹ thuật kiểm thử nền tảng đồ thị Kiểm thử phần mềm bắt đầu bằng việc tạo ra đồ thị của các đối tượng quan trọng và các mối liên quan tới nó, sau đó đưa ra một chuỗi các kiểm thử mà nó bao hàm được đồ thị để thực thi được các đối tượng và các quan hệ của đối tượng để phát hiện lỗi. 1.2.2. Kỹ thuật phỏng đoán lỗi Phỏng đoán lỗi được hình thành qua kinh nghiệm kỹ thuật và dự án. Không có công cụ và công nghệ giành cho kỹ thuật này, nhưng chúng ta có thể dựng các tình huống kiểm thử dựa vào trạng thái làm việc của hàm chức năng. 1.2.3. Kỹ thuật phân tích giá trị đƣờng biên Phân tích giá trị đường biên (BVA - Boundary Value Analysis) là kỹ thuật lựa chọn dữ liệu kiểm thử (kỹ thuật kiểm thử chức năng) với các giá trị đường biên. Giá trị đường biên bao gồm: cực đại, cực tiểu. giá trị sát trong/ sát ngoài đường biên, các giá trị đặc biệt và các giá trị lỗi. Kỹ thuật này thực hiện với kỳ vọng: nếu hệ thống thực hiện đúng với các giá trị đặc biệt này thì sẽ chạy đúng với tất cả các giá trị trong phạm vi của nó[17]. 1.2.4. Kỹ thuật phân vùng tƣơng đƣơng (EP) 7 Kỹ thuật phân vùng tương đương là kỹ thuật kiểm thử hộp đen thực hiện phân chia vùng dữ liệu đầu vào của chương trình trong lớp dữ liệu theo các tình huống kiểm thử có thể phân chia được. Kỹ thuật EP được định nghĩa theo các nguyên tắc sau: 1- Nếu điều kiện vào định rõ phạm vi thì một lớp hợp lệ và hai lớp không hợp lệ được xác định. 2- Nếu điều kiện vào yêu cầu giá trị đặc biệt, thì một lớp tương đối hợp lệ và hai lớp tương đối không hợp lệ được xác định. 3- Nếu điều kiện định rõ thành phần thiết lập, thì một lớp tương đối hợp lệ và một lớp tương đối không hợp lệ được xác định. 4- Nếu điều kiện vào là giá trị logic, thì một lớp hợp lệ và một lớp không hợp lệ được xác định. 1.2.5. Kỹ thuật kiểm thử so sánh Có những tình huống giành cho những phiên bản độc lập của phần mềm ứng dụng, những phiên bản độc lập này là cơ sở của kỹ thuật kiểm thử hộp đen được gọi là kiểm thử so sánh hoặc kiểm thử back – to – back 1.2.6. Kỹ thuật kiểm thử chuỗi trực giao Chiến lược kiểm thử chuỗi trực giao là phương thức thống kê, có hệ thống của kiểm thử tương tác bắt nguồn từ tập hợp nhỏ thích hợp của các tình huống kiểm thử[16,17]. Ƣu điểm:  Người kiểm thử không cần biết về mặt kỹ thuật.  Kỹ thuật kiểm thử này thích hợp nhất cho việc tìm lỗi như một người dùng thực thụ.  Kỹ thuật kiểm thử này hỗ trợ nhận dạng sự gần đúng và trái ngược trong hàm chức năng.  Các tình huống kiểm thử được phác họa ngay sau khi hoàn thành hàm chức năng. 8 Nhƣợc điểm:  Khả năng kiểm thử phụ thuộc vào người lập trình.  Dữ liệu đầu vào cho kiểm thử cần một lượng mẫu lớn.  Rất khó để nhận dạng được tất cả dạng dữ liệu đầu vào cho giới hạn kiểm thử.  Không xác định được đồ thị cho quá trình kiểm thử. 1.3. Lựa chọn kiểu kiểm thử cho hệ thống phần mềm WTB sử dụng kiểm thử cho một sản phẩm phần mềm nên nó không đảm bảo được khả năng thực hiện các chi tiết kỹ thuật (đặc điểm kỹ thuật của phần mềm) một cách trọn vẹn. BBT được sử dụng kiểm thử cho chi tiết kỹ thuật, nhưng nó không đảm bảo khả năng thực hiện được hết tất cả các chi tiết kỹ thuật. Như vậy chúng ta có thể thấy:  BBT là kiểm thử dựa vào đặc tả kỹ thuật, khi tìm thấy lỗi sẽ xác định được cụ thể chi tiết kỹ thuật chưa hoàn chỉnh.  WTB là kiểm thử dựa theo quy trình thực hiện, khi tìm thấy lỗi sẽ xác định được phần lỗi của quy trình. Vậy nên để hoàn thành kiểm thử cho sản phầm phần mềm cần phải áp dụng cả hai loại kiểu thử này. WBT phức tạp hơn BBT vì nó cần đến mã lệnh nguồn của phần mềm trước khi dựng kế hoạch kiểm thử và nếu như phần mềm xây dựng không chính xác theo yêu cầu kỹ thuật thì rất khó xác định dữ liệu đầu vào phù hợp. Vì vậy khi dựng kế hoạch kiểm thử nên bắt đầu từ BBT để xác định được những chi tiết kỹ thuật được dùng, WBT đưa vào thiết kế mức thấp (LLD – Low Level Design) là hoàn thành. LLD sẽ ghi địa chỉ cho tất cả các thuật toán và kiểu mã. Sau đó kiểm tra lại dựa theo BBT và đưa thêm các tình huống kiểm thử theo yêu cầu. Vai trò của giai đoạn giải quyết lỗi kiểm thử rất quan trọng vì lỗi của tình huống kiểm thử có thể có kết quả thay đổi theo từng tình huống khác nhau, trường hợp này yêu cầu phải thực hiện lại BBT và xác định lại đường đi của WBT. Sự lựa chọn ít phức tạp hơn là coi quá trình kiểm thử có kết quả đúng, sau đó dùng kết quả này thực hiện lại bước liền trước đó, có thể sẽ tìm thấy lỗi. 9 10 Chƣơng 2 - WEB SERVICE VÀ CÁC ỨNG DỤNG WEB 2.1. Giới thiệu về web service Web Service là gì: Web Service là một giao diện truy cập mạng đến các ứng dụng chức năng, được xây dựng từ việc sử dụng các công nghệ chuẩn Internet[1,3]. Được minh hoạ trong hình dưới đây. Hình 1: Web Service cho phép truy cập tới các code ứng dụng sử dụng chuẩn công nghệ Internet Thuật ngữ Web Service diễn tả một cách thức tích hợp các ứng dụng trên nền web lại với nhau bằng cách sử dụng các công nghệ XML, SOAP, WSDL, và UDDI trên nền tảng các giao thức Internet với mục tiêu tích hợp ứng dụng và truyền thông điệp. XML được sử dụng để đánh dấu dữ liệu, SOAP được dùng để truyền dữ liệu, WSDL được sử dụng để mô tả các dịch vụ có sẵn và UDDI được sử dụng để liệt kê những dịch vụ nào hiện tại đang có sẵn để có thể sử dụng. Web Service cho phép các tổ chức có thể trao đổi dữ liệu với nhau mà không cần phải có kiến thức hiểu biết về hệ thống thông tin đứng sau Firewall kia [1]. Không giống như mô hình Client/Server truyền thống, chắng hạn như hệ thống Webserver/webpage, Web Service không cung cấp cho người dùng một giao diện đồ họa nào, Web Service đơn thuần chỉ là việc chia sẻ các dữ liệu logic và xử lý các dữ liệu đó thông qua một giao diện chương trình ứng dụng được cài đặt xuyên suốt trên mạng máy tính. Tuy nhiên nguời phát triển Web Service hoàn toàn có thể đưa Web Service vào một giao diện đồ họa người dùng (chẳng hạn như là một trang web hoặc một chương trình thực thi nào đó) để có thể cung cấp thêm các chức năng đặc biệt cho người dùng. Web Service cho phép các ứng dụng khác nhau từ các nguồn khác nhau có thể giao tiếp với các ứng dụng khác mà không đòi hỏi nhiều thời gian viết mã lệnh, do tất cả các quá trình giao tiếp đều tuân theo định dạng XML, cho nên Web Service không bị phụ thuộc vào bất kì hệ điều hành hay ngôn ngữ lập trình nào. Ví dụ, chương trình 11 viết bằng ngôn ngữ Java cũng có thể trao đổi dữ liệu với các chương trình viết bằng Perl, các ứng dụng chạy trên nền Windows cũng có thể trao đổi dữ liệu với các ứng dụng chạy trên nền Linux. Công nghệ Web Service không yêu cầu phải sử dụng trình duyệt và ngôn ngữ HTML, đôi khi Web Service còn được gọi là Application Services. Xét theo một khía cạnh khác, nếu các ứng dụng có thể truy cập thông qua mạng máy tính bằng việc sử dụng các giao thức như HTTP, XML, SMTP hoặc Jabber thì đó chính là Web Service. Như Hình 1 và Hình 2 đã minh họa, Web Service là một Application Interface được đặt giữa Application Code và người sử dụng các code đó. Nó có thể được ví như một tầng trừu tượng, phân tách giữa platform và ngôn ngữ lập trình, nó mô tả cách thức mà các application code được triệu gọi như thế nào. Điều này có nghĩa nếu bất kì một ngôn ngữ lập trình nào hỗ trợ Web Service đều có thể truy cập các ứng dụng chức năng của nhau. Hình 2: Web Service cung cấp một tầng trừu tượng giữa ứng dụng client và ứng dụng cần gọi tới. Ngày này, Web Service có thể được triển khai trên Internet dưới dạng một Website HTML, chính vì thế, các Application Service cần phải có một cơ thế cho việc công bố, quản lý, tìm kiếm và phục hồi nội dung được người sử dụng truy cập thông qua giao thức chuẩn HTTP và định dạng dữ liệu HTML. Các ứng dụng Client ( như Web Browser) cần phải hiểu các chuẩn mà Web Service hỗ trợ để có thể tương tác với các service nhằm thực thi một nhiệm vụ như việc đặt mua sách, gửi thiệp mừng hoặc là đọc bản tin vv... Web Service cung cấp tính trừu tượng cho các giao diện chuẩn, cho nên sẽ không nảy sinh ra bất kì vấn đề gì trong quá trình tương tác khi các service được viết trên java và trình duyệt được viết bằng C++, hoặc các service được triển khai trên Unix trong khi các trình duyệt lại được triển khai trên Windows. Web Service cho phép giao tiếp giữa các platform khác nhau có thể hoạt động cùng nhau theo nguyên tắc tạo ra một platform trung gian có liên quan. 12 Tính tương thích (Inteoperability) là một lợi thế vô cùng mạnh mẽ của Web Service, thông thường, các công nghệ Java và công nghệ của Microsoft rất khó có thể tích hợp được với nhau, nhưng với Web Service thì các Application và Client sử dụng 2 công nghệ trên hoàn toàn có khả năng tương tác với nhau thông qua Web Service[2]. Rất nhiều nhà cung cấp ứng dụng như IBM và Microsoft đều đã hỗ trợ Web Service trong các sản phẩm của họ. IBM hỗ trợ Web Service thông qua gói WebSphere, Tivoli, Lotus và DB2 và Microsoft với.NET cũng đã hỗ trợ Web Service. 2.2. Kiến trúc web service 2.2.1. Mô tả cơ chế hoạt động của web service Hình 3: Mô tả cơ chế hoạt động của Web Service. Cơ chế hoạt động của Web Service yêu cầu phải có 3 thao tác đó là: Find, Public, Bind [1]. Trong kiến trúc Web Service, Service Provider công bố các mô tả về các service thông qua Service Registry. Service Consumer tìm kiếm trong các Service Registry để tìm ra các service mà họ cần sử dụng. Service Consumer có thể là một người hoặc cũng có thể là một chương trình. Kĩ thuật mô tả dịch vụ là một trong những thành phần chủ chốt của kiến trúc Web Service. Các thông tin mô tả đầy đủ nhất về kiến trúc Web Service được thể hiện trong hai tài liệu riêng biệt, đó là NASSL – Network Accessible Service Specification Language và WDS – Web-Defined Service. NASSL là một tài liệu dưới dạng chuẩn của XML cho các service chạy trên nền Network, nó được sử dụng để chỉ ra các thông tin hoạt động của Web Service, chẳng hạn như danh sách các service, các mô tả về service, ngày hết hạn của service và các thông tin liên quan đến các Service Provider, 13 như tên, địa chỉ[5]. Tài liệu WDS là một tài liệu mang tính đáp ứng đầy đủ cho tài liệu NASSL. Khi ta kết hợp hai tài liệu này với nhau ta sẽ có được sự mô tả một cách đầy đủ về các dịch vụ để cho phía yêu cầu dịch vụ có thể dễ dàng tìm kiếm và gọi các dịch vụ đó. 2.2.2. Kiến trúc phân tầng của web service Hình 4: Web Service technology stack Mô hình kiến trúc phân tầng của Web Service tương tự với mô hình TCP/IP được sử dụng để mô tả kiến trúc Internet. Hình 5: TCP/IP network model Các tầng truyền thống như Packaging, Description, và Discovery trong mô hình Web Service Stack là những tầng cung cấp khả năng tích hợp và cần thiết cho mô hình ngôn ngữ lập trình trung lập.  Tầng Discovery: Tầng Discovery cung cấp cơ chế cho người dùng khả năng lấy các thông tin mô tả về các Service Provider. Công nghệ được sử dụng tại tầng này đó chính là UDDI – Universal Description, Discovery and Integration.  Tầng Desciption: Khi Web Service được thực thi, nó cần phải đưa ra các quyết định về các giao thức trên các tầng Network, Transport, Packaging mà nó sẽ hỗ trợ trong quá trình thực thi. Các mô tả về dịch vụ sẽ đưa ra phương pháp để làm thế nào mà các Service Consumer có thể liên kết và sử dụng các service đó. Tại tầng Description, công nghệ được sử dụng ở đây chính là WSDL (Web Service Desciption Language) – Ngôn ngữ mô tả Web Service. Ngoài ra, ít phổ biến hơn, chúng ta còn có 2 ngôn ngữ khác được định nghĩa bởi tổ chức W3C đó