Trước khi xem xét kỹ về WSRF chúng ta phải nắm được những kiến thức cơ bản về dịch vụ web. Dịch vụ web hiểu một cách đơn giản là một công nghệ tính toán phân tán (tương tự CORBA, RMI, EJB...), cho phép ta phát triển các ứng dụng theo kiến trúc client/server.
Hình 2.2. Các dịch vụ web
Trong hình vẽ 2.2, client (chương trình muốn truy nhập các thông tin về thời tiết) sẽ giao tiếp với một dịch vụ web (trên server), và gửi "service request" để yêu cầu các thông tin về thời tiết, server sẽ trả lời bằng "service response". Tất nhiên, đây mới chỉ là một ví dụ rất đơn giản về dịch vụ Web. Chúng ta sẽ xem xét một cách chi tiết hơn ở phần sau.
Các ưu điểm của dịch vụ web so với các công nghệ tính toán phân tán truyền thống (RMI, CORBA, EJBs,…) bao gồm:
- Dịch vụ web là độc lập về nền hệđiều hành và ngôn ngữ, bởi vì ta sử dụng ngôn ngữ XML chuẩn. Điều này có nghĩa là chương trình khách có thể được lập trình bằng C++ và chạy trên nền hệ điều hành Windows, trong khi dịch vụ web được lập trình bằng Java và chạy trên nền hệđiều hành Linux.
- Hầu hết các dịch vụ web sử dụng HTTP cho truyền thông điệp, điều này là một thuận lợi lớn khi ta phát triển các ứng dụng trên Internet, bởi vì các tường lửa và proxy trên Internet không làm đảo lộn các truyền
thông của HTTP (không giống như CORBA gặp phiền toái với vấn đề tường lửa).
Tuy nhiên, dịch vụ web có một số nhược điểm, đó là:
- Trước hết, việc truyền toàn bộ dữ liệu bằng XML rõ ràng là không hiệu quả bằng việc sử dụng mã nhị phân. Để có được tính khả chuyển, nó đã phải đánh đổi bằng tính hiệu quả.
- Thiếu tính linh động: Hiện tại dịch vụ web là không linh động, khi chúng chỉ cho phép một số dạng triệu gọi dịch vụ cơ bản. CORBA có thể cho phép lập trình viên nhiều cách cung cấp dịch vụ hơn như là dịch vụ vĩnh viễn (persistency), thông báo (notifications), quản lý vòng đời (lifecycle management).
Ở phần sau, ta sẽ thấy cách mà dịch vụ lưới bổ sung các nhược điểm trên của dịch vụ web. Tuy nhiên, có một đặc điểm quan trọng để phân biệt dịch vụ web với các công nghệ tính toán phân tán khác. Trong khi các công nghệ như CORBA, EJBs hướng vào các hệ thống tính toán phân tán phụ thuộc chặt (highly-coupled distributed systems), khi mà client và server phải phụ thuộc vào nhau, dịch vụ web lại thích hợp cho các hệ thống phân tán không phụ thuộc (losely- coupled systems), khi mà client có thể không biết gì về dịch vụ web cho tới khi nó triệu gọi các dịch vụ Web. Các hệ thống phân tán phụ thuộc là lý tưởng cho các ứng dụng Intranet, nhưng lại có hiệu suất thấp trên môi trường Internet. Điều này giải thích tại sao dịch vụ web thích hợp hơn đối với các ứng dụng trên Internet nói chung và các ứng dụng trên môi trường lưới nói riêng.
2.1.2.1. Một triệu gọi dịch vụ web điển hình
Để hiểu rõ hơn về hoạt động của dịch vụ web, hãy theo dõi các bước để triệu gọi một dịch vụ web.
Hình 2.3. Một triệu gọi dịch vụ web điển hình
1. Nhưđã đề cập trước đó, một client có thể không biết gì về dịch vụ web mà nó định triệu gọi. Bởi vậy, bước đầu tiên là tìm một dịch vụ web đáp ứng các đòi hỏi của nó. Ví dụ, nếu quan tâm tới một dịch vụ web cung cấp thông tin về thời tiết của các thành phố của Mỹ, ta có thể tìm nó qua bộđăng ký và khai phá dịch vụ UDDI.
2. Bộđăng ký UDDI sẽ trả lời cho chúng ta biết server nào cung cấp dịch vụ mà ta yêu cầu.
3. Khi đã biết về vị trí của dịch vụ web, nhưng vẫn chưa biết triệu gọi dịch vụđó như thế nào. Chúng ta phải yêu cầu dịch vụ web mô tả thông tin về chính nó để biết chính xác phương thức nào cần triệu gọi.
4. Dịch vụ web sẽ trả lời bằng một ngôn ngữ gọi là WSDL.
5. Cuối cùng, chúng ta đã biết dịch vụ web nằm ở đâu và triệu gọi nó như thế nào. Quá trình triệu gọi được thực hiện bởi một ngôn ngữ gọi là
SOAP. Do đó, trước tiên ta phải gửi một yêu cầu SOAP (SOAP request) để lấy thông tin về thời tiết.
6. Dịch vụ Web sẽ trả lời với một đáp ứng SOAP (SOAP response) chứa thông tin về thời tiết mà ta yêu cầu. Nó có thể là một thông báo lỗi nếu yêu cầu SOAP của chúng ta không đúng.
2.1.2.2. Kiến trúc dịch vụ web:
Hình 2.4. Kiến trúc dịch vụ web
- Tầng xử lý dịch vụ (Process): tầng này có thể bao gồm nhiều dịch vụ web. Ví dụ. khả năng khám phá dịch vụ (thuộc về tầng này của kiến trúc) cho phép tìm một dịch vụ web cụ thể từ một tập các dịch vụ web. - Tầng mô tả dịch vụ (Description): một trong những đặc điểm thú vị của
dịch vụ web là nó có khả năng tự mô tả về mình, về những thao tác mà nó có thể cung cấp, tham số vào ra,… Điều này được thực hiện bằng ngôn ngữ mô tả dịch vụ web (Web Service Description Language – WSDL).
- Tầng triệu gọi dịch vụ (Invocation): tầng này chịu trách nhiệm gọi dịch vụ web giữa client và server sau khi đã nắm được vị trí và phương thức triệu gọi. SOAP (Simple Object Access Protocol) sẽ được sử dụng để thông báo cho phía client biết quy cách đưa một yêu cầu đến server và quy cách của kết quả trả về.
Khai phá, kết hợp, …
WSDL
Web Services Description Language Giao thức triệu gọi phổ biến là SOAP
nhưng về lý thuyết có thể sử dụng các giao thức khác
Giao thức truyền thông phổ biến là HTTP, (adsbygoogle = window.adsbygoogle || []).push({});
nhưng về lý thuyết có thể sử dụng các giao thức khác
- Tầng vận chuyển (Transport): tầng này trực tiếp gửi các gói tin giữa 2 phía server và client. Giao thức được sử dụng là HTTP (HyperText Transfer Protocol).
2.1.2.3. Địa chỉ của dịch vụ web
Các dịch vụ web được xác định bằng các định danh tài nguyên thống nhất URIs (Uniform Resource Identifiers) tương tự như URL (Uniform Resource Locator). Chẳng hạn dịch vụ cung cấp thông tin dự báo thời tiết có địa chỉ URI như sau:
http://webservices.mysite.com/weather/us/WeatherService
Địa chỉ này giống như một trang web. Tuy nhiên, dịch vụ web được sử dụng bởi các phần mềm. Nếu người dùng gõ một địa chỉ dịch vụ web URI vào trong trình duyệt, ta sẽ nhận được một thông báo lỗi. Thực tế, hầu hết các chương trình ta viết sẽ nhận về URI của dịch vụ web như một tham số dòng lệnh.
2.1.2.4. Một ứng dụng dịch vụ web
Việc triệu gọi dịch vụ web được thực hiện qua client stub. Vì vậy, trong lược đồ triệu gọi ở phần trước (hình 2.4), client thường không phải thực hiện tất cả các bước trong một triệu gọi đơn. Hơn thế nữa, client stub còn có thể
được sinh tự động dựa trên mô tả WSDL của dịch vụ web.
Như vậy thứ tự các sự kiện bên phía client liên quan đến sử dụng dịch vụ web là như sau:
- Xác định một dịch vụ web đáp ứng các yêu cầu thông qua UDDI. - Thiết lập mô tả WSDL của dịch vụ web.
- Phát sinh stubs ngay sau đó, cho chúng vào ứng dụng của chúng ta. - Ứng dụng sẽ sử dụng stubs tại mỗi thời điểm nó triệu gọi dịch vụ web.
Mô hình lập trình phía server cũng rất đơn giản, ta không cần phải viết một chương trình server phức tạp, tự động thông dịch các yêu cầu SOAP và đưa ra các đáp ứng SOAP. Chúng ta đơn giản chỉ cài đặt tất cả các chức năng cho dịch vụ web của chúng ta, sau đó sinh ra một server stub (hay còn được gọi là skeleton). Server stub sẽ chịu trách nhiệm thông dịch các yêu cầu, đưa chúng tới cho dịch vụ thực thi. Nó cũng có thể tựđộng sinh ra mô tả WSDL, hay các ngôn ngữ mô tả khác (IDL trên CORBA). Việc thực thi phía server và server stubs được quản lý thông qua một thành phần gọi là trình chứa dịch vụ web (Web Service container), bảo đảm các yêu cầu HTTP cho dịch vụ web được trực tiếp tới server stub.
Giả sử rằng chúng ta đã định vị được dịch vụ web, và phát sinh client stubs từ mô tả WSDL. Ngoài ra, các lập trình viên phía server cũng phải phát sinh server stubs. Các bước liên quan tới triệu gọi một dịch vụ web được mô tả như hình 2.6.
1. Bất cứ khi nào ứng dụng client cần triệu gọi dịch vụ web, nó sẽ gọi client stub. Client stub sẽ chuyển triệu gọi địa phương ('local invocation') vào trong một yêu cầu SOAP phù hợp. Quá trình này được gọi là marshaling hay serializing.
2. Yêu cầu SOAP được gửi qua mạng thông qua giao thức HTTP. Trình chứa dịch vụ nhận được các yêu cầu SOAP, và chuyển nó tới server stub. Server stub sẽ biến đổi các yêu cầu SOAP thành dạng phù hợp để chương trình thực thi phía server có thể hiểu được (quá trình này được gọi là unmarshaling hay deserializing).
3. Thực thi dịch vụ sẽ nhận các yêu cầu từ service stub, và tiến hành công việc mà nó được yêu cầu.
4. Kết quả của các toán tử được yêu cầu được chuyển tới server stub, và stub sẽ chuyển nó thành các đáp ứng SOAP.
5. Đáp ứng SOAP được gửi qua mạng thông qua giao thức HTTP. Client stub nhận được các đáp ứng SOAP và chuyển nó về dạng phù hợp để các ứng dụng client có thể hiểu được.
6. Cuối cùng, ứng dụng nhận được kết quả của triệu gọi dịch vụ web và sử dụng nó.
2.1.2.5. Dịch vụ web – phía server
Cuối cùng chúng ta cùng xem xét kiến trúc phía server của một ứng dụng dịch vụ web.
Hình 2.7. Kiến trúc phía server của một ứng dụng dịch vụ web
- Dịch vụ web: Như đã đề cập ở trên, dịch vụ web chỉ là một phần mềm nhỏ để thực hiện một chức năng nào đó, nó có thể được viết bằng một ngôn ngữ lập trình nào đó, chẳng hạn Java. Tuy nhiên, dịch vụ web lại không thể hiểu được các thông điệp SOAP và càng không thể tạo ra được các thông điệp SOAP trả lời, do đó ta cần SOAP engine.
- SOAP engine đơn giản là một phần mềm để xử lý các yêu cầu SOAP và sinh ra các thông điệp trả lời. Thực tế, người ta thường dùng một SOAP engine thay vì thực sự sinh ra các server stubs cho mỗi dịch vụ web riêng lẻ (chú ý rằng, ta vẫn cần các client stubs cho client). Ví dụ cho một SOAP engine là Apache Axis (thực tế SOAP engin này được sử dụng trong Globus Toolkit). Tuy nhiên, chức năng của SOAP engine thường chỉ giới hạn trong việc thao tác SOAP. Để có một chức năng thực sự như một server có thể nhận các yêu cầu từ các client khác nhau, ta nhúng SOAP engine trong trong Server ứng dụng.
- Server ứng dụng (application server) là phần mềm cung cấp "không gian sống" cho các ứng dụng có thể truy nhập từ các client khác nhau. SOAP engine chạy như một ứng dụng trong server ứng dụng này. Ví dụ cho server ứng dụng là Jakarta Tomcat, một trình chứa JSP và Java Servlet thường dùng trong Apache Axis của Globus Toolkit. Nhiều server ứng dụng đã bao gồm các chức năng HTTP, cho nên ta có thể cài đặt và chạy các dịch vụ web bằng cách cài đặt một SOAP engine cùng một server ứng dụng. Tuy nhiên, khi một server ứng dụng thiếu các tính năng HTTP, chúng ta cần có thêm server HTTP.
- Server HTTP: thường được gọi là web server. Nó là một phần mềm biết cách để xử lý các thông điệp HTTP. Ví dụ: Apache HTTP Server là một trong những web server thông dụng nhất trên Internet.