先介绍下我们的OA的环境，websphere6.0.2.15 + db28.1 + eos53 2857 + goldgrid（金格公司在线office） + AIX，应用的多数据源。
按照项目进行，从OA说起，说说我所认同的关于流程，关于EOS的应用等等一些方法论。
OA的公文流转是一个很特殊的系统，因为其中会涉及到
1） 不同流程的切换。
收文转发文，发文转收文，我们的流程的第一个环节的参与者写入相关数据区。
2） 强行回收。
分送出去发现不对（可能是文档不对，也有可能是提交对象出错，本来应该提交给A,B,D，却不小心提交给了A,B,C），而有些人已阅，有些人未阅，那么该怎么办呢？这个时候就会需要强行回收C的工作项，然后把D添加进入该工作项的参与者中，这是强行回收的很好的一种解决方案。
3） 流程激活等等。
我们采用的重新调起一个流程，copy业务数据，还有公文正文，然后重新走简化后流程。这样设计的好处就在于对于公文正文来说，我们操作的一份文件，然后之前的业务数据和流程日志都能保留，并能再次查阅。
用java做架构之初，我们会在整体的基础上，做很多java的接口。这是作为一个好的项目经理或者架构师应该考虑的问题，现如今用我们的EOS，在设计架构之初，就应该考虑到面向服务的接口的设计和规范，才能让项目正确有效的进行。面向服务的接口设计，这样一说，还真的很有SOA的味道了。J
我们EOS不是万金油，涂哪都可以的，在设计的时候，应该有所规避。本来websphere就是一个很吃内存的东西，而如果你读几兆的文件在内存中，多少内存也紧不住并发的吃。而且在内存的节点创建，拷贝，本来就是费时间的操作。所以我个人觉得，我们eos不适合做大数据量的大量的操作。注意，此话的含义不是我们EOS不适合做大的应用，或者高并发的应用。大数据量的大量操作，java调用c去做是最佳方案，我所知道的最典型的案例就是中文分词。退而求其次，java操作。在eos的应用中，我们不是不推荐客户或者pso的兄弟们写bizlet，而是说，如果遇到性能或者效率的瓶颈，用java是最好的选择。
而在eos的底层中，如果单纯的因为复用而复用，把业务逻辑写的很复杂，个人觉得不值当。要有取有舍，一个很简单的业务逻辑，需要考虑很多种情况，就需要加上很多判断，我不认为这样能体现出EOS的复用价值。而且有一种情况，为了完成一个功能，而需要把一个业务逻辑写的很复杂，我觉得应该可以考虑抽取一部分功能形成biz，然后在biz里面调用biz，就算以后优化，我们可以把这个biz转换成bizlet，如果一个biz写的很大，很复杂，非常不适合在做优化。
作者 刘先军 普元PS工程师
