5. Cấu trúc đồ án
1.8Kiến trúc Gridsphere
Gridsphere cung cấp thực thi các portlet, trình chứa portlet, tập hợp các dịch vụ cốt yếu và các portlet được trình bày dưới đây:
Hình 3.11 - Mô hình kiến trúc Gridsphere
Hình vẽ trên thể hiện các thành phần chính, đó là một trình chứa servlet kết hợp với một server ứng dụng web. Một yêu cầu tới portal sẽ được kích hoạt bởi trình duyệt web của người dùng sẽ gọi tới Gridsphere servlet và hành động giống như người điều vận điều khiển tới bộ máy xếp đặt chịu trách nhiệm tô chát đưa ta các kết quả thích hợp tới trình duyệt web của người dùng. Cả Gridsphere servlet và
bộ máy xếp đặt đều sử dụng các dịch vụ nhân, bao gồm cả cơ quan đăng ký portlet, để triệu gọi chính xác các portlet ở trang portal hiện tại của người dùng.
1.8.1 Bộ máy xếp đặt
Các xếp đặt trên portal được định nghĩa bởi các file miêu tả XML, ví dụ dưới đây là file XML hiển thị banner của portal
Hình 3.12 - File mô tả các xếp đặt trong Gridsphere
Cấu trúc lồng nhau của file mô tả không tạo ra sự rắc rối, mà ngược lại cho phép người dùng dễ dàng chỉnh sửa hoặc làm theo các xếp đặt này.Mỗi một thành phần xếp đặt này được định nghĩa trong Gridsphere, ví dụ như PortletFrame, PortletTabbedPane, vv..mỗi thành phần biểu thị một xếp đặt của portlet trên portal. Sơ đồ trình tự UML dưới đây thể hiện một portlet được tô chát và hiển thị trên trang portal như thế nào:
Sơ đồ trên cho thấy một trang portal đơn giản chỉ gồm một tabbed Pane, trong tabbedPane này chỉ có một tab, và trong tab này cũng chỉ có một frame
Thông thường, một trang portal của Gridsphere gồm hai tabbedPane, mỗi tabbed pane này lại có nhiều tab và frame khác giúp điều hướng dễ dàng giống như portal của Amazon hay trang web của Apple.
Như đã trình bày ở trên, một tình huống được gây ra bởi một lần kích chuột lên một thành phần thực thi hành động trên các xếp đặt, khi đó nó sẽ liên hệ tới gốc của cây xếp đặt, sau đó thành phần của cây xếp đặt sẽ được tô chát lại, tuy nhiên chỉ có những thành phần nằm trên tab gây ra hành động của cây xếp đặt chứ không phải tất cả các thành phần trên cây đều được tô chát lại.
Bộ máy xếp đặt hỗ trợ khả năng mềm dẻo và tùy chỉnh toàn phần, những thành phần mới có thế được thêm vào rất đơn giản bằng cách sử dụng một thành phần miêu tả XML và lớp thành phần tương ứng thực thi giao diện PortletComponent. Thực tế đã cho thấy mô hình bộ máy sử dụng trên Gridsphere đã được mở rộng bởi các dự án phục vụ cho các mục đích xác định sử dụng các thành phần trực quan để tô chát iFrame, XHTML và các xếp đặt khác.
Cũng có thể thấy rằng các portal khác không hỗ trợ việc tạo ra và sử dụng thành phần xếp đặt, hầu hết mới chỉ dừng lại ở chỗ cho phép tùy chỉnh thủ công và giới hạn ở một mức nào đó giống như chỉnh sửa các trang web mẫu, chúng không hỗ trợ người phát triển tạo ra và sử dụng các thành phần xếp đặt mới và trình diễn trên portal.
1.8.2 Mô hình portlet của Gridsphere
Khi dự án xây dựng Gridsphere được đề xuất thì chuẩn JSR 168 Portlet API chưa ra đời, lúc này có hai lựa chọn đề xây dựng Gridsphere. Hướng thứ nhất là dựa trên dự án mã nguồn mở Jakarta Jetspeed để phát triển, thực tế ở thời điểm đó Jetspeed là công cụ xây dựng portal mã nguồn mở nổi tiếng và đã có những bước phát triển rất đáng kể, nó đang cố gắng xây dựng nên mô hình portlet API. Tuy nhiên, nhìn xa hơn thì Jetspeed phụ thuộc và rất nhiều các dự án nguồn mở khác của Jakarta, mà các dự án này thì thay đổi rất nhanh, đơn cử như Jakarta Turbine. Thêm vào đó, portlet API được cung cấp khá phức tạp và không đủ mạnh giúp phát triển portlet dễ và đóng gói các portlet của nhà cung cấp portal khác.
Tuy nhiên, khi xem xét IBM Websphere 4.1 Portlet API đội dự án đã nhìn thấy giải pháp cho mình, tài liệu miêu tả portlet API của Websphere phần nào dựa trên portlet API của Jetspeed nhưng đã có những cải tiến đáng kể, điều này khiến nhóm phát triển Gridsphere tin tưởng rằng mô hình portlet API tương lai sẽ tương tự như Websphere API. Do đó, nhóm phát triển đã lựa chọn giải pháp dựa trên java
doc và hướng dẫn Websphere cho các nhà phát triển như là điểm khởi đầu. Trong năm đầu tiên, họ đã bổ xung Websphere Portlet API và xây dựng các portlet lõi của Gridsphere nhằm phục vụ cho mô hình đã xác định, một trong những điểm thuận lợi của Websphere là mô hình đóng gói rõ ràng, cho phép tích hợp portlet của nhà cung cấp thứ ba như Web Archive hay WAR file theo cách tương tự như đặc tả Servlet API.
Theo mô hình portlet của Websphere thì không có giao diện định nghĩa một portlet, để xây dựng portlet mong muốn ví dụ MyPortlet người phát triển phải kế thừa từ lớp trừu tượng AbstractPortlet như trong biểu đồ dưới đây
Hình 3.14 – Sơ đồ lớp khi phát triển một portlet của Gridsphere
Mô hình portlet của Websphere tạo ra sự phân biệt giữa các portlet ứng dụng và portlet cụ thể, trong khi portlet cụ thể là một thể hiện tham số của portlet ứng dụng. Ví dụ một portlet trích dẫn kho có thể có nhiều thể hiện cụ thể, mỗi thể hiện biểu diễn cho các tham số khác nhau là các trích dẫn khác nhau của một kho hoặc nhiều kho khác nhau. Như đã trình bày trong biểu đồ trình tự, một portlet ứng dụng có nhiều thể hiện cụ thể của nó được khởi tạo trong phương thức init() và initConcrete(). Tương tự, các portlet được hủy qua phương thức destroyConcrete() và destroy(). Những phương thức vừa nên chỉ được triệu gọi duy nhất một lần trong xuốt vòng đời của portlet trong khi phương thức actionPerformed() và doView() được triệu gọi mỗi khi có yêu cầu của trình duyệt phía khách. Phương thức actionPerformed() được triệu gọi mỗi khi có một hành động xảy ra trên portlet, thông thường như là đệ trình form, kích chuột vào một nút nhấn hay một siêu liên kết. Phương thức doView() thì được gọi thường xuyên hơn mặc dù mỗi portlet thường có ba chế độ khác nữa là sửa, cấu hình và giúp đỡ tương ứng với các phương thức doEdit(), doConfigure() và doHelp().
Giống như xếp đặt của portal được định nghĩa trong một file miêu tả thì cũng có một file miêu tả portlet là portlet.xml, định nghĩa các thông tin cấu hình và cung cấp cho trình chứa portlet những chi tiết cần thiết cho một thể hiện. Cả PortletConfig và PortletSetting đều được sử dụng trong quá trình khởi tạo portlet, chúng chứa thông tin đọc được từ file triển khai mô tả của portlet.
JSR 168 Portlet API thì tương tự với Websphere portlet API, tuy nhiên một portlet trong JSR 168 được định nghĩa bởi một giao diện portlet và được cài đặt bởi một lớp dựa trên GenericPortlet giống như mô tả theo sơ đồ dưới đây:
Hình 3.15 - Sơ đồ lớp khi phát triển portlet JSR 168.
Một người phát triển Portlet kế thừa lớn GenericPortlet để tạo ra MyPortlet như trong ví dụ. Giao diện chu kỳ sống được cung cấp trong JSR 168 tương tự với Websphere API, tuy nhiên không có sự phân biệt giữa portlet cụ thể và portlet ứng dụng. Chỉ duy nhất một portlet tồn tại và được khởi tạo. Thay vì sử dụng phương thức actionPerformed() để xử lý các hành động, JSR 168 sử dụng phương thức tương tự là processAction(). Không khó để tạo ra sự tương ứng giữa Websphere API và JSR 168 mặc dù Websphere hỗ trợ thêm một vài giao diện khác cho thông điệp portlet và tốt hơn về vấn đề địa phương hóa.
Sau khi JSR 168 được ghi nhận, nhóm phát triển Grisphere đối mặt với vấn đề phải làm thế nào để hỗ trợ JSR 168 Portlet API mà vẫn quản lý các portlet được tạo ra theo mô hình trước đó, để giải quyết cần hoàn thành danh sách công việc sau:
- Cho phép những nhà phát triển portlet tiếp tục sử dụng những portlet trước đó theo mô hình của Websphere mà không cần thiết phải thay đổi chúng cho phù hợp với JSR 168.
- Tiếp tục hỗ trợ sự tương thích với Websphere , cho phép người dùng Websphere sử dụng Gridsphere như một giải pháp portal mã nguồn mở.
- Không tác động nhiều vào mã nguồn của lõi Gridsphere framework trong khoảng thời gian ngắn trước mắt.
- Cho phép phát triển portlet theo mô hình portlet API của JSR 168.
1.8.3 Nền tảng dịch vụ portlet
Nền tảng dịch vụ portlet xác định một kiến trúc cho phép phát triển các dịch vụ portlet cung cấp chức năng cho portlet. Các dịch vụ portlet được thiết kế nhiều chức năng cung cấp bởi các portlets từ các dịch vụ trong đó chúng cần tương tác với nhau. Các dịch vụ portlet cung cấp sự đóng gói theo mô hình dịch vụ có thể dùng lại được nó có thể được dùng lại được bởi một hoặc nhiều portlet. Trong GridSphere, các dịch vụ được dùng để quản lý mọi thứ từ sự ưu tiên sắp xếp, những thông tin người dùng, người dùng truy cập điều khiển như là portlet đăng ký thảo luận trước đây. (adsbygoogle = window.adsbygoogle || []).push({});
Portlet Services API IBM WebSphere API cung cấp một tập hợp giao diện cho việc xác định những dịch vụ portlet và cho phép nhà phát triển lấy các thể hiện dịch vụ portlet thông qua đối tượng PortletContext. Mặc dù JSR portlet API không đề cập đến những dịch vụ portlet, chúng ta có thể cung cấp truy cập tới các dịch vụ bằng việc dùng chính “cải tiến” portlet cái mà phân lớp từ GenericPortlet cơ bản. Trong mô hình hiện tại, một dịch vụ portlet được tạo ra từ PortletServiceFactory. Một PortletService xác định giao diện trắng được cải tiến bởi giao diện PortletServiceProvider xác định một vòng đời gồm các phương thức init và destroy được dùng khi dịch vụ được khởi tạo và kết thúc. Một file cấu hình dịch vụ portlet được dùng để cung cấp thông tin lớp và khởi tạo các tham số được truy cập thông qua đối tượng PortletServiceConfig. PortletServiceFactory cũng chịu trách nhiệm khởi tạo và phá hủy các dịch vụ. Một sơ đồ lớp UML dịch vụ portlet được chỉ ra trong hình vẽ dưới đây
Như mô tả portlet hay xếp đặt, mô tả portlet services cũng rõ ràng như file XML, dưới đây là hình một ví dụ
Hình 3.17 - File XML mô tả portlet services của Gridsphere
1.8.4 Các portlet nhân của Gridsphere
GridSphere framework cung cấp một tập hợp các portlets để cung cấp chức năng cơ bản được yêu cầu cho portal một cách tiện lợi. Danh sách sau ghi thành từng nhóm nhân tập hợp của các portlet đã cung cấp:
- Login: Cho phép người dùng đăng nhập cơ bản dùng name và password
- Locale Selection: Một người dùng có thể chọn ngôn ngữ như tiếng Anh, Pháp, Đức, Ý, Hungari, Czech, Trung Quốc.
- Yêu cầu tài khoản: Cung cấp giao diện cho một người dùng portal mới để yêu cầu một tài khoản mới và chức năng chọn nhóm tham gia
- Quản lý tài khoản: Cung cấp người dùng Super và Admin khả năng cấp phát/thu hồi vai trò người dùng.
- Quản lý người dùng: Cung cấp người dùng Super khả năng phê chuẩn/từ chối yêu cầu tài khoản và người dùng Admin khả năng phê chuẩn/từ chối yêu cầu nhóm.
- Thuộc tính người dùng: Cung cấp khả năng cho người dùng để sửa đổi thông tin cá nhân bao gồm tên, địa chỉ email và lựa chọn ứng dụng portlets để tham gia
- Cấu hình xếp đặt Người dùng có thể cấu hình xếp đặt của họ bao gồm vị trí của các thẻ và các portlets trong tabs
- Portlet Subscription: Cung cấp khả năng cho người dùng thêm hay bỏ những portlets từ workspace
- Quản lý vị trí file: Cung cấp một hệ thống file ảo cho phép người dùng sửa, upload và download file lên portal
- Notepad : Người dùng có thể tạo, sửa, xóa và tìm kiếm ghi chú.
- Text Messaging: Người dùng có thể gửi tin nhắn cho người dùng khác dùng một thể hiện của Yahoo Messenger.