Download miễn phí Đồ án Tìm hiểu về Portlet và ứng dụng trong cổng giao tiếp điện tử



Mục lục
Mục lục 1
Lời Thank 3
Lời nói đầu 4
Chương I: Giới thiệu cổng giao tiếp điện tử 5
1. Định nghĩa 5
2. Lịch sử phát triển 5
3. Phân loại Portal 6
4. Thuộc tính cơ bản của Portal 7
5. Chức năng của Portal 8
6. Kiến trúc của Portal 9
7. Các mô hình phát triển 12
Chương II: Tìm hiểu về Portlet 21
1. Định nghĩa 21
2. Định dạng chung của một Portlet 21
3. Giới thiệu về chuẩn JSR 168 23
3.1. Những nền tảng chung của Portlet 23
3.2. Định nghĩa 24
3.3. Portlets và Servlets . .24
3.4. Những tương tác trong Portal 25
3.4.1. Portlet Interface và lớp GenericPortlet 26
3.4.2. Vòng đời của Portlet 27
3.4.3. Các trạng thái thực thi Portlet 27
3.4.4. Quản lý yêu cầu Portlet 28
3.5. Các yếu tố khác của Java Portlet API 34
3.5.1. PortletConfig 34
3.5.2. PortletURL 35
3.5.3. Các chế độ của Portlet 36
3.5.4. Các cửa sổ trạng thái 37
3.5.5. Ngữ cảnh của Portlet 38
3.5.6. Ngữ cảnh của Portal 38
3.5.7. Các tham chiếu Portlet 38
3.5.8. Phiên làm việc 39
3.5.9. JSPs và Servlet 40
3.5.10. Cấu tạo ứng dụng Portlet 44
4. Phát triển ứng dụng và Workflow cho Portal 44
4.1. Kiến trúc Portlet 45
Chương III: Mô hình kiến trúc tối ưu để xây dựng ứng dụng Portal 48
1. Giới thiệu qua về các mô hình phát triển Web thông dụng hiện nay 48
1.1. Mô hình tổng quan trong phát triển Web 48
1.2. Mô hình JSP 49
1.3. Mô hình MVC 50
1.3.1. Định nghĩa 51
1.3.2. Mô hình JSP Model 2 architecture . .51
2. Đặc điểm của các ứng dụng chạy trên nền Portal (Portlet) 52
2.1. Mô hình hoạt động của Portlet 52
2.2. Các yêu cầu đặt ra đối với ứng dụng Portlet . .53
2.2.1. Tính độc lập với các Portal Engine . . .53
2.2.2. Hệ thống phải hoạt động được với các hệ quản trị cơ sở dữ liệu khác nhau . .53
3. Mô hình truy xuất cơ sở dữ liệu . . .53
3.1. Mô hình truy xuất cơ sở dữ liệu theo kiểu truyền thống .53
3.2. Mô hình truy xuất dữ liệu sử dụng Hibernate Framework .54
3.2.1. Sơ lược về Hibernate Framework . .54
3.2.2. Đề xuất mô hình truy xuất cơ sở dữ liệu .53
3.3. Các yêu cầu đối với mô hình kiến trúc .56
3.4. Lựa chọn mô hình kiến trúc tối ưu . . .56
Kết luận .59
Tài liệu tham khảo 60
 
 
 
 
 
 
 
 
 


http://s1.liketly.com/flash/edoc/jh2i1fkjb33wa7b577g9lou48iyvfkz6-swf-2014-01-17-do_an_tim_hieu_ve_portlet_va_ung_dung_trong_cong_g.furvmjCVht.swf /tai-lieu/de-tai-ung-dung-tren-liketly-54960/
Để tải bản Đầy Đủ của tài liệu, xin Trả lời bài viết này, Mods sẽ gửi Link download cho bạn sớm nhất qua hòm tin nhắn.
Ai cần download tài liệu gì mà không tìm thấy ở đây, thì đăng yêu cầu down tại đây nhé:
Nhận download tài liệu miễn phí

Tóm tắt nội dung tài liệu:

ại
Khôi phục (). Khi bạn nhấn vào nút hay thì các nút này sẽ được thay thế bằng nút . Nút này được dùng để khôi phục lại kích cỡ ban đầu của portlet.
Kéo thả (): nếu bạn muốn di chuyển portlet đến một vị trí khác thì bạn nhấn vào nút này, đồng thời kéo chuột đến vị trí mới và thả ra.
Trợ giúp(): Bạn có thể click vào đây để nhận được trợ giúp.
3. Giới thiệu về chuẩn JSR 168
JSR 168 – viết đầy đủ là Java Specification Request 168. Đây là chuẩn được phê chuẩn tháng 10 năm 2003, phát triển bởi Java Community Process nhằm hoàn tất các thao tác giữa các bộ phận của Portal và Portlet, chuẩn này giúp đơn giản hóa việc phát triển các ứng dụng portlet và cho phép các nhà phát triển tạo các thành phần ứng dụng có khả năng “cắm và chạy” trên bất kỳ nền tảng hệ thống J2EE Portal nào.
3.1 Những nền tảng chung của Portlet
Một server portal quản lý các yêu cầu của client. Giống như một ứng dụng Web phía máy chủ có một web container để quản lý việc "chạy" các thành phần web (như servlets, jsps, bộ lọc filters, v.v...), một portal có một portlet container để quản lý việc chạy các Portlets. Chú ý rằng hầu hết các ứng dụng web phía máy chủ, chẳng hạn như Tomcat, có thêm các chức năng bổ sung bên cạnh web container (console quản lý, CSDL người dùng, v.v), còn bao gồm vài ứng dụng web đặc biệt (chẳng hạn ứng dụng web administration).
Portal được đánh giá là một mẫu tương tự, cung cấp ở mức cao hơn các chức năng bao quanh portlet container chúng gắn chặt với đặc tả, cho phép ứng dụng portlet trở nên khả chuyển, giống như ứng dụng web.
Portlet API là một mở rộng của đặc tả servlet, điều đó có nghĩa là một portlet container cũng vậy, theo định nghĩa một web container. Hình 2.2 chỉ ra stack Portal, nó xác nhận làm thế nào các phần khác nhau được xây dựng phía trên nhau để cung cấp một portal server.
Hình 2.2: Stack Portal
3.2 Định nghĩa
- Portlet một thành phần web có khả năng gắn nối (plugable) được quản lý bởi một portlet container, cái cung cấp một cách linh động nội dung như là một phần của sự kết hợp giao diện người dùng.
- Fragment Kết quả việc thực thi một portlet, một đoạn các ngôn ngữ đánh dấu (HTML, XML..) nó gắn với một vài qui tắc.
- Portlet Container Môi trường thực thi của một portlet. Nó quản lý vòng đời của portlet và quản lý các yêu cầu từ portal bằng cách triệu gọi các portlets bên trong container.
3.3 Portlets và Servlets
Portlet API là một mở rộng của servlet API. Thế nên, có cả sự tương đồng và sự khác biệt giữa các thành phần. Điều này là quan trọng để hiểu những nét độc đáo (đặc thù) này để hiểu tại sao lại có một portlet đặc.
Điểm tương đồng
Portlet và Servlet đều là thành phần web J2EE.
Cả 2 được quản lý bởi container, điều khiển sự tương tác giữa chúng và vòng đời.
Mỗi cái sản sinh nội dung web động thông qua cơ chế request/response.
Điểm khác biệt
Portlet sinh ra framents trong khi servlets sinh ra một tài liệu hoàn chỉnh.
Không giống servlet, portlet không nhảy tới trực tiếp một URL.
Portlet có một lược đồ request phức tạp hơn với 2 loại yêu cầu là: action (hành động) render (đáp ứng).
Portlet gắn chặt đến một tập chuẩn hóa các trạng thái, modes chúng định nghĩa các thao tác ngữ cảnh và những qui tắc đáp ứng (render).
Điểm vượt trội
Portlet có một cơ chế phức tạp hơn để truy cập và cố gắng cấu hình thông tin.
Portlet phải truy cập đến hiện trạng (profile) thông tin người dùng, ngoại trừ người dùng cơ sở và giữ chức năng cung cấp thông tin đặc tả servlet.
Portlet có thể thực hiện việc viết lại portlet, vì thế để tạo một liên kết thì nó độc lập với việc cài đặt ứng dụng portal server (nó có rất nhiều cách để theo dõi thông tin phiên làm việc. . .)
Portlet có 2 đích sessions khác nhau trong đó lưu trữ các đối tượng: ứng dụng chung và portlet riêng tư.
Điểm yếu hơn
- Portlet không thể thay đổi HTTP header hay thiết lập mã hóa các trả lời (response)
- Portlet không thể truy xuất URL mà client dùng để khởi tạo các request trên portal.
- Các ứng dụng portlet là mở rộng của ứng dụng WEB. Vì thế cả 2 ứng dụng được triển khai (deploy) trong file WAR (Web Archive file) và cả 2 bao gồm một file mô tả triển khai ứng dụng web (web.xml). Tuy nhiên một ứng dụng portlet còn bao gồm một file mô tả triển khai ứng dụng portlet (portlet.xml)
- Vì một ứng dụng portlet là một mở rộng của ứng dụng web, nên logic mà nói nó có thể bao gồm những thành phần ứng dụng web khác. Portlet có thể sử dụng JSPs và servlets để cài đặt những chức năng của nó.
3.4 Những tương tác trong Portal
Ta sẽ chỉ ra rằng làm thế nào một tương tác portal điển hình xuất hiện trước khi đi vào chi tiết làm thế nào một portlet có thể tự hoàn trả (render) với JSPs và servlet.
Hình 2.3 ở dưới chỉ ra một chuổi các sự kiện xuất hiện bên trong portal để quản lý một hồi đáp (render) điển hình của client. Bên trong portal là Portlet API – phục tùng mệnh lệnh của portlet container chúng quản lý trạng thái thực thi của portlet.
Hình 2.3: Sự kiện trong Portal
Container đánh giá những portlet đó thành các framents, hay là tạo yêu cầu (request) của portlet hay là lấy một fragment trong cache. Sau đó, container nắm fragment đến portal server để kết hợp chúng vào trong trang portal.
3.4.1. Portlet Interface và lớp GenericPortlet
Giao diện portlet định nghĩa (cách thức) thái độ mà tất cả các portlet phải thực hiện. Một cách cụ thể, chúng ta nên kế thừa (extend) lớp GenericPortlet để xây dựng portlet, bởi nó cung cấp kiến trúc chứa tất cả những cách cài đặt portlet điển hình, không chỉ đơn giản những cái mình cần.
3.4.2 Vòng đời Portlet
Rất giống như servlet, vòng đời một portlet được quản lý bởi container, và có cách init (khởi tạo) nó được dùng để quản lý những yêu cầu khởi tạo (tạo tài nguyên, cấu hình, vv...). Portlet chỉ được tải về khi cần đến, trừ khi bạn cấu hình container để tải chúng ngay khi khởi động. cách init lấy một đối tượng object đã cài đặt (implement) lớp giao tiếp interface PortletConfig, cái quản lý các tham số khởi tạo và bó tài nguyên của Portlet: ResourceBundle. Đối tượng này có thể được sử dụng để lấy tham chiếu đến Object đã cài đặt (implement) lớp giao tiếp PortletContext interface.
Nhà phát triển portlet không hoàn toàn mất thì giờ e sợ về sự phức tạp của biệt lệ khởi tạo (exception) portlet container, bởi thông thường chúng được lấy ra, và nhà phát triển tác động trở lại lên chúng (gỡ rối những tình huống có thể dẫn đến biệt lệ exception và sửa chúng cho chúng nếu có thể). Tuy nhiên, đáng chú ý là một unavailableException có thể xác định thời gian mà portlet sẽ không thích hợp. Cả 2 đều có ích (giữ cho portlet container luôn cố gắng liên tục tải portlet) và làm không vừa lòng nhà phát triển (tại sao portlet container không tải lại portlet của tui ?).
cách destroy cung cấp một cơ may để xoá hết các tài nguyên được thiết lập ở cách init (khởi tạo). Điều này tương tự với portlet destroy trong servlet, và được gọi mỗi khi container tống khứ portlet. Khi một exception được đưa ra trong cách init của portlet, thì cách destroy được đảm b

---