IT博客-Dancing Square

关于RBAC权限

Dancer — Tue, 28 Oct 2008 07:18:00 GMT

权限往往是一个极其复杂的问题，但也可简单表述为这样的逻辑表达式：
判断“Who对What(Which)进行How的操作”的逻辑表达式是否为真。
针对不同的应用，需要根据项目的实际情况和具体架构，在维护性、灵活性、完整性等N多个方案之间比较权衡，选择符合的方案。
目标：
直观，因为系统最终会由最终用户来维护，权限分配的直观和容易理解，显得比较重要，系统不辞劳苦的实现了组的继承，除了功能的必须，更主要的就是因为它足够直观。
简单，包括概念数量上的简单和意义上的简单还有功能上的简单。想用一个权限系统解决所有的权限问题是不现实的。设计中将常常变化的“定制”特点比较强的部分判断为业务逻辑，而将常常相同的“通用”特点比较强的部分判断为权限逻辑就是基于这样的思路。
扩展，采用可继承在扩展上的困难。的Group概念在支持权限以组方式定义的同时有效避免了重定义时
现状：
对于在企业环境中的访问控制方法，一般有三种：
1.自主型访问控制方法。目前在我国的大多数的信息系统中的访问控制模块中基本是借助于自主型访问控制方法中的访问控制列表(ACLs)。
2.强制型访问控制方法。用于多层次安全级别的军事应用。
3.基于角色的访问控制方法（RBAC）。是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是：
1.减小授权管理的复杂性，降低管理开销。
2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。

名词：
粗粒度：表示类别级，即仅考虑对象的类别(the type of object)，不考虑对象的某个特定实例。比如，用户管理中，创建、删除，对所有的用户都一视同仁，并不区分操作的具体对象实例。
细粒度：表示实例级，即需要考虑具体对象的实例(the instance of object)，当然，细粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。比如，合同管理中，列表、删除，需要区分该合同实例是否为当前用户所创建。

原则：
权限逻辑配合业务逻辑。即权限系统以为业务逻辑提供服务为目标。相当多细粒度的权限问题因其极其独特而不具通用意义，它们也能被理解为是“业务逻辑”的一部分。比如，要求：“合同资源只能被它的创建者删除，与创建者同组的用户可以修改，所有的用户能够浏览”。这既可以认为是一个细粒度的权限问题，也可以认为是一个业务逻辑问题。在这里它是业务逻辑问题，在整个权限系统的架构设计之中不予过多考虑。当然，权限系统的架构也必须要能支持这样的控制判断。或者说，系统提供足够多但不是完全的控制能力。即，设计原则归结为：“系统只提供粗粒度的权限，细粒度的权限被认为是业务逻辑的职责”。

需要再次强调的是，这里表述的权限系统仅是一个“不完全”的权限系统，即，它不提供所有关于权限的问题的解决方法。它提供一个基础，并解决那些具有“共性”的(或者说粗粒度的)部分。在这个基础之上，根据“业务逻辑”的独特权限需求，编码实现剩余部分(或者说细粒度的)部分，才算完整。回到权限的问题公式，通用的设计仅解决了Who+What+How 的问题，其他的权限问题留给业务逻辑解决。
概念：
Who：权限的拥用者或主体（Principal、User、Group、Role、Actor等等）
What：权限针对的对象或资源（Resource、Class）。
How：具体的权限（Privilege, 正向授权与负向授权）。
Role：是角色，拥有一定数量的权限。
Operator：操作。表明对What的How 操作。
说明：
User：与 Role 相关，用户仅仅是纯粹的用户，权限是被分离出去了的。User是不能与 Privilege 直接相关的，User 要拥有对某种资源的权限，必须通过Role去关联。解决 Who 的问题。
Resource：就是系统的资源，比如部门新闻，文档等各种可以被提供给用户访问的对象。资源可以反向包含自身，即树状结构，每一个资源节点可以与若干指定权限类别相关可定义是否将其权限应用于子节点。
Privilege：是Resource Related的权限。就是指，这个权限是绑定在特定的资源实例上的。比如说部门新闻的发布权限，叫做"部门新闻发布权限"。这就表明，该Privilege是一个发布权限，而且是针对部门新闻这种资源的一种发布权限。Privilege是由Creator在做开发时就确定的。权限，包括系统定义权限和用户自定义权限用户自定义权限之间可以指定排斥和包含关系(如：读取，修改，管理三个权限，管理权限包含前两种权限)。Privilege 如\"删除" 是一个抽象的名词，当它不与任何具体的 Object 或 Resource 绑定在一起时是没有任何意义的。拿新闻发布来说，发布是一种权限，但是只说发布它是毫无意义的。因为不知道发布可以操作的对象是什么。只有当发布与新闻结合在一起时，才会产生真正的 Privilege。这就是 Privilege Instance。权限系统根据需求的不同可以延伸生很多不同的版本。
Role：是粗粒度和细粒度(业务逻辑)的接口，一个基于粗粒度控制的权限框架软件，对外的接口应该是Role，具体业务实现可以直接继承或拓展丰富Role的内容，Role不是如同User或Group的具体实体，它是接口概念，抽象的通称。
Group：用户组，权限分配的单位与载体。权限不考虑分配给特定的用户。组可以包括组(以实现权限的继承)。组可以包含用户，组内用户继承组的权限。Group要实现继承。即在创建时必须要指定该Group的Parent是什么Group。在粗粒度控制上，可以认为，只要某用户直接或者间接的属于某个Group那么它就具备这个Group的所有操作许可。细粒度控制上，在业务逻辑的判断中，User仅应关注其直接属于的Group，用来判断是否“同组” 。Group是可继承的，对于一个分级的权限实现，某个Group通过“继承”就已经直接获得了其父Group所拥有的所有“权限集合”，对这个Group而言，需要与权限建立直接关联的，仅是它比起其父Group需要“扩展”的那部分权限。子组继承父组的所有权限，规则来得更简单，同时意味着管理更容易。为了更进一步实现权限的继承，最直接的就是在Group上引入“父子关系”。
User与Group是多对多的关系。即一个User可以属于多个Group之中，一个Group可以包括多个User。
子Group与父Group是多对一的关系。
Operator某种意义上类似于Resource + Privilege概念，但这里的Resource仅包括Resource Type不表示Resource Instance。
Group 可以直接映射组织结构，Role 可以直接映射组织结构中的业务角色，比较直观，而且也足够灵活。
Role对系统的贡献实质上就是提供了一个比较粗颗粒的分配单位。
Group与Operator是多对多的关系。各概念的关系图示如下：
解释：
Operator的定义包括了Resource Type和Method概念。即，What和How的概念。之所以将What和How绑定在一起作为一个Operator概念而不是分开建模再建立关联，这是因为很多的How对于某What才有意义。比如，发布操作对新闻对象才有意义，对用户对象则没有意义。
How本身的意义也有所不同，具体来说，对于每一个What可以定义N种操作。比如，对于合同这类对象，可以定义创建操作、提交操作、检查冲突操作等。可以认为，How概念对应于每一个商业方法。其中，与具体用户身份相关的操作既可以定义在操作的业务逻辑之中，也可以定义在操作级别。比如，创建者的浏览视图与普通用户的浏览视图要求内容不同。既可以在外部定义两个操作方法，也可以在一个操作方法的内部根据具体逻辑进行处理。具体应用哪一种方式应依据实际情况进行处理。
这样的架构，应能在易于理解和管理的情况下，满足绝大部分粗粒度权限控制的功能需要。但是除了粗粒度权限，系统中必然还会包括无数对具体Instance的细粒度权限。这些问题，被留给业务逻辑来解决，这样的考虑基于以下两点：
一方面，细粒度的权限判断必须要在资源上建模权限分配的支持信息才可能得以实现。比如，如果要求创建者和普通用户看到不同的信息内容，那么，资源本身应该有其创建者的信息。另一方面，细粒度的权限常常具有相当大的业务逻辑相关性。对不同的业务逻辑，常常意味着完全不同的权限判定原则和策略。相比之下，粗粒度的权限更具通用性，将其实现为一个架构，更有重用价值；而将细粒度的权限判断实现为一个架构级别的东西就显得繁琐，而且不是那么的有必要，用定制的代码来实现就更简洁，更灵活。
所以细粒度控制应该在底层解决，Resource在实例化的时候，必需指定Owner和GroupPrivilege在对Resource进行操作时也必然会确定约束类型：究竟是OwnerOK还是GroupOK还是AllOK。Group应和Role严格分离User和Group是多对多的关系，Group只用于对用户分类，不包含任何Role的意义；Role只授予User，而不是Group。如果用户需要还没有的多种Privilege的组合，必须新增Role。Privilege必须能够访问Resource，同时带User参数，这样权限控制就完备了。
思想：
权限系统的核心由以下三部分构成：1.创造权限，2.分配权限，3.使用权限，然后，系统各部分的主要参与者对照如下：1.创造权限 - Creator创造，2.分配权限 - Administrator 分配，3.使用权限 - User：
1. Creator 创造 Privilege， Creator 在设计和实现系统时会划分，一个子系统或称为模块，应该有哪些权限。这里完成的是 Privilege 与 Resource 的对象声明，并没有真正将 Privilege 与具体Resource 实例联系在一起，形成Operator。
2. Administrator 指定 Privilege 与 Resource Instance 的关联。在这一步，权限真正与资源实例联系到了一起，产生了Operator（Privilege Instance）。Administrator利用Operator这个基本元素，来创造他理想中的权限模型。如，创建角色，创建用户组，给用户组分配用户，将用户组与角色关联等等...这些操作都是由 Administrator 来完成的。
3. User 使用 Administrator 分配给的权限去使用各个子系统。Administrator 是用户，在他的心目中有一个比较适合他管理和维护的权限模型。于是，程序员只要回答一个问题，就是什么权限可以访问什么资源，也就是前面说的 Operator。程序员提供 Operator 就意味着给系统穿上了盔甲。Administrator 就可以按照他的意愿来建立他所希望的权限框架可以自行增加，删除，管理Resource和Privilege之间关系。可以自行设定用户User和角色Role的对应关系。(如果将 Creator看作是 Basic 的发明者， Administrator 就是 Basic 的使用者，他可以做一些脚本式的编程) Operator是这个系统中最关键的部分，它是一个纽带，一个系在Programmer，Administrator，User之间的纽带。
用一个功能模块来举例子。
一．建立角色功能并做分配：
1．如果现在要做一个员工管理的模块(即Resources)，这个模块有三个功能，分别是：增加，修改，删除。给这三个功能各自分配一个ID，这个ID叫做功能代号：
Emp_addEmp，Emp_deleteEmp，Emp_updateEmp。
2．建立一个角色(Role)，把上面的功能代码加到这个角色拥有的权限中，并保存到数据库中。角色包括系统管理员，测试人员等。
3．建立一个员工的账号，并把一种或几种角色赋给这个员工。比如说这个员工既可以是公司管理人员，也可以是测试人员等。这样他登录到系统中将会只看到他拥有权限的那些模块。
二．把身份信息加到Session中。
登录时，先到数据库中查找是否存在这个员工，如果存在，再根据员工的sn查找员工的权限信息，把员工所有的权限信息都入到一个Hashmap中，比如就把上面的Emp_addEmp等放到这个Hashmap中。然后把Hashmap保存在一个UserInfoBean中。最后把这个UserInfoBean放到Session中，这样在整个程序的运行过程中，系统随时都可以取得这个用户的身份信息。
三．根据用户的权限做出不同的显示。
可以对比当前员工的权限和给这个菜单分配的“功能ID”判断当前用户是否有打开这个菜单的权限。例如：如果保存员工权限的Hashmap中没有这三个ID的任何一个，那这个菜单就不会显示，如果员工的Hashmap中有任何一个ID，那这个菜单都会显示。
对于一个新闻系统(Resouce)，假设它有这样的功能(Privilege)：查看，发布，删除，修改；假设对于删除，有\"新闻系统管理者只能删除一月前发布的，而超级管理员可删除所有的这样的限制，这属于业务逻辑(Business logic)，而不属于用户权限范围。也就是说权限负责有没有删除的Permission，至于能删除哪些内容应该根据UserRole or UserGroup来决定(当然给UserRole or UserGroup分配权限时就应该包含上面两条业务逻辑)。
一个用户可以拥有多种角色，但同一时刻用户只能用一种角色进入系统。角色的划分方法可以根据实际情况划分，按部门或机构进行划分的，至于角色拥有多少权限，这就看系统管理员赋给他多少的权限了。用户—角色—权限的关键是角色。用户登录时是以用户和角色两种属性进行登录的（因为一个用户可以拥有多种角色，但同一时刻只能扮演一种角色），根据角色得到用户的权限，登录后进行初始化。这其中的技巧是同一时刻某一用户只能用一种角色进行登录。
针对不同的“角色”动态的建立不同的组，每个项目建立一个单独的Group，对于新的项目，建立新的 Group 即可。在权限判断部分，应在商业方法上予以控制。比如：不同用户的“操作能力”是不同的(粗粒度的控制应能满足要求)，不同用户的“可视区域”是不同的(体现在对被操作的对象的权限数据，是否允许当前用户访问，这需要对业务数据建模的时候考虑权限控制需要)。
扩展性：
有了用户/权限管理的基本框架，Who(User/Group)的概念是不会经常需要扩展的。变化的可能是系统中引入新的 What (新的Resource类型)或者新的How(新的操作方式)。那在三个基本概念中，仅在Permission上进行扩展是不够的。这样的设计中Permission实质上解决了How 的问题，即表示了“怎样”的操作。那么这个“怎样”是在哪一个层次上的定义呢？将Permission定义在“商业方法”级别比较合适。比如，发布、购买、取消。每一个商业方法可以意味着用户进行的一个“动作”。定义在商业逻辑的层次上，一方面保证了数据访问代码的“纯洁性”，另一方面在功能上也是“足够”的。也就是说，对更低层次，能自由的访问数据，对更高层次，也能比较精细的控制权限。
确定了Permission定义的合适层次，更进一步，能够发现Permission实际上还隐含了What的概念。也就是说，对于What的How操作才会是一个完整的Operator。比如，“发布”操作，隐含了“信息”的“发布”概念，而对于“商品”而言发布操作是没有意义的。同样的，“购买”操作，隐含了“商品”的“购买”概念。这里的绑定还体现在大量通用的同名的操作上，比如，需要区分“商品的删除”与“信息的删除”这两个同名为“删除”的不同操作。
提供权限系统的扩展能力是在Operator (Resource + Permission)的概念上进行扩展。Proxy 模式是一个非常合适的实现方式。实现大致如下：在业务逻辑层(EJB Session Facade [Stateful SessionBean]中)，取得该商业方法的Methodname，再根据Classname和 Methodname 检索Operator 数据，然后依据这个Operator信息和Stateful中保存的User信息判断当前用户是否具备该方法的操作权限。
应用在 EJB 模式下，可以定义一个很明确的 Business层次，而一个Business 可能意味着不同的视图，当多个视图都对应于一个业务逻辑的时候，比如，Swing Client以及 Jsp Client 访问的是同一个 EJB 实现的 Business。在 Business 层上应用权限较能提供集中的控制能力。实际上，如果权限系统提供了查询能力，那么会发现，在视图层次已经可以不去理解权限，它只需要根据查询结果控制界面就可以了。
灵活性：
Group和Role，只是一种辅助实现的手段，不是必需的。如果系统的Role很多，逐个授权违背了“简单，方便”的目的，那就引入Group，将权限相同的Role组成一个Group进行集中授权。Role也一样，是某一类Operator的集合，是为了简化针对多个Operator的操作。
Role把具体的用户和组从权限中解放出来。一个用户可以承担不同的角色，从而实现授权的灵活性。当然，Group也可以实现类似的功能。但实际业务中，Group划分多以行政组织结构或业务功能划分；如果为了权限管理强行将一个用户加入不同的组，会导致管理的复杂性。
Domain的应用。为了授权更灵活，可以将Where或者Scope抽象出来，称之为Domain，真正的授权是在Domain的范围内进行，具体的Resource将分属于不同的Domain。比如：一个新闻机构有国内与国外两大分支，两大分支内又都有不同的资源（体育类、生活类、时事政治类）。假如所有国内新闻的权限规则都是一样的，所有国外新闻的权限规则也相同。则可以建立两个域，分别授权，然后只要将各类新闻与不同的域关联，受域上的权限控制，从而使之简化。
权限系统还应该考虑将功能性的授权与资源性的授权分开。很多系统都只有对系统中的数据（资源）的维护有权限控制，但没有对系统功能的权限控制。
权限系统最好是可以分层管理而不是集中管理。大多客户希望不同的部门能且仅能管理其部门内部的事务，而不是什么都需要一个集中的Administrator或Administrators组来管理。虽然你可以将不同部门的人都加入Administrators组，但他们的权限过大，可以管理整个系统资源而不是该部门资源。
正向授权与负向授权：正向授权在开始时假定主体没有任何权限，然后根据需要授予权限，适合于权限要求严格的系统。负向授权在开始时假定主体有所有权限，然后将某些特殊权限收回。
权限计算策略：系统中User，Group，Role都可以授权，权限可以有正负向之分，在计算用户的净权限时定义一套策略。
系统中应该有一个集中管理权限的AccessService，负责权限的维护（业务管理员、安全管理模块）与使用（最终用户、各功能模块），该AccessService在实现时要同时考虑一般权限与特殊权限。虽然在具体实现上可以有很多，比如用Proxy模式，但应该使这些Proxy依赖于AccessService。各模块功能中调用AccessService来检查是否有相应的权限。所以说，权限管理不是安全管理模块自己一个人的事情，而是与系统各功能模块都有关系。每个功能模块的开发人员都应该熟悉安全管理模块，当然，也要从业务上熟悉本模块的安全规则。
技术实现：
1．表单式认证，这是常用的，但用户到达一个不被授权访问的资源时，Web容器就发
出一个html页面，要求输入用户名和密码。
2．一个基于Servlet Sign in/Sign out来集中处理所有的Request，缺点是必须由应用程序自己来处理。
3．用Filter防止用户访问一些未被授权的资源，Filter会截取所有Request/Response，
然后放置一个验证通过的标识在用户的Session中，然后Filter每次依靠这个标识来决定是否放行Response。
这个模式分为：
Gatekeeper ：采取Filter或统一Servlet的方式。
Authenticator：在Web中使用JAAS自己来实现。
用户资格存储LDAP或数据库：
1. Gatekeeper拦截检查每个到达受保护的资源。首先检查这个用户是否有已经创建
好的Login Session，如果没有，Gatekeeper 检查是否有一个全局的和Authenticator相关的session？
2. 如果没有全局的session，这个用户被导向到Authenticator的Sign-on 页面，
要求提供用户名和密码。
3. Authenticator接受用户名和密码，通过用户的资格系统验证用户。
4. 如果验证成功，Authenticator将创建一个全局Login session，并且导向Gatekeeper
来为这个用户在他的web应用中创建一个Login Session。
5. Authenticator和Gatekeepers联合分享Cookie，或者使用Tokens在Query字符里。

Dancer 2008-10-28 15:18 发表评论

BPM与工作流的区别

Dancer — Sat, 14 Jun 2008 07:50:00 GMT

随着信息技术的发展，越来越多的信息系统如 ERP 、 CRM 、 SRM 等得到广泛应用，其中部分信息系统能实现工作流的固化和自动化，提高流程效率。但他们仍无法实质性改善企业的整体流程效率，提高企业的竞争力。 BPM 就是在早期的这些系统的运营与使用经验等基础上建立的。

BPM 与工作流相比有如下的不同：

( 一 ) 跨组织的业务流程描述语言和工具。在工作流系统上马早期，经常会发现同一个企业内部不同组织单元、部门的流程采用不同的描述方法，比如 A/B/C/F 四个部门的账目管理系统采用某种工作流系统，而 A/B/D/E 四个部门的订单和销售管理系统又采用另外一种工作流系统。这种情况在大型企业集团内部尤为明显，影响了各业务单元的业务协同和业务最佳实践的提炼和推广。而 BPM 致力于跨组织的业务流程描述语言和工具，避免了企业各部门进行业务流程交流和沟通时各说各话的情况。

( 二 ) 统一的流程架构。企业内部从单一管理主题出发进行设计的工作流，通常在企业中缺乏对业务运营活动的总体考虑，局限于本部门或者本业务的业务需求，各部门和各管理专题之间的流程无法衔接，信息的共享和传递困难，存在大量流程断点。而 BPM 在流程之间进行衔接、协调，避免了流程孤岛的产生； BPM 的目标是形成端到端的流程体系，提高整个业务流程运行的效率、成本、质量，在激烈的市场竞争环境下，满足客户的需求。

（三）无“甲方优势”现象。如果用一般的工作流系统做接口，我们发现一个有趣的现象，就是服务提供方的甲方优势现象。通常，一个工作流系统要和另外一个已经存在的系统做接口，工作流系统是有求于已经存在的系统，也就是已经存在的系统有“甲方优势”。这样，工作流系统就必须按照已经存在的系统的技术规格来实现，离“跨组织的业务流程描述语言和工具”就越来越远了，更不用谈“跨企业的业务流程管理”。而 BPM 是在“工作流系统”和“已经存在的系统”之间建立了一个公平的约定，不存在“甲方优势”。

( 四 ) 流程的持续改进。由于工作流系统的存在，相关的业务人员通常已经忽略其内嵌的业务流程，业务部门对信息系统内嵌的流程缺乏直观认识和关注，工作流系统的改进非常的复杂，更不要谈什么持续改进了。但是 BPM 帮助业务人员密切关注信息系统内嵌流程与其它业务流程衔接关系，随着业务内外部环境的变化，及时进行流程的调整；这种情况下，流程的持续改进，成为提高企业整体流程运行效率的最主要因素。

（五） BPM 的 SOA 本质。 SOA 是创建更灵活的企业基础架构的架构方法，而 BPM 是一套协调的业务流程活动。 SOA 使用户可以轻松完成将业务流程连接到基础系统的任务，从而节省时间和 IT 资源。与之相比，将流程链接到传统的应用通常要依赖大量不同的专有技术。而且，在采用 BPM 的同时转向 SOA 可以促进 SOA 组件的再利用，从而最大程度地降低业务流程本身的复杂性。

（六） BPM 一定是企业级的。要实施 BPM ，一定要树立流程战略、流程设计、流程实施和流程监控的循环管理理念 : 从企业的发展战略出发制定流程的战略，将战略指标分解为流程的目标体系，通过流程实现战略的落地 ; 根据流程战略进行业务流程的梳理、设计和优化 ; 通过组织结构和信息系统的调整来实施业务流程 ; 通过流程合规管理和流程绩效监控，对流程执行情况进行监控，根据结果调整业务流程设计。

如果你正在为信息孤岛 (ERP 、 CRM 、 HR) 这类的以工作流为核心的系统造成的工作瓶颈而苦恼，如果你想抢得市场先机，或者希望强化服务质量、传承既有知识，现在是该使用 BPM 的时候了。(

Dancer 2008-06-14 15:50 发表评论

学习笔记之什么是持久化和对象关系映射ORM技术

Dancer — Mon, 09 Jun 2008 09:21:00 GMT

2.什么是持久化? 为什么要持久化? 1.什么是持久化？
本人找了好多文章都没有找到满意的答案，最后是从孙卫琴写的《精通Hibernate：Java对象持久化技术详解》中，看到如下的解释，感觉还是比较完整的。摘抄如下：
狭义的理解: “持久化”仅仅指把域对象永久保存到数据库中；广义的理解,“持久化”包括和数据库相关的各种操作(持久化就是将有用的数据以某种技术保存起来,将来可以再次取出来应用,数据库技术,将内存数据一文件的形式保存在永久介质中(磁盘等)都是持久化的例子.)。
●     保存：把域对象永久保存到数据库。
●     更新：更新数据库中域对象的状态。
●     删除：从数据库中删除一个域对象。
●     加载：根据特定的OID，把一个域对象从数据库加载到内存。
●     查询：根据特定的查询条件，把符合查询条件的一个或多个域对象从数据库加载内在存中。 2．为什么要持久化？
持久化技术封装了数据访问细节，为大部分业务逻辑提供面向对象的API。
● 通过持久化技术可以减少访问数据库数据次数，增加应用程序执行速度；
● 代码重用性高，能够完成大部分数据库操作；
● 松散耦合，使持久化不依赖于底层数据库和上层业务逻辑实现，更换数据库时只需修改配置文件而不用修改代码。

学习笔记之什么是持久化和对象关系映射ORM技术
by Naven at 2005-09-19

何谓“持久化”
持久（Persistence），即把数据（如内存中的对象）保存到可永久保存的存储设备中（如磁盘）。持久化的主要应用是将内存中的数据存储在关系型的数据库中，当然也可以存储在磁盘文件中、XML数据文件中等等。
何谓“持久层”
持久层（Persistence Layer），即专注于实现数据持久化应用领域的某个特定系统的一个逻辑层面，将数据使用者和数据实体相关联。
何谓“对象数据映射（ORM）”
ORM-Object/Relational Mapper，即“对象-关系型数据映射组件”。对于O/R，即 Object（对象）和 Relational（关系型数据），表示必须同时使用面向对象和关系型数据进行开发。
备注：建模领域中的 ORM 为 Object/Role Modeling（对象角色建模）。另外这里是“O/R Mapper”而非“O/R Mapping”。相对来讲，O/R Mapping 描述的是一种设计思想或者实现机制，而 O/R Mapper指以O/R原理设计的持久化框架（Framework），包括 O/R机制还有 SQL自生成，事务处理，Cache管理等。

除了 ORM 技术，还有以下几种持久化技术
主动域对象模式
它是在实现中封装了关系数据模型和数据访问细节的一种形式。在 J2EE 架构中，EJB 组件分为会话 EJB 和实体 EJB。会话 EJB 通常实现业务逻辑，而实体 EJB 表示业务实体。实体 EJB 又分为两种：由 EJB 本身管理持久化，即 BMP（Bean-Managed Persistence）；有 EJB 容器管理持久化，即 CMP（Container-Managed Persistence）。BM P就是主动域对象模式的一个例子，BMP 表示由实体 EJB 自身管理数据访问细节。
主动域对象本身位于业务逻辑层，因此采用主动域对象模式时，整个应用仍然是三层应用结构，并没有从业务逻辑层分离出独立的持久化层。
JDO 模式
Java Data Objects（JDO）是 SUN 公司制定的描述对象持久化语义的标准API。严格的说，JDO 并不是对象-关系映射接口，因为它支持把对象持久化到任意一种存储系统中，包括关系数据库、面向对象的数据库、基于 XML 的数据库，以及其他专有存储系统。由于关系数据库是目前最流行的存储系统，许多 JDO 的实现都包含了对象-关系映射服务。
CMP 模式
在 J2EE 架构中，CMP（Container-Managed Persistence）表示由 EJB 容器来管理实体 EJB 的持久化，EJB 容器封装了对象-关系的映射及数据访问细节。CMP 和 ORM 的相似之处在于，两者都提供对象-关系映射服务，都把对象持久化的任务从业务逻辑中分离出来。区别在于 CMP 负责持久化实体 EJB 组件，而 ORM 负责持久化 POJO，它是普通的基于 Java Bean 形式的实体域对象。
一般把基于 Java Bean 形式的实体域对象称为 POJO（Plain Old Java Object），意为又普通又古老的 Java 对象的意思。随着各种 ORM 映射工具的日趋成熟和流行，POJO有重现光彩，它和基于 CMP 的实体 EJB 相比，即简单又具有很高的可移植性，因此联合使用 ORM 映射工具和 POJO，已经成为一种越来越受欢迎的且用来取代 CMP 的持久化方案。POJO 的缺点就是无法做远程调用，不支持分布式计算。

为什么要做持久化和ORM设计
在目前的企业应用系统设计中，MVC，即 Model（模型）- View（视图）- Control（控制）为主要的系统架构模式。MVC 中的 Model 包含了复杂的业务逻辑和数据逻辑，以及数据存取机制（如 JDBC的连接、SQL生成和Statement创建、还有ResultSet结果集的读取等）等。将这些复杂的业务逻辑和数据逻辑分离，以将系统的紧耦合关系转化为松耦合关系（即解耦合），是降低系统耦合度迫切要做的，也是持久化要做的工作。MVC 模式实现了架构上将表现层（即View）和数据处理层（即Model）分离的解耦合，而持久化的设计则实现了数据处理层内部的业务逻辑和数据逻辑分离的解耦合。而 ORM 作为持久化设计中的最重要也最复杂的技术，也是目前业界热点技术。
简单来说，按通常的系统设计，使用 JDBC 操作数据库，业务处理逻辑和数据存取逻辑是混杂在一起的。
一般基本都是如下几个步骤：
1、建立数据库连接，获得 Connection 对象。
2、根据用户的输入组装查询 SQL 语句。
3、根据 SQL 语句建立 Statement 对象或者 PreparedStatement 对象。
4、用 Connection 对象执行 SQL语句，获得结果集 ResultSet 对象。
5、然后一条一条读取结果集 ResultSet 对象中的数据。
6、根据读取到的数据，按特定的业务逻辑进行计算。
7、根据计算得到的结果再组装更新 SQL 语句。
8、再使用 Connection 对象执行更新 SQL 语句，以更新数据库中的数据。
7、最后依次关闭各个 Statement 对象和 Connection 对象。
由上可看出代码逻辑非常复杂，这还不包括某条语句执行失败的处理逻辑。其中的业务处理逻辑和数据存取逻辑完全混杂在一块。而一个完整的系统要包含成千上万个这样重复的而又混杂的处理过程，假如要对其中某些业务逻辑或者一些相关联的业务流程做修改，要改动的代码量将不可想象。另一方面，假如要换数据库产品或者运行环境也可能是个不可能完成的任务。而用户的运行环境和要求却千差万别，我们不可能为每一个用户每一种运行环境设计一套一样的系统。
所以就要将一样的处理代码即业务逻辑和可能不一样的处理即数据存取逻辑分离开来，另一方面，关系型数据库中的数据基本都是以一行行的数据进行存取的，而程序运行却是一个个对象进行处理，而目前大部分数据库驱动技术（如ADO.NET、JDBC、ODBC等等）均是以行集的结果集一条条进行处理的。所以为解决这一困难，就出现 ORM 这一个对象和数据之间映射技术。
举例来说，比如要完成一个购物打折促销的程序，用 ORM 思想将如下实现（引自《深入浅出Hibernate》）：
业务逻辑如下：
public Double calcAmount(String customerid, double amount)
{
    // 根据客户ID获得客户记录
    Customer customer = CustomerManager.getCustomer(custmerid);
    // 根据客户等级获得打折规则
    Promotion promotion = PromotionManager.getPromotion(customer.getLevel());
    // 累积客户总消费额，并保存累计结果
    customer.setSumAmount(customer.getSumAmount().add(amount);
    CustomerManager.save(customer);
    // 返回打折后的金额
    return amount.multiply(protomtion.getRatio());
}
这样代码就非常清晰了，而且与数据存取逻辑完全分离。设计业务逻辑代码的时候完全不需要考虑数据库JDBC的那些千篇一律的操作，而将它交给 CustomerManager 和 PromotionManager 两个类去完成。这就是一个简单的 ORM 设计，实际的 ORM 实现框架比这个要复杂的多。

目前有哪些流行的 ORM 产品
目前众多厂商和开源社区都提供了持久层框架的实现，常见的有
Apache OJB （ http://db.apache.org/ojb/ ）
Cayenne （ http://objectstyle.org/cayenne/ ）
Jaxor （ http://jaxor.sourceforge.net ）
Hibernate （ http://www.hibernate.org ）
iBatis （ http://www.ibatis.com ）
jRelationalFramework （ http://ijf.sourceforge.net ）
mirage （ http://itor.cq2.org/en/oss/mirage/toon ）
SMYLE （ http://www.drjava.de/smyle ）
TopLink （ http://otn.oracle.com/products/ias/toplink/index.html ）
其中 TopLink 是 Oracle 的商业产品，其他均为开源项目。
其中 Hibernate 的轻量级 ORM 模型逐步确立了在 Java ORM 架构中领导地位，甚至取代复杂而又繁琐的 EJB 模型而成为事实上的 Java ORM 工业标准。而且其中的许多设计均被 J2EE 标准组织吸纳而成为最新 EJB 3.0 规范的标准，这也是开源项目影响工业领域标准的有力见证。

参考文献：1、《深入浅出Hibernate》
         2、《精通Hibernate：Java对象持久化技术详解》

Dancer 2008-06-09 17:21 发表评论

向客户提问的艺术

Dancer — Thu, 05 Jun 2008 15:29:00 GMT

题记：只问正确的问题，寻求可量化的信息。

编者按：在向客户推介解决方案之前，聪明的销售人员懂得要先提出正确的问题，了解对方的目标与选择标准，再将这些信息量化，然后才为其量身制定方案。在此过程中，你会不会提问关系重大。

Josh Costell在文中阐述了向客户提问的四个步骤：先用对话式的问题打破僵局，再用筛选式的问题从客户处了解有关其目标的一些模糊的回应，接下来是用澄清式的问题令客户的回应清晰化，最后用核实式的问题得出可量化的信息。如果你对积极倾听与提问的技巧烂熟于心，自然能从客户处得到有意义的回应。

某公司采购部经理奥尔森（Barry Olsen）联系了两位相互竞争的销售人员，想看看谁能最有效地帮助自己降低库存成本。他先与哈金斯（JoanHarkins）进行了谈话，让她说说她的产品可以如何帮助他降低库存成本。“机会难得，”哈金斯心中暗想。于是，她向奥尔森阐述了她的产品是如何借助一个又一个的高科技手段，帮助他实现降低库存成本的目标的，就这样口若悬河地说了整整十分钟。最后，她问奥尔森有何看法。奥尔森表示，自己需要一点时间来消化她提供的这些信息。实际上，他是需要点时间来摆脱这些枯燥的言论。而第二位销售人员史密斯（Lynn Smyth）采用了截然不同的方法。在解释自己的产品可以如何帮助他降低库存成本之前，她向奥尔森提出了一些至关重要的问题，比如，他是如何计算库存成本的。奥尔森只会有两种回答：（1）说明他的做法；（2）问清史密斯的意图。每种回答都将产生有益的结果。

作为第一种回应，奥尔森会解释自己的成本计算法。史密斯就可以找出哪种产品（如果有的话）能够完全实现他的目标。她还问奥尔森，他的计算方式是否包括了所有的相关成本。问这个问题的目的是为了确保自己充分理解奥尔森计算库存成本的方法，防止出现理解上的偏差。

如果奥尔森选择的是第二种回应方式，史密斯就会向他解释为什么要问他是如何计算库存成本的。这使她能够自然而然地向他推介一套新的方法，即评估系统法（SOE），也就是奥尔森的同行们计算库存成本的方法。然后，她对之进行了深入的介绍，并问奥尔森这些方法能否有助于他实现降低库存成本的目标。

当然，要说这些SOE真能帮助奥尔森完全实现目标，或者说它们正是史密斯的产品的独特优势恐怕也不尽然。事实上，史密斯在与奥尔森会面前，拿到了奥尔森所在行业的市场报告，了解了他的公司所在的大环境。这令她胸有成竹。如果你也能完成这样的准备工作，你就能像史密斯那样大胆提问，因为对于答案你心中有数。

那么，你觉得奥尔森或其他客户会认为哪个销售人员更专业，你自己又认为哪个更像专家呢？

做客户的专家

客户只信任那些“客户专家”型的销售人员。他们知道，这样的销售人员是根据客户的目标，而不是自己的产品特性来制定解决方案的。当你向客户询问其目标及选择标准时，客户就会认为，你是把他们的利益放在第一位的。在你量化了客户的目标与选择标准后，你就能靠产品的价值而不是价格来打动客户，并让他感到物超所值。如果你能使用积极倾听与提问的技巧，就可以实现双赢的结果。

优秀的提问者知道如何成为一个积极的倾听者。在交流时，你与客户都应非常投入和专注。要让对方知道，你接收到了并且理解了他传递出的信息。你对客户话语的反应程度显示了你倾听的积极程度。这能进一步显示你对客户思想、感受及观点的关注。当客户发现你问得很细，非常希望准确地了解其想法时，自然更乐于与你交流了。

有时，销售人员一开口便滔滔不绝，甚至在没有听众的情况下也是如此。如果是这样的话，他们肯定无法与客户做成生意。如果客户对你所谈的内容毫无兴趣，他们就会坐立不安，他们会觉得你的推介对他们来说是一种烦扰。有这种习惯的销售人员通常一说完“你好”，就开始介绍自己的产品。如果你能让客户先谈一谈他们的目标与选择标准，这将对双方都有好处。

“积极提问”并非什么新生事物。在寻求他人的理解之前，你得先理解他人。在对客户的话语做出回应之前，你要确保自己明白他的这些话将如何影响他实现目标的能力。“积极提问”背后的基本策略是“安全地带”概念。它促使你去寻找可量化的特定信息（例如客户的目标是什么，他的选择标准是什么，他希望获得哪些可量化的收益，他使用什么样的评估系统）。这样一来，客户会把你当成一个真正的专家。

只有一个地方是客户自认为安全，而且尽在掌握之中的，那就是可量化的目标。客户知道，不经同意，他们精心制定的目标就无法轻易改变。一旦他们觉得自己控制了局面，就会放松下来。因此，请将你的问题与其目标联系起来。目标的可量化性越强，你为客户打造的安全区域的面积就越大。就像热追踪导弹那样，你需要不断地向客户提出追踪目标的问题。

提问的顺序

最有力的销售手段都离不开以下四类问题：对话式、筛选式、澄清式与核实式。后三类问题能逐渐引领客户的回应由模糊到清晰再到可量化。

1．对话式。你得通过对话来打破僵局，让大家都放松下来。可以这样开始对话：“你喜欢这么冷的天气吗？”这是一个不错的开始方式。对话能在你与客户之间营造一种舒适或友善的氛围。但在这类交流中，并不包括对目标、选择标准、产品与服务的讨论。对话的目的只是寻找共同点。要注意，别从客户墙上挂着的那幅帆船画谈起—已经有几千个销售人员这样做过了。

开放式的提问能促成坦率的对话，激发幽默。它还能让双方在谈话中了解彼此的习惯与个性。这种口头探查能帮你确定你该在销售过程中采取何种形式的礼节、步调。如果你向客户说再见时，他只是笑了笑，你就得重新考虑一下，自己是否曲解了对方在刚才对话中所表达的意思。

不要只是在倾听中静静地感受对方的行事风格，而要主动去发现它。如果客户在对话中偷偷看表，说明他们要么有些不耐烦，要么就是个性自大。如果你上门拜访客户时，对方正在接电话，看到你后示意你留在原地，然后跟电话另一边的人聊上了20分钟。这可能说明两件事：他们或者认为自己很重要，或者认为你不很重要。你对其目标与选择标准的关注会让他们觉得自己很重要，但你还得让他们知道你对于帮助他们实现目标也很重要。

你还应学会在只字片语中寻找线索。诸如“我的日程安排很紧张”或“你是怎么想的”这样的话可以反映出客户的耐心程度、自大感觉及对你的关注程度。一旦对方注意到了你，就要准备好从对话转向筛选阶段。对话是由开放式的问题组成的。这些问题以谁、什么、为什么、何时、何地与如何这样的词开头。在对话的过程中，不要去问一些用“是”或“不是”就可以回答的问题。小心，“不”可能会毁掉一次对话。

为什么？
何时？
何地？
什么
对××你是怎么想的？
谁？

2．筛选式。筛选是你需要学会使用的首个提问流程。也许在你的头脑里，“筛选”就是你给客户打出第一个电话，询问他是否需要从你这儿买点什么的过程。事实上，筛选式的问题几乎可以涵盖一切。它是不是能揭示出客户的痛苦程度？它是不是能反映出客户的紧迫程度？它是不是能强化客户对你的感觉？它是不是能告诉你客户有足够的资金？你比我更清楚。

筛选是为了不浪费任何人的时间。因此，筛选式提问的第一步就是帮客户收集有关其目标、选择标准、可量化的收益及评估系统的信息。首先，你要根据客户实现目标的能力，而不是购买你产品的能力对其进行筛选。筛选式的问题也是开放型的。和预计的一样，你最初提出的问题通常只会得到模糊的回应。筛选式的问题就像对话式的问题一样，不以“是”或“不是”作为答案。最后，你会发现这其中的好处。

下面是一个筛选式提问的例子：客户：我们想提高生产率。销售人员：这会涉及哪些方面？（问这个问题的目的是寻求提高生产率的具体目标。）

你觉得从哪几个方面来××这个问题？
你觉得是XX比较好还是XX比较好？
市面上的技术比较多，你认为。。。？

3．澄清式。筛选式的提问将你引入正确的方向后，澄清式的提问可以帮你确认自己没有偏离正确的轨道。通常，这是在给客户的第二个电话中发生的。你会发现，通

完第一个电话后，自己还是有许多不清楚的地方。在筛选阶段后，如果你能提出一些澄清性的问题，就可以节省时间，并且避免做无用功。客户给予的可量化答案有助于你确定是否有必要通第三个电话。

澄清式的问题会将客户给出的模糊回应转化成可量化的回应。无论是以时间还是金钱来衡量，这些回应的可量化性都更高。澄清式的答案会令你明确客户的目标与选择标准，以及他们是如何衡量价值的。澄清式问题同样是开放型的，不以“是”与“不是”为答案。澄清式问题能帮助你避免对未能实现的目标、浪费掉的时间或金钱向客户说抱歉。

澄清式的问题是这样的：

客户：我想通过降低次品率来提高生产率。

销售人员：每年因次品而造成的成本是多少？（这是一个将次品的成本量化的澄清式问题）

客户：25万美元。

销售人员：你想要实现怎样的节约效果？（将节约成果量化的第二个澄清式问题）

4．核实式。这是一种使用“是”或“不是”就可回答的问题。如果你前两个阶段完成得不错，在这个阶段就将得到“是”的答案。核实式的提问将确保双方对具体目标与选择标准达成一致认识。这里需要用“是”与“不是”就可回答的问题，来确认你与客户对那些可量化的目标的认识是相同的。核实式问题是这样的：

客户：我觉得可以将次品成本降低30%。

销售人员：那么，你的目标就是将次品的成本减少7.5万美元？（确认成本节约的目标）客户：是的。

XX是吗？

提问的战术

大体上来说，积极提问背后的战术是非常普通的。然而，销售人员在进行电话销售的时候，对于产品的关注常使他忘记这些战术。因此，做些提醒是完全必要的。

让客户掌握谈话的控制权。通常，客户总想在对话中占据主动地位。这会使他们有一种控制感。那就让他们这样做，客户想谈什么就跟他们谈什么。他们的反应可以提示你接下来该问什么问题。这样，你就会很清楚该问些什么，而不需要进行猜测或反复盘问。

你追问的问题应该帮助你明确对方的目标、选择标准及可量化的收益是什么。同样，若要理解客户对价值的定义，以及你的产品是如何产生价值的，惟一的途径就是获得具体的可量化的指标。再说，争夺对话的控制权并不能让你卖出更多东西，那又何必浪费时间呢？

最后，当你跟随客户的指引推进对话时，你的问题会促使客户向你明示下一个目标或选择标准。你不应该是第一个提出新目标或者选择标准的人，这需要由客户来完成。同样，他的控制感能够给你带来帮助。

用开放式的问题了解具体信息。让客户告诉你他们所知道的一切—至少是他们所知道的关于目标、选择标准与可量化的收益的信息。开放式的问题可以为你做到这一点。它们会让客户告诉你很多你不知道的事情。开放式的问题通常以谁、什么、为什么、何时、何地与如何来开始。

需要注意的是，如果开放式的问题与目标或选择标准无关，反而可能带来麻烦。如果你碰到的是罗嗦的客户，他们可能说了半天却没有一句有用。要避免像“你觉得生活怎么样”这样宽泛的问题。当然，也别走向另一个极端，把客户完全束缚住。

用“是”与“不是”就可以回答的问题会将客户束缚住，使他们不得不从有限的选项中挑选答案。这样的话，他们通常只会提供有限的信息。对客户而言，他们并没有提供信息的动力。例如，“是”与“不是”型的问题常常只会带来“是”与“不是”的回答。这些问题显得随意，会令所有人感到不快。不仅如此，它们听上去更像是猜测而不是提问。“你能发现在哪些地方可以节约成本吗？”“不能。”“那么，节约时间的办法有吗？”“没有。”如果你连续得到三个“不”的回答，那么这桩生意基本上就没戏了。当你希望对方能对你下一个问题做出肯定的回答时，他的态度早已从合作转向了对抗。如果客户问你：“哪一个‘不’的问题你不理解？”这可能预示着不好的结果。“不”的回答会引发对谈话控制权的又一次争夺。

别搬起石头砸自己的脚。如果有人向你开枪却没有打中，你绝不会在他弹药耗尽时给他送上子弹。然而，如果你同意客户提出的反面意见，那么这一幕就发生了。惟一的不同在于，第一种情况下是人被杀死，第二种情况下是你的销售机会泡汤。不要告诉客户，你也认为有些事是不对的，除非双方都知道它对客户目标的实现会带来怎样的影响。如果你不能帮助客户实现目标，就要让他们知道为什么，而且要在他们让你知道原因之前这样做。另一个扭转不利局面，让客户信任你的办法是：迎难而上，解决眼前出现的问题。

积极正面地思考。人们在做假设时，常常会想得很消极。许多人早就学会了凡事都先做最坏的打算，比如，“我打赌他想让我降价。”如果你打算假设，你完全可以往积极的一面去想：“我猜他想让我的产品能配得上他出的价钱。”假设并不需要证据，何不让它助你一臂之力，假设客户相信你是对的，而不是错的？如果你能提出正确的问题，客户往往会给你提供有意义、可量化的答案。如果你不问，他们也不会自动提供。因此，你要做的就是提正确的问题，收集可量化的目标与选择标准，为客户提供有价值的解决方案，并从中获得回报。

你要不断地问自己：“我的问题是不是阐明了我与客户实现其目标的能力？”惟有“是”的回答才有意义。你的倾听与提问技巧是帮助你获得肯定答案的最佳工具。最重要的是，它们会帮助你超越客户的期望。

Dancer 2008-06-05 23:29 发表评论

售前小结

Dancer — Thu, 05 Jun 2008 14:50:00 GMT

如何能在最短时间让客户接受并认同你及你的产品?我想，除了产品的功能能够充分满足客户的需求外，还是要从细节感召对方，通过细节体现差异，拔高竞争门槛。所谓的细节，就是将产品所传递的专业、规范的品质融入到每个销售过程中，以及每个参与的人员的言行中。大多数我们的产品销售是给客户讲你的产品是能够帮助对方在管理上更加专业、更加规范、更加科学、更加系统，那么客户会以你讲的这些内容去衡量你，如果你并不如你的产品所体现的那样专业、科学、规范、系统，那么想打动客户比较难，客户更加相信他观察到的，而不是他听到的。这与眼前多数咨询公司遇到的情况一致，很多咨询公司为企业做管理咨询的时候，提供的方案都是一套一套的，但是自身的管理却是一团混乱，这种混乱是通过过程可以查觉得到的。如何向客户提供与产品品质相匹配的专业与规范呢？

一、专业：销售过程中涉及到的电话沟通、产品演示、需求交流以及提供的书面内容都要能够用专业的语言陈述和表达，以及能够从专业的视角分析和建议，这里就不仅要求顾问是专业的，销售人员更要专业，客户的第一印象尤难改变。人员的专业即职业化，要把你最职业的一面展示给客户，尽量避免一些不职业的言行；

二、规范：这里的规范主要针对提供给客户的所有文字性文档或PPT，只要是对外的文档，一定要桉标准的格式进行排版，包括页眉页脚的设置格式以及页码等都要能够统一，避免一人一个模式，排版的五花八门，以及不知所以然的文字编排，尤其要注意对提供的内容做到简单、方便、集成，即站在客户的角度，使其看得简单明了，方便快捷，所以，我们说不仅仅是为了提供内容而提供，要通过提供的内容向客户传递我们是规范的，以加深和强化客户对我们的印象，同时，这也是与竞争对手体现差异的关键细节。

三、团队：销售是一个整体行为，不能仅靠哪个人的表现。每一个项目都尽可能避免个人单枪匹马的进行。尤其更多竞争对手存在的市场，就更需要团队协同。在与客户面对面交流的现场，更要能够充分协同，才会给客户留下深刻的印象。所谓的团队协同，即在任何需要团队成员同时出现的场合，参与该项目的每个成员都是团队中的一份子，每个成员都要明确自己的角色，明确自己职责，不仅要注意在适当的时候讲适当的话，以及回答适当的问题，还要能够与其他成员充分配合，在最恰当的时间接转话题，而不是答非所问，知无不言或者一言不发。能够充分协同的团队，给客户的感觉是协调的、一致的、流畅的，而没有协同观念的团队给客户的感觉就是不连贯的、没有秩序的、缺少合作的。这里指的团队，即以项目经理为核心的，由顾问、销售人员、项目经理组成的铁三角。团队的协同，不是临时抱佛脚，而是长期合作的成果

Dancer 2008-06-05 22:50 发表评论

软件架构乱弹——问题域及其解决方法

Dancer — Thu, 05 Jun 2008 14:10:00 GMT

写在前面
SOA现在越发闹腾的厉害了，各种宣传越来越多，都把SOA吹上天；到底SOA是什么，有啥神奇之处，真的想宣传说的那么好吗？看了种种文章，只是越发混沌。
罢了，俺做技术的，商业上的宣传，俺不在意。既然SOA只是理念，那么俺就从它的支持技术来看看，从过去到现在的区别，看看SOA到底是啥！

从EAI到SOA
从集成的角度看，集成面临的问题如下
A. 数据集成，包括信息交换和 交换管理
B. 业务集成，包括服务管理和 流程管理

1.史前时代
现象：
1.1. 采用原始交换手段—— 点对点的传输通道依赖，机制是Socket或者后来的RMI。存在两个问题：1. 只能在同一平台上传输数据，无法处理异构系统数据传递，比如RMI没有办法和.NET通信；2.如果目标地址变化或者故障，就出问题。由于没有更多的交换管理能力，点对点的交换越多导致的管理成本就越高；
1.2. 数据格式绑定，依赖于双方的严格的私有格式。

1.3 扩展——EDI的出现解决了异构系统的数据传递格式标准。

2. EAI时代。
现象：
2.1. 基于中间件系统，采用了集中式管理的消息交换管理系统，就是所谓的信息总线技术——MQ技术，包括了两种不同的消息传递方式。
相对以前，统一了内部信息格式（这是基本工作），提供较好的数据交换管理。存在的问题：1. 只关注于消息的内部格式和传递，而忽略的各个系统的集成程序：没有提供对于这些集成程序的打包和管理；2.系统是紧耦合的，不同消息系统间的通信困难。

2.2 扩展——JCA. 相对于JMS，JCA关注于对于旧有系统数据访问，相当于访问数据库的JDBC；

2.3 发展：采用开放的自解释的XML作为系统通信格式，采用松耦合的Web Service作为通信手段。

3. SOA时代。
现象：
3.1. 天然的引入XML和Web Service技术。
3.2. 出现了ESB这样的技术平台。ESB是SOA的最佳基础平台。ESB与MQ一样也提供统一的消息格式，并管理消息传递；不同的是，ESB重新发现了集成程序的价值——在集成环境中，集成程序代表其背后的应用系统，这些程序提供了各个子系统的应用服务，它们才是集成环境中最有价值的部分，是集成环境中的First Class；并对这些程序提供统一的打包方式，并提供运行时管理。另一方面，ESB把集成程序进一步分解为服务（业务逻辑）以及Endpoint（服务的入口点），这样服务不仅仅是可重用，而且是可组装编排; 可快速注册发布; 质量可监控；生命周期可管理的，也正是因此，
3.3. 出现了所谓的BPEL等面向业务的能力开始显现，提供流程管理。

EAI和SOA的区别
EAI时代是企业的收发室，只知道信件本身，对于信件收发者的身份却不知道，更不知道信件所处的流程体系。
SOA时代是企业的办公室，不仅知道信件本身，对于信件收发者的身份都清楚，还可以知道信件所处的流程体系。就可以很容易的组合各个服务，建立起各种虚拟专员（specialist），响应业务的变化。

SOA的产商利益
SOA的基础框架提供了支撑平台，也就是可能性。但要实现SOA的理想，却还需要对业务重新梳理，发现和重用IT资产，正如ERP那样，这才是SOA实施的关键所在；而IBM这样的公司正拥有这样的咨询能力，所以IBM每年都投入大量的资金来推动SOA的应用，就在情理之中了。

Dancer 2008-06-05 22:10 发表评论

面向服务(SO)和面向对象(OO)的比较

Dancer — Thu, 05 Jun 2008 13:55:00 GMT

本文译自Thomas Erl的《Service-Oriented Architecture: Concepts, Technology and Design》部分章节。

注意本节的标题是“面向服务和面向对象”，而不是“面向服务对面向对象”。这种区别是要强调这两种思想之间的关系不是竞争关系这一事实。

事实上，面向对象编程通常用于构建Web Services中应用逻辑的封装。然而，面向对象编程方法到底与面向服务方法有何根本的不同是值得去探索的，理解它们的不同有助于你将它们放在一起工作。

下面列出两种方法在设计方面的比较。（尽管使用“逻辑处理单元”术语在比较服务和对象会引起的混淆，然而面向服务是基于服务来设计，面向对象是以对象创建为中心。）

面向服务强调逻辑处理单元（服务）之间的松耦合。虽然面向对象支持可重用、松耦合的编程程序，但它主要基于预定义的依赖类，产生和逻辑处理单元（对象）的紧耦合。

面向服务鼓励粗粒度接口（服务描述），因此每个通讯单元（消息）都包含完成给定任务所需的尽可能多的信息。面向对象编程完全支持细粒度接口（APIs），因此通讯单元（RPC或本地API调用）能执行各种大小的任务。

面向服务期望逻辑处理单元（服务）的范围可以较大。面向对象中的逻辑处理单元（对象）趋向于在一定范围内更小和更加明确。

面向服务促进逻辑处理单元（服务）未知行为的创建，那是由智能通讯单元（消息）所引起的行为。面向对象鼓励逻辑处理和数据的绑定，产生非常智能的单元（对象）。

面向服务更多采用逻辑处理单元（服务）进行设计并进可能保持无状态。面向对象鼓励数据和逻辑的绑定，因此产生有状态单元（对象）。（然而，近来更多的基于组件的设计方法背离了这种趋势）

面向服务支持逻辑处理单元（服务）的松耦合组合。面向对象也支持组合但趋向于继承自逻辑处理单元（对象），那会导致依赖紧耦合。

上面从耦合度、接口粒度、关注点、状态等方面对面向服务和面向对象进行了比较。下面再对两种方法的设计原则进行比较。

当然，面向服务还欠缺很多面向对象已有的概念和理论。下表提供了一般的面向对象原则与已经讨论过的面向服务的原则的比较。

面向服务原则	面向对象原则
服务的重用	面向对象大多数情况是创建可重用的类，模块化分解的面向对象原则是应用程序的设计方式。相关的原则，如抽象，封装，接口和实现逻辑的分离。服务重用是这个目标的延续。
服务的契约	服务契约的需求和构建面向对象应用中的接口相类似。接口提供了一种提炼类描述的方法，这和 WSDL 的定义非常相似。与 SOA 鼓励的“ WSDL 优先”方法一样，“接口优先”方法也被认为是面向对象的最佳实践。
服务的松耦合	尽管接口的创建一定程度上将类从类的使用者解耦，但耦合是面向服务从面向对象继承到的主要特性。相对面向服务设计方法，继承和其他面向对象原则造成逻辑处理单元之间的紧耦合。
服务的抽象	面向对象的抽象原则要求一个类提供一个接口给外部世界，并通过这个接口来访问类。封装通过建立信息隐藏概念来支持这种方式，通过接口暴露的类内部的任何逻辑都不能被外部所访问。服务抽象可以基本达到对象抽象和封装的程度。它的目标是隐藏服务的内部细节，因此只有服务契约是可以得到的，服务的请求者也只要关心服务契约。
服务的组合	面向对象支持关联的概念，如聚合和组合。在松耦合的上下文中，这些概念也被面向服务的方法支持。例如，可用与组合成对象层次结构相同的方法来将可组合的服务装配成服务层次结构。
服务的自治	自治的特性在面向服务设计中比在面向对象方法中有更重要的作用。在面向服务中，通过利用服务间的松耦合关系，可以实现逻辑处理单元之间的独立性。在面向对象设计中，跨对象引用和继承相关的依赖支持较低程度的对象级自治。
服务的无状态	由类结合和数据构成的对象天生就是有状态的。服务中提倡的无状态趋向于背离典型的面向对象设计。尽管可以创建有状态服务和无状态对象，但无状态原则是面向服务中通常更加强调的。
服务的发现	设计一致的和自描述的类接口是另一个面向对象最佳实践，它能改进识别和区别逻辑处理单元方法。这些特性也允许类被更容易地发现。可发现性是面向服务范例中强调的另一个原则。它鼓励服务契约的交互支持在设计和运行时的可发现性。

可以看到，面向对象和面向服务并非竞争者。面向服务显然在不少方面是以面向对象为基础，当前典型的面向服务的解决方案将由服务（遵循面向服务的原则）和面向对象的组件构成。在合理的设计中，每个原则都能被适当地处理并能相互补充。

Dancer 2008-06-05 21:55 发表评论

浅析面向构件的SOA架构设计

Dancer — Wed, 04 Jun 2008 12:19:00 GMT

概述

　　目前，关于SOA(面向服务的架构)的研究和讨论已经成为IT业界的新热点。尽管各方研究者和专家对SOA架构的认识和理解不尽相同，各IT厂商提供的SOA解决方案也不一而足，SOA相关标准仍在不断发展和完善之中，但大家却都有一个共同的认识，那就是SOA代表着今后一段时期软件技术的发展方向，并已经开始从研究阶段进入实施和推广阶段。本文试图从面向构件的角度，介绍一些SOA架构设计的基本思想和方法论。首先简单介绍一些构件设计和实现的基础知识，然后重点介绍面向服务设计的基本原则和方法。

　　构件的组成要素

　　构件是软件开发、复用和软件组装的实体单元，包括以下要素：构件类型(componenttype)、构件实现(componentimplement)、提供接口(provides-interfaces)和依赖接口(requires-interface)。

　　构件类型(componenttype)：构件类型表明构件是处理什么问题和提供哪些接口功能，它包含了构件类型的名称。

　　构件实现(componentimplement)：对构件类型的具体实现称为构件实现，一个构件类型可能有多个构件实现。

　　提供接口(provides-interfaces)：提供接口指构件提供给外部程序使用的接口。

　　依赖接口(requires-interface)：依赖接口指构件运行时所必须依赖的外部程序接口。

　　构件的基本特征

　　复用：复用是构件最基本的性质，构件的设计必须满足未来能在新的应用、项目中使用。

　　封装：构件封装对外界隐藏构件的设计和实现细节，仅通过接口与外界交互。这可以保证构件功能复用的完整性和构件开发及交付的独立性。

　　组装：构件可以通过组装形成新的构件或系统，组装是构件复用的手段，同时具备可插拔，便于替换，系统可以由不同的开发商开发的构件组装而成。

　　粒度：构件是有大小的，越是跟领域相关的构件粒度越大，小粒度的构件可以方便的组装成较大粒度的构件。

　　层次：构件可以按层次进行划分，企业级应系统的复杂逻辑可以通过层次来解决，不同的层次需要不同层次的构件。按照MVC的体系架构，可以把构件划分为：展现层、控制层、业务层、运算层及数据层等。

　　构件的实现

　　目前软件市面上有三个代表性的构件技术标准分别是：COM/DCOM、CORBA和EJB。

　　COM/DCOM：COM(Conponent Object Model)是由Microsoft公司推出的构件接口标准，DCOM是指可以分布式布的COM。

　　CORBA：CORBA(Common Object Request Broker Architecture)是由对象管理组织(OMG)提出的构件技术标准。

　　EJB：EJB是由SUN公司提出的构件技术标准。

　　以上三种构件标准实现的构件互相依赖的方式仍然是基于对象接口式的，当系统复杂度到一定规模时，整个系统会因依赖关系混乱而陷入失控。

　　比较理想的构件模型是构件之间是数据耦合的，每个构件只单独与数据总线发生联系。当需求发生变化时，可以对各个单独的构件进行添加、减少或者修改而不影响整体的架构和性能。基于数据耦合的构件，据有很高的独立性，对需求变化有较强的适应能力。

　　构件技术与构件化

　　构件技术与构件化的区别在于，构件化的关注点不在于构件本身的技术实现，而在于如何把应用系统分解成稳定、灵活、可重用的构件，在于如何利用已有的构件库组装出随需应变的应用软件，从一个面向构件的环境中去分析应用，如何做出灵活、重用的构件来思考。但是，构件技术是构件化的基础，它为构件的工厂化生产提供技术保障。

　　传统的软件方法学是从面向机器、面向数据、面向过程、面向功能、面向数据流等反映问题的本质；而构件技术关注的是在构件已经可用的情况下，在更高层次上的组装和复用。面向构件的软件设计方法把装配和制造分离，构件运行时负责提供标准接口和框架，负责软件装配，而构件负责软件的制造，使软件开发变成构件的组装。

　　接下来，我们将开始介绍面向服务(SOA)的设计。

面向服务设计

　　服务代表一段完整的业务单元，并且可以根据特定用户的需求组织成为更大和新的服务。服务可以由一个或多个构件组合而成。服务开发者必须考虑构件的粒度，以及构件的流程和组装，这样他们在改变服务的实现时，可以尽可能少的影响其它构件、应用和服务。而服务的设计者则更关心选择合适的服务，并将它们以可管理的方式组织，并最终将它们组装为完整的业务流程。

　　“面向服务”表示一种分离系统关注面的方法，其实质是将一个比较大的问题分解成一系列较小的、互相关联的子问题，从而降低问题的复杂度，使得我们能够较从容地分析、解决和管理它。传统的面向对象的设计方法其实也是一种分离系统关注面的方法，只不过它是在对象层面来分离关注面，相对业务逻辑较远，而面向服务则是在服务层面来分离关注面，直接关注的是业务逻辑，从而使面向服务能够(至少在理论上)更好地满足业务需求。

　　其实，就现实世界而言，到处都是面向服务的业务。一座城市向居住或来到这个城市的人提供各种各样的服务。这些服务分别由不同的服务提供者提供，这些服务提供者包括政府部门、企业、社会团体和自由职业者等。人们早已习惯为享受某种服务而参与某种业务，商业机构也早已习惯为发展某项业务而向公众或其他团体提供某种服务。可以说，服务和业务是有着某种天然联系的，具有很强的业务亲和力和包容度。面向服务的架构就是要通过将信息技术直接作用于服务的实现，从而实现信息技术与实际业务的优质对接。

　　面向服务设计原则

　　封装原则为了保持自治(Autonomy)和抽象(Abstraction)，服务封装了其内部的逻辑，同时对外部进行隐藏(服务契约规定的除外)。服务从来都不是孤立的，它必定有其适用的上下文环境。上下文环境可以是一个业务规则、一个业务实体或者一些业务逻辑的组合。业务可大可小，因此服务所关注的问题可大可小，服务所表示的业务逻辑的规模和范围也各不相同。

　　此外，服务还可包含其他服务提供的业务逻辑，在这种情况下，一个大的服务由多个子服务组合而成。例如，一个业务自动化处理解决方案通常是一套业务流程的实现。按照业务规则和运行时条件，一个业务流程被分解成预先定义好顺序的一系列步骤。在基于服务来构建该业务流程的自动化解决方案的时候，每一个步骤可以被封装为一个服务，或者可以先将多个步骤组合成的一个子流程，然后再将该子流程封装为一个服务，甚至可以将整个流程封装为一个服务。

　　关联原则服务可以被其它服务调用，因此服务与服务之间必须建立某种特殊的联系，我们称为关联。关联过多会造成服务之间的紧耦合，最终导致整个架构的脆弱。为避免这种情况，服务设计者需要谨慎地选择服务，使它们之间建立“松耦合”(Loose coupling)的关系，使得服务之间的耦合降到业务需要的最低，从而使服务之间仅维持相互了解所必须的最少的依赖关系。

　　服务之间的相互了解是通过服务描述(Service description)来实现的。服务描述至少要包含服务的名称、它所实现的具体功能、以及服务的使用方式和调用的返回值等。为了保证服务描述能够被其它服务容易地理解，需要遵守共同的描述方式和语法——服务契约。通过标准的服务契约，服务可以相互理解，无须或很少人工干预。

　　复用原则服务应该是可复用(Reusability)的。它不仅可以被其它服务或使用者调用，而且可以与其它服务一起组合成新的服务。

　　SOA通过服务、服务契约和消息通讯提供了一个支撑复用性的基本架构。其中，服务的精细度是决定服务复用程度的最重要因素。一般而言，服务的精细度越高，服务越细致，其复用性也就越强。但是随之而来的系统的复杂度也会越来越大，服务多，意味着系统必须同时维护大量不同的服务及其组合，反过来会降低复用的意义。此外，同等条件下，服务的开发成本相比传统的基于模块或类的开发方法要高。原因是，服务不仅要完整实现其业务功能和保证其自身的性能(这一点和传统开发方法一样)，而且还要符合SOA所要求的各项规定，以保证SOA架构的统一。因此，服务不是越多越好，服务的设计者必须准确把握服务的精细度，在保障总实现成本最低的同时，还要遵循SOA架构的标准和规范，从而真正发挥SOA架构的优势。

　　质量原则在SOA架构中，服务是最小设计单元。如果把SOA比喻为一座大厦，那么服务就是构建整座大厦的砖石。显然，服务必须满足一定的质量要求，才能真正被 SOA所用。这里的质量要求，不仅包括业务功能的要求，还应包括其它非功能性要求，如可用性、性能、伸缩性、安全性以及隐私策略等。在不同的上下文中，对服务质量的要求也不尽相同。因此，服务还应具备灵活适应各种不同服务宿主环境的能力，满足各种环境下对服务质量的要求，甚至可以根据不同的环境自动提供与之相适应的质量属性供其选择。

　　在服务上下文中，服务质量(QoS)可以看作为一种基于一组定量特性提供保证的机制。这些特性基于重要的功能性和非功能性服务质量属性来进行定义，其中包括实现和部署相关的问题以及其他的重要服务特性，例如：服务测量和计费、性能衡量(如响应时间)、安全需求、(事务)完整性、可靠性、伸缩性和可用性等。对于理解服务的整体行为使得其他应用程序可以与其进行绑定并使其作为商业过程的一部分而执行，这些特性是很必要的。

　　在Web服务环境中，支持服务质量(QoS)的关键元素包括可用性(服务持续对外提供的能力)、完整性(功能实现的程度)、性能(吞吐量和延迟)、可靠性(用每月或每年的事务失败数表示)、伸缩性和安全性(认证、授权、消息完

Dancer 2008-06-04 20:19 发表评论

SOA第一步

Dancer — Wed, 04 Jun 2008 11:32:00 GMT

一、什么是soa?
SOA(Service-Oriented Architecture，面向服务架构) 是一种架构模型，
它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、
组合和使用。服务层是SOA的基础，可以直接被应用调用，使得构建在这样的系
统中的服务可以使用统一和标准的方式进行通信。
二、soa的目标
SOA的根本目标：实现与敏捷业务相适应的IT基础，促进而不是阻碍企业达成灵
活应变，从而在快速变化的时代里获得增长优势。
三、soa中缤纷的概念
java的世界各种各样的名词让人眼花缭乱，有些其实很简单，但因为名次挡在门外
soa中更是如此，这里简单介绍一下相关的一些名次：

1,SCA(Service Component Architecture)不同的软件模块通过服务组件
的标准化而统一地封装起来和被调用访问。

2,SDO(Service Data Objects)则作为一种数据编程架构和API，它统一了不同数据源类型的数据编程，
让开发人员可以从不同的数据源以统一的方式访问和操纵数据。
可以说，SCA以面向构件的方法，简化了客户的业务逻辑编程，提高了应用的灵活性。
而SDO则更进一步从数据对象上大大简化了开发。

3,OSOA:2005 年 11 月， IBM、BEA、IONA、Oracle、SAP AG、Sybase、Xcalia 和 Zend
就合作建立新的业内规范来简化 SOA 应用发展达成了一致，共同发布了两项针对SOA的重要构件模型
规范——SCA 0.9和SDO。此后，该团体陆续吸引了 Cape Clear、Interface21、普元、
Progress Software(前 Sonic Software)、Red Hat、Rogue Wave Software、Software AG、
Sun Microsystems 和 TIBCO Software 、Siemens AG等多家公司的加盟，目前成员数量跃至 18家，
形成了OSOA联盟。

4,eai
什么是EAI(enterprise application integration)企业应用集成?
EAI是将基于各种不同平台、用不同方案建立的异构应用集成的一种方法和技术。
EAI通过建立底层结构，来联系横贯整个企业的异构系统、应用、数据源等，完成
在企业内部的 ERP、CRM、SCM、数据库、数据仓库，以及其他重要的内部系统之
间无缝地共享和交换数据的需要。有了 EAI，企业就可以将企业核心应用和新的
Internet解决方案结合在一起。
EAI(企业应用集成)将进程、软件、标准和硬件联合起来，在两个或更多的企业系
统之间实现无缝集成，使它们就像一个整体一样。尽管EAI常常表现为对一个商业
实体(例如一家公司)的信息系统进行业务应用集成，但当在多个企业系统之间
进行商务交易的时候，EAI也表现为不同公司实体之间的企业系统集成，
例如B2B的电子商务。

5,ESB是企业服务总线（Enterprise Service Bus）的缩写。企业服务总线是一个灵活的用于集成各种应用
和各种服务的连接基础架构。企业服务总线能够通过简化应用和服务之间接口的数量、接口大小及接口复杂度等
方法使客户的面向服务体系（SOA）更加的强大。企业服务总线提供以下功能：
在服务与服务之间路由消息；
在请求者与服务者之间转换传输协议；
在请求者与服务者之间转换消息格式；
处理来自于各种异构源的业务事件；

6,webservice:Web Service就是为了使原来各孤立的站点之间的信息能够相互通信、共享而提出的一种接口。
Web Service所使用的是Internet上统一、开放的标准，如HTTP、XML、SOAP（简单对象访问协议）、
WSDL等，所以Web Service可以在任何支持这些标准的环境（Windows,Linux）中使用。
注：SOAP协议（Simple Object Access Protocal,简单对象访问协议）,它是一个用于分散和分布式环境
下网络信息交换的基于XML的通讯协议。在此协议下，软件组件或应用程序能够通过标准的HTTP协议进行通讯。
它的设计目标就是简单性和扩展性，这有助于大量异构程序和平台之间的互操作性，从而使存在的应用程序能够
被广泛的用户访问。

7,soap:SOAP即简单对象访问协议(Simple Object Access Protocol)，它是用于交换XML编码信息的
轻量级协议。它有三个主要方面：XML-envelope为描述信息内容和如何处理内容定义了框架，将程序对象编码
成为XML对象的规则，执行远程过程调用(RPC)的约定。SOAP可以运行在任何其他传输协议上。例如，你可以使
用 SMTP，即因特网电子邮件协议来传递SOAP消息，这可是很有诱惑力的。在传输层之间的头是不同的，
但XML有效负载保持相同。

8,uddi:UDDI 的目的是为电子商务建立标准；UDDI是一套基于Web的、分布式的、为Web Service提供的、
信息注册中心的实现标准规范，同时也包含一组使企业能将自身提供的Web Service注册，以使别的企业能够
发现的访问协议的实现标准。

9,wsdl:Web Service描述语言WSDL就是用机器能阅读的方式提供的一个正式描述文档而基于XML的语言，
用于描述Web Service及其函数、参数和返回值。因为是基于XML的，所以WSDL既是机器可阅读的，
又是人可阅读的。

10,bpel:BPEL是一门用于自动化业务流程的形式规约语言。用XML文档写入BPEL中的流程能在Web 服务之间
以标准化的交互方式得到精心组织。这些流程能够在任何一个符合BPEL规范的平台或产品上执行。所以，通过
允许顾客们在各种各样的创作工具和执行平台之间移动这些流程，BPEL使得他们保护了他们在流程自动化上的
投资。尽管以前想使业务流程定义标准化，但BPEL已经引起了史无前例的兴趣，而且它最早在软件供应商中获
得大量认可。
11,ibm mq:消息队列（MQ）是一种应用程序对应用程序的通信方法。应用程序通过写和检索出入列队的针
对应用程序的数据（消息）来通信，而无需专用连接来链接它们。消息传递指的是程序之间通过在消息中发送
数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用的技术。排队指的是
应用程序通过队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。

12,jms:在不同系统之间交换信息的一大障碍是如何在精确交换和格式化数据方面取得一致。
Java Message Service（ Java消息服务，简称JMS）通过提供一种与J2EE应用程序或传统系统交互的方
法部分的解决了这个问题。 JMS的通用接口集合以异步方式发送或接收消息。异步方式接收消息显然是使用
间断网络连接的客户机，诸如移动电话和PDA的最好的选择。另外， JMS采用一种宽松结合方式整合企业系统的方法，
其主要的目的就是创建能够使用跨平台数据信息的、可移植的企业级应用程序，而把开发人力解放出来。

13,ibm mb:Message Broker是 IBM 的应用整合中间件，是 IBM WebSphere 业务整合解决方案的重要
组成部分之一，用于企业应用整合领域。它的前身为 WebSphere MQ Integrator Borker 是一种Esb的实现

Dancer 2008-06-04 19:32 发表评论

销售思路

Dancer — Sun, 18 May 2008 12:31:00 GMT

摘要: 阅读全文

Dancer 2008-05-18 20:31 发表评论