WebLogic Portal 10.0 Ajax FAQ

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

Technorati Tags: weblogicportal,ajax

My Favorite Browser Based Development Tools for Internet Explorer

If you aren't using browser based development tools to help with your web application development, it is time to start. With Ajax enabled sites becoming common, View Source is no longer a reliable debugging approach. Also, when looking into issues like Cross Site Scripting (XSS), it is useful to have an embedded HTTP monitor. Firefox users seem to have universally adopted Firebug, but what about Internet Explorer? I personally use two IE tools, IE Developer Toolbar and IE HTTP Analyzer, and this blog explains why they are useful.

NOTE: this blog entry was originally posted February 7th, 2007 on my previous blogging system (dev2dev.bea.com).

My Toolbox

This blog discusses the browser based tools I use for troubleshooting and debugging in the web world. Every developer has their likes and dislikes when it comes to the tools they use. Discussions that compare and contrast different development tools like IDEs often degrade into religious tirades. I am not asserting that my toolbox is necessarily the best - it's simply what I use and what I like. Please add comments to this blog entry if you have found other tools useful. This blog will explain the capabilities that I use with these tools, but I will not cover all of the features.

Both of these tools are client side solutions, and install directly into Internet Explorer. I like the convenience of these features being one click away as I am working with a page. I personally use IE 7, but both of these tools work with IE 6 as well.

IE Developer Toolbar by Microsoft

The IE Developer Toolbar is a free download that snaps into your IE browser. By default, the tool pane is hidden from view. When you want to use the tool, you click on one of the options in the menu toolbar. This tool is great for debugging page content issues.

IE HTTP Analyzer by IEInspector Software LLC

The IE HTTP Analyzer is a modestly priced download that snaps into your IE browser. By default, the tool pane is hidden from view. When you want to use the tool, you click on the small icon to the right of your Page/Tools dropdown. This tool allows you to inspect all aspects of the HTTP protocol as your browser makes requests.

The rest of this blog will describe some use cases for which I have found these tools very helpful.

Use Case 1: Page Inspection - Viewing the Current DOM

Tool of Choice: IE Developer Toolbar

The View Source feature on browsers has no small place in the history of the web. How many people first learned HTML from a book? I, like most other developers, learned HTML using the View Source feature. The rapid expansion of the web back in the 90's was probably helped tremendously by this browser feature.

The View Source feature also used to be a great debugging tool while developing dynamic web projects. JSP not rendering correctly? View Source to the rescue. However, while View Source still has some use, it is no longer a reliable tool to help your development efforts.

Today's websites are far more interactive than the pages of just a few years ago. By way of DHTML and/or Ajax, the HTML that came back from the last page request may not be what the user is currently seeing. As you likely know, parts of the page DOM may get updated as you work within the page. View Source unfortunately is not tuned into this: it will only provide the HTML from the last page load.

Fortunately, the IE Developer Toolbar can help here. It has a View DOM capability that enables the developer to inspect the current state of the DOM for the page. When enabled, the tool will create a new window pane at the bottom of your browser that will show the DOM tree. For each node in the tree, you can inspect its style attributes and text children. As dynamic page capabilities change the DOM, the tree will be updated to reflect the changes. Also, a handy feature is the "Find by Click" capability. This enables you to navigate the tree by clicking anywhere on the page, and the DOM viewer tree will find the element you clicked on.

For example, WebLogic Portal 9.2 can make any portlet Ajax enabled. This prevents clicks within the portlet from causing page refreshes - it will update only the portlet instead. To capture the returned HTML from a portlet update, View Source will do no good. View DOM is the way to go.

Use Case 2: CSS Debug - Why is that text green?

Tool of Choice: IE Developer Toolbar

Cascading Style Sheets (CSS) allow for sophisticated page styles, but come at a price. At times it can be difficult to pinpoint why a style has been applied to an element on the page. Have you ever had trouble determining why a piece of text is a certain color? Or why the font is not what you expected?

WebLogic Portal has a sophisticated Look and Feel capability that allows developers to fine tune the appearance of a portal page. Styles can be associated with page tabs, portlet headers, portlet backgrounds, menus, and many other things. When I work on a Look and Feel, sometimes I need a little help to make things look right.

The tool that I find most useful is once again the IE Developer Toolbar. The DOM inspector allows me to click anywhere in the tree, and look at the applied styles. Then, I can walk the tree upwards until I discover which class the style is coming from. Because this is done in the browser on a rendered page, it is a very accurate and quick approach.

Use Case 3 - Monitoring Requests: Performance and Security Aids

Tool of Choice: IE HTTP Analyzer

Performance

While there are many useful server-side performance tools available, it is still helpful to have a client side tool. There are several scenarios that can be seen on the client:

• Too many artifact requests - a single page may use hundreds of images/css/js files
• Big artifacts - images/css files may be abnormally sized
• Too many XmlHttpRequests - Ajax gone wild can overload the server

The IE HTTP Analyzer when enabled appears in a pane at the bottom of the browser. The top section of the tool shows the list of requests that the browser has issued. With each request, it shows the size in bytes of the response, the response time, and other attributes. With this feature, the above performance concerns can be quickly identified.

Security

Cross Site Scripting (XSS) testing has become an important part of the QA cycle when developing web applications. The typical behavior of a XSS attack is that it will send rogue requests to malicious systems from your browser. I recently wrote a blog entry about a specific XSS vulnerability with PDF files. While I was exploring that issue, it was useful to be able to see those rogue requests being emitted.

I found that the request monitoring feature of IE HTTP Analyzer to be useful in this case. It allowed me to easily see the problem, and validate that the solution that I implemented was sound. For security testers and for developers working on XSS issues, I think this tool is quite helpful.

Use Case 4: HTTP Headers - Viewing and Setting

Tool of Choice: IE HTTP Analyzer

Viewing

Request/response headers are a cornerstone of the HTTP protocol. Every request and response have them, and the information contained within is quite important. Cookies, caching, browser specific HTML, language detection - headers make these features possible. With any feature, sometimes things just don't work correctly.

IE HTTP Analyzer allows you to view the request and response headers for each request. This can be enormously useful when troubleshooting problems related to the headers. This week it helped me diagnose an issue with an incorrect mime type being returned for a resource.

Setting

There are cases when being able to view the headers is not enough. I recently did a blog post about implementing Single Sign On (SSO) with WebLogic Portal. The solution required a server side component to detect a special token in the request headers that contained the user identity. In a production environment, a proxy server would do the job of inserting the header. But while developing the solution, I wanted an easy way to test the implementation.

Once again, the IE HTTP Analyzer gave me a great solution. The tool provides an easy way to clone a request, and then muck with the request headers. In my case, I needed to clone a request to my WLP instance, and then add a test SSO token to the request header. The Request Builder can then rerun the request with the new header, providing a very easy way to test my implementation. See the image below on the tool in action - notice the new header I added (text selected).

Additional Resources

Browser Tools

• IE Developer Toolbar: cannot argue with free
• IE HTTP Analyzer: modestly priced, but worth it
• Firebug: free plugin, traditionally used on Firefox, but also has some IE support. Anyone using it on IE?
• Web Developer Extension: another free plugin for Firefox, I haven't tried it myself.

Online Tools
These are convenient, but only work for testing internet accessible web servers.
Note: these are proxies hosted by 3rd parties, it probably isn't wise to login to your bank through them.

• Web Sniffer: a free hosted tool that proxy's your request, and then prints out the headers. Supports HTTPS.
• Rex Swain's Http Viewer: same, but no HTTPS support.

WebLogic Portal

• WebLogic Portal Demo Site: demo server hosted by the WLP engineers
• Josh Lannin's blog: Group Product Manager, WLP
• My blog: WebLogic Portal, Enterprise Mashups, Propagation Tool

Technorati Tags: browsers,IE,http,javascript

Google Analytics informs me that I am fluent in Chinese

It is well known that Google Analytics is a nice technology, but I would have never guessed that it could reveal a useful skill that I didn't know I had - the ability to write fluent chinese. Well, that isn't exactly true, but in effect it has done that. Let me explain...

NOTE: this blog entry was originally posted February 2nd, 2007 on my previous blogging system (dev2dev.bea.com).

wlp.bea.com

In my various writings on dev2dev, I have provided links back to the demo site I work on - wlp.bea.com. That site contains a number of demos running on WebLogic Portal 9.2 related to Enterprise Mashups, Ajax, Drag and Drop, and Google Gadget technology. If you have read my stuff, you will see the code name Adrenaline, which is a part of the WLP Mashup story. The demos for Adrenaline are on wlp.bea.com. The site is a great way for WLP product engineers like myself to demonstrate new WLP features, or new uses of the existing WLP product.

Google Analytics

Many web admins know of Google Analytics - it is a free service provided by the mother ship. It provides a set of great features for answering questions like:

• How many people have visited my website?
• How many page views do I have per day?
• What Google Search terms drive people to my site?
• Where are my visitors from?

Not only is it useful, it is really easy to implement. You simply need to add a javascript snippet in every page on your site. Google does the rest. About a month ago, I implemented Google Analytics for wlp.bea.com so we can understand better how popular the demo site was, and what people liked looking at. Although we are all technical people who work on it, the business concept of ROI (investment being our time) is important to us.

dev2dev.bea.com.cn

I took a look at my Google Analytics console for wlp.bea.com today and saw something strange. See the image below.

The fact that Adrenaline is not a big hit in Africa and Greenland is not what I found strange. I would like to see more Canadians visiting, but that isn't entirely strange either. What was strange is that a new website became a significant referrer - see the pie chart on the right*. For the first time, dev2dev showed up twice as a top referrer. Why?

Although the UI cuts off the suffix, I could see that the second dev2dev is none other than dev2dev.bea.com.cn. OK, that must be the sister site for dev2dev in China. That made sense, but something didn't. Who is driving traffic to wlp.bea.com from the Chinese dev2dev?

The Skill I Never Knew I Had

Curious, I did a search on dev2dev.bea.com.cn for wlp.bea.com - and it is at this point that I discovered my latent skill. I can write in Chinese! My dev2dev.bea.com article on Adrenaline is also on dev2dev.bea.com.cn, but translated into Chinese. I had a native speaker take a look, and it is no babelfish hack job - it is a real translation. I didn't know I could do that! Well, ok, the real story is we must be employing chinese translators for dev2dev. I didn't know this, but I think it's a great idea.

But what I really like is how Google Analytics revealed an unexpected use of wlp.bea.com. That is what analytics is all about - finding illuminating patterns in the behavior of customers. In this case, Google delivered. Now we have data that can drive a business decision: do we hire a translator for wlp.bea.com?

And to my anonymous translator: thank you!

* the pie chart shows a blurred entry. It appears to be a mail server from Japan, but since I don't why it is showing up, I blurred it. It may somehow identify a BEA customer, and so I played it safe and obscured it.

Additional Resources

• WebLogic Portal Demo Site: demo server hosted by the WLP engineers
• Josh Lannin's blog: Group Product Manager, WLP
• My blog: WebLogic Portal, Enterprise Mashups, Propagation Tool
• Google Analytics

Technorati Tags: googleanalytics,webanalytics