BlogJava-1+1=2,0+0=0-随笔分类-我的技术

SOA的组件实现---EJB+Spring+Hibernate

江上一叶舟 — Tue, 30 Jan 2007 15:29:00 GMT

      最近项目很变态，硬是要把Domino的东西往J2EE上搬，说什么文档型数据库无法跨越系统，我觉得如果照目前电信的系统结构来说，就算把Domino上的所有东西，包括process都搬到J2EE上，也无法解决各个系统之间很好协作的问题，Portal和统一认证已经在某种程度上帮了大忙，如果实在很想各个应用系统之间进行数据交互，开发webservice接口就ok了，甚至在系统开始规划的时候就不应该出现Domino这种东西，现在想起关系型数据库的好来了，未免累死了开发人员，所以我还是秉持我自己的原则：我们无限制的追求软件程序的完美，并不是为了那帮傻逼客户，而是为了让我们之后的程序员能够以更少的精力来更轻松的拿这份工资！
      牢骚完毕来说说目前的J2EE做法。既然涉及到流程，那不免就那两种，WFMC和BPEL，我们选择BPEL，原因是IBM支持BPEL，不要问我两种东西那种更优秀，我会告诉你：你搞清楚了也没意义，用户只相信IBM。
      既然用BPEL，IBM的Websphere Process Server首当其冲，项目组买了几百万的软件和服务就开始开发了，说实话，WPS真的是一个很好的SOA解决方案，但我个人认为绝对不适合中国政府、国企的流程开发，因为他无法很好的解决人工节点的问题，哪怕是引入了human task，于是我们又自己封装了一层小的流程引擎，当然我所要说的重点不是这个，而是我们在wps中所需要的JCA方式绑定的组件的实现方式：EJB+Spring+Hibernate，做好的EJB包可以以EJB Bind的Java component形式打入wps的assembly里，在bpel process中reference进来就可以了。下面我们主要说说EJB的实现。
      由于wps有个特点就是在流程实例结束后删除其自带数据库中的所有实例数据，所以我们必须在流程的最后一部将数据记录在我们自己的业务库中来，我们开发的EJB就实现了这个功能。
首先是业务逻辑，业务逻辑分成三个包，ejb、face、pojo，其中ejb是组件的本地接口，face是组件的功能性接口，pojo是具体实现类。
      具体逻辑代码不贴了，贴一个我写的例子：
      face中的功能接口：

1 package com.ideal.core.biz.face;
2
3 import java.rmi.RemoteException;
4
5 public interface SimpleService
6 {
7 public String sayHello(String message)throws Exception;
8 }
9

ejb中本地接口：

1package com.ideal.core.biz.ejb;
2
3import javax.ejb.EJBLocalObject;
4import com.ideal.core.biz.face.SimpleService;
5
6public interface SimpleLocal
7 extends EJBLocalObject, SimpleService
8{
9 public String sayHello(String message) throws Exception;
10}
11

ejb的home接口不贴了，直接贴bean类，我们这里用Stateless的

1package com.ideal.core.biz.ejb;
2
3import javax.ejb.SessionBean;
4import javax.ejb.SessionContext;
5import javax.ejb.CreateException;
6import com.ideal.core.biz.face.SimpleService;
7import org.springframework.ejb.support.AbstractStatelessSessionBean;
8import java.rmi.RemoteException;
9
10public class SimpleBean
11    extends AbstractStatelessSessionBean
12    implements SimpleService
13{
14    SessionContext sessionContext;
15    private SimpleService m_simple_service;
16
17    public void onEjbCreate() throws CreateException
18    {
19        m_simple_service = (SimpleService) getBeanFactory().getBean("SimpleService");
20    }
21
22    public String sayHello(String message) throws Exception
23    {
                 String message = "";
                       try {
                message = m_simple_service.sayHello(message);

        }
        catch (Exception ex)
        {
            this.sessionContext.setRollbackOnly();
            throw new EJBException();
        }
24        return message;
25    }
26}
27

pojo：

1package com.ideal.core.biz.pojo;
2
3import com.ideal.core.biz.face.SimpleService;
4
5public class SimpleServiceImpl implements SimpleService
6{
7    IUserInfoDAO user_dao;
8    public SimpleServiceImpl()
9    {
10    }
11    public String sayHello(String message)  throws Exception
12    {
13            Userinfo user = new Userinfo();
14            user.setName("2");
15            user.setPassword("2");
16            user.setUserid("2");
17            user_dao.saveUser(user);
18            user.setPassword("asddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd");
19            user_dao.saveUser(user);
20        return "hello," + message + "!";
21    }
22}
23

经过测试，容器事务可以正常回滚，前提是spring与hibernate的配置文件配对。
最终打包发布到Websphere上可以正常运行，做个web客户端简单测试一下就ok了。
放入wps上也运行正常。
最后说一句：不一定所有的国外产品都适用于我们的现状。

江上一叶舟 2007-01-30 23:29 发表评论

web开发中的权限设计拙见一二(3) ----资源配置与权限判断

江上一叶舟 — Wed, 03 Jan 2007 05:56:00 GMT

摘要: 在上文中我们提到了一个资源对应一个数据库表，在T_ResourceInfo表中我们也提到了有一个字段专门来记录表名，然后我书写一个资源配置文件，用来配置我的业务类与资源的对应关系，代码如下：123 4 阅读全文

江上一叶舟 2007-01-03 13:56 发表评论

web开发中的权限设计拙见一二(2) ----数据库设计

江上一叶舟 — Tue, 02 Jan 2007 15:41:00 GMT

      首先上文权限设计拙见(1)中只是想记录下自己权限设计上的一点看法，以及将自己日常最常用的权限解决方案记录下来以供日后回顾，没想到有朋友关注此类的设计，那就只能先把代码拿出来献丑了，抛砖引玉，大家共同探讨学习
      接着上文来说，上文所讨论的权限设计是一条思路，但既然是web应用，少不了数据库的支持，本文我们来讨论一下数据库的设计。（以下想法及思路仅仅代表本人拙见）
      说到权限的数据库设计，必先理清权限中几种实体及其关系，此部分想必有过设计权限经验的同仁都知道怎么设计了，网上摆渡一下也是一裤衩子一裤衩子的，我们就在最平凡直观的数据库关系的基础上来建立权限。下面是我的几个表（所有的表都带有一个pk_id,作为表的自动生成的唯一主键）：
用户表(T_UserInfo)：

1/*==============================================================*/
2/* Table: T_UserInfo                                            */
3/*==============================================================*/
4create table T_UserInfo
5(
6    pk_id                NUMBER                         not null,
7    name                 VARCHAR2(20),
8    sex                  BOOLEAN,
9    age                  int,
10    emp_num              NUMBER,
11    polity               int,
12    unit                 VARCHAR2(50),
13    department           VARCHAR2(20),
14    specialty            int,
15    position             VARCHAR2(10),
16    offtel               VARCHAR2(20),
17    famtel               VARCHAR2(20),
18    post_state           VARCHAR2(10),
19    remark               VARCHAR2(100),
20    constraint PK_T_USERINFO primary key (pk_id)
21);

用户表就不多说了，都是一些常用字段，年龄、电话、职位等，建议大家建立一个通用一些，字段多一些的一个用户表，便于以后扩展，以后如果有特殊需求，不用扩这个基本表，可以通过主外键关系来新建一个表，用于扩充字段
角色表(T_RoleInfo)：

1/*==============================================================*/
2/* Table: T_RoleInfo                                            */
3/*==============================================================*/
4create table T_RoleInfo
5(
6    pk_id                number                         not null,
7    role_name            VARCHAR2(20),
8    role_desc            VARCHAR2(100),
9    parent_role_id       NUMBER,
10    constraint PK_T_ROLEINFO primary key (pk_id)
11);

角色表中需要说明的就一个parent_role_id父角色id，此字段用来扩展角色的继承关系。
资源表(T_ResourceInfo)：

1/*==============================================================*/
2/* Table: T_ResourceInfo                                        */
3/*==============================================================*/
4create table T_ResourceInfo
5(
6    pk_id                NUMBER                         not null,
7    module_name          VARCHAR2(20),
8    module_code          VARCHAR2(10),
9    module_desc          VARCHAR2(100),
10    privilege_name       VARCHAR2(10),
11    privilege_code       CHAR,
12    privilege_desc       VARCHAR2(100),
13    constraint PK_T_RESOURCEINFO primary key (pk_id)
14);
15

这个表需要说明的就比较多了，首先该表用来记录资源与资源权限，我这边所谓的资源就是实体，就是数据库表，角色需要对应到资源，有些角色对该资源有权限，有些角色则对该资源无权限，角色可对此资源操作的权限也不同。说白了，就是不同的角色对不同的数据库表的操作权限不同。因此我们这里的资源就是数据库表。
module_name：资源名；module_code：资源代码（存放数据库表名）；
privilege_name：权限名；privilege_code：权限代码（代表权限的code,也就是我们上文所说的权值）
例如角色a对数据库表T_UserInfo有添加与删除的权限则该表应该按照如下配置：
module_name：人员信息；
module_code：T_UserInfo
privilege_name：添加与删除
privilege_code：6
这里我们假设的是2的0次方为添加权限，2的1次方为添加权限，2的2次方为删除权限，2的3次方为更新权限，则拥有添加与删除权限就应该为2的1次方+2的2次方=6，其实2的几次方代表什么含义我们可以另外开个数据库表来配置（或者xml文件）此处我们忽略这些步骤。当然如果你的权限较多，譬如你还希望a这个角色对人员信息表有上传得权限，我们可以将将上传权限定义为2的4次方，16，16的16进制数为10，记录在数据库里的形式应该为0x10如果a角色拥有添加、删除、更新、上传权限，则a的权值应该为2的1次方+2的2次方+2的3次方+2的4次方=30,用16进制来表示就应该为0x1E，记录16进制数据，你不用担心位数不够。
剩余的就是几张关系表了：
人员角色关系表(T_R_User_Role)：

1/*==============================================================*/
2/* Table: T_R_user_role                                         */
3/*==============================================================*/
4create table T_R_user_role
5(
6    pk_id                NUMBER                         not null,
7    user_id              NUMBER,
8    role_id              NUMBER,
9    constraint PK_T_R_USER_ROLE primary key (pk_id)
10);
11

角色资源关系表(T_R_Role_Resource)

1/*==============================================================*/
2/* Table: T_R_role_resource                                     */
3/*==============================================================*/
4create table T_R_role_resource
5(
6    pk_id                NUMBER                         not null,
7    role_id              NUMBER,
8    res_id               NUMBER,
9    constraint PK_T_R_ROLE_RESOURCE primary key (pk_id)
10);
11

当然如果你不怕麻烦，可以添加进去组(group)、系统(system)、组织(organization)，建立起一套属于你自己的完整的权限解决方案，作为系统无关的模块去套用到每个你所架构的应用中去，那是一件极爽的事情。
连续剧开始了，暂时搁笔~~

江上一叶舟 2007-01-02 23:41 发表评论

web开发中的权限设计拙见一二(1)----设计思路

江上一叶舟 — Tue, 02 Jan 2007 04:11:00 GMT

最近项目的项目很奇怪，一个大项目(系统)里包含了很多小的子系统，而这些子系统中都有权限控制的部分，这件事情挺让我头痛的，记得一年前在沈阳，我曾经有一段时间也因因这个问题而疲于奔命，为什么说疲于奔命呢？由于当时项目进度不允许，导致最终系统权限模块草草了事，每个模块都是由读权限字符串来控制用户ACL，当用户无法访问时，提示权限不够。这么做对用户是很不负责任的，既然让用户看到了操作的方式和界面，为什么又告诉用户没有权限呢？我开始怀疑我们是否应该在底层就封杀用户的访问权限。

现在项目开展起来了，虽然目前我已经有了对权限控制的一套方案，并且实施成了我的可重用框架代码，虽然目前的权限也是基于众星捧月的AOP思想，但我至今对权限设计仍有两个疑惑：

疑惑一：很多同行提出方案，想要在底层就截取用户权限，控制用户对方法或者类的访问。这样做的好处在于可以将系统功能与业务逻辑松散耦合，并且实现简单，结构清晰，三两个advisor、filter，或者acegi就能搞定，但在web程序中体现出了他的劣势，当我们将用户的访问拒绝在业务逻辑之外的时候，我们此时是否应该抛出异常提示用户？一旦提示用户没有相应的权限，我认为对于用户来说，这就不是一个perfect practice。由此得出，我们根本就不应该让用户做此次操作，而控制用户操作的源头就是界面，也就是说，在界面上我们就应该对用户的权限元素(如添加按钮、功能菜单等)进行控制。此时，一对矛盾出现了，要控制界面上形形色色的元素只有两种办法，一，将权限与你的界面结合起来设计，这将违背AOP的思想，也使得系统控制模块的重用性大大下降，二，我们借鉴primeton的想法，将权限控制的理念抽取出来，单独做成一套权限系统，解决你所有的需要权限控制的系统需求，这样也有令人头痛的问题，你的所有想用它来控制权限的系统，必须界面上统一风格。或许这样的方式对商业web系统是合适的，毕竟需要你大刀阔斧个性化的地方不多，但我们却很难保证在未来几年内商业web系统的风格不改变。再者，开发这么一个系统也不是一蹴而就的事，在这个问题上一直让我困惑不已。

疑惑二：大多应用的权限判定是基于权限字符串的，但存储在数据库中的权限字符串能够判定的权限并不多，在我们这次项目中，我引用了基于二进制的8421权限判定法则，我深深的感觉到权限字符串的弱势，这使我想起了中国古老一套数学理论-“盈不足术”，超递增序列的魅力在我眼前滑过，

首先我来解释一下盈余不足理论：有十只盒子，第一个盒子里放一个盘子，第二个盒子里放两只，第三个盒子里放四只，第四个盒子里放八只……第九个盒子里放256只，第十个盒子放512只，即第N只箱子里放2^(N-1)只盘子，一共1023只。那么命题如下：在1023这个数字之内，任何一个数目都可以由这十只盒子里的几只组合相加而成。那么1、2、4、8、16、32、64、128、256、512这个序列为什么有这么个魔力？这个数列的特点：1、每项是后一项的二倍，2、每项都比前面所有项的和大，而且大1。这个1就是关键，就因为这个1，它才可以按1递增，拼出总和之内任意一个整数。这个序列叫做超递增序列，它是解决背包问题的基础。3、拼出总和之内任意一个整数可以由这个序列中的一些数构成，且构成方法唯一，据说是密码学中的NP定理。譬如说这个数列总合中20这个数，只能由16+4一种方法构成，由此延伸出来，如果综合中这个数据代表一个权值，我们可以解出它的所有构成参数（操作），如20这个数据，我们可以挨个和序列中每一项按位与，得出来如果不等于0，就说明他是由这个数构成的。

保存权值到int还是varchar对于我们来说是个问题，当然，保存字符串的好处是运算压力小。我们可能听过一个故事，就是把这个超递增序列延伸到第64项，就是那个术士和皇帝在国际象棋棋盘上要米粒的传说。64项的和是一个天文数字！但计算机本身就是一个只认识二进制的机器！很多程序员整天只关心架构，甚至不知道或者不关心位操作是什么玩意，当然我们有朋友担心数据库的int不够长，那么既然可以保存一个只有0、1组成的varchar字符串，为什么不能保存一个十六进制的字符串，有人规定varchar只能保存01吗？十六进制串的长度正好是二进制的四分之一。

由此我们可以无限制的扩展权值操作。

在最近的项目里，我对权限的控制分成两个部分，第一就是用户体验上，我设置了一个权限标签，从数据库中抽取权限信息，然后做到标签里，也凑或算成是界面AOP了，第二就是底层的拦截，用了Spring 的AOP，为的是防止权限冲突，双管齐下。暂时解决权限所需，另外在算法上我用了16进制的权限判别代码，虽然配置较麻烦，写完代码还要写文档说明，不过也解决了权限繁杂又多的问题，暂时就这样了，嘿嘿，以后有空再研究。

江上一叶舟 2007-01-02 12:11 发表评论