Phần 3. Nghiên cứu cải tiến công nghệ
4. Thiết kế chi tiết
Tôi chọn tầng giao thức như sau (sẽ giải thích bên dưới):
- Tầng Transport: sử dụng HTTP/HTTPS - Tầng Messenging: sử dụng JSON
Service A API 1
Service B API 1
Service A API 2
Service B API 2
Execute Order
User Input 1
User Input 2
Output 1
Output 2 Result 1
Result 2
Result 3
Result 4
Input
Input
Input Default
input
53
- Tầng Service Description: sử dụng JSON (sử dụng Schema mô tả service của Google)
Để lưu trữ Web Service được tổng hợp, tôi sử dụng JGF (JSON Graph Format). Tôi không sử dụng BPEL để đơn giản và trực quan hóa việc tổng hợp Web Service, cũng như giúp việc gọi và thực thi các API đơn giản hơn.
Chi tiết các chuẩn và công nghệ được sử dụng
Trước khi đi vào chi tiết mô hình và cài đặt, tôi sẽ giải thích lý do của việc lựa chọn các chuẩn và công nghệ mình lựa chọn để sử dụng.
Như đã phân tích ở trên, việc sử dụng REST đem lại cho lập trình viên hiệu quả sử dụng, sự linh động (không phụ thuộc quá chặt chẽ như WS*), và hơn cả, hiện tại hầu hết các nhà cung cấp dịch vụ đang sử dụng chuẩn này nên service rất đa dạng, có thể tìm được API của hầu hết các lĩnh vực. Tôi đã thử tìm kiếm các web service được cung cấp dưới dạng WSDL, nhưng không mấy thành công, chỉ có một vài service phổ thông, được dùng trong học thuật, để giới thiệu về công nghệ; hơn nữa, các UDDI registry công cộng cũng đã không còn được sử dụng, các công nghệ này chỉ còn được sử dụng trong nội bộ các doanh nghiệp, tổ chức.
Tiếp theo đó là một chuẩn chung mô tả về service để các service có thể kết hợp hoạt động cùng nhau. Rất may mắn, trong lĩnh vực này, Google đã cung cấp một service gọi là Google API Discovery Service, service này cung cấp một bộ API mà phơi bày ra các metadata của tất cả các API của các service khác mà Google cung cấp, dưới dạng JSON, và được quy chuẩn để máy có thể “đọc” được, các API này có thể:
- Liệt kê các service và các API trong service đó mà được hỗ trợ của Google: tương ứng phương thức list, sử dụng bằng cách gọi:
HTTP GET https://www.googleapis.com/discovery/v1/apis
- Chi tiết về một service hoặc một API, bao gồm các tham số của API, dịnh dạng dữ liệu đầu vào, định dạng dữ liệu đầu ra, scope, mô tả về API, tham số bắt buộc, các giá trị có thể có của tham số, … tất cả các thông tin liên
54
quan đến việc sử dụng API đó: tương ứng phương thức getRest, sử dụng bằng cách gọi:
HTTP GET https://www.googleapis.com/discovery/v1/apis/api/version/rest JSON Scheme của các API được Google định nghĩa và sử dụng có thể được coi như chuẩn WSDL đối với các service của Google, còn kết quả trả về khi thực hiện gọi phương thức getRest có thể coi như mô tả dịch vụ của API đó (ứng với file WSDL). Sau khi tìm hiểu thêm về các sử dụng các API của Google và các quy ước khi sử dụng, tôi nhận định rằng các công ty khác nên áp dụng các mô hình và quy ước của Google, vì độ chuẩn hóa rất cao của các quy ước này. Ví dụ, khi tìm hiểu cách sử dụng các API của Facebook, tôi đã phải viết thủ công một số mô tả về API của Facebook dưới các quy ước của Google để có thể sử dụng được chúng, nếu không, bắt buộc rằng lập trình viên phải đọc tài liệu trên site của Facebook thì mới có thể sử dụng được các API đó.
Dưới đây là một số hình ảnh về ứng dụng web Google APIs Explorer, được xây dựng bởi chính Google, dựa trên service trên.
Hình 26: Các Service mà Google cung cấp
55
Hình 27: Web API trong một Service
Hình 28: Truy vấn một Web API
56
Hình 29: Kết quả trả về
Để người dùng sử dụng được các ứng dụng web được tạo nên từ các API do google cung cấp, cần phải sử dụng các phương thức xác thực và ủy quyền, tùy vào cách thức sử dụng các API đó, để có thể có quyền truy nhập và sử dụng dữ liệu của người dùng. Google chia ứng dụng thành 3 loại, web-server, installed và web-client, sẽ được trình bày cụ thể ở dưới. Google cũng cung cấp các phương thức khác nhau để xác thực và ủy quyền, dưới đây là danh sách các phương thức.
- Google Sign-In
- Smart Lock for Passwords - Google Identity Toolkit - Plain OAuth 2.0
- Chrome Identity API
Các phương thức khác nhau sẽ được sử dụng trong các trường hợp khác nhau, sao cho phù hợp và thuận tiện với người dùng, tôi chỉ liệt kê ra các phương thức mà không đi sâu vào chi tiết do chúng không nằm trong nghiên cứu của luận văn này.
Phương thức định danh mà tôi sử dụng là OAuth 2.0, dù ứng dụng thuộc loại nào, các bước cơ bản để sử dụng được API của Google, sử dụng OAuth 2.0 cũng như sau:
57
- Nhận chứng chỉ Oauth 2.0: Truy cập Google Developers Console để nhận chứng chỉ OAuth 2.0.
- Nhận thẻ truy cập (access token) từ Google Authorization Server: trước khi ứng dụng có thể truy cập vào dữ liệu cá nhân của người dùng, nó cần nhận một access token mà cấp quyền truy cập cho nó để sử dụng API đó. Một tham số được gọi là scope được sử dụng để mô tả một tập các quyền và tài nguyên mà ứng dụng được phép sử dụng và thực thi. Tiếp theo là đến quá trình đồng ý cấp quyền từ phía người dùng, bằng cách nào đó (pop-up, hiển thị link text, …), sau khi người dùng sign in vào tài khoản Google, người dùng sẽ được hỏi nếu họ có đồng ý cấp quyền cho ứng dụng hay không.
Quá trình này được gọi là consent screen hoặc user consent. Nếu người dùng đồng ý, Google Authorization Server trả về một access token, ứng dụng phải lưu lại để có thể sử dụng sau này.
- Sử dụng API kèm access token vừa nhận được: có thể gửi access token thông qua header của giao thức HTTP (authorization header, header này là tùy chọn nhưng Google khuyến cáo gửi thông qua header này) hoặc qua tham số trong URI (không khuyến cáo, vì để lộ ra access token). Access token nhận được ở trên có thể được sử dụng nhiều lần trong nhiều phiên khác nhau nhưng chúng cũng có thời hạn, mặc định là 3600 giây, sau khoảng thời gian này, các ứng dụng phải xin lại một access token khác.
Hiện tại số lượng tối đa số token hợp lệ Google cho phép là 25, nếu xin thêm thì các token xin trước sẽ tự động hết hạn.
- Xin lại một access token khác khi hết hạn: . Web-server và web-client có cơ chế khác nhau khi access token hết hạn, khi xin access token lần đầu tiên (lần mà người dùng được hỏi có đồng ý chấp nhận ủy quyền không), ứng dụng sẽ nhận được một trường code nữa, ứng dụng sẽ phải lưu trữ dài hạn vào một nơi nào đó, ví dụ đối với installed app là một thư mục nào đó trên ổ cứng, với web-app, server lưu trữ code này. Sau đó, khi token hết hạn, ứng dụng có thể xin một token khác để sử dụng.
58
Web server application: các ứng dụng web mà trong đó server là nhân tố gọi các API của google cả sử dụng dữ liệu của người dùng. Các ứng dụng này được ủy quyển để có thể gọi các API đó ngay cả sau khi người dùng đã thoát ra khỏi ứng dụng. Ví dụ, ứng dụng gửi email tại một thời điểm nhất định có thể sử dụng các API của Google Mail để có thể gửi email như là việc người dùng gửi và không đòi hỏi người dùng phải đăng nhập vào ứng dụng trong thời điểm gửi.
Hình 30: Quy trình xác thực
Từ việc nghiên cứu các Web Service có sẵn để tổng hợp, tôi đưa ra quyết định chọn các chuẩn như sau:
Kiến trúc và mô hình: Sử dụng REST, mô hình client/server, người dùng tự tạo mashup hoặc được cung cấp sẵn bởi server
Giao thức tầng giao vận: Sử dụng HTTP, do tính phổ biến của nó.
Định dạng dữ liệu sử dụng: JSON, do tính phổ biến và là một phần của ngôn ngữ javascript nên có thể xử lý ngay trên trình duyệt.
Mô tả service: Sử dụng scheme mô tả service được quy ước bởi Google API Discovery Service.
Server side: Sử dụng web server Glassfish 4.0, ngôn ngữ lập trình Java.
Client side: Sử dụng bộ ngôn ngữ web HTML5/Javascript/CSS, kết hợp với các thư viện như jQuery, d3js, underscore, renderjson, … để hỗ trợ cho việc tạo giao diện đồ họa và hiển thị.