With great power comes great responsibility

That's a very cool title isn't it ? ;-) We were in the Island of adventure Disney park yesterday at LotuSphere, so I buy a lot of spiderman t-shirt....
But I think this sentence is also relevant for Quickr....Let my explain why. With its deep integration with MS windows explorer, and especially with the mail client, Quickr will probably becomes the 'killer app' in the next few years. Maybe this will not be Quickr (but another editor solution), but anyway this thinking is true for all this new generation of collaborative tools.
Using the mail client connectors, you are now able to directly send a link to a document stored in a Quickr repository, rather than attaching the document in the mail message...When attaching the document to the mail, Quickr connector will automatically ask you if you want to include it in the message, or if you want to store it into Quickr and then just send a link referencing this document....That's a great feature !
But my point is that now Quickr becomes part of the desktop office, and it should have the SAME availability and reliability than your mailing system ! Let me explain that in another way: if Quickr crash (for any reason) it will be completely impossible for your employees to retrieve any documents (assuming they now store everything in your new very cool tool)....
So this is not anymore a 'simple' web application project (with wiki, blogs, etc) but it is part of your information system and of your office tools. So when deploying such a solution, you should carefully study all the impact and especially define the size of the administration team and the support team appropriately (to provide the same level of service than expected for solution like your mail system).

With great power comes great responsibility....:-)

Quickr and ECM relationship

Today I would like to talk about the relationship between Quickr and the Enterprise Content Management.
As one of the Quickr product manager said (Jelan Heidelberg / Conference about the Collaborative Document Management): "Quickr is not an ECM. Quickr is made to manage the daily work, help team collaboration". I really aggree with this point of view: you can use Quickr to work on draft version of a document, and collaborate with several people to build the final release of the document...but once your document is finalized, you probably want/should store this version is a more stable and reliable document repository.
Also talked with one of the lead developer of Quickr about this document storage strategy: he said the current version of the Product can store document either in a Domino database, or in the portal JCR 170 repository. He told me a customer has already implemented a custom feature to archive final version of Quickr document in an external ECM (namely Documentum). And as the Quickr API and model is very open, he said it is feasible to have the same approach to archive document in any other ECM.

[Basically, to give you an technical overview of how this work, the document will be phisically moved to the ECM repository and Quickr will keep only some of the document META-DATA and a reference to the ECM repository in its own database.]

And during one of the Greg Melahn conference (about the future of the product and how IBM plan to extend it), IBM will provide support for 2 new ECM for the end of year 2008: FileNet and IBM Content Manager. Also, he said that IBM (and IT services partners) will continue to provide more and more new ECM solution support in the next releases.

More about the Quickr product

Don't have the time to speak about all things that are covered here in LotuSphere, so I choose to focus on Quickr:
> First, there are now more technical solution to 'integrate' this product with the WPS portal. For instance using a new tool called 'webappintegrator' you now can insert the portal banner into a remote web app (like Quickr) to offer a consistent look and feel to the end-user. Of course this is only a light integration, and Quickr will have to run on a separate server, but it will be seamless for the user.
Also, I really prefer to run Quickr on a remote server, just to make sure it will be not impact the portal runtime. Whenever possible I try to build our front intranet portal as a read 'only' tool (to ensure stability, and good performances), and Quickr is of course a typical read-WRITE application. So separation is a good thing, assuming this will be seamless for end-user.
> Quickr also offers some very useful connectors for Notes mail client or Symphony office, and MS Office. Basically, it allows you to work directly from your mail client (or windows explorer) and to drag and drop files directly from these tool...This is a great feature. Unfortunately, there is no connector for Exchange for the moment (but should be delivered in 8.1). Having an Exchange connector is a major requirement for us, so I think we should wait and study this next version....
> My last point is a major concern: document storage management. In the current version of Quickr, documents are stored in the local (JCR 170) repository of Quickr (I think this can be considered as a similar approach as storing document locally in the portal DB, like we do in the previous PDM tool).
IBM will also offers integration facility to store document in other JCR repository. But for the moment, I think only FileNet and IBM Content Manager will be supported....I said it's a major concern because in our company we use another solution (like LiveLink or Alfresco), and storing our documents in the Quickr repository is simply not an option, just because we don't have a good vision so far on the roadmap of this solution :-)
Even if Quickr is used currently internally by IBM (most of IBM people we meet here told us that they store now all their documents in Quickr library), I still think this can not be a long term strategy for Corporate documents...but OK, for working copy, it's probably a good way to store documents.

There is a dedicated session tomorrow about Quickr and the document management strategy....so I will give you some news as soon as I can about this topic.

First day in LotuSphere 2008

First day in LotuSphere 2008,
Most of the conferences are dedicated to Domino 8 and only a few to the WPS portal....There are also a lot of presentation about Lotus Quickr and Sametime which we are really interesting.
About Quickr, we now get a clearer view of what the integration options are with the WPS tool. Basically, most of the Quickr features (especially document Library views) are exposed through
RSS Feed. So it is possible to use a simple RSS Portlet at the portal level to display a list of documents links provided by Quickr. RSS is a simple but easy way to expose data coming from Quickr,
and there is also a lot of features which are exposed through Web Services (mainly REST WS). My feeling is that IBM do not want to introduce an heavy coupling between this 2 solutions, but rather
choose to provide standard and easy solution to expose/consume Quickr data. I think that's because Quickr is a quite new product, with a roadmap which can change very quickly in the next years:
so coupling it tightly with the portal is probably not a good solution.
About Quickr performances, we don't get any information for the moment....but there are some conferences about advanced architecture and performances, so I will try to get more information about this
topic (it's important because with previous J2EE version, namely workplace, we had experienced a lot of performances issues).

About WCM multi-local site approach

IBM has recently published a very interesting article about how to manage multi-language in WCM (IBM Workplace Web Content Management) and to build multi-local sites : multi-local site

As far as I understand the proposed approach (for the moment) is to provide a sample framework to help customer building their own multi-language strategy, rather than implementing a these features in the product core...probably, because there is not a single way to implement multi-language...That's also my point of view. As this framework is based on the WCM public API, customer can easily customize it to match their specific needs.

I wanted to get more information about the roadmap of this multi-language framework, so I asked some questions to David De Vos. So in this post, I just want to share some of these info.

I asked him if IBM has any plan to include this multi-local framework in a next release of the WCM product (as a "core features"), or will IBM continue to provide it as a separated sample ?
As you might remember (see previous post), we (in my company) also have developped our own framework to support multi-language. It is also based on the WCM public API. So we could choose to replace our framework with the IBM one (to implement a solution more aligned with the IBM solution), but this code migration will require a lot of efforts....So, I'm trying to identify the pros & cons to justify this operation (and using a "core feature" could be a good argument for migrating).

So here is basically what David told me:
--------------
The plan is to start to replace some of the components in the new multi-local framework sample code with WCM core function (that is either the same or better) and that over releases most of the stuff in the whitepaper (it could be everything but IBM would never to commit to that) will become core to some degree...

Using this new multi-local framework will provide the following benefits:
* Allow customers to share custom code developed from it with the community,
* Provide customers with more features (assuming customers custom solution doesn't already do everything the sample code does)
* Allow you to remove parts of the same code with core function once it becomes available, thus leaving you with less code to maintain.
--------------

Another of my question was : regarding the roadmap, could IBM confirms that most of the framework should be merged as core feature in release 6.1 (for Q3 2008) ?
--------------
David explains that:
This new framework merge is an ongoing line item that is unlikely to be complete by 6.1.. David said that he can't provide any more concrete details than that as they aren't simply available for the moment...
--------------

I think that whatever custom approach you could have already implemented in your company, this new multi-local framework for WCM should be studied carefully, because some of the provided features are really interesting...I have to work on these subject in the next month, so I will try to give you more details about this new approach.

About WCM rendering performances

We launched our intranet early 2007 in production....What a big effort ! It is always what I say after each portal project deployment. As for today, my experience is that even a "small" portal project requires at least 6 month before going live in production. But planning is not the subject of this post.

When I joined the project, the team was facing a lot of performances issues. The first reason is that people didn't really take care about response time constraint when doing custom developments...It is often the same problem: development team must deliver new features quickly and people are not always ready to invest time (and money) to design a robust solution, with a good caching strategy.
However, thinking about how to design and implement a cache should be studied carefully for every project which should run under heavy load.
So before going live, we spent a lot of development effort on each components: theme, WCM Portlet, and back-end Portlet. The biggest issue was how to optimize the WCM Rendering Portlet response time (because our site is mostly composed by WCM Portlet for the moment).
We, in my company have implemented a custom WCM/WPS java framework, mainly to implement the multi-language capability in WCM. Because of this custom layer, most of the standard WCM caches was not appropriate in our context. Indeed, WCM does not support multi-language, so neither does the WCM cache....
We now have created several type of caches, for several kind of WCM Objects, all based on the WAS dynacache. Dynacache is a good way to cache object, and it is really simple to use.
One of the most powerfull cache we have developed is working as follows: through a custom JSP component, we are able to retrieve the full HTML output of the Portlet and to set it in cache. Next rendering phase are really optimized because there no request to the WCM repository at all (only a lookup in the dynacache).
We also tried to directly cache the WCM content object into our own cache...but this is simply something to avoid because WCM object are associated with the workspace which was initially used to retrieve them from database. So except if you only use public WCM content (visible by every user), which could be the case for internet web site, this approach should not be selected.
For the moment, most of our caches have been enabled for the public area of our site (for anonymous user). In this case, the caching strategy is simple because we do not have to worry about content security (and cache key are really simple). If you implement your own cache, you should carefully think about security access for object which are stored into cache.
We now have really good response time for our public pages. But now, more and more people are connected to the intranet, and they clearly see that response time are not so good after authentication (the HTML output caching is not enabled)...It is hard to understand from the end-user point of view.
So our next challenge is to think about how to cache WCM content, for the authenticated user. One of the biggest problem in this case is how to share cache entries for people which share the same profile. In our context, it is hard to mutualize cache entries, because peoples belongs to distinct UserGroups, and it is difficult to identify generic profiles.
I think other option will be to use Ajax. As we always use WCM JSP component to perform the WCM Portlet rendering, that is technically possible. However, I'm wondering if using Ajax on every WCM Porlet will not generate some side-effect (especially if several Ajax servlet tries to access to the WCM repository at the same time)....I will try to give some update about this problem in a next post.

Welcome message

Hello,

This blog is officialy open ! I created it to help people sharing information about WebSphere Portal project...big subject isn't it.
We (in my company) have deployed this solution to build our corporate intranet...
It's a quite large web site whith about 10.000 unique users per day, coming from all over the world, and from several business units.
We have implemented a full multi-linguism portal, based on the WCM tool (but with a lot of custom developments....). For this first release we also use the PDM (document management) and the embedded search system (portal search engine).
Deploying a portal project requires to manage and understand a lot of distinct tools and technologies. It's a hard but also very exciting work for an architect !
In this blog I will try to share some information about the difficulties and the successes we experience on this project. This blog is intended for architects, project managers and developers who deals with portal and especially the WPS plate-form.
So now please feel free to participate !