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

Implementing Single Sign On (SSO) with a WebLogic Identity Asserter

I worked on an interop project this week that required me to do something I haven't done in a while - develop an SSO solution for WebLogic Server or WebLogic Portal. In this case, my WebLogic Portal 9.2 instance needed to consume a token in the request header and derive Identity from that. In the WebLogic world, an Identity Asserter is the tool for the job. This blog entry details the steps to implement a custom Identity Asserter with WebLogic Server (or WebLogic Portal).

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

 

Identity Asserters and Single Sign On

An Identity Asserter is a pluggable WebLogic component that can determine the identity of a user through inspection of a token in a request header, a cookie, or other mechanisms. This is a useful feature to employ when implementing Single Sign On for your WebLogic project. It allows for an external entity to authenticate a user, and enables WebLogic to honor that authentication.

Identity Asserters aren't new. They have been with WebLogic for years. Out of the box, WebLogic provides an Identity Asserter that supports a variety of token types: X509 certificates, SPNEGO tokens, SAML assertion tokens, and CORBA Common Secure Interoperability version 2 (CSIv2). In addition, 3rd party Identity Management vendors will typically have a pre-built WebLogic Identity Asserter available for you.

However, there are times when a custom Identity Asserter is required. This is the approach I pursued on my project. In my case, an external proxy server has authentication capabilities, and places a token on the request to WLP that identifies the user. I needed a custom Identity Asserter that could look for that token, and decode it. To build my custom Identity Asserter, I took the sample from dev2dev and modified it to suit my needs. I have deployed this on WebLogic Portal 9.2 (which is built on WebLogic Server 9.2). The rest of this blog explains the development and configuration steps.

 

Development and Configuration of a Custom Identity Asserter

Below is the list of steps to build and configure the Identity Asserter:

0. Download the sample Identity Asserter from dev2dev

• Available on dev2dev Codeshare here (as of 2009, no longer available. see comments)
• Look for a project called "Sample Security Providers"
• The samples may not be for your exact version of Weblogic, but they will likely be compatible from 8.1 onwards.
• The download will contain a build system as well as samples of other types of providers

1. Unpack and alter the SimpleSampleIdentityAsserter code and descriptor

• Look in src\providers\identityassertion\simple, you will need to modify both .java and .xml files
• Search and replace "SamplePerimeterAtnToken" in all files with the name of your custom token/request header
• In SimpleSampleIdentityAsserterProviderImpl.java make these changes:
  Where the sample code is working with TOKEN_PREFIX in the assertIdentity method, you will need to change the code to parse the value of the token, perhaps decrypting it, and derive the username. The work done here is very specific to the type of token you are expecting.
• If you don't want the container to automatically decode the token payload using Base64 decoding, make sure you have this in the .xml descriptor:

   <MBeanAttribute
    Name          = "Base64DecodingRequired"
    Type          = "boolean"
    Writeable     = "false"
    Default       = "false"
   />

  
  
  
  
  
  
  

2. Go to your WLS/WLP domain home/bin, and execute setDomainEnv.cmd/sh in your command line shell.

3. Navigate back to the root dir of the SSPI sample directory where build.xml exists.

4. Compile with default Ant task ("ant"). The build puts the jar in BEA_HOME/weblogic92/lib/mbeantypes/wlSecurityProviders.jar

5. Edit web.xml of the webapp that will participate in the Identity Assertion and add/update the login-config element:

  <login-config>




    <auth-method>CLIENT-CERT</auth-method>








    <realm-name>Legacy_ThisElementIsIgnored</realm-name>








  </login-config>

6. Launch WLS/WLP (startWebLogic.cmd/sh).

7. Launch the WLS console (usually http://localhost:7001/console), and create a new instance of this Identity Asserter.

• Navigate to Security Realms -> My Realm -> Providers tab -> Authentication sub tab
  
  
  
  
  



• Click "Lock & Edit"
  
  
  
  
  



• Click "New"
  
  
  
  
  



• Name = [give it a meaningful name] Type = SimpleSampleIdentityAsserter
  
  
  
  
  



• Click "Release Configuration"
  
  

8. Restart the server.

9. Target any resource in the web application with a browser in a way that properly populates the token. You should see output from the debug in the Identity Asserter indicating that the user has been identified. If the username exists in a configured authentication provider, the request will be authenticated.

Next Steps: Left as an exercise to the reader:

Rename SimpleSampleIdentityAsserter to something more appropriate

• Change SimpleSampleIdentityAsserter references in .java and .xml files
  
  
  
  
  



• Update the build to reflect the name change
  
  

Additional Resources

SSO Related:

• Official documentation for Identity Asserters for 9.2
  
  
  
  
  
  



• dev2dev Codeshare example (as of 2009, no longer available)
  
  
  
  
  



• SAML Configuration: a good article by Vikrant Sawant on how to configure SAML
  
  
  

Technorati Tags: weblogic,security,sso,identityasserter

Want short SaaS/Cloud news updates throughout your day? Subscribe to the ondemand Twitter microfeed. http://twitter.com/ondemand

WebLogic Portal Propagation Tool Field Guide

The WebLogic Portal product offers rich capabilities for propagating Portal applications from one environment to another, often from Staging to Production. Because Portals may be changing in both environments at the same time, a reconciliation step is required to update the target environment. The WebLogic Portal Propagation Tool offers this capability. This blog introduces the Propagation Tool Field Guide, which is now available to discuss best practices and known limitations with the tool.

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

What is the Propagation Tool?

The Propagation Tool's primary purpose in life is to provision WebLogic Portal environments with configuration data. The provisioning can be done for a new WLP environment, or as a promotion of updates on top of an existing environment. A propagation is typically immediately preceded by the promotion of a new EAR file, which contains updates to the code artifacts of the application.

To support this primary mission, the Propagation Tool in WLP 9.2 supports these features:

• Exports database and LDAP configuration artifacts as XML files, all packaged into a single zip file (called an inventory file)
• Advanced reconciliation UI allows an operator to visually choose exactly how to reconcile the two environments
• Promotes the new configuration using the inventory file that came from the visual tool
• All operations can also be done using Ant tasks, as an alternative to the visual tool

For more information on the many features of the Propagation Tool in 9.2, please visit the official documentation. The docs take you through the primary use case of the Propagation Tool - moving WLP applications from one environment to another.

Click here for a more detailed diagram.

Release 9.2 is a Major Milestone

The Propagation Tool in WebLogic Portal 9.2 received major updates from the version offered with WebLogic Portal 8.1 SP5. Most significant were these improvements:

• Eclipse User Interface - provides a visual, tree based view reconciling the configuration artifacts of your Portal environments
• Ant tasks - a rich set of Ant tasks have been provided
• Offline story - the Eclipse UI and Ant tasks combine to provide the ability to do most of the propagation work offline from the running servers
• Content Propagation - ability to move Content Repository artifacts, specifically Content Nodes and Types

Introducing the Field Guide

In support of the major launch, I have been working with customers that are implementing the Propagation Tool in their WLP 9.2 projects. From this experience, I have been assembling a Field Guide that provides:

• Best Practices - how best to employ the new toolsets and be successful with Propagation
• Known Issues - a list of known issues and common pitfalls that have arisen with customers using the tools

This Field Guide is being updated on a regular basis (about once a week at this point) as new customers and new issues arise. You may find the guide linked from this site:

Click here to view the Propagation Tool Field Guide

Encouraging Feedback

Good or bad, we actively seek out feedback from the use of the Propagation Tool. There are multiple channels to do this:

• Support Cases - open a Support case at the eSupport site (see a stack trace, open a case!!!)
• Portal Newsgroup - ask a question on the WLP dev2dev newsgroup
• Professional Services - we are in close contact with the BEA Professional Services team
• Blog about it - like this customer did, Anders Mathisen

We like to hear about positive experiences, and when that isn't possible, constructive criticism and questions about problems with the tool.

Resources

• Official Documentation - BEA edocs
• Propagation Tool Field Guide - linked from wlp.bea.com
• My Blog - I will blog about Propagation from time to time, like this entry that demonstrates non-standard uses of the Propagation Tool.

Technorati Tags: weblogicportal

Off the Beaten Path with WebLogic Portal's Propagation Tool

Fast becoming the Swiss army knife of WebLogic Portal 9.2, I will discuss some non-standard uses for the WebLogic Portal Propagation Tool. In addition to a myriad of application provisioning use cases, the Propagation Tool can provide solutions to problems in areas such as Change Reporting as well as Backup and Recovery of WebLogic Portal applications.

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

What is the Propagation Tool?

The Propagation Tool's primary purpose in life is to provision WebLogic Portal environments with configuration data. The provisioning can be done for a new WLP environment, or as a promotion of updates on top of an existing environment. A propagation is typically immediately preceded by the promotion of a new EAR file, which contains updates to the code artifacts of the application.

To support this primary mission, the Propagation Tool in WLP 9.2 supports these features:

• Exports database and LDAP configuration artifacts as XML files, all packaged into a single zip file (called an inventory file)
• Advanced reconciliation UI allows an operator to visually choose exactly how to reconcile the two environments
• Promotes the new configuration using the inventory file that came from the visual tool
• All operations can also be done using Ant tasks, as an alternative to the visual tool

For more information on the many features of the Propagation Tool in 9.2, please visit the official documentation. The docs take you through the primary use case of the Propagation Tool - moving WLP applications from one environment to another.

This blog entry covers some alternate use cases for the Propagation Tool. The toolset that we built is very flexible and can cover more than just promotion use cases. I will cover 2 use cases in this blog that uses the Propagation Tool on a single environment. Before I cover the use cases, I will talk about a best practice that is relevant to this discussion.

 

Best Practice: Historical Inventories

These use cases require that you create and retain a series of historical inventories for the environment. This is a good idea for so many reasons that we recommend that inventories be retained in source code control (if size allows) or a backed up disk drive (for huge inventories). The idea is to periodically take a snapshot of the environment and store that inventory. Think of your inventory as a peer to your code assets - the same care you put into maintaining historical versions of your code should be applied to inventories.

Note: inventory snapshots do not replace the need to do database and file system backups.

 

Use Case 1: Change Reporting

Do you ever wonder how much configuration work has been done in an environment over a period of time? The Propagation Tool can help answer that question. It provides a logical view of exactly what has changed in an environment, as an alternative to dredging through audit logs.

For example, imagine that you have taken a baseline inventory on December 1st. On December 15th, you want to see what Admin changes have been made to your WLP enviroment. To do this, export a new inventory and compare it the baseline inventory with the Propagation Tool Eclipse User Interface. The user interface will show you the net differences in a logical, visual format.

 

Use Case 2: Backup and Recovery

The pain of all operations people is to have to recover an application to a previous state. While traditional backup and recovery procedures are still relevant for WLP environments, the Propagation Tool can provide additional options that will help you get home in time for dinner. Database backups and file system backups can provide point in time recovery options, but may be too big a hammer for certain cases. The Propagation Tool is a more precise instrument, but it does not handle all configuration data , so it does have limits in a recovery role. I will show some cases where the Propagation Tool is the right tool for the job.

For example, imagine that your Portal Administrator deletes a page on a desktop in production accidentally, and the problem is not discovered for 3 hours. After flogging him with a bundle of network cables, what is your next step? A point-in-time database restore is probably not an appealing option, as it will take a lot of your time, will require application downtime, and will result in data loss of updates made after the mistake. Instead, consider a targeted propagation that fixes the problem at the logical level. Using a historical inventory, the Propagation Tool can be used to restore that specific desktop in the production environment. This can be done while users are interacting with the application, so it is a quick and easy approach. It is also precise - it will not disturb any configuration artifacts outside of the scope of the propagation.

Here is a table that suggests a toolset to use for different failure scenarios. In cases where only WLP artifacts in the application need to be restored, the Propagation Tool is generally the best option. The table shows a sample set of use cases, but in fact the Propagation Tool can handle many more types of data in a similar fashion. Also, it should be noted that any problem that is fixable using the Propagation Tool is also fixable by manually affecting changes through the Portal Admin Tool.

* For Portal Framework use cases, be aware that the Propagation Tool cannot restore end user customizations if the artifact was deleted, if any exist for that asset. For example, if a user made customizations to the deleted page, the Propagation Tool cannot restore that. If user customizations are important to recover, another tool called XIP could be used together with Propagation.

Additional Resources

• Propagation official documentation
• Propagation Tool Field Guide - best practices, known issues
• developer.com article - a look at the 8.1 SP5 web app based Propagation Tool (an ancestor to the 9.2 tool)

Technorati Tags: weblogicportal,weblogic

Build Enterprise Mashups with BEA WebLogic Portal 9.2

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

Plug: Don't miss my Webinar on Wednesday, January 10th, 2007 that demonstrates how BEA WebLogic Portal can power Enterprise Mashups today!

Mashups Gain Momentum in the Enterprise

Enterprises are beginning to look at a concept called Mashups to facilitate application development within IT. This approach is gaining traction due to these benefits:

• Mashups focus on lightweight integrations of applications which enables rapid development
• An application component is developed once, and is easily reused and integrated elsewhere
• Public availability of massive amounts of Mashup components, such as Google Gadgets, enables IT to build applications at a lower cost

All of these reasons make Mashups a popular choice both in the consumer space, as well as in the enterprise. In this blog, I will discuss how BEA is helping IT deliver on these initiatives.

The Novelty of Consumer Mashups

Need a beer in New York City? There's a mashup for that: NYC Beer Mashup
Want to stalk a celebrity? Here's a mashup that'll help: Celebrity Home Mashup

Amusing? Yes. Useful? Not so much.

The consumer web brought us Mashups, but I expect that more value from this approach will come from the enterprise. BEA has taken the lead on delivering products that will enable enterprises to create dynamic, user-focused, Mashup sites. Let me explain...

Back to basics - what is a Mashup?

You can define a Mashup web application in a variety of ways. Wikipedia starts with a broad definition:

"A mashup is a website or application that combines content from more than one source into an integrated experience."

You can tighten that definition as you like, but I think we need to recognize that this concept eludes a strict definition. I will suggest instead some common attributes that in my opinion are indicative of a Mashup web application:

• The components come from applications that were developed and deployed independently without knowledge of each other



• The components may be implemented using different technology stacks: Java, .NET, RoR, etc.



• It is straight forward to snap the components together, without a heavy weight back end integration. Browser side integrations are acceptable.



• The combined result provides a new useful way of using the components



• Ideally, the user has some capability to define and customize the integrated application

On the consumer web, Google Personalized Home Page is a good representative of these characteristics. For example, you may build your personalized page with Google Map, Travelocity, Currency Converter, and weather gadgets to compose a travel planning mashup.

Building a Mashup

When assembling a Mashup, there are two types of software involved:

• Mashup Composition: composes components into an integrated application. Portal frameworks and browsers often fulfill this role.



• Component Producer: delivers the application component that surfaces on the Mashup.

When looking at WebLogic Portal 9.2, we will identify how it provides capabilities in both of these areas.

WebLogic Portal 9.2 Delivers Enterprise Mashups

An Enterprise Mashup is simply a mashup web application that is deployed to support an Enterprise, targeting it's customers, employees, or partners. WebLogic Portal 9.2 released in June 2006, and offers capabilities to support both Mashup Composition and Component Producer use cases for the enterprise.

To support Mashup Composition, WLP's portal framework serves as the aggregation framework that assembles the components into a unified application. WLP provides two features that enables this capability: URL portlets and WSRP portlets. URL portlets allow any arbitrary URL to be rendered in the Portal. WSRP is a standard that uses Web Services to accomplish the aggregation.

For the Component Production use case, WLP 9.2 introduced a technology called Adrenaline. Ths core capability offered by Adrenaline is unique to WLP amongst our competitors: HTTP addressable portlets. Any portlet can be exposed as a URL, which therefore enables WLP portlets to surface on external web applications using iframes or html streaming approaches.

The beauty of Adrenaline is that it works on top of the existing WLP enterprise portal framework. While competitors seem to view the Enterprise Portal and Enterprise Mashup spaces as separate, BEA WebLogic Portal allows IT to solve the Enterprise Portal and Enterprise Mashup use cases in a single effort with a unified product stack.

More Information

I will be covering this topic in far more detail in my webinar. Be sure to tune in to my Enterprise Mashup webinar on Wednesday, January 10th, 2007. A replay will be available if you miss the show.

For a visual look at why Enterprise Mashups are compelling, take a look at the demo movie that we have created for WebLogic Portal 9.2.

For technical information, review this Adrenaline Article.

Read more about the concepts behind Enterprise Mashups - I like Dion Hinchcliffe's discussion in this blog entry.

 

Technorati Tags: mashup,weblogic,weblogicportal,enterprise2.0