This is going to be in a two post series because I realizedthe first posting is just too darn long!
With the integration of Eclipse and Expeditor into LotusNotes 8 you get a whole new set of deployment options for consideration whendeploying your composite applications. The Lotus Expeditor introduced the manageability of Eclipse features andplug-ins by allowing the administrator or application assembler to identifywhat features need to be installed when a composite application is opened. Each component in an application can specifywhat Eclipse based features (if any) are needed for this component to beproperly rendered in the client. Likethe portal managed side, the Lotus Notes side has the same capability using theComposite Application Editor. LotusNotes also adds a new twist to the equation – the NSF based update sites! With this powerful tool you can now packageand deploy your features and plug-ins in whole new ways – but there are somethings you need to consider before taking the leap.
Let’s step back a little and walk through the way Eclipseupdate sites work and how features get installed into the system. Then we willapply this to composite applications and then introduce some patterns that canbe used with the NSF based update sites.
When you bundle your plug-ins they are contained within afeature. Each of these artifacts hastheir own version attached to them. Thisis important to remember because the eclipse provisioning system will onlyinstall new or compatible features and plug-ins. Generally, if you have a feature with asingle plug-in or even several plug-ins you might want to keep the version ofthe feature and its plug-ins the same. This will make problem resolution easy down the road. If your feature happens to include otherplug-ins, then the Eclipse provisioning system will look at it in layers. First it sees if the version of the featureis already installed – if so, it will not continue to look into theplug-ins. This means, if you deployedyour feature once, then added a plug-in to it you must increment theversion number before deploying again, otherwise the new plug-ins will not getinstalled on existing systems.
Now let’s look at Composite Applications and how it handlesdownloading plug-ins and features. Composite apps only reference features in their descriptor (the ca xml). Meaning, you must adhere to the featureresolution logic in eclipse in order to have its plug-ins deployedproperly. If you change the feature, youmust increment the version. If youchange a plug-in you must change its version number and one of its containingfeatures in order for it to be deployed. Composite applications also add another level of complexity – forperformance reasons. CAI (CompositeApplication Infrastructure) only looks at applications definitions (ca xml)that have changed- we cache the last time and date stamp of the file. So if your application has not changed, CAIdoes not even crack open the file to install features. So the change dependencytree looks like this:
---ca xml - time and date change
---------feature -version change
-------------plug-in -version change
So in order for a new plug-in to be installed, all three ofthose logic points must be passed.
Now let’s talk about how the new NSF based update site canbe used in your organization and explain some of the scenarios you may want toconsider when using this new technology. The first thing we need to understand is why this technology wascreated. Here are some high levelbullets of why this is so cool:
- Provisioning over NRPC – the number one cool feature is you do not have to deploy secure HTTP sites. Provisioning can be done over the nrpc protocol.
- Easy deployment – use Notes replication to deploy update sites to many servers
- Easy of use – merge features and plug-ins from many sources. File based update sites are merged manually
- Easy to test with – by having the CA XML and update site all contained in a single file it makes sharing and testing a snap
So we need to consider the deployment scenarios and thecaveats each one presents. Let’s startwith what we should consider an enterprise preferred method and go down fromthere.
Preferred Method 1 – Centralized Update Site
Recommended – Company with not alot of features and plug-ins from various vendors
Centralize your update site into a single NSF based updatesite. This means you use one replica of an update site and maybe put it on morethan one server. Using the options inthe database it easily allows you to import existing plug-ins and features frommany different sources. This also meansyour composite applications will all be pointing to a single Notes replica toget their features and plug-ins from.
- The real only caveat here is if the update sites replica ID is ever changed you need to change all references in all applications to the new site.
- If a feature version changes on the central site and you want existing clients to get that new feature you will have to change the version numbers referenced in those applications
*In Notes 8.0.1 there is a new feature called WhiteList that will help in this situation. If the NSF based update site is in the white list the compatible features will automatically get updated to the new versions.
Preferred Method 2 – Shared update sites
Recommended – Company with a lotof features from various companies
You could also have several update sites where features arestill “central” but bundled by application, feature, or function. Meaning, you may want all features referencedby finance organizations in one site or all features from third parties in onesite and all internal features in another site.
Caveat – This may be less expensive than the firstbut you would still have to change rep id’s to feature if any of the “central”site databases changed its replica id. Anytime this happens you need to update the applications that referencethe changed site.
Preferred Method 3 – Application based update sites
Recommended – Small Company withsilo based applications
This is really for applications that have features that willmost likely stay specific to its self. Hopefully all shared features are put onsome kind of central site but in this case this is an easy way for applicationsto get pushed around on servers or as attachments. By having the applicationself contained in a single file it makes prototyping and testing veryeasy. If you intend on deploying in alarge enterprise you may want to consider moving the features to a shared site.
- By including features in the owning NSF you limit sharing or feature re-use.
- This could result in the same feature being installed and deployed in several applications.
The next part will walk you through creating an NSF based update site and then also creating a composite application that houses the NSF Based update site inside of it.