Sau khi đã cài đặt thành công các Soap engine, chúng tôi sẽ tiến hành cài đặt các Service Composition trên các Web Server vừa được cài đặt lên.
Cài đặt Service SearchHotel
Trước tiên tiến hành cài đặt Web Service SearchHotel chạy trên môi trường J2EE tại cổng 2417.
Tệp cài đặt cho Web Service SearchHotel được chúng tôi viết trong file SearchHotelService.java, trong file này có chứa một phương thức SearchHotel với đối số truyền vào là một String và kết quả trả về cũng là một String. Khi Service Proxy gọi tới SearchHotel Service, thì xâu chứa tên của thành phố đích đến được đóng gói vào thông điệp SOAP, tại SearchHotel Service, sử dụng xâu chứa tên thành phố đích đến làm đối số truyền vào, thực hiện thao tác tìm kiếm trong database xem có kết quả khách sạn nào tương ứng với thành phố đích đến đó hay không.
Hình 31:Code kết nối database trong file SearchHotel Service
Sau đó chúng tôi tiến hành biên dịch file SearchHotelService.java thành file HTService.SearchHotelService.class, copy file này và đặt vào trong thư mục Wapp của J2EE theo đường dẫn sau “C:\Sun\SDK\domains\domain1\applications\j2ee- modulees\soap\WEB-INF\classes”.
62
Tiếp theo để triển khai dịch vụ này trên Web Server, ta cần phải viết một tệp deploy.wsdl để triển khai tệp đó lên web server, nội dung của file deploy.wsdl được thể hiện qua Hình 32:
Hình 32:Nội dung của tệp deploy.wsdl
Nhìn vào nội dung của tệp deploy.wsdl ta thấy một số các đặc điểm sau:
id = “urn:HTService” : Đây chính là tên của Web Service mà ta triển khai, sẽ được dùng để gọi trong code của Service Proxy.
methods=”SearchHotel” : Đây chính là phương thức mà Web Service sẽ sử dụng để thực hiện các thao tác tính toán như tìm kiếm database, trả về kết quả.
dd:java class=”HTService.SearchHotelService” : Đây là đường dẫn để web server có thể tìm kiếm được file SearchHotelService.class để thực thi công việc. Sau đó chúng tôi copy file deploy.wsdl này vào thư mục C:\Webservice. Mở một console, chuyển thư mục làm việc tới thư mục C:\WebService và gõ lệnh sau để triển khai
dịch vụ lên Web Server : C:\Webservice > java
org.apache.soap.Server.ServiceManagerClient http://localhost:2417/soap/servlet/rpcrouter deploy deploy.xml. Lệnh này nhận ba tham số truyền vào đó là URL đến máy chủ SOAP, lệnh deploy và tập tin hợp lệ để triển khai dịch vụ trên máy chủ SOAP. Nếu quá trình
63
triển khai thành công thì sẽ không có thông báo lỗi nào xuất hiện, sau đó ta có thể dùng lệnh C:\webservice > java org.apache.soap.Server.ServiceManagerClient http://localhost:2417/soap/servlet/rcprouter list để liệt kê danh sách các service đã được triển khai trên máy chủ SOAP. Nếu ta thấy danh sách dịch vụ có xuất hiện tên urn:HTService là quá trình triển khai của ta đã thành công. Ngoài ra nếu muốn gỡ bỏ dịch vụ SearchHotel Serviece, ta hoàn toàn có thể dùng lệnh để gỡ bỏ dịch vụ bằng lệnh C:\Webservice > java org.apache.soap.Server.ServiceManagerClient http://localhost:8080/soap/servlet/rpcrouter undeploy urn:HTService.
Ngoài việc sử dụng công cụ dòng lệnh để triển khai, gỡ bỏ, liệt kê danh sách các dịch vụ, chúng ta còn có thể sử dụng công cụ triển khai trực quan được truy cập thông qua địa chỉ
http://localhost:8080/soap/admin
Hình 33:Danh sách các dịch vụ liệt kê trên web site soap engine
Nhìn vào hình minh họa trên ta có thể thấy được danh sách các dịch vụ đã được triển khai trên máy chủ SOAP của chúng ta. Dễ thấy dịch vụ SearchHotel Service đã được triển khai, thể hiện của SearchHotel Service chính là “urn:HTService”.
64
Cài đặt Service SearchFlight
SearchHotel Service đã được cài đặt trên nền J2EE, với máy chủ Soap engine chạy trên cổng 2417 sử dụng thư viện API Apache Soap. Giờ chúng ta sẽ tiến hành cài đặt dịch vụ SearchFlight trên Web Server Apache TomCat, tại cổng 8080, sử dụng thư viện API Apache Axis. Đây là một thư viện hoàn toàn khác so với Apache Soap, điều đó càng minh họa rõ hơn cho công nghệ Web Service là một công nghệ không phụ thuộc vào môi trường cài đặt, ta hoàn toàn có thể sử dụng các công nghệ khác nhau nhưng vẫn làm cho các Service giao tiếp được với nhau.
Tương tự như dịch vụ SearchHotel, dịch vụ SearchFlight cũng được viết trong một file SearchFlightService.java. Và file này được dịch ra file SearchFlightService.SearchFlightService.class. Sau đó ta cần phải copy file này vào thư mục C:\Webservice\tomcat\webapps\axis\WEB-INF\classes. Và để triển khai dịch vụ này, chúng ta cần phải viết một file deploy.wsdd để triển khai dịch vụ. Nội dung của tệp deploy.wsdd được minh họa trong hình dưới đây :
Hình 34:Nội dung file deploy.wsdd
Trong file deploy.wsdd trên ta cần lưu ý :
Thuộc tính service name = “SearchFlightService” : đây chính là tên của Service được dùng để triệu gọi, nó tương đương với thuộc tính id=”urn:HTService” trong file deploy.wsdl dùng để triển khai dịch vụ trên Apache Soap.
65
Thuộc tính parameter = “” value=”SearchFlightService.SearchFlightService ” : trỏ đến vị trí của file SearchFlightService.class để máy chủ Axis tìm kiếm và sử
dụng. Nó tương đương với thuộc tính dd:java
class=”HTService.SearchHotelService” trên Apache Soap.
Sau đó chúng tôi copy file deploy.wsdd này vào thư mục C:\Webservice. Mở một console, chuyển thư mục làm việc tới thư mục C:\WebService và gõ lệnh sau để triển khai dịch vụ lên Web Server: C:\Webservice > java org.apache.axis.Client.AdminClient deploy.wsdd để triển khai dịch vụ. Thực chất lệnh này sử dụng thư viện trong axis nhận tham số truyền vào là file deploy.wsdd để triển khai dịch vụ. Khi chạy lệnh thành công sẽ có thông báo “Processing file deploy.wsdd”. Nếu muốn hủy bỏ dịch vụ, chúng ta chỉ cần đổi tên file deploy.wsdd thành undeploy.wsdd và sửa nội dung 2 thẻ đóng mở <deployment> trong file undeploy.wsdd thành <undeployment> và thực hiện lệnh java org.apache.axis.Client.AdminClient undeploy.wsdd để hủy bỏ dịch vụ. Sau khi triển khai thành công Web Service SearchFlight đã sẵn sàng phục vụ.
Ta có thể nhìn thấy danh sách các dịch vụ đã được triển khai trong trang quản trị của Apache Axis như hình dưới đây:
66
6.3.3.Xây dựng và triển khai Service Proxy
Đây là nội dung quan trọng và là vấn đề chủ chốt để giải quyết bài toán đặt ra trong khóa luận này. Chúng tôi sẽ triển khai Service Proxy trên web server Apache-Tomcat tại cổng 8080 sử dụng Soap engine là Apache Soap.
Thông thường thì Service Proxy thường không phải code cứng bởi người lập trình, mà nó thường được tự sinh ra từ file WSDL của các Web Services mà Service Proxy triệu gọi đến. Tuy nhiên, vì vấn đề bản quyền nên ở đây chúng tôi chỉ tận dụng được một tính năng rất nhỏ trong việc tự sinh ra Service Proxy từ file WSDL, ở đây chỉ sinh ra tên lớp và tên phương thức sao cho Service Proxy có thể triệu gọi tới các Service Composition.
File mã nguồn Service Proxy được viết trong một file Proxy.java, trong file này chúng tôi định nghĩa ra hai lớp, một lớp dùng để triệu gọi các Web Service Composition, và một lớp khác dùng để lấy kết quả trả về khi triệu gọi tuần tự hai Web Service Composition đó. Tương ứng với hai Web Services SearchHotel và SearchFlight, lần lượt trong mỗi lớp chúng ta đều có 2 phương thức tương ứng để triệu gọi tới hai Web Services đó. Dưới đây chúng tôi sẽ trình bày phương pháp tạo ra Service Proxy từ file WSDL của dịch vụ SearchFlightService, với dịch vụ SearchHotelService cách làm cũng tương tự. Hình dưới minh họa file WSDL của Web Service SearchFlight:
67
Để sinh ra Service Proxy ta chỉ cần copy nội dung file WSDL đưa vào chương trình tự sinh, ta sẽ có Service Proxy cần thiết để gọi tới các Service Composition. Chúng tôi sử dụng chương trình tự sinh của web-site http://nsoftware.com , sau khi đưa nội dung file WSDL vào chương trình tự sinh của website đó, ta có phương thức cần triệu gọi đến Service Composition là phương thức Search_Flight trong dịch vụ SearchFlight. Phương thức Search_Flight này cần phải được triệu gọi trong lời gọi dịch vụ được code trong mã nguồn của Service Proxy. Sau khi đã tự sinh ra các lớp và phương thức trừu tượng cho Service Proxy, chúng ta cần phải hiệu chỉnh lại Service Proxy để có thể sử dụng trên thư viện API apache Soap.
Hình 37:Code Service Proxy goi tới SearchFlightService
Nhìn vào hình trên ta có thể thấy, do Service Proxy chuyển tiếp yêu cầu tới 2 Web Services phục vụ mục đích thật, cho nên phương thức Flight của Service Proxy cũng phải có kiểu trả về là một String và nhận đối số truyền vào là một String như mục đích yêu cầu của Service Proxy chúng tôi đã trình bày trong phần tìm hiểu bài toán. Dễ thấy trong hình trên, Service Proxy gọi tới dịch vụ SearchFlight tại địa chỉ “
68
Và gọi tới phương thức Search_Flight của dịch vụ SearchFlight bằng lời gọi call.setMethodname(“SearchFlight”).
Mục tiêu bài toán của chúng ta đó chính là xây dựng Service Proxy để kiểm tra ràng buộc thời gian đáp ứng của các Web Service Composition, cho nên không thể thiếu được phần đo lường thời gian trong code Service Proxy. Một phương pháp đơn giản để đo lường thời giap đáp ứng các Web Service Composition đó là ta chỉ cần sử dụng một đồng hồ đếm thời gian trong khoảng thời gian thực hiện lời gọi dịch vụ.
Hình dưới đây minh họa phương pháp đo lường thời gian đáp ứng:
Hình 38:Minh họa đo lường thời gian đáp ứng
Ta có thể thấy lời gọi đến các Service Composition được thực hiện qua phương thức Response resp = call.invoke(url,””);
Ý tưởng thuật toán đo lường thời gian đáp ứng trong Web Service Composition được mô tả như sau:
Trước khi thực hiện lời gọi tới các Services thành phần, ta bật đồng hồ đếm thời gian thông qua phương thức timer.start();
Sau khi gọi phương thức và lấy kết quả trả về ta dừng đồng hồ đếm thời gian thông qua lời gọi phương thức timer.stop();
Sau khi ta có thời gian bắt đầu, thời gian kết thúc, ta hoàn toàn có thể tính ra được thời gian đáp ứng là bao nhiêu thông qua phương thức getDifference() = timer.stop() – timer.start();
69
Như vậy với các Web Services khác ta đều có phương pháp đo lường thời gian tương tự như đo lường thời gian áp dụng với SearchFlight Service.
Việc đo lường thời gian đáp ứng đối với SearchHotel Service cũng được thực hiện với cách tương tự như áp dụng với dịch vụ SearchFlight. Như vậy chúng ta đã có đầy đủ một Service Proxy để đo lường thời gian đáp ứng của hai Web Services SearchHotel Service và SearchFlight Service.
Về việc cài đặt Service Proxy được chúng tôi viết trong 2 file. File ServiceProxy.java chứa 2 lớp, một lớp Service chứa hai phương thức gọi dịch vụ tới hai Web Services thành phần, một lớp ServiceProxy chứa hai phương thức để gọi lần lượt tới hai phương thức trong lớp Service. File Timer.java là file chuyên biệt dùng để đo lường thời gian đáp ứng của các Web Services. Trong code của file ServiceProxy chúng ta phải import file Timer.class để có thể thực hiện việc đo thời gian đáp ứng. Chúng tôi biên dịch hai File này ra thành 3 lớp, đó là lớp mytimer.Timer.class, test.ServiceProxy.class,
test.Service.Class, copy 3 file này vào thư mục
C:\Webservice\tomcat\webapps\soap\WEB-INF\classes. Service Proxy được cài đặt sử dụng Soap engine Apache Soap nên quá trình cài đặt hoàn toàn tương tự như khi chúng ta cài đặt dịch vụ SearchHotel. Điểm khác biệt duy nhất ở đây đó là địa chỉ của ServiceProxy lúc này sẽ là http://localhost:8080/soap/ chứ không phải
http://localhost:2417/soap/ như đối với SearchHotel Service.
6.3.4.Phát triển chương trình client và thực nghiệm
Sau khi đã có tất cả cả Web Services thành phần và Service Proxy, chúng tôi sẽ phát triển một chương trình client đơn giản để có thể nhìn thấy kết quả đáp ứng thời gian của các Service Composition. Để lấy kết quả trả về, chúng ta chỉ việc chọn thành phố xuất phát tại thẻ Source, thành phố đến tại thẻ Destination và sau đó nhấn nút Search để có kết quả trả về.
70
Hình 39:Minh họa test chương trình
Ta thấy sau khi nhấn nút Search, kết quả của SearchHotel Service sẽ được hiển thị trong TextField 1, kết quả tìm kiếm máy bay sẽ hiển thị trong TextField 2. Đồng thời Service Proxy cũng trả về thời gian đáp ứng cho SearchHotel Service là 33ms, thời gian đáp ứng của SearchFlight Service là 32ms.
Chương trình của chúng ta đã đo lường được thời gian đáp ứng của các Web Service Composition, giờ chúng ta sẽ kiểm chứng xem thời gian đáp ứng đó có đáp ứng được tiêu chuẩn QoS đặt ra về thời gian hay không ?
71
Giả sử ta đặt ra quy ước về thời gian đáp ứng khi gọi tuần tự cả hai dịch vụ trong môi trường localhost tối đa mất 60 micro giây. Ta có biểu đồ Timing Diagram cho việc đặc tả ràng buộc thời gian đáp ứng trong Web Service Compostion như sau:
72
Nhìn vào biểu đồ trên ta thấy, toàn bộ quá trình thực hiện hai Web Service Composition một cách tuần tự được giới hạn trong vòng 60micro giây, nếu thời gian vượt quá 60micro giây thì coi như không đáp ứng được yêu cầu QoS về thời gian đặt ra. Các thao tác tại hai Web Services như tìm kiếm cơ sở dữ liệu, trả lại kết quả trả về đều được xác định bằng các khoảng thời gian trừu tượng minh họa bằng thời gian t vì ở đây ta không thể biết chính xác rằng mất bao lâu để thực thi các thao tác đó, ta chỉ có thể ước lượng được mất bao lâu để một thao tác như vậy có thể hoàn thành. Ở đây chúng ta chỉ kiểm chứng thời gian đáp ứng của các Web Service Composition cho nên các thao tác được thực hiện tại Client như nhập thông tin, gọi đến Service Proxy hay Service Proxy trả lại kết quả cho Client sẽ không liên quan đến các ràng buộc thời gian của chúng ta.
Ta có mô hình kiểm chứng được minh hoạ như sau:
Hình 41:Minh hoạ mô hình kiểm chứng ràng buộc thời gian đáp ứng
Với kết quả trả về bởi Service Proxy khi thực hiện quá trình triệu gọi đến hai Web Services, ta có thời gian thực hiện tìm kiếm kết quả của SearchHotel Service là 33 micro
73
giây, SearchFlight Service là 32 micro giây, do việc gọi 2 dịch vụ này được thực hiện tuần tự nên tổng thời gian gọi dịch vụ là 65 micro giây. Trong khi đó ràng buộc QoS cho thời gian đáp ứng của chúng ta đặt ra là tối đa cho phép 2 dịch vụ này gọi trong môi trường localhost là 60 micro giây. Áp dụng lên mô hình kểm chứng minh hoạ ở hình 41 ta thấy rằng t1+t2 > t (33ms + 32ms > 60ms) nên ta dẫn đến kết luận là thời gian đáp ứng của hai Web Service Composition này chưa đáp ứng được tiêu chuẩn đã đề ra.
Như vậy chúng ta đã xây dựng được nên một Service Proxy để kiểm tra ràng buộc thời gian đáp ứng trong Web Service Composition, đặc tả ràng buộc thời gian đó trên biểu đồ UML Timing Diagram. Ta hoàn toàn có thể mở rộng bài toán với một tập hợp rất nhiều các Web Service Composition khác với phương pháp áp dụng như trên, ở đây mục tiêu của khóa luận chỉ là kiểm tra xem thời gian đáp ứng đó có tuân thủ thời gian QoS đề ra hay không. Ta mới kiểm tra một trường hợp, tùy vào từng ngữ cảnh mà ta có thể kết luận liệu các dịch vụ đó có đáp ứng được với tiêu chuẩn QoS về thời gian không. Tuy nhiên trong thực nghiệm khi chúng tôi kiểm tra các đáp ứng với nhiều truy vấn chúng tôi thấy thời gian đáp ứng càng giảm đi đáng kể, và hầu hết các Service Composition đều đáp ứng được với yêu cầu về ràng buộc thời gian đưa ra. Tuy nhiên để thể hiện đầy đủ thì cần phải có các phương pháp, điều kiện ngữ cảnh khác nhau mới có thể có kết luận chính xác. Do điều kiện hạn hẹp nên chúng tôi mới chỉ thể hiện phương pháp bài toán, để chính xác với thực tế cần phải thể hiện bài toán trên môi trường Internet, nơi mà có rất nhiều yếu tố ảnh hưởng tới chất lượng đáp ứng của các dịch vụ.
74
CHƯƠNG 7: KẾT LUẬN
Công nghệ Web Service ngày càng được sử dụng rộng rãi trong việc giải quyết các bài toán liên quan đến dữ liệu phân tán. Với các ưu điểm của mình, Web Service đã chứng tỏ được khả năng đáp ứng mạnh mẽ đối với các quy trình nghiệp vụ ngày càng phức tạp của các tổ chức doanh nghiệp. Sự phát triển của Web Service sẽ dẫn đến nhu cầu đánh giá chất lượng dịch vụ Web nào tốt nhất cho người sử dụng, để người sử dụng có thể