报表工具都有哪些应用部署方式？

回答这个问题之前，我们先来看看报表工具到目前为止都有哪些形态，虽然国产的大部分都是 java 语言开发的，功能方面也基本相同，但是形态还是有差异的。

差异在于，有一些厂商始终把报表定位为一个通用工具类中间件产品，因其特性，使得集成商与自己的产品或项目做集成时比较简便且灵活，这也是大部分集成商希望的一个定位。

另外有些厂商，不愿意只挣工具的钱了，想把报表包装成一个通用的平台，既能挣工具的钱，又能挣一部分平台的钱，这个形态的优点是，遇上一些需求简单的终端用户可以直接拿来用；缺点是，很多项目定制程度高，统一平台基本用不了，集成商会很头疼，因为多给我一套系统，不知道该怎么部署集成了，具体后面再说。

了解了产品形态，接下来我们再来看看报表工具有哪些部署方式。概括起来也是两种：集成部署与独立部署，先解释下两种模式：

集成部署是把报表嵌入已有系统，以模块形式存在，统一使用系统的登录、组织架构、权限等平台功能。集成部署细分的话，又包括两种情况：深入集成、报表作为服务集成。

其中深入集成是把报表和已有系统放到一块儿，物理上就在一个应用里。

而服务式的集成，则将报表和已有系统分离，各自部署，物理上是两个（或多个）应用，报表提供服务接口（一般就是 url）被其他系统集成调用，通俗点儿说就是在其他系统挂报表的链接。

作为服务集成，实际就涉及到报表工具独立部署方式了。独立部署从字面意思也可以看出 **，** 报表与其他应用是分离的，各自独立、分别部署、本身互不干扰，如果需要调用其资源，则采用跨系统挂链接调用的方式。

那么，上面的两大类报表工具，适用哪种部署方式呢？

定位为中间件的适合无缝集成，因为他们的定位就是面向开发的集成商用户被集成，不论做产品还是项目，都可以把报表嵌入进系统。

优点很明显，如同一颗钉子，钉到哪块儿木板上，就属于该木头板儿了，作为一个整体不分离，统一管理维护。另外，集成也比较简捷，以 java 类产品为例，基本都是复制一些 jar 文件，再放置或合并一些配置文件，就完成了。

唯独有个缺点，必须要求报表和已有系统开发语言一致。

中间件产品不能作为报表服务调用吗？其实也不是，部分厂商也为客户考虑到这一点，除提供中间件报表工具外，也会带一个简易的报表平台，不作为卖点，免费使用，甚至开源，便于用户快速开发。

而做成平台的报表基本上只能独立部署，因为此类产品基本不提供模块拆分集成的模式（即便个别提供，也会作为定制服务收取昂贵的费用），自己“拆”这个活儿也是很麻烦的，估计也拆不明白。

优点在文章开始已经提到，能快速拥有一套完整的系统，尤其是需求简单的终端用户比较喜欢，产品呈现出来也显得功能更多、更炫。

但是，这类产品独立部署独立使用是最好的，一旦涉及跨系统调用，几乎都需要适配统一认证、组织架构同步、权限同步等，这个工作很费精力，一般情况下就是提供一堆接口自行实现，对于集成商来说，集成反而整的焦头烂额。

总结来说，不同产品有不同的适配场景，当我们选择时，要根据自己是啥情况然后确定要啥，如果是中间件需求，就不要要求平台功能，那都是多余的，嵌入集成时反而是累赘。如果是完整系统需求，则不用考虑嵌入集成性，更应从系统整体考虑，可选择完善的平台或基于开源平台改造。