After exploring Kuantan and Sungei Lembing we continued our personal Discover Malaysia trip to Genting Highlands Theme Park. After having seen the orginal a number of times it was obvious where Genting's inspiration came from (Wasn't there something with "flattery"). They have to practice with their website however. With NoScript active you don't see a thing. The theme park is divided into an indoor and an outdoor area (tribute to the weather here) with the indoor area actually containing a number of rides including a ferries wheel and a roller coaster. After the beach and nature in Kuantan that felt a bit creepy. But it operates well. SWMBO went - what Genting is all about - gambling and won the family dinner last night. One of my favorites are animal pictures. The body of a snake (a must have accessory over here) is muscle pure - quite a stretch target for my gym exercise.
Of course the main attraction of any theme park are the rides. Genting has a number of them: The Corkscrew, Space Shot, Sky Venture (a body flying tower, very cool, Flying Coaster, Snow World (the only way to see snow in the tropics) and more. All of them are pretty new and feature impressive structures.
However when you embark on a ride on the Cyclops you enjoy Malaysia's first roller coaster ever,
Routing and replication is a core function of the Domino server. There are a few basic facts you need to consider when setting them up. A very popular setup, which I quite like too, is a hub spoke architecture: a central spoke communicates with spokes, so any communication has a maximum of 2 hops. An additional advantage of such an architecture is, that a server only needs to "see" the hub to reach any of the other servers. But even for a hub-spoke architecture there is room for improvement. Let us make two assumptions: the hub is where your SMTP mails arrive and depart (so "hub" could be a cluster) and all servers can see each other on the network.
Mail Routing The normal Hub-Spoke routing has the advantage, that every email message is delivered with the maximum of 2 hops and that you only need 2 connection documents per server. It also works independent from network architecture or IP ranges.
Of course - you need connection documents and every message will use 2 hops. If you have a lot of large internal traffic you create a bottleneck at the hub (even with multiple mailboxes). When all Domino servers "see" each other direct routing will be more efficient. To setup direct routing you need to put all participating Domino server into the same Notes Named Network (which implies that they all share the same network protocol - not an issue with TCP/IP everywhere today). You won't need connection documents anymore and routing is instant and direct.
Are there reasons (beside obviously wanting of the prerequisites) why you wouldn't want to use direct routing? When you use your hub to perform central functions like virus scan, content integrity, enterprise archival, compliance check etc. you want every message to pass through your hub. Be careful what you wish for, you might just create your next bottleneck.
Replication Replication comes with many choices: What server starts it, pull only, push only, pull-pull, pull-push. So it can get a little confusing (should I draw a diagram for you?). Hub Spoke replication architectures make a lot of sense. With 2 cycles all replicas are current. This is especially important for your system documents. However you need to be clear about how you set it up. The typical setup is the hub server to be scheduled to replicate with the spokes. From the 2 options: pull-pull and pull-push we find mostly pull-push. This means the hub does all the work.
Since the hub doesn't do anything else (eventually run some central agents?), that seems a sensible choice. However it has a large pitfall. By default there is one replicator up and running per server. So your Hub is replicating with one spoke at a time. You can increase that number to 4 but you will with large changeset and many spokes run out of your replication time window. On the other side of a replication there is just another user session (watch your console, you will find: "Session opened for server Hub/MyCorp"). So when you turn the replication direction around it scales much better.
When you schedule a pull-push replication on every hub, you can schedule all replications at the same time, since they are just sessions on the hub. You still will need 2 cycles to have all documents on all servers. Why would you not want to do that? 2 potential reasons (one stronger, one weaker) come to mind: firstly since all spokes push documents to the hub at the same time the peak utilization of the indexer on the hub goes up and might slow down other functions temporarily (time critical agents?); secondly replication is a bit "messier" the spokes might get some of the updated documents already in the first cycle instead of the second, if your application relies on sets of documents (Lotus Workflow comes to my mind) you end up with some documents "missing" until the completion of the second cycle. Other than that Spoke Hub replication is your method of choice.
Germany is well know for its Garden Dwarft culture. Now I discovered, that the Chinese too have them!
There was more to see in that monastery garden. A collection of statues (I need to find out what they mean) that invite to contemplate.
Near Kuantan in Malaysia is the old mining town Sungei Lembing where Anthony's and Ernest's grandparents were born. The mines went out of business in the 1980ties, but the shafts are still there. Of course it is strictly forbidden and dangerous to explore them.
When you translate "strictly forbidden and dangerous" into the languge of 2 nine year olds it awfully sounds like "fun and excitement".
The gentleman in green is Ernest Jian Long, the one in purple Anthony Bau Long.
Lotus Notes and Domino upgrades are comparable easy. The only challenge: poorly implemented Domino server will stay poorly implemented even after an upgrade. Unless of course you fix things. Once you know what you want to achieve there aremanyways to get there. You simply could use smart upgrade to push out the clients and just install the new server software. What you end up with is your "old" Notes/Domino installation running with new code. That doesn't really cut it. It is like upgrading your trusted old Volkswagen two seater to a Mercedes S class (5 seater) but refuse to take more than one passenger, since that was your limit so far (or for that sake: drive faster than 150 km/h since that was the max the VW did). So how can you identify the ideal upgrade? Some of the following stuff should already run in your Domain, so it wouldn't require any effort other than a nod, but there are Domino installations that run despite their poor configuration (Domino is very forgiving):
Update: I have color coded items a well managed R6/7 Domain would have already before your upgrade.
The Domino server is clustered for high availability
Your network ports have encryption and compression enabled
DAOS is up and running (make sure you get your backups right)
Out-Of-Office is handled by the service, not the agents
The room and resources database is deployed
All servers in the same Notes Named Network can see each other on the network and each NIC interface on the server has its own NNN
Adminp runs flawlessly ( make sure your system databases replicate properly)
Traveler is up and running (buy yourself an iPhone as excuse)
All databases on your server have both the latest design and the latest ODS (currently ODS51)
You have designed and implemented Domino policies for all aspects of Notes/Domino usage (that might very well a project in its own right)
On your Domino server you have space for all user profiles since you have implemented roaming user profiles
You have installed and configured your Sametime chat entitlement
You have installed and configured your Quickr entry entitlement
There is a widget catalog with useful widgets for your organization
Smart Upgrade is configured
Your routing and replication structure is Spoke-Hub, not Hub-Spoke (that's a topic for another post)
The Notes Client
You have defragmented your PC's harddisk. Do that before and after the installation. You could consider different file systems used by other more cherished operating systems.
Your machines have current drivers (Video is important) and patch levels
The Notes client installation has been moved to the Program Files for the application and the User Files for the user's data files (in Notes lingo we call that shared user install), so users logging into a workstation get their Notes install and not another.
You have implemented roaming users (one way or the other)
Policies configure and (if your users want to be
carefree) lock down your Notes clients
Shared login is implemented
The only version deployed is the full client, not the basic one. For weaker machines you use the notes.ini setting (deployed by a policy) to start the "classic" client
User know what the Notebook (formerly Journal) is for and use it
Important: The list above isn't the steps you need to do, but the results you should strive for. And remember: A lot of these should be in place already. If they are not, now is the time to clean-up. Don't settle for less. As usual: YMMV. Please comment what to add on.
Imitation is the strongest form of flattery. So a successful brand (or more accurate: excellent execution of a great idea: providing a 3rd place besides home) attracts imitators. Today at Xi'an's airport I was spotting a familiar sign, only on the second look it was quite different.
While SPR shamelessly borrowed typeface, colour, style ideas (lights, seating or counter) and charming girls in green, they added their own style. There is full service at your table and you get a wide selection of Asian food. The coffee is good, but the late is not even close to the original.
Today I completed a short introduction into XPages for a business partner in Xi'an. Initially the participants were a little stiff:
But with food and demo (click on the picture above) they warmed up to the new way of doing things. I'll spend the weekend in Xi'an visiting one of the five holy mountains of the Taoist: Mount Huashan. I'm curious how this will work out.
I'm pleased to announce, that I will conduct another XPages workshop, this time in Hong Kong. ( Update: Date for HK has changed!)The class will be on the 06/07 July 2009 and is open for registration. For details, location, fees etc. please contact Tony KT Lee from IBM Hong Kong.
In a business partner meeting (always an excellent source for blog ideas) in Beijing an interesting question popped up: "How should I split a (Domino) database if it gets really huge". The usual approaches are to split them along location or department lines. However in the discussion an interesting alternative approach emerged:
Document go through 4 phases:
Draft: the document gets created but is not complete yet. Very often that state is neglected by Stalinist validation code.
Current: The document runs through a workflow and people actively work with it, changing it often (e.g. add approvals)
Historic: The document reached its final form and does not change any more. The document is still relevant and is looked at (often)
Old: Nobody cares for the document any more, but you want to keep it for compliance or forensic reasons
From 1-4 the frequency of updates is declining while the number of documents is increasing. So splitting these documents into 3-4 different databases can make sense. In a XPage (or Dojo) application you can unify the display of these data easily. Food for your thoughts.