-1-

Web 2.0, Using Web 2.0 in WebSphere Portal

Series: Web 2.0 for Lotus, WebSphere Portal and You

Listen to Pete Janzen from IBM Lotus interview various experts from the Lotus and

WebSphere Portal development teams on Web 2.0 technologies. Hear how IBM has

utilized these technologies in the various products and how you, the developer, can

leverage them in your custom applications.

Abstract: John Boezeman discloses how WebSphere Portal embraces Web 2.0

technologies like Ajax and REST. Hear how composite applications, aka enterprise

mashups, have evolved in WebSphere Portal and where they are going in the future.

You'll also get information on how WebSphere Portal 6.0.1 introduced the ability to

leverage Google Gadgets within your portal applications. John Boezeman is an

architect for WebSphere Portal.

Discussion:

JANSEN: Welcome to our developerWorks podcast series on Web 2.0 as it applies

to various Lotus and WebSphere Portal offerings. My name is Pete Jansen and I am the

Product Manager for Lotus Component Designer and Enterprise Integration for the

Notes and Domino platform.

I am your host for this podcast series where I will interview a number of our technical

thought leaders on topics related to Web 2.0. Our objective is to enlighten you on the

various concepts and technologies that comprise Web 2.0 and how they apply to the

products we develop.

In this podcast we will explore the topic of using Web 2.0 and WebSphere Portal. I am

-2-

very pleased to welcome [John Boezeman] who is an architect for WebSphere Portal

and IBM Senior Technical Staff Member.

John has been instrumental in leading the adoption of Web 2.0 technologies and

WebSphere Portal. Welcome to our podcast series, John.

BOEZEMAN: Thank you.

JANSEN: Okay, so I thought we'd start off with just kind of getting some a little

bit of historical information. And if, you know, since WebSphere Portal has been around

for a number of years as a premiere portal platform, I was just wondering if you could

please outline how WebSphere Portal has evolved its support for building Web 2.0 style

applications?

BOEZEMAN: Yes, so in the past especially back when Portal started it was back

even in the Netscape 4.7 timeframe. There's not, there's things called [I layers] before

even [div tag] supported in the common browsers and IE, just at that point in time IE

[forward] just added it.

So Portal at that time was doing mostly server side rendering and didn't take advantage

of some of the new features that were starting to come out in the technology.

Since that time, we've added full support for all the new Web 2 type of aspects from the

client side rendering to partial page rendering to doing social interactions in the browser

to take advantage of some of the new browser features and functions.

Virtually anything that is supported by the different browsers that you want to do in your

applications can be done in WebSphere Portal.

-3-

And this was all done to add additional innovation and productivity to your applications:

things like being able to allow users to contribute, being able to do collaboration, things

like the situational app support and some of the mashups. Ajax is used, and previous

discussions about and some take advantage of some of the other new things that are

coming in the Web 2 space.

JANSEN: Oh, great. Yes, as you just mentioned in one of our other podcasts in

this series a colleague of yours, [Stefan Hessner], provided some information on really

how Ajax has been utilized in WebSphere Portal.

But I was just wondering if you could kind of provide some of the highlights for using

Ajax in WebSphere Portal so that we have this in the context of this podcast.

I know that we touted a bunch of Ajax related capabilities in WebSphere Portal 6.0 and

maybe you could just kind of refresh us on those and give us an update to where we are

today.

BOEZEMAN: Sure. Portal provides several different ways of doing different Web 2

aspects. There's many different areas in Web 2 both from rendering to also some of the

collaboration aspects that we really care about.

For example, one of the key features that portal provides is a way to provide [govern]

mashups -- be able to combine public data, enterprise data and protect that data. So

secure, rich applications which we call composite applications allow you to assemble

and deliver those services to a business user and allow you to do some self service.

That's one aspect of contribution of Web 2.

-4-

Additionally, we allow you to do things like user contribution through the new document

support and in line editing kind of features. So for example, as I'm editing Web content,

you can in place directly edit the content, just like you were doing the wiki today with

common applications.

We allow the users to control and customize the different aspects to their needs. We've

done things like Ajax portlets. We use Ajax in many different places. Just like you

probably listened to [Stefan Hessmer's] presentation, we use it around navigation, we do

it with parts of portlets that are rendering, we have Ajax enabled themes, skins and so

forth, to really make it look like a desktop application.

We've also done and some of the new things coming out in the future are things like

assembly that you, if you...and then portal [INAUDIBLE] conferences down in Orlando,

or in Munich. You'll see some of the new things that we're doing like even moving our

rendering and assembly from the server's IP and even being able to be done in a

browser. So you can pick if you want the server to render or if you want the client side in

the browser to render to get different throughput, different performance and

characteristics.

Additionally, things, we had a big announcement earlier this year with Google Gadgets.

With Google Gadgets ports [over] virtually any or most of the Google Gadgets work

inside Portal Server. Both the I frame mode and so forth. They'll allow you to have more

additional external content and apps.

And additionally, we are doing things like you can go download one of the highly

downloaded portlets is the feed reader in Ajax support that we put on the catalogue. So

you can also do feed support and also additionally, we're doing things like proxying and

secure processing, protect the data that you're going against.

-5-

JANSEN: Okay. So you touched on a bunch of things there. First off, the

Google Gadget capability that we announced earlier this year, this allows you to bring in

a Google Gadget into a portlet, I believe, in WebSphere Portal and then go ahead and

have that Google Gadget interact with other portlets on your page. Does that kind of

summarize it?

BOEZEMAN: Yes, yes. So you have, we have a generic Google Gadget portlet that

allows you to browse the different catalogue of Google that thousands and thousands of

gadgets that are available. And you can pick any one of those and then to be used

inside the Portal Server.

Additionally, all the properties and the property sheets that are associated with that

gadget is available under the edit mode. So you can actually personalize that Google

Gadget for your end users or have an admin define the default properties for that widget.

So, for example, I could take a date time picker and change its color to blue for when I

see the date time.

JANSEN: I see. So explore, excuse me, expose its properties and then we also

provide you the ability to do inter portlet communication or wire them together to pass

data from other parts into the Google Gadget, correct?

BOEZEMAN: Yes. Some of that features you have to be careful on the data and

the back end data, the gadget. What properties that it exposes to surface that capability.

But since it's wrappered in a portlet you can take advantage of the existing wiring

features and property broker features that we have in Portal Server.

JANSEN: I see. And so customers who are interested in exploring this further

-6-

can go out to the WebSphere Portal Zone and download that portlet and then start to be

able to leverage this capability for Google Gadgets.

BOEZEMAN: Exactly.

JANSEN: Excellent, excellent.

Let's see. So, oh, the other thing you were kind of talking about was how we've

leveraged Ajax. And so from an application development perspective, we have

capabilities that are built into the core WebSphere Portal platform that provide Ajax

functionality and that's what you were alluding to there.

And then above and beyond that, we have various tools be it portlet factory, a Rational

Application Developer that have built in capabilities that allow you to take advantage or

implement Ajax functionality within the portlets and portlet applications you're building.

BOEZEMAN: Yes, yes. So there's many features from that both from the tooling

side, for example, in portlet factory you can, they have builders for all different kinds of

Ajax enabled portlets so you can have, they have builders for a lot of the different

column renderings, table renderings and so forth so you can have those go out be it the

next page through an Ajax called alt.

Then with just a few clicks through GUI of portlet factory, you can generate portlets and

have that preembedded widgets. Additionally, we have wizards in Rational Application

Developer to allow you to generate Ajax based portlets.

We also, IBM's contributing heavily to the dojo environment and the dojo works just fine

inside portlet so you can have dojo in different environments.

Also there's, we've worked with other third party vendors like Adobe with Flex. We even

-7-

have Flex in portlets and so forth. So we've done a lot to open it up to allow any

different widget vendor and so forth or virtually any that work inside of portlets because

we don't restrict that.

But we've also done things like augmenting the dojo to allow it to be accessible, to allow

it to be fully supportive of the different location support based on IBM's contribution back

to dojo.

We use dojo, for example, inside some of the out of box themes and skins for rendering

and assembly. In the new, if you play around with the current open beta of Portal 6.1

you an see that a lot of new Web 2 features enabled like we talked about the client side

assembly of the page so assembling the whole page in the browser.

And this allows you to get partial page updates so you can as I interact with one portlet it

doesn't affect the other portlets. We do a lot of things in there also. We have a proxy

that allow you to proxy your data.

So say your data comes from a different domain, your browsers will restrict that. We

have a proxy so you can go through a proxy to get to that back end third party domain.

We do things like, we have active content filtering going on to allow some of the content

you're doing to save on all active content if that's what you want or filter it.

We've surfaced things like the feed reader portlet that we talked about. And the feeds

capability inside. We also heavily use Atom and ReST style type services inside of

Portal Server not only for this new assembling aspect, but also making those services

available so you can consume in your own portlets.

-8-

So for example, if I want to go get the navigation I can access the feed version of that.

Or I can go through a JavaScript interface to go retrieve that and it'll retrieve it via an

Atom request. Or an Atom will come back over and retrieve the data and you can do

whatever you want with that data like generate your navigation widget or something of

that nature.

So we've tried to take advantage of a lot of the new Web 2 features that fully enable

them in all the different browsers nowadays to surface those capabilities.

You can still do it in the existing product. So Portal 6.0 and 5.1 you can take advantage

of Ajax calls as Stefan probably explained in his podcast. Ajax [INAUDIBLE] back in 4.1

you can have Portal Server. So you can do that inside your portlet.

What we're now doing is opening up our different models and our services to also be

enabled as a Web 2 service via ReST style and Atom to be able to recombine to

whatever fashion you want as a consumer.

JANSEN: Excellent. Okay. That was kind of where I was going to go a little bit

next on some of the, you know, making sure that we did touch on the other technologies

that we typically associate with Web 2.0.

We've had in this series some podcasts on RSS and Atom and ReST and I think what

you were just saying basically gives us the, how we've gone ahead and utilized or

exposed these technologies to be used within WebSphere Portal.

I think that the feed reader portlet you were referring to is something that probably gets

used a lot for integration with other systems. And maybe when we get to the next

section where I kind of want to ask you about where we're going with composite

-9-

applications we can get more into maybe a little bit more discussion on ReST. But I

think that was a lot of great information, thanks, John.

So, you now, once your portal typically is a platform that allows you to aggregate dispirit

applications and so, you know, we have been a platform for delivering these composite

applications which are also referred to these days as mashups.

This type of application is typically associated with the technical side of Web 2.0. So,

you know, I recall back in WebSphere Portal 6.0 we introduced the capability of

composite application templates. So kind of giving you a little bit, a way to go ahead and

templateize your composite application definitions.

I was just wondering if you could provide some insight as to how composite applications

in WebSphere Portal have evolved to where they are today.

BOEZEMAN: Yes, sure. One of the things we saw after talking with a lot of

customers and feedback we've got and Portal back in Portal 5.1 was a lot of customers

wanted to take advantage of one aspect of Web 2.0 is user contribution and also some

of the self discovery aspects.

And one of the things that, and so we saw that missing or not necessarily exposed as

nicely as we wanted it to. So that's one of the reasons where composite applications

came from.

Composite applications from a high-level perspective is the ability to assemble different

disjoint content, maybe portlets, maybe some business logic and some set of pages or

portlets or some other type of components together into a template that's reusable,

recombinable, you can create multiple instances of that application, you can specify

-10-

points of variability.

By that I mean you can, so if I hear I need the following three types of parameters filled

out when I create an instance of this whole application. So there's these initialization

parameters that you can specify and surface as part of the template.

So you want to define this application, this nice mashup of these different business

logics, portlets and so forth. And assemble them together and be able to define them as

a reasonable recombinable template and then I can create instances of this application

by specifying some creation criteria. And then reuse them.

A good example of this in previous products is a [team space]. If anybody's looked at

Lotus Quickr, for example, they surface this capabilities similar to creating multiple team

spaces.

The idea I have three or four pages, a set of five portlets, I might have some back end

business logic like a wiki or a blog or some other back end service that needs to go

create a database table for example, composite apps allows you to define that set up of

pages and those portlets and even relate the business applications and components that

are not necessarily portlets that are also related to that composite application.

Additionally, then Portal now provides several life cycle management operations to those

portlets and those registered business components. Those business components are

registered using Eclipse extension framework. So there's a plug in XML that you define

for your business components.

And then inside there, we, Portal will even instantiate an instance of this application we

will notify the business components and the portlets that, hey, you're being instantiated.

-11-

And that business component might need to go create a database table, it might need to

go retrieve something out of the database, it might need to go call an EJB to do

something as part of this initialization.

And then there's several other life cycle notifications going on. Things like, I need to

serialize you and achieve your component, your whole application. And I need to

restore your application to a particular version. Or I need to delete that application

because I no longer need this application and go clean yourself up.

And there's a whole other session that we've had in the past on composite applications.

So I don't want to take up the whole time for this discussion, right.

But the idea is, is it's got a self management aspect so your business users can manage

the roles as a way to expose our fine-grained permissions into a higher-level role of

mappings.

So a business user can manage his, for example, team space or his workspace that he's

created. And allows us the user contribution and allow users to take back control of their

application so that you don't have to bring in an IT shop for each of these type of

operations.

JANSEN: Excellent. So that kind of almost speaks to some of the social

aspects of Web 2.0 when here we are providing the technical underpinnings that allow

that to be realized.

BOEZEMAN: Exactly, exactly.

JANSEN: So I was going to ask you, how, you know, what we're doing for

-12-

composite applications, a.k.a. mashups and WebSphere Portal differs from some of the

more consumer oriented mashup technologies we hear about these days.

It sounds to me like you just kind of gave us a bunch of those differentiators there and

how we've implemented this infrastructure. Would you, is that pretty much what you just

alluded to there?

BOEZEMAN: Just to be clear on that. A couple of key things I think that

differentiate us. One is the life cycle management aspect. I think that's a key one that's

often overlooked in a lot of the very light mashups that you see in today's technologies.

Where they just say I have some data and I want to go augment, go map with some

data. That's a very light mashup where you're not really controlling the data, you're not

controlling how it's really assembled.

Versus something in Portal where I'm saying that here's a managed component, I have

access control, very fine-grained access control around each element in the component.

I can control where that data came from, who it came from, I can pass in credentials on

getting that data and I can really take that data and manipulate it.

Along with that the composite applications gives you that lifecycle operations that you

virtually never see in any of the other lightweight kind of mashup tools that you see out

there.

For example, if I'm getting that data, maybe I need to, you know, because of compliance

and government regulations, I need to know what's on my site on January 1st, 2005. If

you're doing one of those light type of assemblies, you don't have that ability to go back

and look at the archive or restore back to that restore point.

-13-

Or say someone went and modified that mashup and it doesn't work and I need to get

back to the previous working version immediately I can't restore back.

So I think those life cycle operations are some really key aspect when you start dealing

in the business world with real business cases along with the enterprise ready access

control support. Those are some of the key, I would say, differentiators between us and

that.

But this also doesn't stop just to be clear, it doesn't stop you from doing lightweight

assemblies also. Inside your composite applications, you can take full advantage of

every Web 2.0 feature. You can take a Google Gadget for example, or a map or

something of that nature and mash up it with some data that came from the business

unit by calling Ajax calls back to the business component or to the portlets.

So you can do those client, those lightweight client side kind of mashups inside of

composite application or in just in Portal in general if you want to.

The thing that composite app really gives you is for the really enterprise kind of

applications where I need to track my data, I need to have the persistence and restoring

life cycle operations, really brings it up to the forefront.

But there's no reason you couldn't take those life cycle component models, take your

favorite client side widget and framework and assemble them together, mash them

together from that perspective. And when you try to do even surface some of that with

some of the new things we're doing in 6.1 about the proxy for example.

JANSEN: Excellent. So that's where I wanted to go next. I was just wondering

-14-

if you could kind of share some thoughts on where we are going with Web 2.0 as it

applies to WebSphere Portal and our future releases.

So I think you can talk about certainly, you know, WebSphere Portal 6.1 which is out in

beta now and just some ideas that you have about where we're going in general.

BOEZEMAN: Yes. I probably already stole your thunder a little bit by talking about

a few of the things earlier. But just kind of summarize those and also talk where we're

going from a long-term perspective to even maybe post 6.1.

From a high-level perspective, we're...portals been embracing the Web 2 and Ajax for a

while. 5.1 we had some Ajax, we had Ajax based kind of a themes and scan support.

6.0 we have, we are actually using it in all of our, in several out of box themes and

scans. Also in several portlets some of the composite app portlets that do Ajax calls that

go retrieve partial next set of tables and so forth.

And since that's become some, is now more common throughout the industry in the

different browser platforms, we can really start taking advantage of it internally. So that's

one big use case that we see and that's where we're going further.

As you see when in some of the new features in 6.1 if you play around with the current

open beta, you'll see that we've really embraced it for the capability.

But we also just to be clear, we also don't stop the...if you really want the fine-grained

server control that's fully supported so there's no, it's...and inside of an application,

inside of a page, set of hierarchy pages you say this page should be rendered on a

server or this page could be rendered on the client.

-15-

And so we in embracing the Web 2 technology, but not stopping the traditional type of

rendering mechanism if that's what your IT organization or as a customer you would like

to have.

But we, in 6.1, and you can play around with this in the 6.1 beta, we've completely made

it so that the Web 2 client side library is going to be a whole set of public APIs, allow you

to talk back to Portal Server.

We're exposing a lot of our data models available as ReST style services and the

protocol we picked was Atom as a way that we're exposing it.

And then we've provided a JavaScript infrastructure around that Atom to allow you to, so

you don't have to talk and decode Atom, you can just talk to JavaScript.

So, for example, you can go get the navigation model in Portal just via JavaScript. It'll

under the covers talk, open up an Ajax call to the Portal Server and retrieve the

navigation model as Atom and render it back as a JavaScript object.

This allows you to just write the nice Web 2 kind of fabby code in the client and now you

have access to the entire navigation. You have that access to that for the portlet

preferences, for some of the user groups features, to the page layout. So you can even

do your own client side rendering how you want to assemble the page in 6.1.

Additional service we allow you to do, we have a federation services that allow you to

make federated at the navigation level, multiple portal navigations together. And so just

ReST style services that we can access.

It also now assemble multiple portal navigations together, it's something we call

-16-

federated portal or [rubler] portal as some people like to call it.

We allow you to do how it retrieves the data, we can go through proxies to go retrieve it.

So we provide a very, a nice proxy that's being used across multiple products for

proxying the data to get outside the [tobain].

We are doing things like the whole, a new one is called, what we call semantec

frameworks or semantec tags. We allow you to find tags in your mark up to mean

different things.

For example, I might have a span tag that say class equal V card. And now anything in

that span is considered a V card. So you might only have to put an e-mail address

there. Now we can look in your current LDAP that you associated that portal with and go

retrieve the entire LDAP record for that user.

So when you hover over [John Boezeman] when it appears on a page, when I hover

over it, I can click there's a set of actions that expose up. Like, for example, you might

see my picture, my e-mail address, phone number, be able to go chat to me, send me

an e-mail and it will augment with other actions.

In your markup as the end user, also you had to specify was a span tag and class

equals, you know, WPS V card and give us an e-mail address, a wraparound whatever

text you wanted.

And so this makes it a lot easier for an author, content creator to augment their pages

with all kinds of additional semantic frameworks and semantec tags.

You can imagine you could do this for something like an address, a city, state kind of

-17-

aspect. You can do it with phone numbers, you can do it with...even we do several

demos that you'll see in the 6.1 with you are old click to action demo where we have

order IDs and order entries.

I can hover over an order ID and then click on it and submit it to different widgets all in

the browser. So it sends it over to the, which event to that widget in a browser. Then

from there, you can call back to the server to go retrieve that individual portlet markup.

So we've really made almost most of those services that people use and take advantage

of on the server side, exposing all those features and functions in the browser. So from

the rendering to the eventing to client side eventing to the ability to do partial portlet

updates.

Another thing we've done in 6.1 is allow you to take an existing application and we'll

automatically replace all the different form submits and anchor links that point to, back to

the portlet. We replace those with JavaScript calls that call a local code and that will do

an Ajax call underneath call back to that portlet.

So we can take an existing portlet and basically Web 2 Ajax-ify that portlet and make

that portlet work on a partial page update. So, I mean, it works for...you know, there are

some caveats, I don't want to say that works for every portlet that anybody's ever written

because if you do JavaScript kind of assembly where you're assembling the URL we

can't easily detect that in a browser.

But if it's a nice, well-structured portlet, we can basically turn it into an Ajax enabled

portlet without a customer ever having to write a single line of code or even know how to

spell what an XML HP request is or the return codes and so forth. So you can take your

existing portlets and basically allow them to play ball in the Web 2 space.

-18-

Additionally, you know, we've turned in, made several [thinks] and feeds. We've also

have, are doing things with calendar and documents. A document supports being able

to feed and we're embracing it across the product stack.

I'm assuming that in one of these other podcasts, they've also talked about that to you all

and how we're embracing the connections products and the quicker products, making

the data be available in the ReST style feeds so they can recombined and assembled

together.

So those are kind of the things in the immediate 6.1 timeframe. There's a lot more detail

that we can go into whole session on just some of those finer grain things.

But additionally, I'd like to just talk beyond 6.1 and maybe it might make 6.1 but beyond

6.1 some of the things that we're also looking at is allowing you to do some additional

client side kind of mashups from the component model.

So no only can today, like I said, you can do the rich composite application mashups and

assemblies and managed real enterprise assemblies. And you can also do client side.

We don't provide some built in mechanisms for doing some of that client side other than

through some other JavaScript frameworks and so forth.

And we're looking at maybe in the long term providing some UI frameworks around

allowing you to do those client side mash ups very easily and targeted towards the

business user kind of set of widgets and so forth.

So you can do those client side assemblies very easily and set up the eventing between

them all from a client side. So we're, so that's kind of a future direction, you know, watch

-19-

this space kind of aspect.

But those are kind of the...so we're really just to kind of summarize. You know, you can

see throughout almost everything that we've done we're really trying to surface these as

ReST style feeds and services, a lot of features and functions.

And we're using it but at the same time we want to protect in the investment in today's

existing environments and apps. So all the existing old ways work. You don't have to

use the Web 2 theme if you don't want to.

If you don't have to take advantage of Ajax if you don't want to or take advantage of the

proxy if you don't want to. All these features we try to make them as just ways to

augment you as a consumer even beside which and where it makes in your

infrastructure, where you would like to take advantage of and where you would not.

As a platform we try to make, surface all these things multiple way. There's three or four

ways to do an almost everything from a Web 2 to a service side to a mixed model. And

to make it so you can combine it whichever way makes sense for you as a consumer.

JANSEN: I think you summarized it very well. One thing that caught my

ear...well, there's many things, but one thing in particular was the fact that a developer

can go ahead and Ajax-ize, I think was the term you used, to an existing portlet and

without having to do any additional work.

So I think that's something that people will definitely like to explore and will be very

interested in, as well as the numerous other features that we're implementing here in

WebSphere Portal 6.1, as well as where we're going in the future around some of the

client side aggregation things.

-20-

BOEZEMAN: And related to that, I just when you said that it made me remember

one other new thing that we're having in 6.1. Not in the current 6.1 beta but it will be

when we update the next refresh probably of the beta.

And that's the ability to define your pages and normal your favorite HTML editing tool

along with CSSs and so forth. And then upload those into portal. And so you can

basically use your favorite tools, upload those pages and create portal pages that base

off those templates.

And we created a new tag just like we have the span class equals, you know, V card.

There's a span and a class equal, you know, WPS portlet. This will allow your Web

content creators, they can create and use your, their favorite HTML editing tool the

define the whole page layout.

And then wherever they want the portlet to go, they just put this span with portlet, you

know, it's like a portlet goes here tag but you span class equals WPS portlet. And then

you, we require one parameter that tells us the concrete portlet name.

With that, we allow you to, you know, create whole portal pages and portlet instances

without having to use RUI for example. Now you can create those in your favorite tool

and upload them into portal and portal when the [VAS] surrender that page will use that

HTML to render the page.

So you no longer constrain to our layout mechanism that we do in Portal. You can use,

you know, CSS positional layout, you can take advantage of all the layer features from

that perspective and [div] based layout. You can define your...you don't even have to

use themes in that example. I could define a whole page as an HTML file and take over

-21-

the whole page. And bypass the themes if I want to.

Or I can include if you have, if you don't include the H, the body tag and the HTML tag,

then we'll render the themes. But in the content area of the page, we'll render that

HTML as a fragment.

So this allows you to take advantage of any of the latest technologies and rendering

mechanisms but now insert portlets wherever you want to just like you would an image

tag.

JANSEN: That's great. Thanks for that additional bit of information. So I think

what we want to do is strongly encourage our listeners to go out to the WebSphere

Portal Zone and that's where you can go ahead and get the download for WebSphere

Portal 6.1 beta.

As part of that there's also a WebSphere Portal Factory 6.1 beta. So we would love for

our audience to go out and download it, use it and especially provide us with feedback

on it so that we can go ahead and improve the product before we go ahead and GA it.

So, John, thanks a lot for taking the time to talk to us today and provide some great

information. I just like to remind our listeners that this is one in a series of podcasts that

we've done here on the use of Web 2.0 within Lotus and WebSphere Portal products

and I'd like to thank you all very much for listening today.

[END OF SEGMENT]