公司从事电力行业软件开发，前两年开发了一套全省使用的系统，采用C/S架构，前端由BCB开发，后台是Tuxedo。

不知当时的架构师是怎么考虑的，为了减少服务器和客户端间的数据流量，传送内容按定长字节来进行切割，如0~10字节放用户名，10～14放年龄，14～100放备注信息。说是这样可以有效减少中间的冗余数据。

为此做了一个工具，在这个工具中建一个传送用的结构体（类似于数据库建表），有名称以及各字段名和长度类型等信息，然后由这个工具自动生成一部分c代码，用来进行上述的“打包”和“解包”工作。client需要请求服务时，需要在这个结构体中放入必要的参数然后打包发送给server，server接收到数据后进行解包，拿到参数，然后在tuxedo中查询数据库，再将结果“打包”发回client，client再进行“解包”获得最终数据。

今年开始，技术总监要求全公司统一架构，首先考虑的就是tuxedo作为交易中间件的高性能、高并发和分布式事务控制。于是我们各个部门和项目组开始转型。我们的系统大部分是B/S结构，Server端为Java，浏览器有JSP/Flex/SilverLight等等。

问题出现了，上述提到的工具生成的c代码（用于打包和解包）无法在java中使用，为此考虑使用了JNI开发一个适配来调用这块c程序，再由它和Tuxedo进行通讯。当时也考虑了由Tuxedo开放一个WebService的接口，Java直接访问WebService获取数据。

因为首要考虑性能，经过测试，通过JNI访问Tuxedo的速度优于JDBC（或Hibernate）的Java访问方式，且两者的速度都优于通过WebService访问Tuxedo的速度。最终确定了JNI的方案，随之带来的状况就是，以前用Grails十分钟或用JDBC一小时可以完成的查询，用JNI需要一至两天。

其中在JNI里解析Java程序传入的参数，再将参数打包发送给Tuxedo，再到Tuxedo的节点服务器和组件服务器里用pro c来解包并组织SQL进行查询，再对查询结果进行打包发回JNI，JNI再将结果转为Java格式返回。在这个开发过程中，基本远程连接到Linux服务器用vi编辑器编写c代码，没有好的IDE。写好程序后需要重新编译和发布，耗时几分钟，然后由客户端进行调用来测试是否正常，如果出错，就只能回去c代码中增加打印语句，重复上述过程来看输出的信息。

这样低效率的开发也就罢了。

项目中几个模块需要实现工单流转，要用到工作流引擎。不能再走java的路，JBPM等也无用武之地。负责Tuxedo架构的平台组提供了解决方案，在数据库建了三张表（两张记录各环节的信息以及连接关系，一张记录工单实例），然后再Tuxedo中提供了几个服务来读写这几张表，这就是“工作流引擎”了。可以实现顺序的流程配置，以及基于“SQL”查询的是非判断来选择走向。

因其过于简单，为了满足我们项目的需要，项目组的6人中抽出2人来对其进行扩展。项目原本预计时间为6人3个月，用上这个新的“架构”后，半年过去了，项目砍去了大部分功能或外包出去，预计还需2个月才能完成剩下的部分。“工作流引擎”扩展了半年，现在还在扩展中。。。

------------------------------------------

这个月，平台组为了进一步推广这个架构，使用Apache写了一个Http服务，所有前台（Java、Flex或其他技术）都将参数按规定的XML格式进行组织，然后发送给这个服务，由其按照一个单独的配置文件（记录了结构体的信息）将XML解析并打包发送给Tuxedo，返回的内容也由其解包并组织成XML反馈给前台。这样就把原来开发JNI的工作转变为编写这个配置文件的工作了。工作量减轻了不少。但是性能呢？相对于JDBC的优势呢？

现在公司要求慢慢放弃传统B/S项目三层中的服务层和持久层，由Tuxedo来实现。

------------------------------------------

我的疑问是，我们这些B/S项目的服务层和持久层主要进行数据库查询，用Tuxedo来实现这些查询真的有必要么？所谓的高并发高性能和分布式事务换来的是极其低下的开发效率和大量的体力劳动。按目前的架构，就算前台负载巨大，Tuxedo高并发的最终结果也只是把SQL压到了数据库端，就算用Java开发，结果也是一样，最终的瓶颈都在数据库。

为了体现Tuxedo的这些特性，更要把业务逻辑放到Tuxedo中去实现。

好吧���我们现在有了一个自己做的简单“工作流引擎”，我们还需要图形报表解析和生成功能，还需要进行文件上载和存储，还需要。。。。。。

一直被领导批评，项目进度缓慢，开发人员效率低，责任心不强，不能按时完成任务。

现在，领导说，这些技术上的问题都是可以解决的。

嗯，向着领导手指的方向继续前进吧。。。