實現機關辦公自動化工作需要計算機技術的支援，在計算機軟體範圍中，有網路作業系統軟體、資料庫軟體和開發工具等基本系統軟體，在此基礎上開發出適合本單位使用的應用軟體。對如何選用系統軟體，筆者沒有發言權，但是根據實際情況，筆者有必要對Lotus Domino談點人個看法。因為該軟體一是目前比軟流行且已為眾多機關所採用，二是該軟體費用軟高，三是由於該軟體是個半成品軟體，稍加改動就可以適用於給領導演示。可以說，該軟體有許多優點，但筆者在諮詢有關專家後，認為由於 Domino 的技術限制和我國政務辦公資訊系統的特殊性，選擇 Domino 作為我國政務辦公資訊系統的基礎平臺，複雜功能實現困難、使用麻煩、開發費昂貴、互操作性差、介面呆板、資料共享與整合效能差，系統固有各種缺點遠大於其優點，在部委系統內完整的成功案例很少。該軟體不適合於部級以上黨政軍機關應用，其原因主要有以下幾個方面：
點評：這裡發現該文作者存在一個問題，即一方面認為Notes/Domino是一個半成品軟體，可以迅速開發，同時又將這種迅速開發原型與那些經過需要較長開發時間的技術相比較，指出其種種缺點，這是不公平的。
事實上，Notes/Domino系統開發一直存在兩種方式即簡單開發和系統化定製。
簡單開發--使用Notes/Domino提供的設計元素、甚至模板資料庫直接堆砌而成，以基本功能實現為主要目標，其優點是對開發者要求低（甚至許多EndUser都可以進行），開發週期短、費用低，缺點是對介面和複雜應用考慮較少，不能滿足使用者的特殊要求，屬於較低層次的開發。
系統化定製-充分考慮到使用者的特殊需求，以Domino為基本設計平臺，結合多種先進技術和應用軟體，整合多種後臺資料型別的增值性開發。這種開發，可實現的功能更多、介面更美觀、也更能貼切使用者的需要，但相對的，週期較長，技術門檻較高，開發費用也較高。但考慮到可以充分發揮Domino強大的功能，還是值得的。
兩種開發方式互有補充，各有優缺點，所以泛泛的批評Notes/Domino開發的“各種固有缺點”有誤導之嫌 。
1．速度太慢。 Domino 是基於文件的資料庫、不具備資料快速檢索功能。當資料庫中文件數超過二到三萬條時，幾乎顯得無能為力。Domino 使用解釋性的客戶響應機制，在採用 Browser-Domino 結構響應 Web 請求時， Server 端實時地將 Domino檢視轉換或解釋為 HTML 文件傳送回客戶端，對於複雜檢視轉換時間長。在客戶端 Browser 上利用 Java Applet 實現資料的互操作性，客戶端啟動 Java VM就需要耗費很長時間， Java VM 啟動後，還要解釋執行緩慢的Java Applet，使用者等時太嚴重。在 PIII500 PC 伺服器上對 1 萬個文件的資料庫目錄列表就需等待 1 分 20 秒左右，超出一般使用者的可忍受程度。如在10 M 共享網路上，10 個使用者同時查詢具有1 萬個文件的資料庫，將費時數分鐘，而一般部委內部網路上均有數百個使用者。
點評：這裡發現其論據有問題，將檢索速度與某個條件下的顯示速度混為了一談，事實上，由於要求下載時間等原因，java applet本身就存在著初始顯示慢等問題。而Domino中的Java Applet作為為使用者提供的一種易用的快速開發元素，確實也存在一些不盡人意的地方，例如沒有分頁功能，這意味著所有的資料都要一次讀到客戶端-這直接導致了作者所提到的顯示緩慢問題。以此來指責Domino的檢索速度是沒有說服力的。關於檢索速度，相信我做過的一個實驗更能說明問題，我們曾經在一臺PIII500 PC機上建立過一個十萬條文件的測試資料庫（每個文件有20個域，每個域填充由亂數產生的單詞，單詞的數目也是由亂數決定（不超過20））。在這個資料庫中檢索包含某一個單詞的文件，平均耗時約為0.1秒。附帶提一句，Java Applet並不是顯示檢視的唯一選擇，Domino本身還內建了ht ml的顯示形式，只需要修改一下檢視的屬性，不需要任何程式碼，其顯示速度非常快。如果對這兩者都不滿意，還可以進行定製開發。由於篇幅和主題的問題，這裡就不詳述了。
2． 綜合統計能力太差。在辦公資訊系統中,實時地對公文執行狀況進行分類彙總、監控是必不可少的功能。而 Domino 是基於文件的小型資料庫，如要求進行多維資料彙總，其實現過程十分複雜，效率極其低下，反應緩慢，遠不如關係型資料庫。
點評：“Domino是基於文件的小型資料庫”，“基於文件”可以說不錯，“小型資料庫”的印象卻不知從何得來？不知該文作者的標準是什麼？十萬篇文件和十萬條關係型記錄，無論從儲存容量、檢索難度、複雜度等方面都不可同日而語。所以，在我的印象當中，Domino資料庫的指標一般只提容量，很少提文件數目，沒有什麼原因，只是因為在達到文件數目的限制前儲存介質早就“爆”掉了。並且將Domino簡單地稱為“資料庫”，對於它所能完成的工作而言，實在是一種誤解，Notes/Domino一直是作為市場領先的伺服器電子郵件和群件產品而得到廣泛承認的。至於“對公文執行進行分類彙總、監控”，以我們的經驗來看，沒有問題呀，甚至可以說是強項。至於“多維資料彙總”，“遠不如關係型資料庫”，這的確是事實，不過該文作者似乎把辦公資訊系統的任務與管理資訊系統（MIS）混淆了，這是一個普遍存在的誤區。對大量的原始資料進行多維彙總、處理加工、產生統計報表（原始文件），這些是MIS系統的領域與專長。而運用工作流機制、協同、通訊、促進知識共享、進度、效率和生產率才應是辦公資訊系統的著重所在。從國內辦公系統的現狀來看，正是這些普遍存在的誤解，導致了國內辦公系統的開發複雜、投入多、收益少。
3．實現複雜的應用和介面困難。政務資訊系統的面界一般具有眾多的介面元素。如會籤介面上至少有檔案標題、正文、附件、起草人、起草時間、處室稽核人、稽核時間、司局稽核人、簽發人、簽發時間、會籤司局………等等數十項，在 Domino 的檢視上實現如此眾多的介面元素十分困難，在 Domino R5 版本中，對於複雜檢視在 Notes 中有時竟然無法正常顯示而導致當機，而採用 Browser 方式需將複雜檢視在伺服器端轉換成 HTML + Java Applet 傳送到客戶端執行，耗時太多，執行緩慢。
點評：這些更不知道從何說起了，就我所知，利用Domino想要實現該文作者提到的政務系統無論從介面還是功能，都應該是很成熟的技術了，一點也不困難。事實上，困難的應該是這種想把這數十項元素放置到同一個檢視的想法，利用這樣一個檢視來處理公文，這既不現實也不實用。這裡又提到了Java Applet，由於上面已經說過，不再駁了，建議他使用html方式，或者乾脆自己定製一個介面好了。至於當機問題，確實存在，不過主要是在開發端和notes客戶端（Domino Server的穩定不成問題），或許是因為Notes R5在介面上改進了很多的原因吧，R5(尤其是R5.0和R5.01)的客戶端和開發端穩定性差了很多,R5.05就已經好多了，希望Lotus公司能夠儘快改進這些問題。
4．介面呆板。Domino 的介面主要由幀、檢視、大綱等一些固定格式組成，缺乏靈活性，樣式粗糙呆板，與 HTML 或應用程式介面相比過於原始化、簡單化，缺乏個性和藝術性。
點評：的確，直接使用這些元素是缺乏靈活性，但原因恰恰來在於這些設計元素易用性。一個粗通Notes程式設計的人可以在極短的時間內搭接出一個基本可用的系統，這是其它系統所難實現的。隨著對於Domino程式設計的進一步瞭解,還可以進行介面的定製，應用諸如內嵌HTML程式碼、結合Javascript、DHTML等技術開發出開發出充滿個性和藝術性的介面的應用程式，這方面，國內已經有成功的例子，建議在今年的Domino Day可以好好看一看。當然，靈活性的提高通常也伴隨著複雜度的提高，這些工作都是需要一定的程式設計量的，如何取捨，是見仁見智的問題。
5. 資料共享、匯入、匯出限難。Domino 文件資料庫不支援ACCESS, EXCELL,Fox Pro等通用前臺資料庫的共享訪問，也不支援各種 SQL 檢索工具通過 ODBC 訪問，不支援 SQL 語句查詢，資料共享效能極差、資料批量格式化匯入匯出困難，在流行的 Internet/Intranet環境下，難以滿足使用者端資料訪問多樣化的需求。
點評：首先注意到該文作者提到的都是Microsoft產品，所以這裡特別提一下Domino R5可提供與Microsoft Office大量的整合。使用者可以在www.lotus.com/itcentral網站上找到系列白皮書及文章。附帶提一下Domino R5.05中包含有幾個新的Microsoft整合功能，包括：
· Domino Network File Store，它允許通過Windows 網路訪問任何Domino資料庫並把Domino資料庫轉換成網路檔案共享資料庫。
· iNotes Access for Microsoft Outlook，允許用Outlook 98/2000客戶端訪問Domino郵箱中的郵件/日曆服務。
· Domino Collaboration Objects，新增功能，優化Domino使用COM的開發。
· OLE/DB聯結器，用於Domino與SQL Server 7之間的內在資料移動。
其次，由於把後端資料合併到事務處理中可以最大限度地體現 Notes/Domino 應用程式的價值，所以Lotus公司非常重視，提供了一系列的產品或介面（LSX、DECS、LEI、ESB、NotesSql、JDBC等）。利用這些企業整合技術，可以將那些在傳統意義上很難訪問的資料整合到事務應用程式中，因此完全可以滿足資料訪問多樣化的需求。
下面簡單介紹幾種企業資料整合互連方法。
1．@DB 命令--可以使用 @DB 命令同使用 ODBC 的關聯式資料庫交換資料。
2．DECS - Domino 企業連線服務 基於表單的開發工具。提供對企業資料和應用程式（包括關聯式資料庫、事務系統以及企業資源規劃(ERP) 系統）的實時存取。
3．LS:DO - LotusScript Data Object---可以存取任何 ODBC 相容的資料來源的 LotusScript。
4．JDBC - Java Database Connectivity---通過標準 JDBC 類從 Java 代理到關係資料的訪問。Domino 還附帶 JDBC 到 ODBC 的橋樑。
5．Lotus Domino Connector LotusScript Classes---擁有一致介面程式設計訪問企業資料和應用程式的一種統一的物件模型，可以通過 LotusScript 或 Java 使用這些類。
6．Lotus Domino Connector---提供到企業資料來源本地連線的模組。通過 Domino 企業連線服務或利用 Domino 類程式設計可以訪問這些聯結器。Domino 伺服器提供了對 DB2、Oracle、Sybase、基於文字和檔案的系統、EDA/SQL 和 ODBC 的聯結器。另外，還可以單獨獲得到 ERP 應用程式、事務監視以及目錄系統的額外聯結器。
7．LSX - LotusScript 擴充套件---建立工作於 Domino 應用程式、Java 和 OLE 中的定製物件。MQSeries、SAP、DB2 和 Rich text 都是 LSX 的應用範例。
8．Lotus Enterprise Integrator---提供支援事件驅動或定時大量資料傳輸以及資料來源同步的資料分佈伺服器。
9．Domino Connector Toolkit---為開發者提供構建其他 Domino 聯結器和用於 Java 或 LotusScript 類的工具和資訊。
需要指出，這些方法大部分不需要額外的購買（LEI與ESB除外）。
另外，文中提到不支援“各種 SQL 檢索工具通過 ODBC 訪問，不支援sql語句查詢”，顯然，作者的思路還侷限在關係型資料庫開發的思路中，忽視了對於辦公系統的主要處理物件-文件，這種查詢是否還適用。比較而言，Notes/Domino提供的強大的全文檢索功能要更實用一些，決不是僅僅查詢一下標題和關鍵字這麼簡單，其效率也更高。別忘了，類似的全文檢索功能，大多都是需要單獨購買的，而Domino則是內建的。另外提一句，使用sql通過 ODBC 訪問 Domino 資料的 NotesSQL 驅動程式可以在 Lotus Web 站點 http://www.lotus.com/ 免費得到。
對於資料的共享，下面在關於“可擴充套件性”問題裡還會提到資料擴充套件的問題
6．成本太高。使用 Notes-Domino 構築辦公平臺在成本上與基於 ASP-SQL 或其他當前通用解決方案相比，其成本不在同一數量級，有可能高出數倍乃至數十倍。
點評：比較成本，前提應是功能相似，因此，一般的比較是Domino與以Exchange Server為郵件平臺的辦公系統。
Domino系統內建了辦公系統所需的電子郵件、群組協作、工作流、角色控制、安全機制、複製機制等功能等，若以ASP-SQL模式實現，在成本中勢必要加上Exchange Server。
既然提到了ASP-SQL辦公系統方案，請參考一下微軟最近宣佈的Exchange 2000的定價。可以看到當某個產品成熟時，微軟一般會提高其價格。因此Exchange 2000的價格大大高出Exchange 5、6，當然還包括Domino R5。當向Zdnet提及Exchange價格變化時，微軟的伺服器應用群件產品經理Stan Sorensen談到："我們的價格比其它產品都高"。現在，Exchange使用者從Windows NT 4.0、Exchange 5.5以及Windows NT 4.0向Windows 2000和Exchange 2000升級時面對著不可思議的高成本。這裡強調指出，Exchange 2000與Domino是相似、但絕非相同的產品。Domino可以提供超過Exchange的附加特性和優勢。例如，Creative Network研究表明：Domino使用者平均可在一個單獨的基礎設施上享用347個協作應用，比典型的Exchange使用者（僅37個應用）多十倍。還有一點可進一步說明產品功能的差異，那就是微軟已宣佈一個新產品 - "Tahoe"，此產品試圖彌補Exch ange的不足，使其成為"辦公室使用者可以簡便獲取、共享與釋出資訊的伺服器"。
據此，我完全得出了相反的結論。
7．硬體要求高，頻寬需求大。Domino 是一種傳統的Clent/Server平臺，儘管為適應Internet環境進行了更新，但其核心技術依然源於過時的Clent/Server方式。在多使用者的Client/Server環境下，採用 Notes-Domino 解決方案，對伺服器的效能要求大大高於ASP-SQL 等先進的 Browser/Server 解決方案，前者對網路頻寬的要求同樣也很高。
當前，在應用中選擇C/S結構還是B/S結構是討論較多的話題。B/S結構的特點在於具有廣泛的資訊釋出能力，客戶端只需要普通的瀏覽器即可，特別適合簡單的應用流程和Internet應用，由於其簡單、輕量、易於維護，因此受到了終端使用者的歡迎。但在大型複雜應用中，由於在B/S結構中有一些根本的弱點，使B/S結構的效能仍不能與C/S結構抗衡。採用B/S結構，客戶端只完成瀏覽、查詢、資料輸入等簡單功能，而絕大部分工作由伺服器承擔，因此伺服器的負擔重，對其效能的要求更高！而採用C/S結構時，客戶端和伺服器端都需要處理部分任務，對客戶機的要求較高，但因此反而減輕的伺服器的壓力。B/S結構應用的是HTTP協議，由於HTTP固有的侷限性（最早為單純網上瀏覽而發展起來的），因此B/S結構不適合複雜的互動式應用。而C/S結構一直在互動式應用中大顯身手，技術成熟，穩定，對複雜應用適應性好。例如，在完成一次任務處理的互動過程中，C/S結構只需連線一次，而B/S結構需要對任務中的每一個請求都重新進行連線，其效率大大低於C/S結構。現在，隨著客戶計算機的計算能力的不斷增強，越來越多的關鍵性應用又重新選擇了C/S結構。所以，B/S方式和C/S方式各有優缺點，可以互補，怎麼能說C/S結構已經過時了呢？（烏鴉的補充：在我轉貼這篇文章的時候，市面上基於Domino平臺實現的B/S結構系統已經比比皆是，極盡奇巧之能，所以這點也不能成立啦。）
8．可擴充套件性差。 Domino 與其他程式的使用者介面實現困難，致使程式擴充套件效能差，不利於與各類輸入輸出裝置（如掃描器、IC密碼機、印表機等）實現無縫鏈結，以及與其他程式有機整合，難以做到辦公資訊系統的文件一體化。(VB、C API、C++、Java)
點評：對於第三方軟體的整合和軟體的擴充套件是軟體一個必要重要的工作，也是需要軟體開發人員考慮並做工作的地方。下面談一談Domino應用的擴充套件和整合：
1)基於資料的擴充套件
首先，前面提到過Domino提供了LSX、DECS、ODBC、JDBC等多種方法來存取外部的資料，利用這些方法，Domino應用可以存取外部的資料，達到資料的一致和同步，從而將應用整合在一起。舉例而言，我們曾經通過這些方法，利用Notes強大的文件管理功能來管理並檢索通過下載軟體得到的資料，大大提高了這些資料的使用效率。
第二，Domino對XML提供了很好的支援。XML的應用已然成為軟體開發的一大趨勢，越來越多多軟體開發將使用XML作為軟體的資料介面。在這種情況下，Notes應用和其他軟體之間的資料交換之間將更加便利。
第三，Domino R5開始使用了一種名為CORBRA的架構。這是一個由OMG定義的開發標準。在分部的計算環境中，CORBA作為中介軟體，為客戶端呼叫駐留在其他計算機上的遠端程式設計介面進行服務。CORBA使用IIOP協議，這個架構將提供分散式物件見相互定位和交換資料的傳輸功能，提供異種語言、作業系統、硬體平臺、網路互操作性；從而式分散式系統的設計、實現都大為簡化。從軟體發展的趨勢來看，很多應用軟體的設計開發將遵循這個架構，提供相應介面。在這種情況下，Notes應用和其他應用軟體的整合將更加容易。
2)開發工具的擴充套件
Notes開發本身使用公式、Lotus Script和Java。
a. LotusScript是一種類Basic語言，可以呼叫各種物件、API。完全可以像VB一樣實現對各種ActiveX控制元件或物件的操作，例如將檢視直接生成Excel表格或著存取Access資料庫資料，還可以通過操作或者代理呼叫外部的其他程式擴充套件自身功能。
b.可以將其他應用程式提供等動態連結庫等，在Notes中宣告其介面以後直接呼叫。
我們的產品Indi.Image（烏鴉的話：看來這位前輩是來自慧點科技的吧？據我所知，就是慧點老是用Indi.xxx的名字，不知道到底是什麼意思？）就利用了這種方法，使軟體可以無縫地使用各種掃描器，包括高速掃描器，將各種資料掃描，並轉換成高效的格式儲存在Notes資料庫中，統一進行管理，包括對不同的掃描資料進行各種有機的組合。
c.利用Lotus提供的API、控制元件和物件
Lotus為Notes應用的擴充套件提供了很多API－－C API,HiTest API, C++ API。這些API是使用者可以很自如的從外部直接控制Notes資料庫的各種物件，包括資料物件、設計物件、事件物件，從域物件到資料庫物件。利用API開發，可以很好地將其他各種應用程式和Notes應用結合起來。
我們就曾利用這種方式和保密機構進行合作，在Notes應用中無縫整合了對方的加密系統，使既其保持了Notes應用原有的使用簡便性，又達到了使用者對安全保密的要求。
VB、VBA中也可以呼叫Lotus物件。在安裝過Notes客戶端的系統中，可以通過Notes物件，獨立於Notes介面訪問資料庫、發郵件，並使用標準的網格顯示檢視等。還可以通過在伺服器端自定義的介面來實現客戶端程式對Domino資料庫的訪問。
事實上，甚至還可以通過Vbscipt寫的ASP頁面訪問Domino資料庫，實現發郵件和檢視日曆等。
3)作業系統、硬體平臺的可移植性
在軟體擴充套件方面，Domino應用還具有良好的可移植性。Notes應用是基於Domino平臺來開發使用的，而不是直接基於作業系統。所以Notes應用在不同硬體平臺、不同作業系統之間的移植效能很好。
9．不符合中國國情。我國政府機關政務辦公資訊系統不適合使用基於文件型的資料庫平臺。Domino 適用於小型簡單辦公系統，如中小企業、中小學校、中小機關。一般為某人起草一個檔案、傳給某主管上司批示、辦結這一簡單流程，特別適用於西方簡捷辦公模式，辦公文件也沒有太多的欄位，一般情況下僅有檔案標題、正文，起草人，批示人等十個左右的介面元素。而我國政務辦公系統中的文件，每一個正文往往附帶數十個附加欄位，如一個普通的司局會籤檔案就有檔案標題、正文、附件、起草人、起草時間、處室稽核人、會籤司局、會籤人及時間、等等數十項，關係複雜、流程分散、牽涉面廣，簡單文件資料庫難以承擔, 更適合使用關係型資料庫。因此使用 Domino 開發我國政務資訊系統不適合中國國情。
點評：立論很奇怪！關係複雜、流程分散、牽涉面廣，正是內建工作流和安全機制的Domino系統的用武之地呀！（再強調一下，Domino不是“簡單文件資料庫”!）至於“數十個附加欄位”，更是Domino的拿手好戲，反而是該文作者推崇的關係型資料庫，在這方面很難施展。相信有大型關係型資料庫開發經驗的人都知道，關係型資料庫對於資料型別、長度、資料關聯都有很嚴格的要求，而且對於資料結構的修改更是慎而又慎，哪怕是一個char型別欄位長度的修改，都是令開發者很撓頭的事情，這樣怎麼能適應政務資訊系統的開發呢？事實上，西方的辦公模式確實簡潔，重實效而輕形式，但並非簡單，尤其是大型的跨國企業，往往數百家機構分佈在數十個國家或地區裡，普通的軟體根本無法適應其辦公通訊的需要，而這些大型的公司或機構往往都採用Domino作為其辦公系統的平臺，這恰恰說明了問題。 （烏鴉的話：當初我看到這個結論也覺得很奇怪，欄位多Domino又不會干涉你，而且還可以在程式中自動新增欄位。關係分散、流程複雜不正是Domino工作流的拿手好戲嗎？呵呵。）
小結：Domino作為一個相對成熟的開發平臺，有其長處，也有其不足，不過就其在辦公系統領域的表現而言，目前，還無出其右。