Anyway, the new version looks good. The data is either at one end or the other, not in some intermediate mail.box or replica, so the business process owners are happy. The developers like the new tools that they get to play with, NetBeans or Eclipse, providing a much nicer coding environment than Designer (if not as well integrated into Notes).
The only unhappy person in the project is me - poor admin guy. Deploying servlets on Domino is awful! Just lob them in the right path under the server data directory and then fiddle with the servlets.properties TEXT file (assuming the server document has the right servlet engine config settings - not the default ones). This is crap !
I know (don't tell me) there was a better plan, can you say "Garnet". But once the powers that be decided a that real servlet implementation (v2.2, SOAP etc) was not what we (the Customer) wanted, they should have at least come up with a better plan for managing what functionality the product has now. There are config documents for some server features and a multitude of different web config docs. Creating one to replace the servlets.properties file could not have been too complex a task. So, we will end up having to automate this process ourselves, because Lotus have only done half the job. On each of Domino server we already have a database that we use for distributing files and DBs (create a new doc in the DB, attach the files, specify the destination server(s) and path and stand well clear to let replication and agents do the rest). Initially the servlets.properties file will be the same everywhere so it can just be attached along with the Java classes etc. Longer term we'll (when I say we I reall y me
an Jeff who builds our admin tools) generate the file from scratch based on details in a config doc in our distribution DB.
All this gives me the feeling that IBM are not serious about Domino as a development platform in the medium to long term. I'm sure you have all seen the roadmap where, eventually, there is a big purple J2EE box with a few small yellow "collaboration" boxes buried out the back. Note how Sametime and Quickplace are also migration to this environment and off Domino as a host.
I also think that we who use, manage, or develop in the Notes/Domino environment have been spoiled as virtually all the tools we need have been available (or can be built) on the one platform. The idea of having to bolt on another tool is anathema to us. I think this need for bolt-ons will continue, and probably accelerate, in the future. This means more time spent on developing "glue" to ensure multiple products work seamlessly (or give that appearance to the end user). You either take a sip of the nice Websphere Kool-Aid - sign signon (gulp); modern servlet engine (gulp); J2EE (gulp) - mmmmmmmmmm - or scour the net for brave souls like these and these doing the same thing with other products. Can you hear the whispers saying "dot net will solve all your problems - its part of the operating system too".
On the other hand, our environment is well suited to ordinary Notes applications - global distribution and skinny communications links to lots of places. We have servers in each location for speedy access and replication makes the most of the comms. I'd hate to imagine all browser-based applications coming back here or lots of terminal-server (can you say dumb terminal) sessions. These "classic" Notes applications will continue to serve most of our needs for the next few years.
In summary, I'm disappointed at the ugliness of deploying a servlet-based Domino application compared to an "ordinary" Notes one. I think it is an example of the more general lack of commitment that IBM/Lotus have for moving Domino forward. Domino is not dead, but its application environment is not keeping up. There will come a point in the future when the classic Notes application is so far from the mainstream that the cost of bridging the gap will be large. Websphere is obviously IBM's strategic product and they are positioning it right next to Domino so that this seems like the easiest course (and smallest jump), but the gap is so large and ever-widening that there is little downside in looking at the alternatives.
No comments:
Post a Comment