Integration between Portal and Quickr (J2EE Version)
Question: We've just had a customer asking the different integration approaches between Portal and Quickr (J2EE).
1.) The easiest approach for a new Quickr installation is: Why not use Quickr as your Portal? Quickr (J2EE) lives on a full-fledged WebSphere Portal 6 installation - so you could use this as your portal and deploy your applications onto the Quickr Portal or even use Virtual Portals.
The System Verification Test (SVT) Team has published some scenarios with Quickr8 Services for WebSphere Portal. http://www-1.ibm.com/support/docview.wss?uid=swg27010312
2.) If you want to have separate Portal Servers - you could use WSRP Portlets to surface your portlets on the Quickr side where needed. To keep the setup easy, you might want to use the same URL domain (for the LTPA token) and the same LDAP server. Integrating these is straightforward.
Slow Login Performance when using Active Directory
Question: How do I increase login performance when using Microsoft Active Directory as LDAP server?
Firstly, I'd like to stress the fact that the low login performance is not a problem that is specifically related to WebSphere Portal. Any LDAP based system (your Apache Server, PHP Application or any other tool using LDAP as authentication source) will have the same problem. This is related to the hierarchical structure that can grow to deeply nested subtrees in large deployments. When WebSphere Portal (or any other LDAP-based authentication mechanism) issues a search request, Active Directory has to search for the users through all sub-trees recursively, which can be time-consuming.
Depending on the Active Directory setup, maybe some of the sub-trees reside on different servers which results in network traffice between AD server nodes.
There a some ways around this:
1.) Active Directory provides "Global Catalog" Servers with a condensed version of the directory with better response times (Windows and AD internally use these, too - but with proprietary protocols, not LDAP )
You should consult with your Windows / AD admins how and where these "GC" servers have been set up. Specifically use these, not just any AD server.
2.) If it is not possible to use the GC servers, use Tivoli Directory Integrator to create a condensed version of your directory for LDAP authentication purposes only. If you do, be aware that changes made to user profiles (e.g. through self-care) need to be replicated back to the Active Directory.
3.) Re-Design the Active Directory (which is not possible in most of the cases, but for sake of completeness...) to store users and groups at specific places / in specific trees instead of scattered throughout the AD infrastructure.
Markus Nagel | 22 January 2008 05:35:19 PM ET | | Comments (0)
