背景描述:客户的实际情况是需要在具体系统构架前,通过与厂商讨论确定最终的系统架构方案。

需求是客户自己有管理系统,希望建立一个独立的报表服务器,该报表服务器可以对多个管理系统提供报表服务,不知道润乾产品可以提供多少种报表的调用方式可以选择。

其次,希望可以通过API调用报表的某些功能,但是不知道服务器间访问如何调用API接口。

第三,报表访问时,需要防止直接拷贝url访问。而且其他系统调用报表时,也可以配置报表的授权情况。

 

相应解答:

由于客户需要的并非一个明确的技术答复,而是希望厂商给予架构部署时的参考意见,所以首先需要告诉客户的是润乾报表的基本技术规格,即润乾报表是以J2EE架构下的Servlet形式封装的一种服务类产品,因此所有适合于Servlet部署的方案都可以采用在润乾报表身上。此外,润乾报表的前端输出的可选方式是Taglib、以及调用API输出流两种主要方式,其中Taglib又包括文件方式和Bean方式。此三种方式都可以对应不同的报表调用技术和权限控制技术。

当客户明白润乾报表从底层到底是怎样的一种构成时,就可以引导客户进一步探讨各种技术方案的利弊和可行性,首先从跨服务器调用报表这种需求看,服务器端的选择基本上可以确定为一个Application Server部署润乾报表即可,所以重点是在于作为Client端的其他应用以何种方式来调用,这与其他应用的架构有关,经过了解,可能存在的应用有Java的,.net的以及C/S架构的。应此从调用方式上推荐采用HTML字符流式引用,这样可以以一种标准在多种应用下被调用。

采用流程调用的另外一个特点是适合于客户权限以及API调用的需求。首先在报表服务器上建立登录服务、调用服务、通用JSP接口、报表发布及下载接口以及标准JAVA RMI的stub以及skeleton。同时设计各种技术体系下访问上述服务的客户端代理(RMI只能在JAVA应用下使用)。其向对应的关系如下:

1、报表服务登录客户端代理————》报表登录服务

每个需要调用报表的客户应用,在Login过程加入报表服务登录客户端代理调用。

2、报表调用客户端代理————》报表调用服务

每个需要调用报表的客户应用,在自己系统内部完成权限验证后,调用客户端代理,读入HTML字符流。或者通过客户端代理传入标准身份信息,由报表调用服务完成身份验证。

3、JS直接引用————》通用JSP

此方式的好处是修改JSP不需要重新打包发布WAR,便于维护。但输出接口方式不够灵活,只能以WEB层进行引用。

4、报表调用客户端代理————》通用JSP

此方式与上面的好处相同,而且可以封装报表服务器的URL。缺点也与上一方式相同。

5、润乾的RMI客户端stub————》报表服务器的RMI skeleton

完成跨服务器的API调用,最灵活的方式。

结合灵活性、安全性、便利性(如尽量减少报表服务器的重部署频率,修改尽量集中在一两个可覆盖文件上)等综合因素,优先考虑的是通用JSP方式以及配套的服务——客户端代理方式。

此外,该架构还要考虑各系统使用者的责权分担问题,大家都希望在一定程度上各自负担自己系统部分的建设,但有不能部署那么多报表服务器,而且还需要有集中管控。所以可以考虑的两种方式,一、在同一服务器上并行部署多个报表应用,各应用将来的维护以及报表的增改都由各系统负责人管理,但这样一些共性修改会涉及到大量的重复工作,而且集中管控难度还是比较大的。二、同一到一个应用中,对外发布不用访问路径以及报表读写通用接口,各系统维护自己的对外接口和报表存放目录,其他的统一管理,这种方式比较理想,但需要各部分先协调完成共性部分,例如对可控项的整理(打印属性、样式集、权限控制点等等)。

最后,性能方案推荐采用专业版的管理控制台进行管理、采用动态并发控制以及集群技术,并在前期设计时考虑将来集群扩充的便利性。