報表工具都有哪些應用部署方式？

回答這個問題之前，我們先來看看報表工具到目前為止都有哪些形態，雖然國產的大部分都是 java 語言開發的，功能方面也基本相同，但是形態還是有差異的。

差異在於，有一些廠商始終把報表定位為一個通用工具類中介軟體產品，因其特性，使得整合商與自己的產品或專案做整合時比較簡便且靈活，這也是大部分整合商希望的一個定位。

另外有些廠商，不願意只掙工具的錢了，想把報表包裝成一個通用的平臺，既能掙工具的錢，又能掙一部分平臺的錢，這個形態的優點是，遇上一些需求簡單的終端使用者可以直接拿來用；缺點是，很多專案定製程度高，統一平臺基本用不了，整合商會很頭疼，因為多給我一套系統，不知道該怎麼部署整合了，具體後面再說。

瞭解了產品形態，接下來我們再來看看報表工具有哪些部署方式。概括起來也是兩種：整合部署與獨立部署，先解釋下兩種模式：

整合部署是把報表嵌入已有系統，以模組形式存在，統一使用系統的登入、組織架構、許可權等平臺功能。整合部署細分的話，又包括兩種情況：深入整合、報表作為服務整合。

其中深入整合是把報表和已有系統放到一塊兒，物理上就在一個應用裡。

而服務式的整合，則將報表和已有系統分離，各自部署，物理上是兩個（或多個）應用，報表提供服務介面（一般就是 url）被其他系統整合呼叫，通俗點兒說就是在其他系統掛報表的連結。

作為服務整合，實際就涉及到報表工具獨立部署方式了。獨立部署從字面意思也可以看出 **，** 報表與其他應用是分離的，各自獨立、分別部署、本身互不干擾，如果需要呼叫其資源，則採用跨系統掛連結呼叫的方式。

那麼，上面的兩大類報表工具，適用哪種部署方式呢？

定位為中介軟體的適合無縫整合，因為他們的定位就是面向開發的整合商使用者被整合，不論做產品還是專案，都可以把報表嵌入進系統。

優點很明顯，如同一顆釘子，釘到哪塊兒木板上，就屬於該木頭板兒了，作為一個整體不分離，統一管理維護。另外，整合也比較簡捷，以 java 類產品為例，基本都是複製一些 jar 檔案，再放置或合併一些配置檔案，就完成了。

唯獨有個缺點，必須要求報表和已有系統開發語言一致。

中介軟體產品不能作為報表服務呼叫嗎？其實也不是，部分廠商也為客戶考慮到這一點，除提供中介軟體報表工具外，也會帶一個簡易的報表平臺，不作為賣點，免費使用，甚至開源，便於使用者快速開發。

而做成平臺的報表基本上只能獨立部署，因為此類產品基本不提供模組拆分整合的模式（即便個別提供，也會作為定製服務收取昂貴的費用），自己“拆”這個活兒也是很麻煩的，估計也拆不明白。

優點在文章開始已經提到，能快速擁有一套完整的系統，尤其是需求簡單的終端使用者比較喜歡，產品呈現出來也顯得功能更多、更炫。

但是，這類產品獨立部署獨立使用是最好的，一旦涉及跨系統呼叫，幾乎都需要適配統一認證、組織架構同步、許可權同步等，這個工作很費精力，一般情況下就是提供一堆介面自行實現，對於整合商來說，整合反而整的焦頭爛額。

總結來說，不同產品有不同的適配場景，當我們選擇時，要根據自己是啥情況然後確定要啥，如果是中介軟體需求，就不要要求平臺功能，那都是多餘的，嵌入整合時反而是累贅。如果是完整系統需求，則不用考慮嵌入整合性，更應從系統整體考慮，可選擇完善的平臺或基於開源平臺改造。