Chris Jolley and Bob Bergman did a webinar today on the Ajax capabilities of WebLogic Portal 10.0. We had an enormous audience - we are happy to see the amount of interest in this feature. The replay of the webinar will be up in about a week, and the slides are already posted. This blog entry will cover some of the many questions that were asked during the webinar.
NOTE: this blog entry was originally posted February 14th, 2007 on my previous blogging system (dev2dev.bea.com).
WebLogic Portal 10.0 Ajax Summary
A WebLogic Portal desktop is esssentially an instance of a portal. A desktop has these features:
- Shell - define the overall layout of the portal, usually with a header and footer.
- Look and Feel (LaF) - is a set of CSS/JS files that are applied to the portal, which can be dynamically changed at runtime
- Books - a tabbed set of pages, each desktop has a top level book, and any number of nested books
- Pages - a container of portlets and nested books
- Portlets - application windows, built using a variety of technologies including JSP, JSR 168, JSF, JPF, WSRP, etc.
In WebLogic Portal 9.2, portlets can be declaratively specified (just enable a checkbox in Workshop) to render via an XmlHttpRequest (Ajax). What this means is that when a user interacts with the portlet, only that portlet needs to be refreshed. WLP handles all of the link rewriting to make this happen.
In WebLogic Portal 10.0, the entire desktop can be Ajax enabled. The way this works is the first request to the desktop brings back the entire desktop as before. However, whenever a user interacts with a portlet, or if there are events that change the page, only the pieces of the desktop that need updating are refreshed. This is done using an XmlHttpRequest.
For a more detailed explanation, I encourage you to:
- Download the slides, available NOW on wlp.bea.com
- Watch the webinar replay, which should be available in about a week on dev2dev Live!
WebLogic Portal 10.0 Ajax FAQ
While Chris was presenting the webinar, we got a massive number of questions typed in from meeting viewers. There were 3 of us from the WLP engineering team hammering away at the answers. It was hard to keep up! We saw a set of questions asked multiple times, so I wanted to blog about those and present the answers in a durable way.
What do these terms mean: XmlHttpRequest, XHR, JSON, Dojo, etc?
These are standard technologies in use today to implement Ajax applications. The XmlHttpRequest (XHR) is an out of band mechanism to issue HTTP requests from Javascript. JSON is an alternative data serialization format to XML. Dojo is a popular Ajax framework. There are plenty of resources on the web that can describe them in more detail.
How does WebLogic Portal 10.0 work with other Ajax frameworks, like Dojo, DWR, GWT, etc
We haven't formally certified WLP with any of these frameworks, but we have found through informal use that client side frameworks like Dojo work well. A hosted demo of WebLogic Portal 9.2 can be on wlp.bea.com, which uses Dojo to implement drag and drop.
What is the N+1 problem?
The WebLogic Portal 10.0 Ajax feature avoids the N+1 problem - but what is it? In this case, we are talking about scalability and the number of requests issued from the browser to the server. 'N' refers to the number of portlets on a page. What you don't want when the user first requests the desktop URL (or refreshes the page) is for the browser to issue a request for every portlet. If there are 10 portlets on the page, that would cause 11 requests to be issued - 1 for the page, and 10 for the portlets (N+1).
WLP 10.0 solves the N+1 problem by returning the entire rendered desktop page on the first request for the desktop (so that's 1, not N+1). Thereafter, when a user interacts with portlets on the page, they will be updated individually without a full page refresh (once again, 1 request per click).
What is IPC?
IPC is inter-portlet communication. This is most often seen in the master-detail use case - when a user clicks on a link in one portlet, it causes a detail view to appear in another portlet. WebLogic Portal has a rich eventing model for server-side IPC, that is fully supported by the Ajax feautre. When the Ajax desktop is enabled, a single XmlHttpRequest will be issued when the user clicks in the portlet. On the server side, the portlet runs through a lifecycle and publishes IPC events. If another portlet wishes to participate, it will also be re-rendered. Both updated portlets then return on the single response. One request, one response, multiple portlets are updated.
When should I use the WebLogic 10.0 Desktop Ajax vs. the 9.2 style portlet Ajax
It depends on what you want. The 9.2 solution is fine grained - it is enabled per portlet. It allows you to enable Ajax only for the portlets that need it. However, the 9.2 approach has a drawback in that it issues a request per Ajax portlet. So if all portlets on the page are individually Ajax enabled, the N+1 problem will appear. In that case, the 10.0 desktop Ajax is the recommended solution.
Do all WLP features (like WSRP, entitlements, threading, caching, IPC) work with WLP 10.0 desktop Ajax?
With only a few minor exceptions, yes. The webinar has a slide that covers a few cases, but overall the Ajax feature encompasses almost all WLP features.
What are the security issues to be aware of with the Ajax feature?
This is a difficult question to answer succinctly because there a number of considerations. But here is a quick list:
- XmlHttpRequest: the browser will refuse to load an XmlHttpRequest if it is directed to a domain different to the parent page. WLP's feature abides by this rule.
- HTTPS: the Ajax feature will use the protocol of the parent page, so HTTPS is supported.
- Entitlements: WLP uses a role based system called entitlements to provide authorization of portlets. The Ajax feature honors entitlements, just like non-Ajax portlets.
- Identity/cookies: XmlHttpRequests do pass cookies, and so the identity of the user is maintained with the Ajax feature.
What about iframes?
WebLogic Portal supports iframe portlets, and they are still a valid approach. They can consume content from any domain (unlike XHR), and seem similar to XHR in that they bring back content out of band of the primary page request. However, there a number of limitations with iframes, including an inability to participate in IPC.
How does the Back button work with the Ajax feature?
XmlHttpRequests are not hooked into the Back button on browsers. Therefore, the Back button will take the user to the last full page refresh, and will not unwind portlet/page refreshes that used the Ajax feature.
What is Adrenaline, and how does it work with the Ajax feature?
Adrenaline is a technology that allows WLP portlets to be consumed outside the the WLP portal framework. Consuming pages (like a legacy webapp, or your Vista desktop, or your Mac OS X desktop) can render the portlet without the encompassing page. When rendered from a web page, there are two major options for rendering an Adrenaline portlet, covered in this article:
- iframe: the consuming page uses an iframe to bring the portlet onto the page
- WLP 9.2 style Ajax: the consuming page can also include an Ajax snippet that in effect uses the WLP 9.2 portlet Ajax capability
No comments:
Post a Comment