Deploying Lotus Connections in a High-Scalability/High-Availability environment

Tweet

 Earlier today I got an email from a customer's IT Architect. He asked the following:

We are proposing to deploy Connections (all apps) across 3 data centers (3 Active Resilient Architecture) for the Portal/Connections RFP.    Could you please provide your input on the best way to architect the deployment of Connections across 3 sites?  For example, what are the ramifications of using a single database for say, Profiles or 3 separate Databases. If using 3 Databases, then how do we replicate?

I figured that this will be a question that will be in a lot of people's minds.  I wanted to capture my response in this blog for prosperity (and so that when someone else asks me this same question I can just direct them to this blog entry) :).  Anyway, here's my response:

This is actually pretty straightforward with WebSphere Network Deployment. And there are several approaches you can take as well. Since Connections is a J2EE application, all we need to do is set up WebSphere in a high-availability/high-scalability fashion. I've done this several times (not for Connections, but for other Lotus products that run on WebSphere).

You should probably take a look at this article first and this diagram:

The structure that I recommend is highlighted in this diagram:

Notes:

• Each part of the cluster will be on its own data center. For example, the Edge (standby) would be on a separate data center than where the normal Edge server is.
• We need to add a Caching Proxy in front of the Edge server (see figures above). The caching proxy would need to be set up in HA mode
• The slides only represent a cluster of two nodes just to show the idea.. imagine figure above with 3 boxes in each cluster
• I would rather have all application servers use the same database and have the database on hot standby and replicated via HACMP (see figures below). When one database fails, the other one picks up.
  • Alternatively, you can set the database requests to be sprayed using a DB sprayer such as Edge and have the databases replicated, again, via HACMP
• The slides don't show the LDAP. It's assumed that the customer already has a HA/HS solution for LDAP. If not, then you could set up a cluster of LDAP servers and use an IP Sprayer (Edge) to load balance the requests. Depending on the LDAP vendor, you'll need to figure out how to do the data replication.

More on WebSphere High Availability / High Scalability.

HACMP example:

Adding 'dogear this' button to your webpages

Tweet

Product development has made integration of Dogear with existing web applications even easier!!! Currently, you can add a 'dogear this' button to existing web pages by simply copying the bookmarlet code. The bookmarklet code is presented here:

var h='https://greenhouse.lotus.com/dogear'; var d=document; var b=d.body; var e=encodeURIComponent; var t=setTimeout; var dw; (function() { if(b){ a var p=d.createElement('script'); p.charset='UTF-8'; p.src=h+'/tools/blet.js'; b.appendChild(p); } t("var u=d.getElementById('dogear_postUrl'); if(u){ u=u.href; } else { u=h+'/post?url='+e(location.href)+'&title='+e(d.title); } dw=open(u+'&ver=0.9','dogear','toolbars=no,width=670,height=650'); if(!(dw==null||typeof(dw)=='undefined')){ dw.focus()}",250) } )()

Long, huh? Well, it's not that bad considering they give you the code and it's just a matter of copy-paste into all your webpages. If you are interested, this developerWorks article explains more on how to use the above code.

As of today, however, we have an even EASIER way to do this. And all it takes is two lines of code!! -- I promise, let's check it out.. First, add this line to your HTML's HEAD element:

<script type="text/javascript" src="http://greenhouse.lotus.com/dogear/tools/doglink.js"></script>

Then, add this line to the <BODY> element of your web page (right now it's a DIV but you could make it a button if you wanted to...):

<a href="#" style="text-decoration:none;" onclick="DogLink.post_to_dogear(location.href, document.title, '', '');return false;"><IMG height=16 src="http://server.com/dogear/misc/favicon.gif" width=16 border=0>Bookmark this!</A>

Note: Updated 27/Apr/2009 to fix code as per comments

That's it!! Nifty, eh? This will be available to customers in the 1.0.2 release.

More on SSO between Sharepoint and Connections

Tweet

Here are the tree options that we came up with, thanks to the help of a co-worker Martin Lansche.

3 options:
1)  SPNEGO (2-4 weeks; most of the effort is having computers join the Active Directory domain)
    Pros:
        Full SSO between the desktop and the web applications.  Only one sign-on to the user's PC and they are logged on to all the web applications!!
        No extra coding (out-of-the-box functionality - in WAS v6.1)
        Bi-directional

    Cons:
        Need all user computers to join the Active Directory domain (will the customer let us?)

2)  HTTP Headers (1-2 week)
    Pros: 
        No need for computers to join a domain

    Cons:
        Needs to go to Sharepoint first
        Needs customization to Sharepoint
        Only works one way:  Sharepoint to WebSphere (users need to sign on to Sharepoint, then go to Connections)
        It's a hack - not secure... not how it would be done in production
   
3)  URL attributes  (1-2 week)
    Pros: 
        No need for computers to join a domain

    Cons:
        Needs to go to Sharepoint first
        Needs customization to Sharepoint
        Needs to develop code on the WAS side (custom TAI adapter)
        Only works one way:  Sharepoint to WebSphere (users need to sign on to Sharepoint, then go to Connections)
        It's a hack - not secure... not how it would be done in production
 
We are currently leaning on option #1.  Stay tuned...

SSO between Connections and Sharepoint

Tweet

Continuing on this subject of single sign on, the customer has now requested SSO between Microsoft Sharepoint and Lotus Connections.  There are several ways to do this:

1. Use a product such as TAM/WebSEAL, which can be tricky to implement but the cool thing is that it not only allows SSO between web applications, it can also be used for SSO between the desktop and Lotus Connections.
2. Develop a custom Trust Association Interceptor (TAI) for WebSphere.  This minimizes the cost, but requires a Java Developer to know WebSphere's TAI API in order to do this.  If you haven't heard of,or don't know what TAI is, it's awesome!!! It's really "easy" to use.  The disadvantage is that it only works if one web application links to another and can pass the username of the current user as part of the URL or in the HTTP headers.
   
3. Use TAM eSSO, a client-based utility which stores passwords.  The problem with this is that it's not really SSO.  Users will still be prompted for a username/password, but it will be automatically entered by this utility that must be installed into each user's PC.

We are currently going to pursue #2 and see how far we can get.  We are a little bit strapped for hours, so we may not be able to finish this, and as I said before, I need to figure out whether Sharepoint can create URLs to Connections and embed the username in the links.

Beautiful story on social software!

Tweet

So, on Tuesday I blogged internally about integrating Microsoft Sharepoint feeds into Notes 8. Basically, I had a hard time getting it to work until I figured out a hack. Several minutes later, a co-worker, who I've never met before, enters a comment on my blog explaining he knows how to configure Microsoft Sharepoint RSS feeds so that they can be accessed anonymously. I comment back on my blog asking to get instructions on how to do this.

The next day, while I'm working at the customer site, I get an instant message from him! Thanks to Sametime's 'Location Awareness', he says that he sees that I'm in Detroit working for the same customer that he is!! He tells me that he is in building 200, floor 25 and asks me where I'm located. I replied back that I was in tower 200, floor 27! He came up to where I was sitting and we were able to exchange war stories. It was great bonding between two IBMers who had just met.

Thanks to a blog that I wrote using Lotus Connections, I was able to make a real-life connection and solve my problem!