2.4.1. Kiến trúc cài đặt hệ thống
Hình 2.14. Mô hình kiến trúc cài đặt hệ thống
Số lượng lớp và các interface khi ta xây dựng ứng dụng GWT theo kiến trúc MVP là khá lớn. Giả sử như với một giao diện đơn giản là phần hiển thị những tài liệu mới được tải lên.
69
Hình 2.15. Biểu đồ hiển thị thông tin về ảnh đại diện
Ta sẽ mô tả kỹ cho trường hợp nhóm lớp này, các nhóm lớp khác là tương tự về mặt logic tổ chức.
- HomeView HowRowView: quyết định giao diện hiển thị. Ở đây giao diện sẽ bao gồm một vùng hiển thị lớn (Home) chứa những dòng hiển thị thông tin về một tài liệu (HomeRow). Mỗi dòng gồm một ảnh, tên, ngày tải lên và một đường link để xem chi tiết của tài liệu. View không biết thông tin mà nó hiển thị là gì và nó cài đặt lớp Display của hai lớp tương ứng là HomePresenter và
70
- HomePresenter HomeRowPresenter: quyết đinh thông tin hiển thị và sự kiện khi nhấn vào nút xem tài liệu. Ở đây HomePresenter lấy thông tin về các tài liệu mới (TaiLieuInfo) và khởi tạo các một HomeRowPresenter ứng với mỗi tài liệu. HomeRowPresenter sau đó dùng một đối tượng cài đặt interface Display của nó để hiển thị. Đồng thời nó cũng xác định phải làm gì khi người dùng nhấn vào nút xem chi tiết. HomePresenter lấy các đối tượng TaiLieuInfo thông qua lời gọi không đồng bộ của lớp TaiLieuServiceAsync như đã mô tả ở phần GWT RPC.
- TaiLieuInfo: đóng vai trò Model trong ô hình MVP, ở đây ta còn dùng lớp TaiLieu. Lớp tài liệu là lớp lưu trữ thông tin vào JDO. Nó có những trường Long dùng để tham chiếu đến các đối tượng TacGia, LinhVuc … Lớp tài liệu không thể dùng trực tiếp do những thông tin kiểu Long tham chiếu không có nghĩa. Lớp TaiLieuInfo chuyển những trường Long thành trường String có nghĩa để hiển thị. - TaiLieuService, TaiLieuServiceAsync, TaiLieuProfileImpl : ba lớp/interface cần
thiết để gọi các phương thức theo mô hình RPC.
Như vậy với một giao diện ta có thể có 7 file java. Tuy nhiên không phải lúc nào cũng sinh ra file dịch vụ mới, ta có thể nhóm các chức năng dịch vụ xử lý cùng một loại thực thể model vào làm một dịch vụ.
72
Hình 2.16. Gói client gồm các interface dịch vụ (1)
Hình 2.17. Gói client gồm các interface dịch vụ (2)
Chú ý là trong gói này ta thấy có hai lớp là Srychrea và AppController.
AppController như đã mô tả ở trong mô hình MVP là lớp quyết định việc xử lý logic ở mức ứng dụng. Ở đây ta sẽ cài đặt nó để điều khiển việc thay đổi giao diện của
73
ứng dụng tùy vào dấu hiệu của History. Lớp Srychrea kế thừa lớp EntryPoint là điểm khởi đầu của ứng dụng GWT tương tự như hàm main.
Hình 2.18. Các lớp của gói server nhằm thực hiện công việc ở phía server
Trong các lớp ở server, các lớp cài đặt các interface đã nêu trong gói client có tên được đặt theo quy tắc tên dịch vụ “impl”. Các lớp này là lớp bắt buộc trong mô hình gọi hàm của RPC GWT đã nêu ở phần trên. Ngoài ra trong gói còn có một số lớp phụ :
- PMF : lớp bao bọc một đối tượng dùng để thao tác với cơ sở dữ liệu. Do đặc tính các đối tượng PersistenceManagerFactory mất nhiều thời gian để khởi tạo, ta tạo ra một lớp có một đối tượng PersistenceManagerFactory đặt là static để sẵn sàng được sử dụng khi có yêu cầu.
- Upload: lớp này tiếp nhận file người dùng muốn tải lên và lưu trữ lại vào blobstore. Sở dĩ không làm lớp này thành dịch vụ RPC là do cấu trúc của dịch vụ blobstore yêu cầu ảnh được gửi lên thông qua một yêu cầu HTTP hoàn chỉnh. - Serve : trả lại nội dung của blobstore, lớp này được sử dụng k m với dịch vụ
Image để tạo thumbnail của các ảnh đã được tải lên và hiển thị ảnh cho một vài kiểu file.
74
2.4.2. Các dịch vụ sử dụng trong hệ thống
Mục này sẽ tổng kết những dịch vụ GAE đã được sử dụng trong ứng dụng và lý giải vì sao lại sử dụng chúng.
2.4.2.1. Dịch vụ Account
Dùng để quản lý việc đăng nhập vào ứng dụng. Khi xây dựng cơ chế xác thực cho ứng dụng ta có thể tụ xây dựng cơ chế này như vẫn xây dựng trên các hệ thống cổ điển. Tuy nhiên khi cân nhắc đến vấn đề liệu ta có nhất thiết phải xây dựng mới không khi mà ta khó có thể đưa ứng dụng của ta ra và chạy trên một nền tảng khác, ta thấy sẽ là phí công sức khi xây dựng mói một hệ thống xác nhận người dùng.
Phát hiện người dùng đã đăng nhập tài khoản Google hay chưa và chuyển hướng người dùng tới trang đăng nhập.
Đặc điểm:
- Dùng tài khoản Google để xác thực.
2.4.2.2 Dịch vụ Image
Dùng trong việc giảm dữ liệu chuyển về client khi client yêu cầu xem ảnh đại diện và thumbnail các ảnh được người dùng tải lên. Do ảnh được người dùng tải lên có thể có dung lượng và kích thước lớn nhưng các ảnh đại diện hay ảnh hiển thị thumbnail chỉ có kích thước nhỏ, sẽ là phí phạm băng thông nếu ta truyên các bức ảnh lớn mỗi lần được yêu cầu.
Dịch vụ này có thể phóng to, cắt, xoay hay gộp nhiều ảnh lại; nó cũng có thể chuyển đổi giữa nhiều định dạng khác nhau. Ngoài ra có còn cung cấp các thuật toán cải thiện ảnh. Ta cũng có thể lấy được thông tin về như chiều cao, độ rộng hay thâm chí cả histrogram của ảnh.
Dịch vụ Image có thể thay đổi kích cỡ, xoay, lật, và cắt hình ảnh, và nâng cao chất lượng hình ảnh. Nó cũng có thể tông hợp nhiều hình ảnh thành một hình ảnh duy nhất.
Dịch vụ này chấp nhận các dữ liệu hình ảnh trong JPEG, PNP, GIF (kể cả GIF động), BMP, TIFF và các định dạng ICO.
Nó có thể trả lại hình ảnh đã được chuyển đổi theo định dạng JPEG và PNG. Nếu đầu vào và đầu ra định dạng khác nhau, dịch vụ chuyển đổi dữ liệu đầu vào thành định dạng đầu ra trước khi thực hiện phép biến đổi.
75
Dịch vụ Image có thể sử dụng một giá trị từ Blobstore như là đầu vào để biến đổi. Một hình ảnh từ Blobstore có thể có kích thước tối đa như kích thước tối đa của một giá trị Blobstore. Lưu ý, kết quả của chuyển đổi sẽ được trả trực tiếp cho các ứng dụng, và phải do đó không được vượt quá giới hạn của Iamge API là 1 megabyte. Bạn có thể sử dụng tính năng này để thu nhỏ của hình ảnh được tải lên bởi người sử dụng khi người dùng xem danh sách ảnh, giảm dung lượng truyền tải, trong khi vẫn giữ ảnh gốc nếu cần. Đặc điểm:
- Xử lý ảnh, cải thiện ảnh, chuyển đổi định dạng
- Có thể sử dụng ảnh trong BlobStore, khi đó kích thước ảnh có thể bỏ qua tuy nhiên ảnh trả về vẫn bị giới hạn nhỏ hơn 1MB.
Giới hạn:
- Kích thước tối đa của ảnh nhận và gửi là 1MB
Loại tài nguyên Định mức miễn phí Định mức trả phí
Giới hạn hàng ngày
Mức tối đa Giới hạn hàng ngày
Mức tối đa Gọi API 864.000 lời gọi 4.800 lần/phút 45.000.000 lời
gọi
31.000 lần/phút
Dữ liệu gửi đến 1 gigabyte 5
megabyte/phút
560 gigabyte 400
megabyte/phút
Dữ liệu gửi đi 5 gigabyte 28
megabyte/phút 427 gigabyte 300 megabyte/phút Số phép biến đổi 2.500.000 lần 14.000 lần/phút 47.000.000 lần 32.000 lần/phút ảng2.1. ịnh mức dịch vụ Image
76
2.4.2.3. Blobstore
Dùng dịch vụ này để lưu trữ ảnh đại diện của người dùng và các tập tin tài nguyên mà người dùng tải lên. Dịch vụ này sử dụng hơi khác khi kết hợp với GWT do yêu cầu gửi nội dung tập tin trong một yêu cầu HTTP POST.
Blobstore API cho phép chương trình lưu trữ dữ liệu lớn những gì mà cơ sở dữ liệu cho phép (>1MB). Mỗi blob là một đối tượng dữ liệu được tạo ra khi người dùng upload một file. Khi form được submit, Blobstore API sẽ tạo một blob từ nội dung file và trả về một tham chiếu đến đó, gọi là blob key, mà ta có thể sử dụng để lấy lại file đã tải lên.
Để tạo và tải lên một blob, hãy làm theo trình tự sau này:
- Đặt blobstoreService.createUploadUrl là hành động của form, đường dẫn đến khi phương thức POST được hoàn tất.
- Form phải bao gồm thẻ Upload, và enctype của mẫu phải được đặt là
multipart/form-data. Khi người dùng gửi form, dữ liệu của POST sẽ được xử lý bởi các API Blobstore, và tạo ra các blob. API này cũng tạo ra các thông tin cho blob và lưu trữ các chúng trong kho dữ liệu, và viết lại yêu cầu đến địa chỉ mà ta chỉ ra trong hành động của form với tham số là khóa của blob.
- Trong đoạn mã xử lý, bạn có thể lưu trữ các khóa blob với phần còn lại của mô hình ứng dụng dữ liệu của bạn (chẳng hạn như ghi nhớ mà người dùng tải lên các tập tin). Chìa khóa blob còn có thể truy cập được từ các đối tượng thông tin trong kho dữ liệu. Lưu ý rằng sau khi ta gửi form và mã xử lý được gọi, blob đã được lưu lại và các thông tin đã được bổ sung vào kho dữ liệu. Nếu ứng dụng của bạn không muốn giữ blob, bạn nên xóa các blob ngay lập tức để tránh cho nó không được quản lý.
Trong đoạn mã sau, phương pháp getUploadedBlobs trả về một tập hợp các blob đã được tải lên. Các đối tượng Map là một danh sách liên kết tên của các trường tải file lên và khóa của blob.
Khi Blobstore API ghi lại yêu cầu của người dùng, những phần MIME của các tập tin tải lên đã bị làm trống, và khóa của blob được thêm vào thành một tiêu đề phần MIME. Tất cả các trường và bộ phận khác được giữ nguyên truyền cho mã xử lý.
77
Nếu bạn không chỉ định một loại nội dung, Blobstore API sẽ cố gắng để suy luận kiểu nội dung từ phần mở rộng. Nếu không có kiểu nội dung có thể được xác định, các blob mới tạo được phân công ứng dụng kiểu nội dung /octet-stream.
Để sử dụng các blob, ta phải tạo một đoạn mã đưa ra nội dung blob như một đường dẫn trong ứng dụng của bạn (serlet). Đoạn mã xử lý này nên đưa khóa của muốn lấy vào blobstoreService.serve (blobKey, res);. Trong ví dụ này, khóa blob được đưa vào từ querystring để lấy nội dụng blob đó (req.getParameter ( blob-key )). Trong thực tế ta có thể lấy khóa blob bằng bất cứ cách nào.
Đặc điểm:
- Tạo ra cơ chế để lưu trữ những thông tin không tổ chức, như ảnh, icon hoặc file dữ liệu.
Giới hạn:
- Kích thước tối đa của blob là 50MB.
2.4.2.4. Memcache
Ứng dụng dịch vụ này để lưu ảnh đại diện của người dùng, do luôn có nhu cầu sử dụng ảnh đại diện nên ta lưu nó vào memcache nhằm giảm lượng truy cập và dữ liệu lấy từ datastore (do đó giảm chi phí và tăng độ ứng dụng).
2.4.2.5. Tông kết tất cả các lớp
78
79
80
81
Hình 2.22. Tất cả các lớp (4)