这段时间突然多了好多客户演示，与单纯的OA不同，这次客户的项目涉及比较广泛，有税务有银行甚至还有erp，都是业务系统。与OA相比，更多的业务操作加入到了流程当中。这是个很好的现象，workflow的市场在持续增长。用户本身以前从来没有用过工作流，都是从去年才开始逐渐关注。有流程的地方就应该有工作流，这是用户的一个认知过程。工作流的使用在大众化，并不再局限于OA和一些特定的领域，由此带来的必然是工作流的竞争加剧和价格的白菜化。
    对工作流厂商来说，我觉得现在是一个很好的机会。就工作流系统本身，各个厂家产品的功能应该相差并不多，关键还在于产品的成熟度，如果听到用户抱怨他们成了你的测试部时，那你基本上就完了。在大的功能相差不大的情况下，剩下的就是用户体验，如何尽可能的让用户开发方便，良好的可扩展的接口固然不错，提供几个典型的实现就更好了。甚至在对方也采用webwork、struts的情况下可以提供已封装好的action,或者页面组件。最后不得不提的是价格，对一个成熟的产品来说，实际上它的成本是接近于0的，但实际情况切是往往需要很多的技术支持，越是不成熟的产品它的成本必然越高。就功能上来说，门户搭配工作项列表比单纯的工作项列表要好很多。
    在workflow价格低廉的情况下，BPM无疑是一个新的利润点。workflow在大多情况下是一种嵌入式，BPM则是独立部署。在用户实际业务集成的需求下，BPM更多的是一种高端的产品出现。目前国内真正意义上的BPM还是处于空白的状态，有的也只是在workflow中加入一些统计和报表的功能，一种概念上的炒作。所以说现在BPM正当时，对工作流厂家来说，BPM应该是努力的方向。
    但是BPM对于很多研发团队只有几个人的厂家来说是否又过于遥远呢？
一个朋友留言，提了一些关心的问题，这里说说自己的想法（不一定对）。
问题：数据范围的控制：“事实上不是每个用户都可以看到所有记录的。以财务管理为例，部门经理只能查看金额小于1W的数据；而总经理则没有限制”。象这样要根据数据的某个字段对数据范围进行控制，应该实现呢，是通过AOP动态改变执行的SQL吗？这样似乎不太可行，如果要执行的SQL特别复杂，那动态改变SQL 就更难了。现在的应用中一般使用hibernate，这样的话就变成了动态改变HQL，也是难的。
回答：目前在我的代码里就是通过AOP动态改变执行的SQL，改变HQL确实很困难，但是改变criteria就比较简单了。对于特别复杂的sql，我的建议是把这些SQL直接写到你的业务程序里去，或者单独配置出来，和ibatis比较类似。

问题：单条数据ACL权限：由于数据是不断增加的，所以要对单条数据的ACL权限，不应该是数据已存在，然后再对存在的数据授权，应该是对某种规则进行授权。以你举的个人通讯录为例，各人自己维护自己的通讯记录，数据只对自己可见，要想实现对自己的数据的可再授权，应该是对符合某个规则的数据进行授权，也就是说 “要执行授权操作的人就是数据的拥有者”这是个规则，那是不是应该对这个规则授权呢。
回答：我理解的和你不一样。我的理解是这样的，实际中我把单条数据的权限划分为拥有、浏览、修改、删除四种权限，用户拥有哪种权限就可以对数据进行相应哪种操作。“要执行授权操作的人就是数据的拥有者”也可以理解为“要执行授权操作的人就必须有该数据的拥有权限”，这可以理解为一种规则，但我更愿意把它理解为一种习惯，很显然对习惯授权是没有意义的。当然这里是存在规则的，这种规则简单的说是这样：当我新增一条数据时，哪些人对该条数据拥有拥有的权限，哪些人对该条数据拥有浏览的权限，哪些人对该条数据拥有修改的权限，哪些人对该条数据拥有删除的权限。权限相关记录会在新增这条数据时根据该规则生成。在上面的例子里，这一规则体现在：各人自己维护自己的通讯记录，数据只对自己可见。也就是说在用户新增自己的通讯记录时，系统同时往权限表里插入了该用户对该记录的一个拥有权限记录。

问题：数据字段权限：要实现对某个字段的权限控制，那是不是应该所有字段应该有个默认的操作呢，或者默认就是只可以查看，要进行修改的话就必须授权。但是通常整个应用中的字段非常多，这样是乎不太合理。那是不是可以做成所有字段默认就是可以CRUD的，只有要控制的字段才进行权限判断。同样，由于使用 Hibernate来进行持久化，那对字段的控制是不是就变成了对类中属性的控制。
回答：数据字段权限一直是一个很难办的事情，实际上我很倾向于把这个问题推到页面来解决。其实所有的权限控制最后都是要通过页面来表现的。其实对字段来说，所需要的权限也很简单：可见/不可见,只读/可修改。这样的话，通过标签的形式来控制字段的显示、只读就显得很自然。对字段的权限记录可以放入到数据库，或者xml中，与具体的pojo类没有关系，当渲染页面的时候，由标签来读取相关权限记录并控制显示。

问题：角色权限的继承：角色权限的继承通过规则来做，这个规则应该怎么设计呢。
回答：这个问题其实是一个分离关注点的问题。你可以抽象出一个规则接口，这个接口定义了对部门、角色下的用户而言，哪些权限是可以从部门角色继承的，继承几级，哪些是不可以的。然后再具体实现。更灵活的方式是定义出一个配置文件，运行时可以灵活修改。


平台现在无疑已经是一个用滥的概念。先来看看业务平台的定义：是为企业提供的一个可快速开发的、稳定的、成熟的业务基础开发平台。实际上在一个技术人员的眼里，平台=类springside的开发框架+一套组织机构+和组织机构相适应的一套权限系统+门户+信息资源库+工作流引擎+一些通用的业务模块。因为一直做关于所谓业务平台的开发，有过困惑也有思考，这里说说自己对于平台的一些想法，也希望大家多多拍砖。我认为一个好的业务平台应该做到下面的几点：
1、业务性。
   这个问题我曾经和胡长城有过很长时间的争论。最后我得承认胡兄的正确性：业务确实是一个平台的根本。一个业务平台如果不满足业务的需求，那么它存在的意义就值得怀疑。一个很简单的例子，协同办公中不可缺少的发文管理，正文需要用到电子签章，业务中有这个需求，平台不支持，那么这个平台就不是个好的业务平台。
2、易用性
   业务平台不是面对最终用户的，它需要做二次开发。这样平台对程序员的友好性就相当重要，毕竟平台的使用者还是程序员。
   基础代码生成是必要的，不管你采用何种方式，是根据已有表格来生成模型和相应代码还是先画出模型再来生成表格和相应代码（所谓的MDA）。平台的代码结构最好能够和IDE有个良好的结合，因为项目的开发往往是几个程序员协作的过程，平台对代码开发的支持不可能做到IDE的水平。最好的方式是生成的代码自动在IDE里有着清晰的结构，在IDE里编辑、测试自己的代码，然后自动发布到平台相应目录中，启动平台，代码运行成功。eclipse插件是个很好的选择。
   良好的API的支持，开发中不可避免的会与平台已有的组织机构模型和权限系统交互，这样良好的、封装清晰的API支持就很重要。
   页面组件的支持。往往有时候凌乱的WEB页面最让人头疼。对常用的一些页面元素可以用标签或是AJAX做进一步的封装。比如树组件、弹出层组件、分页组件等等。与这些相比，一些业务页面组件的封装也很重要。比如需要在页面选择用户，直接封装出一个用户选择组件，而不用开发人员在页面用弹出层+用户树自己再去组装。再比如说发文中的签批意见，可以用AJAX直接封装到页面里，不用用户自己调用相应API。意思就是让用户开发尽量简单，把工作从代码里尽量推到页面上去。
3、模块化。
   尽管这个或类似概念（比如说组件、构件）一再被平台厂家们提及，我对实际的实现一直报怀疑的态度。实际的实现往往是对模块的一个模拟。这里的模块实际上是对代码做出的一种人为上的区分，所谓的模块配置，更直接一点就是页面URL的配置。与代码行为无关，与运行期管理更没关。
4、可扩展性
   这个暂且不说，很大的一个话题。
5、前瞻性。
   一个优秀的平台凭什么和别人不同，一个很重要的一点就是平台的前瞻性。一句话，就是要有别人没有的东西。个人非常看好未来对业务整合的需求，遗留的业务系统+国外大厂商的概念轰炸让客户开口就是业务整合、BPM。是时候不再忽悠而是做点实际的东西了。
可以说，业务性+易用性在现阶段就是一个很好的平台了。如果再有些前瞻性的东西（注意：不是口头上！）这个平台应该说很优秀了。至于模块化、可扩展性，想想，现在只能说忽悠了。
随着近两年来各企业/单位的基础系统的建设，应用集成的需求已经越来越急切。个人认为现在的应用集成可以分为以下三种情况：
  一、门户+单点登录。这种情况最简单，说白了就是简单的页面集成。各个系统通过门户统一登录，登录完毕后在门户上显示各自的业务页面，当需要具体处理各项业务时跳转到各自的业务系统里。当然这里也有问题，仅仅B/S系统能做这种集成。这种情况也是实际项目中碰到最多的情况。
  二、数据集成。这个和第一种情况相比就复杂了很多。拿一个简单的情况来说，系统A和系统B里都有各自的一套组织机构，现在我想做集成，只保留一套组织机构然后做统一管理。需求合情合理，处理起来就麻烦了。模型设计相似还好一点，再简单一点可以做数据库的同步。但这往往是开发人员的一厢情愿。写适配器几乎是必须的。模型的不同带来的问题是最大的，系统A里有岗位这个对象，系统B里没有，怎么办？这种情况在实际项目中越来越多了，然后每一次都让人特别的难受。
  三、业务集成。提到业务集成，不得不说说SOA。SCA让业务集成看起来那么的顺理成章，SDO又搞定了数据交换这个头痛的问题。一切都是那么的美好（有点不太真实，嚯嚯）。因为最近对BPM关注比较多也准备往这方面做一些尝试，所以这里拿BPM举例，好比一个公司录人的流程，一开始我会调用原有的HR系统的业务服务录入人员信息，然后我又会在下一个流程节点调用财务系统相应的业务服务来计算新员工工资。可以这样认为，BPM是业务集成的最好的例子。这种情况在实际中用户也越来越多的提出来，或者说提到了这个概念（和各大公司的宣传有很大的关系）。个人也认为这一块应该有很大的发展空间。麻烦的地方也在于数据或者说服务的调用交互。
除了第一种情况，剩下两种情况都是很麻烦的。很多人都在说业务集成，但是数据集成是在任何有不止一套遗留系统时必须面对的问题。甚至我可以这么认为，数据集成是最困难的，因为它还没有一个标准，也不会有标准了。
最新的1.2*版本开始支持jndi数据源，版本与1.*完全兼容。注意的是以前的jackrabbit-core-1.x.jar现在
需要jackrabbit-core.jar，jackrabbit-api.jar, jackrabbit-jcr-commons.jar三个包来替代；另外，其要求Lucene 的版本要2.0，下了个2.1不行。
然后就是改配置文件。
原先的配置

现在的配置：

还有就是：不要仅仅修改你总的那个配置文件，每个工作区间下的配置文件都要同时修改，却记却记啊！