背景描述：客户的实际情况是需要在具体系统构架前，通过与厂商讨论确定最终的系统架构方案。
需求是客户自己有管理系统，希望建立一个独立的报表服务器，该报表服务器可以对多个管理系统提供报表服务，不知道润乾产品可以提供多少种报表的调用方式可以选择。
其次，希望可以通过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方式以及配套的服务——客户端代理方式。
此外，该架构还要考虑各系统使用者的责权分担问题，大家都希望在一定程度上各自负担自己系统部分的建设，但有不能部署那么多报表服务器，而且还需要有集中管控。所以可以考虑的两种方式，一、在同一服务器上并行部署多个报表应用，各应用将来的维护以及报表的增改都由各系统负责人管理，但这样一些共性修改会涉及到大量的重复工作，而且集中管控难度还是比较大的。二、同一到一个应用中，对外发布不用访问路径以及报表读写通用接口，各系统维护自己的对外接口和报表存放目录，其他的统一管理，这种方式比较理想，但需要各部分先协调完成共性部分，例如对可控项的整理（打印属性、样式集、权限控制点等等）。
最后，性能方案推荐采用专业版的管理控制台进行管理、采用动态并发控制以及集群技术，并在前期设计时考虑将来集群扩充的便利性。
