对新创项目而言，是idea更重要，还是执行力更重要？在没有用户时，我们该如何冷启动？团队、人、技术、产品、推广和拜春哥，哪一个更重要？到底是什么决定了一个项目的生存或者毁灭？

    来吧，一起书写51daifan的成长史吧。51daifan是一个同事之间分享午餐、特产的公益平台。每天带饭的同学，可以多带几份爱心便当，分享给身边的同事。大家中午一起热饭，一起桌上足球，一起品尝同事带来的爱心便当。让午餐变成每天最快乐的时光。

    51daifan从5月底开始有想法，一周后6月初web版本上线，四周后7月中旬android版本上线，现在，8月初，ios版本即将上线。2个月时间，有过快乐，有过迷茫，也有过痛苦。它到底会不会成功，谁也不知道，这也许就是生活最富有魅力的部分吧。关注我们的微信公共号，一起来品味产品成长中的酸甜苦辣吧：

    一起来品味产品成长中的酸甜苦辣吧，每周一，我们将把51daifan上周所有滋味倾诉在这里：产品的运营数据、开发进度、对产品方向的思考、产品运营遇到的问题和想法。加入我们，一起来决定产品的进程吧，把你的想法告诉我们，我们一起来尝试，不管结果如何，当我们的额头爬满皱纹，我们能做到的就是，不让它们也爬在心里。

一、产品源起

产品想法缘起每天的午饭：

但是，我们周围还有这样一群人：

于是，我们想：

产品运营&数据

    目前产品上线8周，注册用户160人，app下载用户22人，日活跃用户在25人。有过订饭/带饭行为的用户为62人，订饭数据371人次。

产品运营分为3个阶段：

1. 6月份中上旬在部门里试用，用户数到达30人，日活跃用户在20人，2人带饭，日均订饭数12；
2. 6月下旬在公司BBS进行了第一次推广，一周内注册用户数达到90人，但带饭人数依旧是2人，拓展新的带饭同事困难（之前假设妹子有时间带饭的路证明是不通的），日均订饭数16；
3. 7月开始转换思路，同时鼓励同事可以分享自己家产的特产，进行了两次自家蜂蜜和蜂王浆的团购，产品推广集中在bbs发帖，人数缓慢增长到160，一位带饭的同事退出（确实是太累了，纯爱心活），为了增加网站粘度，增加了711免费带饭服务，但效果并不明显。因为没有找到新的带饭同事，目前日均订饭数下降至10。

    对当前产品运营来说，最重要的工作就是如何找到更多愿意分享的同事。目前有两种思路：一是降低分享的门槛，例如我们可以分享自己15分钟家常菜的菜谱，通过降低门槛拉动社区的活跃度；二是推广我们的网站，认为没有更多分享同事是因为我们用户数还很少。

    9月份有个大的分享活动是nanana同学家在五常，10月她家新稻米收割，我们会组织一次团购，五常稻花香大米在超市的价格在10元左右是陈米并且一定掺有其他米（这已经是所有大米收购时就有的潜规则），我们初步考虑的价格在7元左右，成本在于物流，真是个大问题，目前考虑是长途车送至四惠客运站，然后再包车拉到公司（可行性还在讨论）。

 

对产品方向的不懈思考

    我始终认为产品大的方向绝对正确，就是基于社交关系的O2O（这里是同事关系）。在这个全国造假、连政府信用都已经破产的当下，冷漠、造假似乎是我们这个时代的代名词。我们一定能做点什么，通过基于社交/同事关系的O2O，我们认为一定能重建人们之间的关心和温暖。一方面我们能获得绿色、环保、健康的食品，另一方面，能够拉近同事间的关系。

 

当前开发进度

    目前web、android、ios开发全部在同步进行，全部是业余时间开发，代码开源在：https://github.com/ronghao100。Android第一个版本已经发布，第二个版本将包含上传图片和消息通知，计划下周发布，ios本周提交审核，计划一周后发布。

 

对这个项目发展你有什么想法，来吧，一起决定它的未来！扫描二维码立刻关注我们的微信公共账号：

 

一、我们要解决的问题

无论是什么样的解决方案，一定要牢记我们要解决的问题是什么，切不能将解决方案当做问题本身。具体到过程改进，不管是何种方式的改进，它们所要解决的问题永远只有一个：缩短从产品想法到可用软件之间的时间周期。自动化发布正是如此，如果软件发布只做一次，我们说根本不需要自动化，但如果三次以上，那么软件开发的黄金法则DRY就必须遵守，让时间真正用到开发当中去。

 

二、与发布相关的问题

所谓自动化只不过是将原先手工做的工作谦让给机器做，所以自动化之前一定要先清楚与发布相关的问题有哪些，即使不自动化，这些工作也一个也不能少：

1. 应用程序如何打包？ 发布包能否追踪到SVN版本号？
2. 对目标机器环境有什么样的要求？
3. 配置信息是否需要根据目标机器信息做出调整？
4. 应用程序如何安装和启动？
5. 应用程序启动后如何切流量？
6. 应用程序如何升级？ 旧版本程序数据如何迁移？
7. 升级过程中和结束后如何切流量？
8. 应用程序如何卸载？

 

三、我们的方案

李安的少年Pi正在狂刷票房，我们的自动化发布方案也要跟上潮流：Puppet+CI我们的少年Pi。

Ø 使用CI自动化打包，追踪每个发布包的SVN版本；

Ø 使用Puppet管理发布包、目标机器环境、应用程序配置信息以及应用程序线上生命周期；

Ø 使用伽利略系统提供应用程序的命名服务和进行流量切换。

现在应用程序的发布需要两步：CI一键打包、puppet指定应用程序版本SVN提交。

 

四、具体方案

具体方案也就是如何解决与发布相关八个问题的过程。

1.         如何安装、升级和卸载应用程序

我们使用操作系统原生包管理系统来安装、升级和卸载应用程序，我们的应用程序打出RPM二进制包。免安装，所有机器自带，绿色的，有机的。

打包：rpm -ba ./team_member-1.spec

安装：rpm –ivh team_ member-2.0.1-48.x86_64.rpm

升级：rpm –U team_ member-2.0.1-49.x86_64.rpm

卸载：rpm –e team_ member-2.0.1-48.x86_64.rpm

程序升级前要停旧版本服务怎么办？旧版本数据要做处理怎么办？RPM已经帮我们料理好这一切，只要写出spec文件，剩下的交给我们。尽情的插入吧：

 

2.         如何管理目标机器环境和应用配置信息

应用程序已经打好rpm包了，但这还不够，应用程序发布到哪台机器上？应用程序对目标机器有什么要求？发布时需要修改哪些配置和参数？实际发布如何执行，难道需要登陆到每台目标机器运行rpm命令吗？

我们使用Puppet来搞定这一切，Puppet是现在应用第一的devops工具，它通过master/agent的工作模式管理机器。我们通过声明来控制我们的机器达到目标状态。同时，所有puppet文件全部在SVN里，所有对机器的修改全部codereview和可审计。

 

如何管理应用程序发布到哪台机器上？在回答这个问题前我们必须将应用程序在线上的生命周期再进行一次封装。

应用程序TeamMember被我们封装成一个puppet module，配置文件和参数被封装在对应templates和files里，每次发布前都要修改配置文件和传递不同的参数？out了吧，puppet帮你传参搞定:

Teammember.conf文件内容：

封装完成后的效果是这样的：

最后在管理部署的site.pp文件里声明一下，应用程序TeamMember的2146版本就被自动部署到10.128.34.141.test.back.shequ这台机器上了，我们后续的工作也就是维护这个site.pp文件了，所有应用程序的部署信息都在SVN被集中管理起来：

登陆到每台目标机器运行rpm命令？No!现在TeamMember已经被封装，我们修改完毕site.pp并提交后，puppet就自动执行命令了，要不怎么说是自动化呢。（现在puppet默认在agent每半小时同步一次，但同时支持马上触发执行）。

 

3.         如何追踪每次发布的SVN版本号

我们使用CI进行应用程序的打包，将build号作为包命名的一部分：

 

4.         如何在发布过程中切换流量

这是另外一个很大的话题，参见伽利略计划。

 

五、下一步工作

使用CI将环境的自动化部署与自动化测试串联起来，搭建起整个研发流程自动化平台：

 

六、小结

没有银弹，自动化所做的只是将之前手工工作交给计算机完成，需要做的工作一个都不能少，此外，我们还要多做一些封装或脚本工作，但是，当我们需要重复做这些事情的时候，价值就出现了。我们的目标永远是缩短从产品想法到可用软件之间的时间周期。让时间真正用到开发当中去。

王晓丽收拾了东西，给高晨晨打了电话，高晨晨来接了她。留下张小庆一个人在房间里空荡荡的呆着，一切都是空荡荡的，衣柜是空荡荡的，房间是空荡荡的，连灯泡也变得空荡荡的起来，张小庆想了半天，最后给张岩打了电话，第一句话是，我该怎么办？

接下来的几天，王晓丽的手机一直处于关机的状态，去她公司，去高晨晨那里，她都不在，后来，高晨晨告诉他，王刚要结婚她回家了。第一天晚上张小庆是自己睡的，但睡的心神不宁，一躺下就想起和王晓丽在一起的日子，然后就浮现出那一巴掌，后来几天，张岩叫他去了他家，这个男人见到张小庆的第一句话是，屁大个事，女人都这样，走，吃烧烤去。

张岩过得并不幸福，因为他的女人。张岩最初到北京是在一个大学当保安，年轻人，没事的时候喜欢到处逛，后来就认识了黄英，一个在旁边歌舞厅陪酒的女人，尽管黄英不说但张岩心里也清楚她是做什么的，黄英是个漂亮的女人，岁数也和张岩差不多，她是如此的爱着这个男人，几乎是对张岩百依百顺，挣得钱都给他买了衣服，她白天休息晚上上班，张岩每次回家都能吃到她做好的热呼的饭菜，后来王晓丽过来，张岩也换了工作，黄英就经常带王晓丽出去玩给王晓丽买衣服，有一次过年，她甚至给张岩的父母一人买了一件几千块的皮衣，但即使是这样，即使他们已经同居了好几年，张岩却始终下不了决心娶她，他心里对她的工作一直有着障碍，直到一次过年，黄英突然独自一人找到了他的家，晚上的时候，跪在他的面前，央求他，说自己岁数大了父母一定要自己结婚了要他娶她自己也攒了些钱不再陪酒一起做些小生意，张岩想了好久，最后还是拒绝了她，他过不了那一关，她痛哭着离开了他。后来，又过几年，张岩开始在老家找对象，于是就遇到了他现在的女人李萍，李萍是大专毕业，毕业后一直在县城一个律师事务所里帮忙，和一个律师在一起，但却是个有妇之夫，后来岁数也大了，这样也不是个办法，律师证也一直没拿到，于是开始想找个人结婚，刚好有人介绍张岩，于是见了一面就来了北京，不到一个月，她就怀了孕，张岩说，打了吧，她说，这不是我第一次打胎，打了就怀不上了，我一定会生下来。张岩没办法，于是就结了婚。张岩不幸的生活就这样开始了，李萍很快发现自己对张岩的判断有错误，她以为张岩在北京工作了快十年，会有些钱，再加上媒人一顿乱吹，于是对这个男人的期望就高过了头，现在，结了婚，她才发现这个对朋友花钱大方的男人根本就没有什么积蓄，每个月的工资也不稳定，她跌落到地上，再接下来的，就是对这个男人的失望和看不起，中专毕业，没什么文化，最大的爱好就是和几个狐朋狗友一起喝点酒吹会牛，不懂得生活也不懂得浪漫，总之，这个男人实在是差到了极点，她开始有意无意的在他朋友面前不给他面子，一次去他同事家吃饭，他同事刚刚炒股买了套房子，吃着饭，她突然就说她男人的没本事，旁边人陪着笑说会有的都会有的，她却越说越激动，说，就凭他，我这一辈子都不想了，嫁给他是我最大的失败。大学毕业生觉得自己和中专毕业生在一起亏了，于是，中专毕业生的脸挂不住了，又不好发作，于是跑出去，一个大男人，站在大街上哭着给王晓丽打电话，说，要不是儿子就和她离婚了。

现在，李萍带孩子回了老家，张岩和张小庆坐在马路丫子上吃着烧烤。本来是安慰张小庆的，后来说起女人说起自己，却变成张小庆安慰张岩了。张岩说，没事，你给我舅打个电话，屁大的事，我和你嫂子打架还打110呢。

第一次没有王晓丽在的时候给王刚打电话，张小庆有点紧张，他打了他女儿，他不知道他会怎么样。电话接通了，王刚喝了点酒，他的第一句话是，屁大个事，女人都这样，该收拾时就要收拾。这句话多少出乎张小庆的预料，他对王刚的印象突然就好了起来。一会儿，王刚叫王晓丽接了电话，打她后第一次和她说话，张小庆不知道该说些什么，于是犹豫半天后小心翼翼的问了下天气，王晓丽说了句还可以就挂了电话。

从家回来后王晓丽还是住在高晨晨那儿，每天下班后，张小庆就会去高晨晨的宿舍，王晓丽不开门，张小庆就站在门外央求她原谅他。张小庆想，即使不和好，最起码得让王晓丽接受自己的道歉，自己打她是不对的。时间就这样一天天过去，高晨晨还是不理他，这天中午，张小庆在位置上写着代码，突然，他惊讶的发现窗外的大厦门口突然集聚了很多的人，他一开始还没有在意，人很快就多起来，QQ上突然就有很多头像在闪烁，所有人都在发一条消息：地震了！地震了吗？张小庆公司在三楼，他并没有感觉，他开始打开所有的QQ消息，这些发消息的人有的在东北，有的在云南，有的在广东，一种不好的预感在他心里缠绕，这是一个大地震！他连忙给家里打了电话，父亲说他刚刚把学生疏散没事，他连忙又给王晓丽打了电话，这次王晓丽接了他的电话，她说她们刚刚疏散下楼没事，他又挨个的给所有认识的人打电话，都没事。再过一会，正式的消息出来了，震中在四川！

晚上的时候，新闻陆续就开始报道了，张小庆在网上看了一会图片，眼泪突然就遏制不住的下来了，心里说不出来的难受，一种从没有过的难受。骑车走在去高晨晨宿舍的路上，一路上，他感觉所有的人都神情难过，连路灯都跟着难过起来，来到门前，一敲门王晓丽就开了门，电视里正在放现场的滚动报道，两个人紧紧抱在了一起，眼睛里都含着眼泪，王晓丽哭着说，地震了，张小庆拍着她的背，说，我知道，我知道，没事了，没事了。

现场情况源源不断的通过电视直播回来，王晓丽和张小庆一起回了家，每天他们都要看很长时间电视，他们都觉得自己应该做点什么。于是，就是捐款，给红十字会捐款，尽量多捐一些。这天下午，管财务的黄梅突然气呼呼的从办公室里冲出来，大声的说，你们到底有没有一点良心啊，到底爱不爱国啊，一些人就捐200块，还有一些人，杨晓，你一份钱都没捐，你还是不是中国人啊？！

张小庆知道杨晓捐了钱，但他捐给了一个民间组织，没有捐给红十字会，杨晓说官方机构根本不能信，他说，你信不信，捐款多少很快就要变成衡量你爱不爱国的标志了，他还说，你看着吧，官方很快就要把坏事变成好事了。张小庆不信，他说，这样的国难，红十字会不会这样的。

杨晓后面说的话很快就变成现实了，电视上，各个晚会都在举办，每个企业每个名人都在捐款，镜头对准最多的是他们捐款的数额，支票背后那些人的脸或喜或悲都变得那么不那么重要和模糊不清了，网上，开始有人制作出各个企业和名人的捐款排行榜。现场报道不见了，对校舍质量追问的帖子不见了，取而代之的是对各路英雄的宣传，各种表彰也开始了，国难是可以兴邦的。张小庆们终于对电视和各个门户网站感到不耐烦了，他去的是天涯，只有那里还有一些现场的消息，而这些消息也总是不总是能看到的，他们一起嘲笑了郭跳跳，电视和郭跳跳一起让人感到厌恶。

生活还要继续，张小庆进的是刘哥的保险公司的项目，他们遇到了严重的性能问题，系统运行的比在开发机器上还慢。张小庆开始排查问题，他第一个想到的是是不是数据库访问太频繁，于是，他把所有操作的数据库语句全部打印出来，一个一个的调优，接下来，他又给频繁访问的数据加上缓存，在公司开发机器上，系统性能几乎是立刻得到了大幅度的提升，但在产品环境，系统还是那么慢。问题似乎陷入了僵局，产品环境是IBM小型机，本地开发环境是PC机，本地根本就没有办法模拟产品环境。于是就开始猜，会不会是运行环境的问题，是不是操作系统的问题，是不是数据库的问题，是不是WEB容器的问题。最后，在一个weblogic原有开发人员的帮助下，他们终于发现现场部署的weblogic默认是运行在32位机器上的，与64位机器存在一定的不兼容。通过替换一个IO包，问题得到了解决。替换完毕后，速度立刻提升了30%。保险公司使用的是盗版weblogic，如果没有这个私人关系，他们根本就不会得到这个64位下的jar包的。这个问题花了张小庆整整一个月的时间，他骂了人，妈的，这么大的一个保险公司，中间件、数据库、企业IM竟然全部是盗版，软件在他们眼里就那么一文不值。

性能问题解决后，问题还没完，访问量一上来，系统开始频繁宕机，出现内存泄漏了。继续找问题原因，还是老样子，在本地重现不了内存泄漏，继续把眼睛放到产品环境盗版的数据库和中间件上面，没有技术支持，去搜索各个帖子，一项一项的查看配置参数，终于发现内存泄漏出现在数据库驱动和连接池的一个设置上面，一个缓存选项被系统集成商的实施人员设到了最大，直接导致内存溢出。

项目结束了，尽管王总和金鹏都表扬了他，但张小庆却感到深深的失望，他在想，为什么在这样的大公司里面，还会如此到处用盗版软件，项目总价300万，硬件占了230万，软件才占70万，而软件中根本就没有考虑用正版数据库和中间件，而这些硬件，在张小庆眼里，根本就是用不上的，这样的访问量根本就用不了这么好的机器。张小庆在想，这个收入排名前列的保险国企尚且如此，其他国企是否也是如此呢。当然，张小庆也是有收获的，第一就是性能调优之前一定要先找出出现问题的瓶颈，而不是想当然的马上进行优化，第一次调优花了一个月时间，其实对代码的调优完全是不必要的；第二是一定要对系统运行的环境配置信息也管理起来，如果可以，测试环境一定要与产品环境一致。不管怎么样，张小庆还是难过，他开始回想起他在科技动力所做过的所有项目，除了第一个一汽丰田项目，其他的都不算成功，新业务平台开发没有取得预期的销售，准确的说只售出一单，那一单幸亏还是客户换领导取消否则还真很难说，剩下的都变成内部项目使用了，新工作流开发吧，就根本没有完成就取消了，现在，这个保险项目，又是滥用盗版软件。这不是我想要的，张小庆对自己说，他想能够开发真正产生价值的软件，这个软件被客户真正使用，不是政绩和面子工程，而又获得客户好评。有这样的公司吗，他问自己。

工作上感到失望，和王晓丽的关系似乎也微妙起来。上次因为地震的关系，两个人又生活在了一起，但没多久，谁都能感觉到他们回不到过去了，还是一起吃饭，还是一起骑车回家，还是一起买菜，但两个人多少有些心不在焉，话少了很多，晚上张小庆写自己的代码，王晓丽看自己的电视，王晓丽不再要求张小庆陪自己看电视，王晓丽也不再追问什么时候结婚的事情，张小庆也不想去主动提这件事，两个人似乎都在等一个最后时刻的来临，这个时刻就是当一个人提出分手的这个时候，一个人说，好吧，这样真的很没意思，你看，我们不如分开一段时间吧，另一个人很礼貌的回答，好的，我也是这么想的，我之前不说是怕你有想法，你现在这么说我就放心了。于是，两个人礼貌的握手，就此变为朋友。这个时刻什么时候来临呢，谁都不知道，都在等待。

这天张小庆刚到公司打开电脑不久突然就接到了王晓丽的电话，这是这段时间很少出现的事情。这天早上王晓丽去了医院，她去复查身体，和她妈妈一样，她的乳房里有个硬结，不过已经很多年了，一直都没事。刚接通电话就传来王晓丽哽咽的声音，她说，小庆，你快过来，医生说，恶变了，呜呜。

     摘要:       事实证明，所谓中小企业联合会就是一个骗子。过完年后光头就再没出现过，他给王总打过一个电话说是今年因为奥运会的缘故人民大会堂的会被取消了，所有的相关开发也就停止了。听张小庆说完这事，张岩大笑起来，说，他和我们就是一路的。张岩是王晓丽的表哥，中专毕业来北京已经快十年了，最开始在某大学做保安，中专读的就是保安专业，还是在河南找关系读的，后来就从事了现在的这一行。...  阅读全文

下午和周筠老师聊天，周筠老师一口气推荐了杨早的三篇文章：我最难忘的一位老师、等待起风的日子和没有空白的年代，言语之间能够看出周筠老师对杨早的特别喜欢。之前也看过杨早的一些文学评论，同样是周筠老师推荐，却没有那么深的感触，因为自己读书太少的缘故，杨早对王朔、王小波、王蒙的评价，因为自己阅读这些作者少或遗忘的缘故，没有太多的共鸣，惭愧。

 

读《我最难忘的一位老师》，我想起了我的高中语文老师，那是一个老头，上课的时候特别喜欢天马行空，他对古诗词是十分精通的，通常讲着讲着课文突然就能来那么一段，本来，长年累月的背诵早让我们对古诗词充满了畏惧，但是，他即兴发挥的一段却总能却中当时的情景，老头是自己背诵，带着感情，甚至有一次，看见泪水从他的眼眶中溢出来。我喜欢这个老头，我的语文其实并不好，一提起拼音就头疼，但是我的作文却总是能被他当做范文在班里阅读，评语同样是非常的简单，就是一个字：好！我是一个喜欢胡思乱想的家伙，一次是情景作文，要对断臂的维纳斯写一篇文章，所有人都写非常遗憾如果有胳膊就完美了，我却讨厌了千遍一律，我写的题目是“缺陷美”，自然，如我意料中的，这篇文章得到了最高的90分，评语还是那个字：好。老头喜欢我，我是知道的，因为想吸引班里一个女生注意的缘故，我经常往报纸杂志投一些很幼稚的稿件，也有能够发表的，每次发表，老头总能下课后找到我，指着杂志上的名字问我：这是你吗？我点点头，老头点点头笑笑，却不说话。

 

我们毕业后老头就退休了，他年龄大了。一直想着去看他，却犹豫再三，我是自卑的，高中前两年除了语文和数学其他科一直都不是很好，高三成绩好容易好起来高考却失败了，在父母的安排下读了军校，上了半年学却大病一场，几乎要了我的命，一直依靠药物维持着。这样，当同学约好一起去看老师时，我犹豫了，与他们相比，我是自卑的，他们上着这样和那样的学校、在这样和那样的公司，我却要为活着而活着，我是如此的卑微，我想，也许等我有一天出人头地了，能够再去看他，我是如此的固执，固执的自卑着，我想，如果不能做些成绩回去，真对不起他给的那些评语“好”。后来，我听同学说，他问了我，他是盼望我去的，但是，我让他失望了，其实，这个失望又何尝不是对自己呢。于是，一直都没去，直到现在。

 

我想，如果再回家，一定要去看看老头，那怕自己什么都不是，那又有什么呢。

 

读《等待起风的日子》，里面这段话自己非常欣赏：你真的想这样做吗？不是为了赢得别人的赞誉，不是为了博得进步的资本，真的想这样做？

 

 想。

 

 那就去做吧。

 

非常契合我现在的状态。因为张小庆的缘故，暂时离职了，在家里。周围的亲戚朋友说，不要太冲动，再好好想想。

 

高一分班，想读文科，考中文系。周围的亲戚朋友说，不要太冲动，再好好想想。于是，选择了理科。

 

高考失败，想着重考一年，周围的亲戚朋友说，不要太冲动，再好好想想。于是，读了他们安排好的学校。

 

大学的时候，读书，写字，想找份新闻出版相关的工作，周围的亲戚朋友说，不要太冲动，再好好想想。于是，自学了编程。

 

同样是在大学的时候，被高中一直喜欢着自己的女孩追到毕业，这次是自己对自己说，不要太冲动，再好好想想，自己现在什么都不是，身体还不好。于是，一再拒绝人家。

 

大学毕业，想去北京，周围的亲戚朋友说，不要太冲动，再好好想想。这次，没有听他们的意见进一个事业单位，于是，来了北京。

 

我总是很容易被周围的人所影响，不断的摇摆、不断的蹉跎，慢慢就迷失了自己，别人在追求着什么东西，哦，那也应该是自己追求的，于是，岁月就在不断的遗憾中逝去。我在追求什么？我是在追求自己的快乐，是自己的，不是别人认为的。每个人都在追求快乐，但是，快乐是需要自己定义的。

 

这次，请让我以杨早的话作为结尾：好吧，朋友，感谢你的关心。可是风已经起了，我要开始我的历程了。麻烦你把那个水瓶递给我。然后，请让我静一静，让我怀抱着我的梦想，开始我的翱翔。

 

为什么想表达，在《没有空白的年代》里，有这么一段话：粗分一下，这本集子里所讲的不过两个方面：一是一个身处世纪末的中国南方的青年如何与社会的各种影响，与自身的平庸抗争的心路历程。这在旁人看来自是平淡无奇，但在我的回眸里，却相当惊心动魄，我曾多少次在文字的迷阵里试图抓牢自己漂浮的灵魂，感谢上苍，在我的二十四岁，我终于取得了一点儿成功，但愿前面的路能好走一些。二是这个青年正在努力介入社会生活，对他感兴趣的东西发出自己的声音。他的执着在某些人看来是可笑的，特别是在南方，关心这些没什么油水的事的人不多。但是他相信保持对社会和文化的关念是这个社会的知识分子的职责，他愿意做这里面的一员。

 

这正是自己想表达的东西：一是一个生于八十年代的青年的心路变化，在之前大部分时候，他是懦弱的，他是摇摆的，他是被动的，现在，他在努力工作支付按揭贷款的同时，正在努力构建自己的精神世界，他原先的世界观在接触这个现实世界的一瞬间崩塌了，然后一直都没有重建。二是这个青年对这个社会是抱有希望的，最开始，他是相信一个人能改变世界的，现在，也许我们不能改变世界，但我们能改变自己，坚信只要做好自己应该做好的事情，就会改变。

 

再说说小说的提纲，小说现在分为两条线，一条是张小庆现在的生活，一条是张小庆对过去的回忆。回忆从小学开始一直到周扬离开，中间的主要事件在上面已经做了说明，表现张小庆的摇摆，为他人和社会所影响，世界观从最开始的感觉生活在巨大幸福之中到怀疑到沮丧到被动接受到希望改变，人生目标也从科学家到为共产主义奋斗到出国留学到先生存下来到做一些喜欢的觉得有意义的事情。现在的生活从早上的930开始，到晚上下班回家，描述一天的工作，侧重点会放在对两个项目的经历和思考上，和他周围的人一样，他追求卓越和代码质量，他认为这是他的本质工作，当你糊弄自己的工作时，那和掺三聚氰胺和染色馒头一样没有区别。

 

最后，谢谢周筠老师，谢谢杨早，谢谢他的文字，我会更多阅读他。

早上六点半的时候，张小庆起床了。天还没有亮，张小庆打了个大大的哈欠，其实闹钟定的是六点二十，每隔十分钟再响一次，张小庆特别享受六点二十到六点三十这段时光，这是他睡得最幸福的时刻。王晓丽和儿子还在熟睡，他亲了儿子一下，然后洗漱、穿衣服、将馒头在锅里蒸上、将稀饭煮开调成微火，走得时候，他拿了一本书，对王晓丽说，我走了，馒头蒸好了，稀饭还在锅里。王晓丽没有睁开眼睛，恩了一声。

走出单元门，天刚刚蒙蒙亮，和往常一样，这不是一个好天气，但是，按照某个标准，这又是一个好天气。张小庆这些天一直被一个问题困扰着，这个问题如此扰乱着他，让他时而激动不已，时而又头疼不已，这个问题已经困扰他很长一段时间了，却找不到答案。

有两种方式去北京，一种是拼车，一种是930。其实曾经有过第三种方式：小区班车。但第三种方式在发改委与国际接轨的过程中取消了，值得兴庆的是，是小区班车不是小区班机。倒数第二次乘坐班车的时候，一个结实的中年人发了传单：我们要抗议开发商违背承诺，取消班车。传单把全车老老少少男男女女们的情绪点燃了，气氛显得热烈而又群愤激昂，时间定在第二天的晚上，地点在开发商开发的大酒店。中年人甚至给司机说好了明天晚上到大酒店停一下，司机笑了下，说，支持。于是，第二天司机就拐了个弯把车停在了大酒店，却没有几个人挪动昨天群愤激昂的屁股，中年人说，兄弟们，争取我们自己利益的时刻到了。车厢里很安静，工作了一天，人们都太累了睡着了。中年人说，这是最后一天了，没有机会了。有人被吵醒了，把头扭向了车窗外。中年人和空气僵持在那里，终于，有人说话了，低低的，明天还要上班呢，太晚了。有人附和，是啊，明天还要上班呢。明天是星期六。

再过一会儿，空气不安起来。

有人说，没用的，开发商是黑社会。

有人说，930其实也不错，加车了。

于是，中年人只好下了车，张小庆默默的跟在他的屁股后面，也下了车，原来群愤激昂是靠不住的。在后面走得时候，张小庆望着中年人的背影，突然就想起了三哥哥，那个在童年里带着他走得三哥哥，他们的背影是如此的相像。

老板没有出现，出现的是市场总监，一个强悍的更年期女人，后面跟着两个帅气的保镖。女人说，没得谈。果然很像黑社会的女人。

中年人说，你们当初是怎么承诺我们的，那么大的广告牌写着社区班车30分钟直达国贸，为什么说取消就取消？

女人不耐烦的说，你没看完。

张小庆跑到门外，那个大大的广告牌还耸立在那里，四周的射灯照得社区班车四个字耀耀生辉。在右下角，一个不起眼的角落处，张小庆看到了这么一行字，这行字很小，几乎淹没在阴影里，不注意的话根本看不见，这行字是：最终解释权归开发商所有。真是个大杀器，制定好游戏规则，白字黑字的印出来，贴得到处都是，最后却是解释权归他们所有，也就是他们可以不遵守游戏规则，规则都是制定给别人遵守的。这一瞬间，张小庆想起了“威震天”，那个下午，威震天走进教室，脸上还淌着鲜血，说，别担心，现在是属于他们的，但未来是属于我们的。但事实是，现在还是属于他们的。

警察以前所未有的速度出了警，来了很多警察，开始对每个抗议的人一个接一个的录像。双方僵持在那里，女人说，两个方案，一个是取消，一个是每个月从200涨到400块钱，其他，没得谈。再一次上班的时候，张小庆在小区门口的电线杆上看到了班车恢复的通知，它就那样贴在那里，和治疗梅毒、阳痿的小广告们并排挤在一起，上面写着：为积极响应政府关于绿色出行的号召，鼓励大家乘坐公交车，经过和业主的积极协商，同时考虑到业主们的实际困难，经研究决定恢复班车，价格，399元一月。

拼车是不坏的选择，10块，从小区门口到国贸地铁站。最开始是QQ、富康和比亚迪，后来现代和雪福来也加入进来，再后来，张小庆甚至有一次做了回奥迪。也偶尔有不要钱的，说同一个小区顺道带了，但坐那车需要勇气，因为当得知不要钱的时候，怎么看那个司机怎么都不像个好人，如果心脏不好，很可能就就因为这10块钱挂在路上了，得不偿失。

拼车能碰到各种各样的人。有一次，一个女人开车，开得飞快，不停的变线，从国贸下车的时候，张小庆发现自己的后背汗湿了，想，再也不要坐女人开的车；有一次，QQ，塞下5个大男人，司机以你们都是80后吧，我也是作为开场白，聊起自己的大爱经历，说公司刚来的一个90后妹妹真开放，真嫩，说北京有哪些比较有档次的迪厅妞，说自己经常开车去二外，那里只要停车就有学生敲你的车窗，说这话的时候，屁股底下的QQ剧烈晃动不好意思起来，一超过70码，它就开始替它的主人不好意思；有一次，聊到最近最火的艺术家，前面的司机缓缓回了一句，我就是那个推手，这是我的名片，说以前只要说是艺术就会火，后来需要将学生和艺术这两个职业叠加起来才能火，现在则必须首先要是名牌大学的，越来越难啊，人民群众重口味了；还有一次，聊到了少先队，两个人争起来，究竟有没有五道杆，张小庆突然想起了黄晶晶，那个小学时代的三道杆大队长，当时她是那么的英姿飒爽，自己又是那么的迷恋。

几乎所有的司机都会在拥挤的道路上打开“一路畅通”，那感觉，就像一个坐在马桶上的便秘老男人憋红了脸旁边却在泉水叮咚，主持人说，今天路况还是不错的，西二环和北二环压力有些大，南二环和东二环参照西二环和北二环，三环参照二环、四环参照三环，五环参照四环，恩，六环还是相当不错的，但是大家也不要都往六环上挤，因为听我们广播的人很多，如果都去的话，很快就会挤起来。所有的司机听到这里都会着急上火的占用应急车道，张小庆很想提醒一下这是应急车道，但是他张不开嘴。他总是在犹豫，在担心，小学时是这样，中学时是这样，大学时是这样，现在，也是这样，他需要一个人推着他走，领着他走，杨玲曾经叹过气，说，你这个人啊，就是太担心，担心什么呢，都是自己担心出来的，我就和你不一样，起码我爱过你了。但是现在，必须他自己做出决定了。终于一次，一个司机没有占用应急车道，张小庆感到一阵欣慰，谁知司机摇下车窗，一口浓痰吐到路上，说，这帮傻比，刚过去的地方前两天刚装了摄像头都不知道，罚死这帮孙子，哈哈。说完这话，一把轮，拐回到应急车道上。

今天的930来得比较准时，等车的人不多，能上车，不用等下一辆。这是不常见的，常见的是又堵在北京了，半天才来一辆，人们潮水般的涌过去，这时候，张小庆是不去挤的，他不想去争些什么，从来都是这样，他站在一旁，等所有的人都上去，自己最后上，然后司机关门，把自己的脸贴在玻璃门上，挺好，在乎的不是目的地，而是沿途的风景。在车上站定，张小庆打开手中的书，路上四个小时，只有这一个半小时可以不被浪费，但是今天，他看不下去，他得做出决定。窗外，一地瓦砾，一栋危楼上一面五星红旗在迎风飘荡，巨大的标语：二次强拆，楼毁人伤，朗朗乾坤，公理何在。他们还在这里，张小庆想。自从去年春天，他们就屹立在这里，春天过去了，夏天过去了，秋天过去了，冬天过去了，一年过去了，这次春天是否会来呢？

车到开发区的时候，上来一个老太太。车上热烈的气氛顿时消逝了，车厢里再次变得安静，要开始一天的工作，人们都太累了睡着了，有人低声说了一句操，好像老太太会杀死他们。没有售票员，司机喊了一声，谁给老人让个座，没有人回答。张小庆的心脏突然剧烈跳动起来，要不要叫那个坐黄座的年轻眼镜让个座？他犹豫了，他担心别人讨厌他，担心给别人带来麻烦，所以他总是不去争什么，车上有人开了窗，吹着自己很冷，总是先忍着，想别人一定很热，等到实在忍无可忍时才小心翼翼的问别人是否可以将窗户关小一点，这就是他，一直都是这样。这次，憋了很久，他终于对着睡着的眼镜小心翼翼的说能否给老人让个座，果然，眼镜睡得很死，他不得不再小心翼翼了一次，这下全车人都听见了小心翼翼，有人幸灾乐祸的笑了一下，眼镜的眼镜后面泛过一道寒光，那一瞬间，像极了柯南，嘟嘟噜噜的站起来，从张小庆身边经过的时候就说了一句傻比她是你娘吗。张小庆的脸唰的红了，一种被侮辱的感觉传遍全身，这种感觉其实在他生命中经常存在，他一边被这种感觉侮辱着，一边一声不吭沉默不语。他想起了周扬，如果是他，他一定会淡然的笑一笑，脸上挂上一种满不在乎的神情。

车过酒厂，迎面驶过来一个绿色的大牌子，上书：北京界。不远处，一列火车迎面开来，和谐号，速度快，让人数不清有多少节。王晓丽嘱咐今天要在北京给孩子买鱼肝油，其实燕郊也有，比北京便宜很多，但是王晓丽从不放心：北京的东西才是真的，一定要去北京买。张小庆说，都有防伪标签的，北京还贵。王晓丽说，为了孩子，你这几个钱都舍不得花吗，你怎么当爹的？于是当爹的就闭了嘴，他想，这根本就是两码事嘛。王晓丽喜欢北京，她的梦想就是要在北京买套房子，她的这个梦想像个美丽的肥皂泡，经常变幻出美丽的颜色。其实不止是她，王碧薇、高晨晨、张雨和陈华，张小庆所认识的女人里面，都是喜欢北京的，她们中间有的有北京户口，有的没有，有的一个月能拿到七八千块，有的只能拿到一千块，有的用着几千块钱一套的雅诗兰黛，有的用着几块钱一瓶的大宝，但是她们对北京的热爱却是相通的，她们爱着此刻930正在奔跑着的地方。张小庆想起了王阳，想起了余鹏，想起了张川低低的哭泣，王阳说，不要给我提北京，我痛恨那个城市，余鹏从不说什么，但是一提起北京，他就转身离开。

太阳升起来了，照在张小庆的书上，有些晃眼睛，一页都没有看下去。他回到他的问题上来了，这个问题表面上是个选择题，选A还是选B，似乎都没有那么简单，那么该怎么办。在这个时候，张小庆想起三哥哥来了，如果是他，他会怎么选择。

第一卷还有两章就写完了，框架已经搭好，很快就会写完，但是，却写不下去了。第一卷是失败的，从写作技巧上，可以列出它很多失败的地方：没有一个一致的框架、线索，没有冲突、过于迷恋细节、太多无关的人物，主要人物经历片段化。写到第五章的时候，父亲说，你写得太平淡了，这是第一个向我提意见的人，接下来米高在开心上提到张力不够的事情。但当时的我还沉浸在生活就是如此平淡的迷梦中，终于到了第九章，在微博上，一个朋友猛烈的抨击了我：越来越无聊了，像流水账，毫无可读性可言。妹妹也批评了我：王碧薇会喜欢上张小庆，张小庆何德何能啊！把主角写成如此不堪，我是如此的不堪。于是，开始痛苦的思考和转型，第一件事是列剩下章节的提纲，以一条主线统一组织内容，制造矛盾和冲突，老舍说，以爱情来组织故事总是最容易的一件事，于是，我就偷了这个懒，另外，在妹妹的提议下，加入多角度的描述以突出人物。但是，我越来越感觉到不对劲，这（爱情）是我想表达的东西吗？不是啊！

我想表达什么，或者说我为什么想写张小庆？写张小庆是因为一件事触动了我，这件事是年前周扬告诉我要回家创业了，周扬是我的朋友，比我小两岁，85年的，中专毕业，在北京一家牙厂里当送货员，住的是地下室。一年过年回家的时候，还是送货员的他告诉我，他一定要自己开个牙厂，尽管是他的朋友，但其实我内心还是不太看得起他的，年龄小，学历不高，挣得不多，最开始还喜欢玩网游，处于社会的最底层。但接下来的事情却让我吃惊，做了两年送货员，第三年他开始和老板一起跑业务，第四年开始学做烤瓷，第五年学做牙冠，好几个过年都没有回家，现在，突然就要创业了。其实第五年他的工资就已经过了万元，我曾经问他，在燕郊买个房子吧，和我住一起。他笑笑，说，不，那不是我想要的。从一开始，他就有一个坚定的想法，就是在家做些事，和父母家人在一起，一直没变。在他的心中，北京只是个驿站，路途的一个临时停靠点而已，他的家一直在生他的地方。

看看他，再看看自己。在下东直门地铁站的时候，我问自己，我在追求什么，天天做地铁再换公交车，每天路上四个小时，天天忙忙碌碌，我到底在追求什么。问自己这个问题的时候，我愣住了，因为这真是他妈的一个好问题，因为我根本不知道该怎么回答。追求什么，追求当苹果新产品问世时，第一时间知道，第一时间拿到手吗；追求什么，追求当有好莱坞大片上映，第一时间知道，第一时间去观影吗；追求什么，追求能够用上最好最新的互联网产品，刷微薄，然后不断转帖吗；追求什么，追求，看，我们从不喝国产奶粉，都是从外代购吗；追求什么，追求过年回家时，面对那些在家的同学所具有的所谓的一点点优越感吗；追求什么，追求钱吗，那为什么总是爱说，等我有钱了，那就什么什么的呢。我在追求什么？！海贼王里说得很明白，金钱、地位和荣誉，是每个男人都追求的东西，真是这样吗，我怀疑，起码我怀疑自己。

这个社会不是一个理想的社会，这点我毫不怀疑。大学时，听到911事件的新闻，全班同学一起发出兴奋的狂呼，现在想想，冷汗直流，为什么会这样。李刚儿子遭到那么多人的咒骂，我相信，很多人其实是在咒骂为什么自己的爸爸不叫李刚。不管是好还是坏，总有人在咒骂，在他们眼里，所有支持这个政府的人都是五毛，所有批评这个政府的人都是愤青，非黑即白。还有人，听到油价上涨，一阵狂喜，涨死那帮买了车的，可知道，自己吃的东西用的东西都是用车运来的。拼车时，一边抱怨交通不好，一边占用应急车道；等车时，一边抱怨交通不好，一边不管别人死活的插队；在家时，一边抱怨城市关系落寞，一边根本不和对门刚出来的人打招呼；做馒头时，一边大骂双汇，一边给馒头染色。很遗憾，这里面都有自己的影子。都是别人的事情，一说都是社会的错，耸耸肩，无可奈何，自己一点点责任没有，移民吧，赶快的。所以，我想，张小庆应该不是这样，他应该是抱有希望的，尽管很渺小，但是尽力做好自己的事情，坚信只好做好自己应该做的事就一定能够慢慢改变。

周围的好多人和事。哥哥和嫂子总是打架，嫂子是大学毕业，哥哥是中专，嫂子是不甘心，为什么周围的女人们都这么热爱这座城市，想留在这里，想生活在这里，哪怕这个城市并不热爱她们。朋友因为分手和前男友打房子的官司，房子，如此畸形的影响生活。朋友的老婆身体有病，一直在休养，朋友就这样知道她身体不好的情况下和她结了婚、租房、生活，工资不高，一起在北京生活，他们又在追求着什么。朋友是北京的女孩，腿有残疾，家境很好，有车又有房，但一直在奋斗，为学日语，六个月天天学到凌晨2点，现在是一家外企的技术经理，一个女孩子，她又在追求什么，她曾经在路边跌倒过，很多很多的人经过，没有人去扶她一把，她只好自己挪到树边，自己挣扎的站起来，当时，她是一种什么样的心境。朋友一直在家做老师，教学水平却并不好，管不住学生，同学们谈起他总会带一种不是有意但是不知不觉的轻蔑，他是怎么想的。过年回到家，老人之间谈论最多的却是钱，谁谁在什么地方一个月多少钱，谁谁嫁给了如何如何有钱的老公，突然周围全是有钱人，此外，小县城突然也开始堵车了，这是以前从来没有过的事情，都是外地打工回来的人们，开车回来，他们像一群候鸟，几天后就飞走了。高中的同学，父母在当官的，很多重新回来，接了父亲的班。

至于软件开发，我也是有疑惑的。我们到底为什么在做软件？为什么我们软件用户只有政府和国企，中小企业都到哪里去了，他们在用什么软件？为什么很多时候，软件只是个花架子，我还记得，当客户单位更换领导取消我们项目（但付款）时，我们发出的欢呼。为什么我们一边把自己的软件加密再加密，一边却在网上跪求破解码？为什么产品开发最后会失败，明明只剩下最后一公里了，却迈不过去？为什么要重写软件，为什么不能打补丁，只是因为觉得代码丑陋？为什么看似是大公司接的项目，最后却是层层外包，还是我们小公司来做，资质只是做投标用的吗？为什么现在看东西越来越浮躁了，没有内容，只剩下标题，为什么只看了一篇报道就下了判断？

这就是我想写张小庆的原因，我想表达出周围人们的生存状态，表达出自己的疑惑，尽管还没有答案。所以，突然就想重写了，重写总是比重构来得容易。会抛掉所有无关的细节，以一条张小庆的视角串起来所有的故事，重新组织。所以，对不起了，所有关注张小庆的朋友，这个礼拜会开始重写，周末的时候会发出重写后的第一章，抱歉。

第一卷写得不好，但是张小庆说，今天比昨天好，明天比今天好，这就是希望。我是有希望的。

晚上的时候，张小庆突然收到了王碧薇的短信，问他有没有时间，能不能陪她散散步。这条短信让张小庆很意外，他说，什么时间，在什么地方。王碧薇说，就是现在，在活动中心的门口。张小庆说，好。

    汤姆在桌子上敲代码，看到张小庆出去，说，又去约会？

    张小庆说，没有，出去买点东西。

    汤姆笑了笑，说，别骗人了，买东西还需要照个镜子？

    张小庆说，真是买东西。说完这句话自己都觉得很无力，无奈的看看汤姆，两个男人相视一笑。

    张小庆和王碧薇在亦庄活动中心的门口见面了。一路上张小庆走得有点快，这让他的心脏跳得有些快，这样，当他远远看见王碧薇的时候，他停了下来，慢慢平息一下心情，然后才以正常的步子走过去。活动中心的门口有几级台阶，王碧薇站在最高的台阶上等张小庆，天气很热，她穿了件白色体恤，下面是一条碎花裙子，露出匀称的小腿，一双高跟凉拖，露出高高的脚倮，她低着头，在台阶上来回踱着步子。看到张小庆，她停下来，说，吃饭了吗，没有打扰到你吧。

    张小庆笑起来，他觉得王碧薇这身衣服穿得很漂亮，说，吃过了，反正我晚上也没什么事。

    王碧薇说，请你吃雪糕吧。

    张小庆说，好啊。

    于是，王碧薇给张小庆买了根他要求的北冰洋双棒，轮到自己时，来了瓶矿泉水。张小庆问，你不吃雪糕吗？王碧薇说，我怕长胖。张小庆说，你一点都不胖啊，甚至，有点瘦。张小庆的回答让王碧薇恢复了以前活泼的神气，说，哈哈，我最喜欢听的就是这句话了。

    尽管之前很多次的和王碧薇见面，也有独处的时候，但这次还是带给张小庆一些不一样的感觉，至于是什么感觉，却又说不出来。两个人开始绕着星岛嘉园慢慢的走，路上有很多行人，那是些老头和老太太，他们去活动中心旁边的广场上跳舞。王碧薇说了自己，她比张小庆早毕业3年，一毕业就来到北京，一直做得就是翻译工作，自己现在最大的愿望就是能在北京有个自己的家，不再租房，不再东搬西搬。她抬头看看小区里的点点灯火，一个窗口里，是一个男人和女人一起做饭的身影。说完自己，王碧薇问张小庆，你的理想是什么。

    张小庆说，写代码，写自己喜欢的代码。

    王碧薇说，就只是写代码吗，你不是一直说要去IBM和微软吗？

    张小庆说，那是因为我现在认为在IBM和微软能写自己喜欢的代码。

    王碧薇说，你会考虑一直在北京吗？

    张小庆说，当然，这里有我的希望。

    王碧薇说，你的希望？

    张小庆说，是啊，今天比昨天好，明天比今天好，这就是希望。

    王碧薇说，我想做好好做现在的工作，我想做项目经理。

    张小庆说，我不想做项目经理，我的职业规划是做个好程序员，一直写代码到老。

    两个人不知道绕着小区转了几圈，他们聊了很多，聊到公司里的同事，聊到自己上学甚至小时候的事情，张小庆说到了李静，说到高二时一次从未和他说过话的李静突然回过头来向他借一本高一的代数书，他急急忙忙的从高高的教学楼里跑下，奔向自己的寝室，翻箱倒柜的找，没有找到，于是到其他寝室里去借，好容易借到，然后再心急火燎的跑回教学楼，奔上高高的教室，临到门口，心跳的厉害，大口的深呼吸几次，这才进了教室，把书平静的递给李静。王碧薇哈哈大笑，说，当时她说什么了吗？

    张小庆说，她说我找了很久吧。

  

    王碧薇说，你怎么回答的呢？

    张小庆说，我说没有，就在床边，顺手拿来，easy。

    王碧薇笑得止不住，说，现在她在做什么呢？你没有联系吗？

    张小庆摇摇头，说，没有联系，她现在在西安交大念研究生，我们之间的差距太大了。张小庆说到了高三的时候，一次摸底考试成绩下来后，看到成绩，自己在本子上画了个高高的李静，旁边是蚂蚁般渺小的自己，无数的箭头从蚂蚁身上划过。王碧薇说，你想太多了，女孩子是很好追的。张小庆说，整个高中我都没和她说过几句话，她也不知道我喜欢她。王碧薇说，相信我，她一定知道，说不定那次向你借书就是想和你说说话呢。末了，王碧薇突然补了一句，你现在还喜欢她吗？对这个问题，张小庆不知道该如何回答，他只是说，5年没有见面了，不知道了。王碧薇哦了一声。张小庆说，你呢？

    天色已经很晚了，周围都安静下来，偌大的广场上早没了人影，小区也已经睡着了，只剩下橘红色的路灯孤寂的发出滋滋的声响，空气中开始弥漫着一股凉气，有点冷了。王碧薇在一个路边的靠椅上坐下，说起了她现在的男朋友，张小庆在她旁边站着，由于光线的缘故，他只能看到她长长眼睫毛投下的阴影，看不见她的眼睛。王碧薇说，他是她大学的同学，大学毕业后一起来到北京，工作了半年就考了研，现在还在读研。张小庆说，挺好的，读个研究生挺好的。这话说得酸酸的。王碧薇说，不是你想的那个样子，他其实是想逃避，他不喜欢北京，他想回成都，为此我和他吵过好几架，但是没有效果，他很坚决。张小庆说，成都也挺好的。王碧薇说，可是我喜欢北京，我在这里生活了3年，我喜欢这里，第一年工作给他的打击很大，他只想着离开，他为什么就不理解我呢。说到这里，王碧薇的声音有些哽咽，可以想到，她长长眼睫毛的阴影下，可怜的眼泪一定流下来了，这不是张小庆所认识的王碧薇，有一段时间，他站在那里，看着面前这个漂亮女孩的肩膀随着情绪一动一动，他却束手无策，不知道怎么办才好，他想递给她一个纸巾，却没有带，他想去搂住这个可怜的姑娘，但却喉咙发干，挪不动步子。时间就这样一分一秒的过去，慢慢的，王碧薇的情绪平静下来，两个人都没有说话，又待了一会，她站起来，擦擦眼睛，说，对不起，我没控制住情绪。张小庆说，我陪你回去吧。一路无言，走到王碧薇住的楼下的时候，张小庆说，没事的，明天一定比今天好，不要放弃希望。王碧薇说，恩，好，再见。

    回到家里，汤姆已经睡了。张小庆却无法平复自己此刻的心情，一躺到床上，就浮现出王碧薇肩膀随着情绪抽动的情景，真是个可怜的女人。心中便生出许多爱怜来。

    张小庆的夏天突然多彩起来，给他的夏天涂上色彩的是王碧薇。每个晚上，吃过晚饭，洗过澡，张小庆给王碧薇发过短信，老地方见！生活多了期盼，便多了生气。大多数的时候，他们沿着活动中心的广场慢慢的走，有些时候，他们也会走远一些，绕着贵园北里走。他们说到了博客，张小庆说到博客中国刚进行了第一轮融资，方东兴正是意气风发的时候，自己也刚刚开了一个博客。王碧薇访问了张小庆的博客，说，每天记录一些东西，真好，你都什么时间写博客。张小庆红了脸，小声的说，上班时间。王碧薇哈哈大笑，说，背着比尔吧。张小庆说，没有，是比尔鼓励我开的，因为我家里没有电脑。他允许我上班时间写博客，不过要是和技术相关的，他说他也在看。张小庆说到了自己给牛人发信问问题的事情，说都石沉大海没有回应。王碧薇说，牛人们不屑回答吗。张小庆说，开始我也不理解，但是想想，和我一样给他发信的菜鸟一定很多，他一定是处理不过来。他们说到了房价，王碧薇说政府正在对快速上涨的房价进行第一次调控。张小庆说我也听到了，那次从首图回来在公交车上听到的，广播里说最近一段时间办理二手房过户手续的人激增。他们说到了篮球，每个中午，比尔都会喊上张小庆去楼下的球场打球，王碧薇和张丽站在远远的树荫下看。王碧薇说，你知道我们公司最帅的男人是谁吗？张小庆说，不知道。王碧薇说，每次你都说不知道，你就不能猜一次吗？张小庆说，猜不到。王碧薇叹口气，说，是比尔！说完，和张小庆一起哈哈大笑。

    夏天移动的很快，因为王碧薇。8月一个星期天的傍晚，王碧薇给张小庆发了消息：去超市吗，我们一起去美廉美吧。早上的时候，汤姆出去了，张小庆在汤姆的机器上写代码。张小庆说，好几个星期了，你每个周末都出去，约会了吧。

    汤姆说，我哪像你啊，我是去我的同学那里。

    张小庆笑了笑，说，别骗人了，男人见面还需要照个镜子？

    汤姆说，真是见同学。说完这句话两个男人都想起来什么，这对话是那么的熟悉，只不过是换了个位置而已，于是两个人都笑起来。

    美廉美在天宝南街，两个人在小区门口见面，一起坐班车过去。张小庆不得不承认，美廉美和小白羊是两种风格完全不同的超市。两个人在美廉美吃了饭，王碧薇要了两份卤煮，张小庆没有吃过卤煮，王碧薇说，很好吃的，老北京特色，我特别喜欢吃。端上来，黏黏的，火烧、豆腐、小肠和肺头掺杂在一起，上面生长着些绿意葱葱的韭菜花。王碧薇说，这是补心肝的，快吃。张小庆却一下子适应不了这个味，皱着眉头，想咽咽不下，想吐对面坐着的却是王碧薇，于是就犯了难，含在嘴里，半天不动。最后还是王碧薇解了围，哈哈笑起来，说，我第一次也是吃不下，吐了吧，吐了吧。

    两个人在超市逛了很久，王碧薇买了很多东西，其中有瓶六神的沐浴露，张小庆想，原来她身上好闻的沐浴露味是六神的啊。从超市出来，已经8点半了，班车停了，于是两个人只好步行回家，天气有些阴，走到天宝中街的时候，突然下起雨来，两个人跑到一家临街的小商店里躲起来。雨越下越大，两个人站在小店的窗户前向外望，雨点打在窗户上，窗户渐渐模糊起来，映射出两个人的身影。王碧薇着急起来，过一会就让张小庆出去看看雨是不是停了，张小庆走到门外，把手伸到屋檐外，心里说，不要停，不要停，嘴里说，小了些，但是走不了。一会儿，王碧薇也走出来，两个人并排站着，把手都伸出去，两只手并排靠在一起，一只大一些，一只小一些，有个雨点刚好落在两个手心的中间，散开来，溅在两个人的手心里，凉滋滋的，背后，小店温暖的灯光从玻璃里挤出来，洒在两个人的身上，张小庆突然就想抓住旁边这只纤细的手，然后，慢慢的走。路上开始弥漫起水气味，不远处，体育中心的草坪刚刚剪过，水气味夹杂着青草的清香，真是个美好的夏天晚上。

    尽管张小庆特别想这个夏天过得更长一点，但是，夏天终究还是要过去了。

五一来了，空气中开始弥漫一种淡淡的清香，那是好闻的沐浴露的味道。每天早上和王碧薇一起上班的时候，张小庆都能闻到这种味道。这个五一被张小庆安 排的满满的，一号二号要去周扬那儿，自从搬家后就一直没有去过了，答应请周扬吃饭的事情也一直拖着，刚好，他们五一就放一号二号两天假；三号农业展览馆有 个规模巨大的招聘会，要陪余鹏去看看，那天余鹏在公交车上说要回老家，公司因为迟迟没有业务散伙了，房子租到五月七号，张小庆立刻表达了剧烈的反对，怎么 能这么快就放弃？！余鹏一言不发，张小庆缓和了一下情绪，说，来一趟不容易，至少要试一试吧。张小庆这么说是因为他想起了那个阳光明媚的早上，小余老师懒 懒的躺在床上打了个长长的哈欠，眼睛都没有睁开，眼角上挂满了刚刚分泌出的新鲜眼屎。张小庆觉得在来北京这件事情上他是要对余鹏负责的。最后几天，他要去 首都图书馆办张借书卡。吃饭时，比尔问了张小庆五一的打算，张小庆说要去西单图书大厦看几天书，比尔说，为什么要去西单图书大厦？

张小庆说，那里书多。

比尔说，可以去首都图书馆，那里近。

张小庆感到一些稍微的吃惊，说，那里对外地人开放吗？

比尔说，开放。

张小庆还是有些担心，说，我还没办暂住证。

比尔说，身份证就可以。

这真是出乎张小庆的意料，在他印象中，办张公交月票都是要北京户口的。每个月的月初几天，周扬都会拿着他的月票卡去公交车站购买下个月的月票，他是得意的，因为只有北京户口才可以办理公交月票，尽管月票卡上是他的照片，但却不是他的名字。张小庆不无羡慕的说，牛啊。

周扬说，牛屁，所有业务员都有，老板找关系办的。

张小庆说，帮我也办一张吧。

周扬说，你还是先把暂住证办了吧，免得某一天去昌平挖了沙子。

距离周扬说这话突然间就过去了三个月，张小庆说，吃什么，我请客。

周扬说，真的吗，想吃什么就吃什么？

张小庆说，真的。

周扬说，那前面去？

张小庆说，没问题，走！

说完这话，两个人都笑起来。牙厂前面是一家三层的海鲜城，每天晚上夜幕降临的时候，巨大的霓虹灯亮起来，旁边，足足也有三层高的巨大基围虾紧紧贴在 海鲜城的墙壁上，闪闪发亮，下面，吃客们开始陆续到来，没有步行的，也没有骑车的，有的都是自驾和司机，院子里的停车场里很快堆满了各式各样的小汽车，还 有些由于没有位置就停在了路边上，有的标志张小庆认识，比如说奔驰，比如说宝马，有的标志张小庆不认识，周扬嘲笑了他，那是林肯；有的车牌张小庆认识，比 如说京B、比如说津C，有的车牌张小庆不认识，周扬嘲笑了他，那是军牌。他们都是衣着光鲜的，漂亮女人那是经常见到的，提着漂亮的手提包，跟在男人后边 走，橘红色的灯光打在他们的身上，别样的神彩。

最后，张小庆和周扬还是在牙厂解决了他们的吃饭问题，周扬说，吃什么不都是吃吗，请我上网好了。去网吧的路上，张小庆买了两份和路雪。张小庆注意到没有看见周燕，那个纤细的女孩子，他问了周扬，你表妹呢？

周扬说，回家了。

张小庆有点意外，说，回家了？不是刚来吗？

周扬说，你不知道吗？被她父母接回去了。

张小庆说，我不知道，怎么回事？

周扬叹口气，说，老板看上她了。

事情就是这样，老板看上周燕了，这个刚刚中专毕业从农村来到这座大城市的年轻女孩，在这里，她是羞涩的，见到谁都会微微低下头，脸微微的红；在这 里，她是好奇的，有太多太多和家乡不一样的地方，那么多的人们，那么多的车门，那么宽阔的马路们；在这里，她是朴素的，没有买衣服，没有买洗面奶，有时间 的时候，和几个姐妹一起压马路。于是，老板看上她了，他看上了她的羞涩、他看上了她的好奇、他看上了她的朴素，此外，最重要的，他看上了她的纤细，纤细的 眉毛，纤细的脸，一身的纤细。白白胖胖的牙厂老板、来自广东移民香港的牙厂老板、已经结婚儿子都上高中的牙厂老板，看上周燕了。他带她去了天安门、故宫和 长城，她带她去了前面吃了好几千块钱一顿的海鲜，她带她去了商城买了好几千块钱的衣服，这一切都让周燕紧张、心慌和不知所措，她告诉了周扬，周扬立刻给她 父母打了电话。当两位老实巴交的农民听到这一切时，他们震惊了，他们的第一反应是，丢人！他们几乎是刚接到电话就立刻买了火车票，他们的想法很简单，接回 女儿，不干了。甚至当老板想与他们见个面时，都被他们拒绝了。老板只好告诉周扬，不要结婚，只要答应当他在北京时陪他3年，那么，附近买一套三居室，老家 盖一座小洋楼，外加30万。

你和他们说了吗？张小庆问。

周扬说，说了，为什么不说。后来老板还跟着回去了，买了9999朵玫瑰，单腿下跪，送去周燕家，在家里都轰动了。

张小庆说，结果呢？

周扬说，闭门羹。我舅舅还找了几个人去打老板。

张小庆有点激动，说，就该这样，该打！

周扬摇摇头，说，人家老板也没做什么出格的事情，这事，太平常了。

张小庆说，那现在呢？

周扬说，现在老板找了个首师大的大二女生当情人，一个月一万。

张小庆突然就内心黑暗了一下，很想见见这个月薪一万元女生。

三号的早上，张小庆和余鹏在农展馆见面了，他们显然是迟到了，早上八点，他们下公交车的时候，车站全部是人，从车站到农展馆的路上，人们形成了长长 的队伍，像在行军，一对向北，那是进展览馆的，一对向南，那是已经投完简历出来的。走到门口，放眼望进去，全部是人，门口的售票窗口已经关闭了，直接改在 入口处交钱进人。

余鹏突然就说，我不去了。

张小庆说，不行！

余鹏说，我就没有准备简历。

张小庆很生气，语气有些生硬，说，那我们就去准备！

于是两个人没有进农展馆，继续向北走，张小庆在前面走得很快，碰到人就问哪里有打字复印，余鹏在后面不紧不慢的跟着。在一个小胡同里，一个五平方米 的小屋子里，他们找到了复印机，自然，全部是人，因为招聘会的原因，涨价了，复印一份一块。张小庆重新在计算机上给余鹏敲打了简历，很难写，在工作经历这 一段，他写下了，东湖中学，政治老师，一年，写完了，字数很少，于是，加上被评为优秀老师，想了想，没有加在北京工作的经历。写好了，老板问打印几份，余 鹏说五份，张小庆说十份，于是打印了十份，张小庆给了钱，两个人走出来。

展览馆里是人贴人，走完A馆和B馆，两个人都觉得累了，在从B馆到C馆的过道上停下来，张小庆去买了两瓶水，递给余鹏，两个人就坐在过道的石条凳子 上，偶尔喝口水，默默无语。张小庆很理解余鹏现在的处境，两个人逛了很长时间，那么多的展位，没有一个地方招政治老师的，好容易有几个教育培训机构，投过 去简历，不是摇头就是要求先交培训费培训再上岗。

我这种情况，只能干销售，余鹏说。

张小庆不知道该怎样回答，他想起了那个中关村人才市场的春天的早上，道路两旁的柳树发出绿芽，路上的人们行色匆匆，没人注意到自己，自己拿着装有简 历的文件夹，穿着印有无数双新鲜脚印的黑皮鞋，一个人默默的在路上走，这个世界不是属于自己的。现在，展览馆里各种树木都绿了，生气盎然，花坛里，花们全 部在怒放，旁边，卖矿泉水的老大妈正在数钱，喜笑颜开，同样，这是不属于余鹏的，在此时此地，也是不属于张小庆的。

张小庆说，我们去C馆吧。

余鹏摇摇头，说，你觉得有意义吗？

张小庆没有直接回答，只是说，走吧。

余鹏恢复了他那一贯满不在乎的神情，说，走吧，回去。

张小庆说，我觉得你也许可以先参加一些培训，没有地方住的话，先和我一起住。张小庆这么说完就后悔了，因为这么说表示他自己也没有信心了。

余鹏突然笑起来，张小庆的话让他放松下来，他说，走吧，又不是你找工作，怎么搞得像是我陪你找工作一样。

张小庆却认真起来，说，我可以教你编程，你再报个计算机班。

余鹏哈哈大笑，他已经放下了，他说，我可付不起家教费，这事只能说我和北京性格不合，在哪里不是一样的过，一定要在北京吗？北京确实挣得多，但我真的需要那么多钱吗？那真是我想要的吗？

张小庆却还是放不下，余鹏说，我们去买个电视吧。

张小庆一直想买个电视，这个愿望在麦迪4月26号113比111绝杀小牛后达到高峰，现在，火箭与小牛打成2比2平，第五场正在进行中。于是，两个 人出了展览馆，去了旁边的苏宁电器，一切颠倒过来，这次是余鹏手插在裤兜里走在前面，张小庆在后面慢慢的跟，余鹏的表情是轻松的，因为他已经做出决定，张 小庆的表情是黯淡的，因为他还想说服余鹏努力一把，但是却找不到甚至能够说服自己的理由，当已经不爱了，勉强在一起还有什么意义。

电视同样让张小庆失望了，最最便宜的21寸也需要一千多块，这超出他的期望太多，更让他失望的是，火箭103比106输给了小牛，比赛结束时，姚明 同样黯淡的走。如果火箭输了球，那么，买个电视同样失去了意义。两个人一起回了亦庄，在贵园南里下了车，余鹏说晚上要在张小庆这里过夜，但是这次，他也食 言了。有一辆665路经过，余鹏突然就在张小庆手里塞了个东西，然后跳上了665。

余鹏说，庆娃子，再见了，回家见。

张小庆展开手中的东西，那是一张一百元钱，他就追着那辆665，一边跑一边骂，你他妈什么意思，什么意思？！

余鹏双手插在口袋里，站在窗口，看着下边的张小庆，他本来是想请张小庆吃顿饭的，一直以来，都是张小庆请自己吃饭，这让他过意不去，但是最后他又改变主意了，他对自己说，再见，北京！

665越走越远，张小庆停下脚步，心里满是难过，不仅仅为余鹏，更是为自己，现在是余鹏，未来，会不会轮到自己。这么想着，一个人慢慢往回挪动的步 子就变得沉重起来。突然间，他看见王碧薇了，在小白羊超市的门口，王碧薇亭亭玉立的站在那里，像是在等待什么人。一会儿，一个男人走出来，手里提着一大袋 东西，男人走到王碧薇的身边，说了些什么，王碧薇突然笑起来，然后，两个人一起往这边走过来。

依旧是公司团体票，家住河北，早上5点就起床出发，这意味着我对这次QCon有着很高的期望。其实在公司时，团队一帮人就为第一天的票而争个不停，最后，我说，我住河北，于是，获胜，上午，同事南方，下午。

早上是三场专题演讲，分别是Facebook的《支撑Facebook消息处理的HBase存储系统》，Oracle的《Java EE 7平台：走进云计算》以及《在实践中实现企业的敏捷性》，最为期待的无疑是在中国并不存在的Facebook。

上台的Facebook是个年轻的小伙子，典型的闷骚性程序员，坐第三排，竟能看见他几次脸红的笑，没能引起共鸣，一个人自己笑。PPT做得不是很好，很多文字，费劲的去看，却因为近视而始终看不完。其实个人最为关心的是为什么选择HBase，它解决了什么问题，以及从Mysql切换到HBase后的相关对比数据，很显然，我失望了，除了最开始提到每月处理11TB聊天消息和14TB邮件以外，再没有看到任何数据，我现在越来越迷恋数据，当你说什么东西好的时候，对不起，请拿数据说话，不要用主观感受，不要拿什么大大提高了效率，客户很高兴之类糊弄人。介绍了Facebook的技术栈、HBase的优点以及Facebook对其的扩展，都是一带而过，没有深入；提到了对系统运行的有效监控，这也是我非常感兴趣的点，同样是一带而过；提到了Facebook采用新技术时最优先考虑的是快速上线与最小风险，有些感触，写程序一定要避免开发人员镀金与需求镀金；提到了与开源社区的有效互动。

总体感觉就是，太泛了，没有一个点能够深入，很不给力。团队内部要求做个分享，我想，我会说，很简单，打开浏览器，输入google，回车，再输入关键字Facebook加HBase，回车，好了，就是这些。

第二场是Oracle的《Java EE 7平台：走进云计算》，开始之前，周围的人都在说接下来是广告时间。还好，不是广告，但是，同样，打开浏览器，输入google，回车，再输入关键字Java EE 7，回车,好吧，也就是这些。关键词：容器、PAAS、资源与状态管理、更好的隔离性、对缓存的标准API、管理和监控、打包、版本、模块化以及各种规范。演讲的老先生让我想起了大学时的计算机老师，不管楼下风吹雨打，我自屹立岿然不动。

我想，是不是这种综合性大会决定了每个话题都不能深入？

第三场给了我惊喜，如果是在两年前。嘉宾显然比前两位有更多的演讲经验和技巧，PPT很干净、甚至还有视频，能够开些玩笑。但是，实质的东西太少，核心就是需要知道Why。我想，这个在TW已经是反复强调的原则，做任何事情都要想清楚为什么要这么做，这么做解决了什么问题，而不是直接拿一些所谓最佳实践去套，不存在最佳实践，只存在适合本项目的有效实践。我们的目标不是实施敏捷，而是对项目进行实实在在的改进，所谓敏捷，不过是个bizword,很多实践早已存在多年，现在突然全被称为了敏捷实践。说到这里，不得不再提自己对所谓Scrum认证的恶感来。

哎呀，真平淡啊，没有太多收获。但是明显感到INFOQ的组织水平提升很快，最突出的是大会茶歇时开始播放广告了，记得09的时候，还是无聊的播放维多利亚的秘密呢，当时就很诧异，这么好的广告时间竟然被浪费了。另外，大会人员也比前几届多了。但是这些人都是些什么来历呢，中午吃饭的时候，明显感到一些人是通过公司来打酱油的，不管怎样，有线的赞助商多了，交费参会的人多了，对QCon都是好事。

我在想，QCon是否能够在会前就将PPT开放出来呢，这样，不用去赌运气，南方应该就比我的运气好。

张小庆感到有点点意外，说，是吗？

王碧薇说，你猜猜是谁？

张小庆想了想，说，猜不到。

王碧薇说，再想想，你最近都碰到过哪些女孩子。

张小庆说，真不知道。

王碧薇放弃了，说，真没劲，是罗悦。

听到这个名字，张小庆想了好一阵，这才从眼前浮现出一个胖乎乎大大咧咧的女孩子来，她是和张丽合租房子的女孩，黄色的头发，烫过，上周末搬家时见过。

张小庆笑了笑，说，真的假的？

王碧薇说，当然是真的，我什么时候骗过你，是海蒂让我告诉你的。怎么样，是不是有点小兴奋？

张小庆说，没有，我不想去。

王碧薇说，哎呀，你这个人真是的，人家女孩子约你，你还不接受，哪有你这样的？

张小庆说，真不想去。

王碧薇说，可是我答应过海蒂的，你会去的。

王碧薇抓住了张小庆的软肋，张小庆犹豫了，说，这个。

王碧薇看出张小庆即将到来的妥协，她迅速换为了肯定句，说，那好，我告诉海蒂了！

于是，张小庆就没有选择了。星期五下班的时候，他给罗悦发了短信，约她周六一起去朝阳公园，他很快就收到了女孩的回信：好的！

星期六的早上，天气很好，太阳甚至好得有点晃眼睛，张小庆在贵园南里的公交车站旁等罗悦，他们约好9点见面。9点过5分，女孩子出现了，她显然打扮过了，脸蛋红扑扑的，眼睫毛黑黑的翘起，嘴唇打上了薄薄的一层唇彩，手上提着一只大大的包。

张小庆说，早。

女孩子说，早！

打过招呼，张小庆问女孩子吃没吃早饭，女孩回答说没有，于是，他们一起去了车站对面的小白羊超市，在那里，张小庆给女孩买了一袋牛奶和一袋苏打饼干，另外，还买了两瓶水。他们一起坐上了927路，车上的人不多，两个人在后排找个靠窗的座位坐下。张小庆显得有些拘束，他不知道该说点什么好，也不知道该如何开始，反倒是女孩显得很大方，问些张小庆之前的学校，哪里人，现在的工作。在小红门，他们下了车，要去倒625路，这次，等车的人很多，车来了，没有排队，一起往上挤，张小庆在前面，女孩在后面跟着，没有座位，两个人在拥挤的过道里站着，随着汽车的启动加速减速刹车而有规律的摇摆。05年的四环，还没有多少车，625行驶的很快，车窗外，吐出新芽的树木们像一帧帧的彩色电影胶片向后滑动，张小庆抓住头顶上的扶杆，女孩抓住车座背后的扶手，车厢里很嘈杂，这让张小庆舒出一口气，不用刻意找些话题，可以什么都不说，说了也听不清，静下来，专心看窗外的电影胶片。

下车的时候，张小庆又看见了他曾面试过的那家公司，那幢独立的三层小楼依旧漂亮的立在那里，没有说话。张小庆想，如果当初这家公司录用了自己，那会是一种怎样的情形。也许自己此刻正窝在地下室里看书，也许自己此刻正在公司加班，也许自己此刻写代码有些累了，正透过巨大的落地窗户向朝阳公园张望。谁知道呢，生活就是这样，充满未知，因为未知，再加上希望，生活就变得朝气蓬勃起来。

张小庆去售票处买了票，两个人就进入了公园。朝阳公园真大，因为春天，格外美丽，所有的小草都绿了，旁边，小草告诉你：正在成长，请勿打扰。两个人一起去坐了升降天梯，在最高处，张小庆看见了整座城市；两个人一起去坐了过山车，张小庆是第一次坐，有那么一瞬间，他感到自己的心脏像要跳出来；两个人一起经过了一块足球场，里面，一个男孩子刚进了一粒漂亮的远射，咆哮，和他的伙伴们热烈拥抱在一起，让张小庆想起了巴蒂斯图塔；最后，两个人沿着河岸慢慢的走。

依旧是女孩先问问题，接下去是张小庆回答，最后，女孩再介绍自己。一问一答中，张小庆知道女孩是东北人，也是去年毕业，现在在一家外贸公司里当总经理秘书，一个月2000块钱。女孩也问了张小庆的工作和将来的打算，张小庆回答说要好好做技术，将来去IBM和微软。女孩还问了张小庆是否喜欢看书和看电影，张小庆回答说很喜欢，最喜欢的是余华和活着。问答中，女孩没有提到房子。05年的时候，所有的年轻人都不认为房子会是个问题，如果在工作的城市连房子都买不起，那，还混个屁！这是张小庆当时的想法，他不会知道，仅仅一年过后，所有女孩子们约会的第一个问题就是房子，而房子，将成为未结婚的男人人生中一个最大的问题。最后，话题转移到了喝酒上。

女孩说，你们那边喝酒吗？

张小庆说，喝。

女孩说，我爸爸特别喜欢喝酒，每年他都会自己买些葡萄，自己酿葡萄酒，两大桶，酸酸的甜甜的，非常好喝。每次回家我都会喝好多。你们那边都喝什么酒？

张小庆说，我们那边喝米酒，自己买酒曲就能做，非常好喝。

女孩说，我爸爸也喜欢喝白酒，每天吃饭都要喝一点。我有时候也偷喝一点，哈哈。对了，你喝酒吗？

张小庆说，我不喝。

女孩说，噢。

从公园出来已经是下午一点，两个人去了公园对面的肯德基，人很多，排了好一会队，很奇怪，真正吃到嘴里，张小庆感到比想象中的差去很远，甚至比电视里都差去很远。当你向往一个东西的时候，你会把它想象的过于美好，而当你得到它的时候，你却习以为常，认为不过如此，直到你失去。

两个人最后在贵园南里公交车站分了手，女孩说，谢谢你今天陪我去朝阳公园，再见。张小庆说，再见。

真的就再见了。星期一的早上，张小庆感到了王碧薇眼神的异样。王碧薇说，迈克，周六的约会怎么样？张小庆说，挺好的。接着，张小庆就看到了王碧薇的异样，那是种想笑又竭力憋住的异样。中午吃饭的时候，王碧薇和张丽坐在一起，她们不知道在说些什么，一边说一边向张小庆这边看，看完了还神秘的笑，张小庆隐约感觉到了什么。下班的时候，他叫住了王碧薇，问是不是罗悦说了些什么，王碧薇说没有，但张小庆坚持问，最后，王碧薇告诉他，你是不是忘记帮女孩子拿包了？

张小庆想起来，那个早上，女孩提了一只硕大的包，他甚至觉得个子不高的女孩和那只包搭配在一起有一点点的比例失调。女孩提着那只硕大的包和他一起挤了公交车，在摇摆的公交车上，她一只手紧紧抓住车座背后的扶手，一只手紧紧抓住她的包，想到这里，张小庆的脸红了；女孩提着那只硕大的包和他一起坐了升降天梯，天梯上升的时候，她一只手紧紧抓住天梯的扶手，一只手紧紧抓住她的包，想到这里，张小庆的脖子也跟着红了；女孩提着那只硕大的包和他一起坐了过山车，过山车下落的时候，她一只手紧紧抓住过山车的扶手，一只手紧紧抓住她的包，想到这里，汗从张小庆的脸上渗出来；女孩提着那只硕大的包和他一起经过了足球场，进球的时候，她的高跟鞋正在路上绊了一下，她下意识紧紧的抓住了她的包，想到这里，张小庆大汗淋漓；甚至，在肯德基吃饭的时候，女孩也紧紧抓住她的包和她一起进了并不硕大的厕所，想到这里，张小庆啊了一声昏厥过去。

王碧薇说的非常委婉，但张小庆显然受到了巨大的打击，他想找点水喝，同时，他想告诉王碧薇，不是忘记，是根本都没有意识到，他也曾经犹豫了一下，但是，他想，包里可能有女孩非常私人的东西，也许并不方便。王碧薇感觉到了张小庆的创伤，她决定帮助他，于是，她说，其实也不是这个，主要还是你不会喝酒。这个理由让张小庆多少感觉好过了点。王碧薇还不放心，说，要不要我陪你走走？张小庆说，不用了，谢谢，我想回家。

受到打击的张小庆、忘记拿包的张小庆、大汗淋漓的张小庆，没有回家，他去了网吧，在那里，他在论坛发了贴，但是，很快，他受到了程序员们的打击，他被定了性，根本就不懂得关心人。这个定性让整个事情有了向人性挖掘的可喜变化，人类真伟大，人性真简单，因为定性是如此的容易，就像打个标签，绿色、环保、低碳、吐把口水就可以。

关键时候，是王娓娓和余鹏拯救了他。听完张小庆的叙述，王娓娓哈哈大笑，说，就这么大点事啊！

张小庆说，是不是件大事，但是，这说明我根本就不懂得关心人。

余鹏说，狗屁逻辑！

王娓娓说，刚开始都是这样的，没有谁天生就知道如何关心女孩子的。当然，这是最基本的，要帮女孩子拿包，要随身带着面巾纸。下次就知道啦。

余鹏说，我他妈最烦的就是为人定性的，作业没写完就是不爱学习的，批评就是反对的，买日本货就是不爱国的，上访就是精神病的。

张小庆说，可是，我觉得他们说的也有一些道理。

余鹏说，我靠，你自己也信了，真扯淡。你还真拿别人的话来解释自己？！

王娓娓说，你对那个女孩子有感觉吗？

张小庆说，没有。

王娓娓说，那为什么约会？

这个问题让张小庆很难回答，他总不能说是因为王碧薇答应别人而自己又不好拒绝王碧薇吧。张小庆说，这个很难回答。

王娓娓说，其实没有感觉就好，你也没有失去什么，就当是一次学习吧。

说这话的时候，三个人正坐在王娓娓租的屋子里吃饭。王娓娓自己做了饭，西红柿炒鸡蛋、可乐鸡翅、胡萝卜瘦肉和清炒绿豆芽，张小庆和余鹏打了下手，本来是胡萝卜炒肉丝的，张小庆将肉丝切得和心情一样厚重，结果就变成了胡萝卜炖肉块。

吃完饭，三个人一起去了安贞华联，旁边的，服装市场。整个市场被无数五六平方的小铺子分隔开来，在这里，你总是可以看到当下最流行的款式。王娓娓告诉张小庆至少要对半砍价，夏天要来了，张小庆看中了一套耐克的短袖短裤，老板要价50，张小庆说，25。

老板说，同样的衣服，你去华联看看，至少要200。

张小庆说，可人家是真的，而你是山寨的。

老板说，兄弟，其实质量差不太多，不要迷恋哥，40。

张小庆还想划价，他努力找出个线头，说，看，这有个线头。

张小庆话音还没来得及落下，老板已经转身抽出剪刀咔嚓将线头剪去了，速度之快让张小庆甚至没有看清他是如何出刀的。老板说，好了，没了，30。

于是30成交，王娓娓买了条裙子，余鹏打了酱油。张小庆和余鹏向东，王娓娓向西，张小庆和余鹏向东坐了957，王娓娓向西坐了957。其实张小庆他们还可以坐300，但是300太恐怖。汽车开到成寿寺，余鹏突然说，我要回家了。

张小庆没有听清，说，什么？

余鹏说，我要回老家了。说这话的时候，他一只手搭在公交车扶杆上，一只手插在裤兜里，非常平静，依旧是那副满不在乎的神情。

     摘要: 张小庆说，苏珊！ 王碧薇看见张小庆了，她好看的毛毛眼笑起来，说，你搬家了吗？ 张小庆说，是啊，刚搬过来，好巧啊。 王碧薇说，哈哈，太好了，有晚饭吃了！ 于是，下班的时候，张小庆、王碧薇和张丽再次去了贵园北里旁边的那家餐馆里，张小庆请客。王碧薇点了地三鲜，张小庆点了鱼香肉丝，张丽点了清炒空心菜。吃饭的时候，王碧薇说，迈克，这个周六海蒂要搬家，你也过来帮忙吧。这话让张小庆没有办...  阅读全文

     星期六的早晨，张小庆一大早就乘车去了中关村海龙大厦，他是愉悦的，甚至带一点点骄傲。他骄傲的走在城市形形色色或匆忙或迷茫的人群中；他骄傲的对卖MP3的小姑娘说，我就要这个，那是一个399元的爱国者；他骄傲的在摇摆的公交车上给王娓娓和余鹏分别打了电话，他对王娓娓说，娓娓姐，来吃饭吧，他对余鹏说，快来给我搬家，早点过来；他骄傲的在邮局工作人员的注视下将MP3小心翼翼的装进包裹并添上自己的名字。做完这一切，他感到全身轻松，他给他妹妹打了电话，他能想到妹妹在同学当中使用这只MP3时同学们羡慕的表情，这个表情让他感到了满足，然后他返回了鹿圈，开始收拾明天搬家的东西。

    隔壁年轻的妈妈看见张小庆收拾东西了，她说，要搬家？

    张小庆骄傲的说，是啊。

    妈妈说，搬到哪儿？

    张小庆说，河那边。

    妈妈笑起来，说，不错，我要去菜市场，你要不要去买点东西？

    于是，张小庆，妈妈，妈妈的小女儿一起去了鹿圈的菜市场。妈妈帮张小庆仔细挑了做饭用的蒸锅、炒菜用的铁锅、锅铲以及洗菜的塑料盆，这些东西亮晶晶的，闪闪发亮。妈妈像给自己买东西一样为了几块钱与店主争的面红耳赤，这让张小庆有点不好意思起来。最后张小庆还红着脸问了妈妈，这蒸锅能做饭吗？妈妈说，可以，用碗淘小半碗米，一蒸就可以。

    余鹏周日来得果然就很早，张小庆说，这都8点了你才来，余鹏说，我靠，你也不看看我住哪儿，你以为我住你隔壁啊，说话间两个人一起把被褥打了包。张小庆以为没有多少东西，他想到了一个月前，自己一个编织袋就将这一切拖了来，但现在，多了两只手，才能勉强避免跑两趟。张小庆一只手扛着包，一只手提了水瓶，余鹏拿了盆，盆里乱七八糟的放了很多东西，两个人出了门，张小庆走在前面，走得很快，余鹏照旧是不紧不慢的跟在后边，有好几次，张小庆回过头，埋怨余鹏走得太慢，余鹏反驳说，我拉下了吗？

    到了贵园南里，汤姆还没起床，他睡眼婆娑的开了门，说好早啊。两个人进了门，开始归置东西，汤姆开始起床刷牙。说是归置东西，其实也没有什么东西可以归置，把褥子在床上铺好，编织袋塞到床底下，锅碗瓢盆放进厨房，背包挂在门后的钉子上，其余的往桌子上一摆，这就好了。汤姆给了张小庆钥匙，两个人又去了小白羊超市，买了油盐酱醋，最后，张小庆在雀巢咖啡的货架前停了下来，他想起了大学时对雀巢咖啡的迷恋，一块钱一小袋，一直舍不得买，这次，他想到犒劳自己的方法了，每次发完工资，就买一种大学时想吃又舍不得吃的东西，不仅要买，而且要买大盒的，要一次吃个够，把以前落下的补回来。于是，张小庆拿了一大盒的雀巢咖啡，但是在拿之前，他还是犹豫了一下，最后拿了一盒促销装。出了超市，王娓娓也就到了，三个人一起回了家。

    汤姆没有料到王娓娓的出现，其时他正在享受他的早饭，早饭是一袋康师傅方便面。主卧的房间门大开着，被子保留着主人刚起床时的凌乱样；书桌上，一本本的专业的非专业的书横七竖八了无生气的躺着，最内侧，是两大包康师傅的实惠装，都打开了；地上，很久没有打扫过了，厚厚的灰尘，还有两团蜷缩成一团的卫生纸；阳台上，一周的衣服侵染在一只红色的塑料桶里，微微向空气中弥漫些细微的味道。张小庆打开门的一瞬间，汤姆正在把缸子里的面条往口中送，因为有点烫，汗珠从他的脸上微微渗出来了，头发搭上汗珠凌乱的贴在前额上，见到张小庆身后的王娓娓，面条有那么一瞬间在他的嘴中僵硬住了，和他脸上的表情一样，措手不及。

    汤姆说，这是？

    张小庆说，这是我的师姐，王娓娓。

    汤姆说，你好，我是张小庆的同事，我叫张和。

    没等王娓娓回答，汤姆迅速转身和他的方便面一起回了他的房间，房间门被立刻合上了。五分钟过后，房间门打开，一切都发生了惊人的变化：被子被叠好了，床单被使劲扯过了，床铺变得平平整整；书桌上的书们恢复了次序，从上到下，从小到大，整整齐齐，大包的方便面不见了，被扔进了抽屉，关起来；地被打扫过了，虽然依旧算不上干净，但是两团抱团的卫生纸不见了；阳台上，红色的塑料桶被盖上了盖。张小庆看到，汤姆的头发也被打理过了，一边向左一边向右，不再无精打采的趴在前额，他还换了件衣服，将刚才的秋衣换成了衬衣。

    汤姆显然是从刚才紧张的情绪中释放出来了，他说话的语速不再那么快，他说，不好意思，房间有点乱，刚才还没来得及收拾。

    王娓娓说，张小庆是我的师弟，刚参加工作，还需要麻烦你多帮助他啊。

    汤姆说，没事，没事，那是肯定的。

    王娓娓说，张小庆，你都收拾好了吗，我帮你收拾收拾吧。

    张小庆说，都收拾好了，没什么可收拾的了。

    但张小庆很快发现了女人和男人观察世界视角的不同。王娓娓发现了房间顶角的两个蜘蛛网，她让张小庆用扫把把它们拭去了；她发现了窗户夹缝里众多的灰尘，她自己用抹布仔细的都擦去了；她发现了张小庆刚摆好的桌子是如此的凌乱，水杯、牙缸、热得快、饭缸、书籍，胡乱的混搭在一起，尽管摆的整整齐齐，但是用起来是那么的不顺手，她帮张小庆重新规整了桌子。最后，她来到了厨房，厨房显然是刚刚被汤姆打扫过了，灶台上不再有方便面沫和鸡蛋壳屑，锅被洗过了，挂在墙上正向下滴滴答答滴着水，连灶台角垃圾桶中的垃圾袋也被换过了。但王娓娓很快让张小庆有了新发现，她让张小庆拿来了清洁球和洗涤灵，使劲一擦，原本褐色的灶台露出了丝白色的脸，啊，灶台原来是白色的啊，张小庆吃惊的想，还有，抽油烟机，原本也是白色的，还有，汤姆的脸原本也是白色的，但此时，它再次因为紧张而染得通红。汤姆说，我来，我来。

    到了中午，三个人要去外边吃饭，他们热情的邀请了汤姆，但汤姆不肯去，他说，我有点事，就不去了。张小庆说，有什么事比吃饭还重要吗？汤姆瞅一眼王娓娓，说，真有事，真不去了。于是三个人来到了小区旁边的福华肥牛，饭馆是张小庆找的，他并不知道肥牛的意思，他只是知道，这是一座三层的饭馆，很大，很大就会很上档次。

    于是，在肥牛饭馆里，张小庆叫了肥牛服务员，张小庆对肥牛服务员说，来份羊蝎子！从周扬那里，张小庆知道，羊蝎子和水煮鱼是今年最火的两道菜。

    肥牛服务员面露了难色，小声提醒说，我们是肥牛。

    张小庆并不明白，王娓娓笑了起来，说，这里只有火锅。

    于是，大大的炭火火锅端上来，色彩鲜红的肥牛端上来，绿色油油的茼蒿端上来，三个人边吃边聊。与上次见面相比，东道主发生了变化，由王娓娓变成了张小庆，张小庆很享受这种变化，他不停的问，要不要再加点菜。余鹏依旧是懒懒的，他坐在那里，不提出话题，只是回答，他的工作没有进展，依然没有找到客户。张小庆说，这不是家真正的软件公司，我明年要去一家真正的软件公司，目标不变，微软和IBM。

    吃着吃着，热起来，张小庆脱去了外套，里面是他前不久在菜市场买的白色衬衣，扎在他黑色的裤子里，白领嘛，自然是要穿白衬衣的。接下来的事情就很戏剧性了，在张小庆去卫生间穿过长长过道的时候，有人叫住了他：服务员，点菜！最开始张小庆并未在意，但是当那个人再次叫了服务员并且周围并没有其他人时，张小庆意识到，完了，自己被当成服务员了。张小庆尴尬的说，我不是服务员！说完，加快了行走的步伐，同时，迅速的将衬衣从裤子里拉出来。

    晚上的时候，汤姆对张小庆说，你师姐来也不通知我一声。

    张小庆说，你也没有告诉我要通知你啊。

    汤姆说，你师姐是做什么的？

    张小庆说，她在这边做导游。

    汤姆说，她是几几年的？

    张小庆说，79年的，哎，你是不是对她有兴趣啊？

    汤姆说，没有，没有，别乱说，我只是问问。

    汤姆的午饭和晚饭都是方便面，在厨房刷牙的时候，张小庆发现垃圾桶里躺着四个方便面袋子和两个蛋壳，同时，张小庆看见，那两大包方便面重新出现在汤姆的书桌上。洗完澡，张小庆躺上床，偎依在床角，看书，他买了本犀牛书-Java  script  权威指南。汤姆也坐在他的桌子旁，看书，两个人都没有电视，也没有电脑，夜晚由此显得安静，只剩电棒发出孤独的滋滋声以及偶尔翻动的纸张的声音，像极了高中的晚自习。

    哎呀，张小庆突然想起来，走的时候，他还没有给房东电费。这个问题扰乱了他的心境，他决定下个周末再回鹿圈一趟。

    张小庆贵园南里的生活正式开始了。和鹿圈相比，他离公司更近了，步行只需不到十分钟，9点上班，每天早晨8点30准时起床，十分钟洗漱，下楼，在小区门口买个鸡蛋灌饼，边走边吃，8点50，他的机器已经开始工作。最开始的时候，他还叫汤姆一起起床，后来汤姆说，不用叫他了，他8点45起床。晚上6点下班，他会先去买份北京晚报，迅速翻到最后一页，姚明的球队在那一页正为季后赛努力，有时候，他会买点馒头回家煮点稀饭，有时候，他会买点面条，更懒的时候，就买张大饼，喝点水都能吃下去，汤姆的晚饭一成不变，变的是牌子和口味，康师傅、统一、今麦郎和白象，牛肉味、番茄味、炖鸡味和麻辣味。周末的时候，张小庆会去菜市场，他买了莲藕和排骨，莲藕炖排骨，家乡菜，多放点水，可以吃两天，有了这道菜，就可以试着焖点米饭了。

    这天早上，张小庆晚起了5分钟，不过不用着急，不会迟到，他像往常一样，去了小区门口买鸡蛋灌饼。搬过来唯一让他觉得不方便的是早餐，没有选择，鸡蛋灌饼、鸡蛋灌饼、还是鸡蛋灌饼，没有油条，没有豆浆，也没有咸菜。当然，也可以稍微跑远一点，那里有个北京早餐，张小庆去过一次，然后就决定再也不去了，一个包子竟然要8毛钱，而且巨难吃，是那种刚吃第一口就决定放弃的包子。在灌饼摊旁边，他看见王碧薇了！她也在那里等待买灌饼。

      如果一天是前一天的重复，一周是前一周的复制，那么日子将过得滞黏，没有惊喜，没有期待，也没有活气。对张小庆来说，第一个月的每一刻都是崭新的。他实现了菜单树，建立了第一张MySQL数据库表，尝试了一把Lucene，尽管没有找到合适的中文分词；他在Jdon围观了彭晨阳与范凯的巨幅吵架帖，牛人就是牛人，吵架都是那么牛逼闪闪，火星四溅；他还兼职了一周的网管，原来的网管离职了，人们理所当然的认为程序员什么都会，于是张小庆就经常满脸通红的在各个工位和各种莫名其妙的电脑问题间奔波，他满脸通红是因为他也不会，他会说，等等，我要查查，然后飞快的跑回座位进行Google，然后将结果抄在本子上，再疲于奔命的奔回来，好了，我来看看。

      周五的下午，临近下班，随着时钟的跳动，张小庆的心跳也逐渐加快，因为他要去赶368路，他要去周扬那儿，他要和他的兄弟一起吃饭、吹牛和打牌。他的黑色挎包里也第一次装上了东西，装了要换洗的一套干净衣服，他要去周扬那儿洗澡，周扬的工厂提供热水，两个水桶，一个水桶是漫漫的热水，一个水桶是小半桶冷水，提进厕所，关上门，脱掉衣服，对热水，用毛巾快速的擦。厕所是男女不分的，三个坑，经常是洗着洗着隔壁传来一阵满脸通红的挣扎声，一会儿，挣扎戛然而止，接下去就是什么东西落到水里的声音，有些时候，挣扎的时间过长，让张小庆都跟着着急，他真想拉开门，走过去，说，哥们，你应该多吃点蔬菜。

      这天，周扬给张小庆介绍了他的表妹，女孩子叫周燕，纤细的眉毛，纤细的脸，一身纤细的坐在那里，见到张小庆，眉毛低低的纤细的笑。周扬说，我表妹，刚来的，学做牙齿。

      吃完饭照例是打牌，斗地主，在周扬昏暗的地下室里，张小庆、周扬和周扬同样年轻的同事，一毛钱起抓，炸弹翻番，五毛封顶。张小庆买了袋瓜子，周扬把电视打开，那是老乡送给他的，屏幕巴掌大小，黑白，天线坏了，用根铁丝插着，只能收到中央一台，三个人开始抓牌、嗑瓜子和不时的拍拍没有图像的电视。这个晚上张小庆的运气很好，连续抓了三把大小猫，炸了三炸，他面前的纸币很快堆得像小山一样。凌晨两点的时候，他们结束了打牌，周扬同事回了自己的房间，张小庆和周扬走出地面透透气，张小庆点了点赢了多少钱，一共是十七张纸币和十个硬币，两块七毛钱，张小庆想，真是个愉快的晚上。两个人去小卖铺买包烟，月亮很大，从小店回来的时候，能清晰的看见自己贴在地上的身影，北京春天的晚上还是很凉的，张小庆吸了吸鼻子，看见周扬在冲自己笑。

      张小庆说，你笑什么？

     周扬从口袋里掏出部手机，说，你看这个。

     张小庆张大了嘴，我靠！诺基亚3250！

     其时正是诺基亚3250和诺基亚牛逼的时候，3250躺在电视里、躺在横幅里、躺在彩页里、躺在周扬的嘴里，充溢满这个城市。

     张小庆说，多少钱？

     周扬说，三千六百多。

     张小庆说，有钱人啊！

     周扬说，有钱个屁，我半年的工资！

     张小庆说，我日，那还买？

     周扬说，我就这点爱好，人活着总得满足自己一两个爱好吧，要不岂不白活。张小庆知道他的第二个爱好是他的分头。

     第二天，周扬去送货，张小庆去了公主坟电子工业出版社的地下书城，在那里，有几个柜台，专卖计算机书籍，张小庆会在那里呆上一整天，直到天黑。张小庆特别喜欢到一家店主是老奶奶的书店，老奶奶从来都不会催这个只看不买的年轻人，相反，她每次看到张小庆，总会点点头，说，来啦，时间长了，她还会告诉张小庆，这里有凳子，坐着看。这让张小庆感到了不好意思，他的脸红了，不自在，于是，在第二天再来的时候，他总会买上一本书。他买过《21天学通Java》，很遗憾，第21天的时候，他失败了；他买过《Java编程宝典》，国人原创，电力出版社，很遗憾，全书三分之二全是代码，越看越像葵花宝典；他买过《Java应用开发指南》，Jdon彭晨阳作品，神一样的男子，很遗憾，附属光盘里的代码全是片段，没有一个能够神奇的跑起来。

      周日下午，张小庆重新背上他的挎包，回家，回亦庄。在368上，他给一个老奶奶让了座，每次让完座，张小庆总会离让出的位置远远的，因为站在一个说谢谢你的人的旁边，让他感到不自在。回到大蒜屋，打开房门，打开灯，把衣服从挎包里取出来，扔进脸盆，到门外水龙头接上水，洗衣服。张小庆想，等这个月发了工资，就换到桥那边去，找个楼房。

      王碧薇找到房子了，在贵园北里，三居室，三个女孩合租。下班的时候，她叫了张小庆，走，请你吃饭。

      张小庆说，为什么啊？

      王碧薇说，我找到房子了。

      张小庆说，我也没帮上什么忙。

      王碧薇说，你就说，去不去吧。

      于是，张小庆、王碧薇和张丽一起去了贵园北里旁边的一家餐馆里，张丽和王碧薇同一天入职，是个安静的女孩子。餐馆不大，但是很整洁，服务员穿着统一的上衣，有人吃完饭，马上就会有人上去将餐具收拾干净，做好一道菜，厨师会拉响窗口的铃铛，服务员就会过去将热气腾腾的菜端出来。他们靠着窗户坐下，王碧薇将菜单递给张小庆，说，点菜。张小庆说，我不会点，还是你点吧。王碧薇将菜单拿回来，打开，说，哎呀，还担心你点贵了呢，这下放心了。王碧薇点了个地三鲜，她还是问了张小庆，你吃什么。张小庆说，随便。王碧薇问了站在身边的服务员，这里有随便吗？服务员说，没有。于是她对张小庆说，没有，换一个。这下张小庆的脸果然就如她期望的那般红了，说，那就来个青椒肉丝吧。张丽点了清炒油麦菜。等菜的空儿，三个人聊起来，王碧薇说，我最喜欢吃地三鲜了，一道菜吃到三种菜，合算。张小庆说，我什么都行。张丽说，我喜欢带叶的菜。王碧薇说，迈克，你是刚毕业的吗？张小庆说，是啊。王碧薇说，那你和张丽一样，她也是刚毕业的。张小庆说，你呢？王碧薇说，保密。

      一会儿，地三鲜先端上来，放了些西红柿，颜色顿时香起来，煞是生动。张小庆坐在那里，等着王碧薇和张丽先动筷子。王碧薇看看张小庆，笑了笑，说，还等谁呢，开动啦。

      吃完饭，王碧薇要去贵园北里，张丽要去贵园南里南区，张小庆要去鹿圈，三个人就此分手。王碧薇突然问了张小庆，迈克，你为什么总背个包啊，里面装什么东西了吗？张小庆措手不及，一时不知道该怎么回答才好，总不能说这样看起来像白领吧，他就那样愣在那里，支支吾吾不出来。王碧薇说，哈，我知道了，我刚上班时也这样。张丽在旁边眯起眼睛慢慢笑起来。

      张小庆没有马上回鹿圈，他去了富源里小区，昨天下班时他在电线杆上看到了出租信息，300块钱一个月。房子在顶层，张小庆爬上9楼敲开门，他大开了眼界，100多平米的房子里竟然住了有十来个人，全部是高低床，还有在地上打地铺的。从小区出来，张小庆反复对自己说，便宜没好货，便宜没好货，便宜没好货，靠，便宜没好货。

      是汤姆最后帮助了他，汤姆是个白白净净的年轻人，个子不高，带一副眼睛，是公司的翻译项目经理，研究生毕业。汤姆刚好在找人合租贵园南里的房子，他和张小庆聊起来，两个人发现，他们还是老乡，这拉近了两个人的关系。下班之后，张小庆跟着汤姆去了他租的房子，这是一间小两居，六层中的第五层，汤姆住大间，张小庆住小间，这小间确实足够小，因为原本是作餐厅的。汤姆说这房子是个老太太的，老太太是这里的农民，拆迁之后在这个小区分得了三套房子，自己住一套，往外租两套。这套房子的价格是每个月950块钱，如果没有意见的话，他出500，张小庆出450，包物业和取暖，水电单算平分，因为小间没有家具，张小庆的衣服可以放在大间的衣柜里。张小庆非常满意，他坐了坐小间里的单人床，非常好，非常稳，坐上去不会发出吱吱的声音，也没有让人突然陷下去的大窟窿，而且，房间里还有一张餐桌可以当书桌使用；他去看了厨房，管道煤气，尽管燃气灶上糊了厚厚的一层油渍，旁边还有残留下来的方便面沫和鸡蛋壳屑，但不影响使用；他去看了厕所，终于不用在大庭广众之下露出屁股了，有插电的热水器，也不用一边洗澡一边倾听隔壁的挣扎声和落水声了。张小庆几乎是不假思索的马上决定搬过来住，他和汤姆说好，这个月底发了工资就搬过来。汤姆也很高兴，他给他的老乡煮了一碗方便面，打了一个鸡蛋，吃完后又强烈挽留老乡在他那儿洗了个热水澡。从汤姆家出来，张小庆的整个身子都清爽了，不是洗澡的缘故，他走得很带劲，甚至都哼起不着调的歌来，走过凉水桥的时候，他想，再过几天，就再也不用到这边来了，这真令人高兴。

      第二天早晨上班的时候，走出门，张小庆突然想起点什么，他想起了王碧薇那双笑成一条缝的毛毛眼，于是，他返回去，将挎包放下，这才重新出了门。

      发工资了，张小庆这个月少上了2天班，发了1988块6毛，和他预想的差了一点点，不过这并不影响他的心情，他将工资卷起来装进自己的裤子口袋，厚厚的一叠，在大腿上鼓起一块，很有成就感。更让他感到高兴的是，比尔找了他，对他这个月的工作很满意，决定提前转正，工资从下个月开始涨到3000块。对程序员来说，能够得到工作的肯定，是一件幸福的事情，最怕的是，经理只会分配任务，从不知道有与手下私下沟通这回事。

      1988块6毛，能干些什么呢？首先是要付新房租，要搬家，恩，这是最重要的；其次是请王娓娓和余鹏吃饭，这是说好了的，让余鹏过来替自己搬东西；还有，要给妹妹买台MP3，自己答应过要给她一个惊喜的；最后，扣掉生活费，应该还能剩500块，去银行办张银行卡。事真多啊，张小庆想，但是每一件都是那么让人愉快，对了，还应该好好犒劳一下自己，怎么犒劳呢？还得想想。

张小庆的第一个任务是实现一棵菜单树，比尔没有限定时间，他给了张小庆一个地址，告诉他可以参考他们的实现。这是金蝶上次来公司做售前安装的ERP试用版本，同一时间只允许一个用户在线。从此以后，张小庆和比尔将无数次的访问该ERP以及辛苦的查找其对应的源文件，有很多次，比尔打开ERP的某个页面，然后告诉张小庆，我们需要这样的一个功能；又有很多次，比尔打开ERP的某个页面，然后告诉张小庆，看，这里有个类似实现，找找他们的源文件。当然，在张小庆每次访问ERP之前，他都得记得对比尔说，比尔，你在用吗，我要ERP。如果忘记的话，比尔的桌面上将华丽的弹出一个警告框同时强迫比尔下线，这应该是该ERP实现最酷的部分了，张小庆想。

找源文件是一件苦力活，同样是JSP加JavaBean，金蝶的工程师应该都是警察出身，上千个JSP，一个JSP嵌套一个JSP，一个JSP再引入另外一个JSP，JSP们也玩躲猫猫。终于，张小庆在一个几百行的JSP里艰难找到了一行Java  script  代码：XTree tree = new XTree()。在这个简短的JSP里爬满了注释：xxx增加于xxxx年xx月xx日，华丽的分割线；xxx修改于xxxx年xx月xx日，又一条华丽的分割线。不管怎么说，找到了，张小庆长长嘘出一口气，过段时间看自己写过的代码都是一种痛苦，更别说看别人的代码了，除了煎熬张小庆实在想不出更合适的词。

张小庆搜索了XTree并访问了其网站，很快，他就被作者强大的Java  script  编程能力所折服了，强大的页面JS组件，以前从未见过的超酷的动态效果，新鲜的好听的名字DHTML，最最重要的是：这些Java  script  代码张小庆能看懂的不超过10行。张小庆被彻底打倒了，真他妈酷，张小庆想，在他印象里， Java  script  只是实现一些辅助的页面效果和简单的校验使用，但现在，XTree给他打开了一扇新的窗户，他重新搜索了DHTML，这次，Google给他打开了一扇大门。

吃午饭的时候，张小庆问了比尔：为什么金蝶卖的这么贵？

比尔说，因为它叫ERP。

张小庆说，这么贵有人买吗？

比尔笑了笑，说，所以你我才有机会坐到这里。

吃完饭，张小庆接到了余鹏打来的电话，余鹏说，庆娃子，在哪儿呢？

张小庆说，鹏娃子，我上班呢，你哪儿呢？

余鹏说，在亦庄呢，没吃午饭，快饿死了，快请我吃饭！

张小庆和余鹏是死党，他们是同一所学校老师的孩子，余鹏之所以来北京，用他自己的话讲，全是张小庆忽悠的。正月初三的早上，张小庆去余鹏家找了他，其时余鹏刚刚奋战完一个通宵的麻将睡下没多久。

张小庆说，我靠，还睡呢！

余鹏说，这么好的天气不睡觉做什么？说这话的时候，他正懒懒的躺在床上打了个长长的哈欠，眼睛都没有睁开，眼角上挂满了刚刚分泌出的新鲜眼屎。

张小庆说，别睡了，去北京吧。

余鹏翻了个身，背对着了张小庆，说，去北京干鸟？

张小庆说，找北京的工作，买北京的房，谈北京的老婆，生北京的娃。

余鹏对张小庆的提议并不感兴趣，因为回答张小庆的是他忽高忽低的鼾声，这让张小庆很生气，于是他上前一把扯掉了余鹏的被子，他知道余鹏的习惯，这是个睡觉不穿衣服的家伙，再加上南方没有暖气，余鹏果然就如同他期望的那样从床上白花花的弹起来。

余鹏说，大哥，会感冒的。

张小庆说，我知道。

余鹏说，感冒会发烧的。

张小庆说，我知道。

余鹏说，发烧会很难过的。

张小庆说，这个我也知道。

余鹏说，知道还不把被子还给我？

张小庆说，又不是我感冒。

两个人终于在床边有些认真的扯淡起来。张小庆知道，他面前的余鹏已经是小余老师，余鹏读的是师专，比张小庆早毕业一年，毕业之后就回到他们的镇上学校教历史和政治，也算是子承父业。此时的张小庆，对未来充满足够的热情，尽管没有去过北京，但是他对这座城市时常荡漾着首都的朴素情感，他坚信，他的未来不是梦，而在这座遥远的城市里，有着他的梦。他竭力的鼓动余鹏，走吧，一起去北京。余鹏反复在问同一个问题，为什么要去北京。张小庆说，北京是首都，余鹏说，这不是理由；张小庆说，北京发展机会多，余鹏说，太抽象；张小庆说，北京挣得多，余鹏说，消费多；张小庆说，北京漂亮姑娘多，余鹏说，只有看的份；张小庆说，王娓娓在北京，余鹏说，这勉强算一个理由；张小庆说，你不去我会想你的，余鹏说，好吧，这听起来好像有点靠谱了。

过了两天，张小庆和余鹏一起去了王娓娓家，王娓娓和他们也是同一个学校院子的，大他们两届，一毕业就在北京工作，从余鹏家到王娓娓家不过十来步的距离。王娓娓热情的接待了他们，他们在沙发上坐下，王娓娓的父母王老师和黄老师端来了热水和点心，三个人一边嗑瓜子一边愉快的聊天，电视里，正在播放陈红主演的《纽约风暴》。张小庆详细问了王娓娓在北京的工作和生活情况，回答是让张小庆满意的，没有想象中的那么好，当然，也没有想象中的那么糟，只要找到工作，工作努力，踏踏实实，那么两年三年的过去，会越来越好，买个房，谈个朋友，结婚，生活似乎是一条坦途，闲暇的时候，可以去看看电影，看看演出，北京有着很多著名和不著名的景点，这些，都是北京所有魅力的一部分。王娓娓问了张小庆和余鹏的想法，张小庆说先要找到工作，余鹏说还没有想好。最后，告别时，张小庆突然问了王娓娓电视里那个漂亮女主角结婚没老公是谁，王娓娓说接了是陈凯歌，张小庆叹口气，说又是老牛吃嫩草。张小庆和王娓娓约定好了，说北京见，余鹏没有表态，他还是需要个理由。

余鹏的理由来得比张小庆的车票早，张小庆刚在周扬的地下室里蹲了一天，还没开始找工作，余鹏就来了电话，他在电话里得意的哈哈大笑：庆娃子，猜猜我在哪儿，我已经到北京上班了。张小庆急急的说，你在哪儿？什么时候来得？什么工作？余鹏故意调张小庆的胃口，说，见面说。张小庆说，靠。于是张小庆余鹏王娓娓再一次见面了，这次是在北京，一个星期天，王娓娓休息。张小庆和余鹏分别从各自住得地方坐公交车到了铁狮子坟，王娓娓在那里租的房子，三个人约定在北师大的校门口见面，余鹏先到了，张小庆跳下公交车，余鹏正在公交站台上眯着眼睛等他，他的手插在裤兜里，倾斜着身子，两个人见了面，第一句话是：狗日的！然后两个人相视哈哈大笑，在校门口用方言肆无忌惮的大声喧哗起来，张小庆问了余鹏工作的情况，余鹏告诉他他在草桥一家建筑工程公司上班，销售建筑材料，这家公司是他一个远房亲戚开的，也是刚成立，一个月800块钱底薪，包住不包吃。说到这里，余鹏从裤兜里掏出一张折叠过的因为遗忘而皱皱巴巴的宣传彩页，展开，递给张小庆，说，如果有机会帮他也宣传宣传。张小庆接过彩页，说，余销售这么快就进入角色了，搞个彩页也搞个完整的点吧。余鹏说，你就没这个必要了，有消息我会亲自上的，当然，少不了你的回扣。张小庆说，你可千万别发了，这样我会嫉妒你的。说话间，王娓娓到了，不用寻找，循着声音就闻出浓厚的家乡味。王娓娓皮肤白白的，刚烫过了头发，蓬松的扎着马尾巴辨。张小庆说，娓娓姐，你的头发真好看。王娓娓说，真的吗，刚烫的。张小庆说，假的。王娓娓说，讨厌。余鹏在旁边吃吃的笑。

三个人在王娓娓的带领下一起步行去了后海，一切在张小庆眼里都是全新的，宽阔的马路，亮晶晶的全玻璃的大楼，带辨儿的公交电车，狭小青砖的胡同以及步伐冲冲的人们。张小庆一路上都在贪婪的观看，他东张西望，他四处观望，他想理解眼前的这一切，他知道，他以后将生活在这里，他需要习惯这里；余鹏双手插在裤兜里，斜着身子，在后面慢慢的走，他是懒懒的，满不在乎的；王娓娓一路上不停的在纠结自己的头发，她显然是对张小庆的玩笑在乎上了，她终于再一次问了张小庆，这头发真的做的不好吗？张小庆有了一点点尴尬，说，我开玩笑的，做的真的很好。王娓娓仍不放心，说，你是说做的很好，还是做的很适合我。张小庆开始为他的玩笑后悔了，说，做的很好，非常适合你，很漂亮。王娓娓这才放下心来。

后海完全是另外一种风情，它是安静的、悠闲的、放松的和慢性子的。张小庆余鹏王娓娓三个人在路边买了三瓶矿泉水，一个人手里拿着一瓶，顺着河沿慢慢的漫无目的走，不时有人力三轮从他们的身边经过，手拉着车把上的绳儿，车上的铃儿就清脆的响，三个人就往路边闪一闪，花坛边上，有晨练还没回家的老人，在一棵树上，他们还看见了一串的鸟笼，不知名的鸟儿在里面唱着不知名的歌儿，一如旁边酒吧里的歌手。在经过一家酒吧时，张小庆微微骚动了，这家酒吧叫欲望都市，这是个充满欲望的名字，容易让人产生联想。王娓娓说，这里晚上有钢管舞。等我有钱了，一定要来一次这里，张小庆想。三个人最后在一个花坛边上坐下，王娓娓再次问了每个人的想法。张小庆说，我要去微软和IBM，一定会去。余鹏说，多挣钱。中午王娓娓请张小庆和余鹏吃了韩国烧烤，余鹏来了瓶啤酒，王娓娓和张小庆一人来了份果汁。很多年过去，很多细节已经释去，张小庆印象深刻的是最后端上来的金银小馒头，真的是好吃，沾上点果酱，甜甜的，正如北京给他的第一印象，此后有很多次，在很多家餐馆，张小庆一次次的点到金银小馒头，可惜，再也找不到当初这种心动的感觉了。如果找不到工作，我就回家做金银小馒头，张小庆说。王娓娓笑起来，我支持你，来，一起干一杯，加油！张小庆突然就觉得王娓娓的头发真的很好看。张小庆余鹏说，加油！

张小庆说，你怎么到亦庄来了？

余鹏说，哪里有塔吊哪里就有我。

张小庆说，你想吃什么？

余鹏说，一听这话就知道你的心不诚，算了，走了。下次等你发了工资再来宰你。记着啊，你欠我一顿。

发工资，是啊，张小庆从来没有如此热烈的盼望发工资，少上2天班，应该还有2000块，他想。

【荣浩作品，欢迎转帖】

张小庆和他的经理在礼拜一的早上再次见面了。经理是个子高高的年轻人，穿一条洗得发白的牛仔裤，上身是一件灰色的衬衣，方脸，浓眉毛，衬衣整整齐齐的扎在裤子里，看到张小庆，他们打了招呼。

经理说：早，小庆，来得真早，找到房子了吗？上班还顺利吗？

张小庆说：早，找到了，挺顺利的。

经理说：那就好，饮水机在那里，带杯子了吗？没有带的话下面有一次性的，带饭盒了吗？公司中午提供午饭。

经理的话让局促的张小庆暖和起来，他连忙说：带了。

经理的工位就在张小庆的对面，抬起头来就能互相看见，经理站在对面擦自己的桌子，说：对了，公司要求每个人都有个英文名，我叫Bill，你以后叫我比尔就好了。听到这话，张小庆的心忽然长长呼出一口气，他其实很担心如何称呼他未来的经理，叫方哥吧，会不会太亲切而不够正式？叫方经理吧，会不会太正式而不够亲切？叫方师傅吧，会不会让人想起方世玉？这下好了，什么问题都不复存在了，一切都云消雾散了。

王碧薇从旁边探出她的毛毛眼，说，啊，刚才忘了，我叫Susan，小庆，你叫什么？

张小庆说，我要想想。

第一天工作的内容总是相似：搭建开发环境和了解系统。比尔给张小庆共享了一个目录，张小庆从里面拷贝了JDK1.4、Jbuilder2005、Tomcat4.0、MySQL4.1以及项目源代码文件。张小庆打开电脑，操作系统是Windows2000，他安装了JDK1.4，接下来，他左键选中“我的电脑”，右键菜单点击“属性”，找到高级选项，点击了下面的环境变量按钮，有两栏，上面一栏是用户环境变量，下面一栏是系统变量，在系统变量一栏里，他点击了新建，在接下来出现的系统环境变量编辑框里，他输入了变量名“classpath”以及变量值“.” ；接着，他又新建了一个变量，变量名是“JAVA_HOME”，变量值是JDK的安装目录；最后，他找到系统变量里面有个path的变量双击了它，在变量值最前面加上了“%JAVA_HOME%\bin;”。做完这一切，张小庆打开命令行，输入“java”，屏幕上反馈出长长一串的帮助信息，好了，张小庆想。

系统还未上线，张小庆访问了比尔机器上正运行着的实例，这是公司内部的业务流程系统，公司主要的业务是翻译和本地化，系统主要对公司内部的工作进行协调。

中午的时候，张小庆和比尔一起去楼下的员工餐厅吃了饭，公司的午餐外包给了一对年长的夫妇。每天中午，张小庆透过窗户看见一辆白色的面包车晃晃悠悠的开进大门，他就知道，午饭时间到了。车在楼下停稳，女人从驾驶的位置下来，看看表，点上一支烟，抽烟，男人从副驾驶的位置下来，拉开滑动门，将盛有饭菜的不锈钢桶往餐厅搬，6个桶，四菜一汤两荤两素加上米饭和大饼。张小庆喜欢他们做的酸辣汤，豆腐、冬菇、海参、鱿鱼分别切成细丝，同熟肉丝、熟鸡丝稠稠的纠缠在一起，最上面漂浮着懒懒的鸡蛋花，喝一口，酸酸的，带点微辣，刚好使鼻尖有点微微渗出的汗意，一切都是恰到好处。如果是酸辣汤，张小庆吃饭的速度会稍稍快一点，他要抢两碗。等大家都吃完饭，一切都反过来，男人到门外，看看表，点上一支烟，抽烟，女人负责收拾，把6个桶两两落在一起，搬上车，关上滑动门，然后坐上副驾驶的位置，等男人抽烟，男人抽完烟，坐上驾驶的位置，点火，发动汽车，面包车就晃晃悠悠的开出大门。

吃完饭，张小庆陪王碧薇去找了房子。这个春日的中午，王碧薇像一只被放归大自然的小兽敏捷而灵活地跑来跑去，拖着张小庆前行。对一个女人来说，最重要的不是漂亮的外表，也不是各种名贵的衣服和首饰，更不是化妆品堆积起来的庸俗，而是光线，是走在千千万万女人群中一眼就能标新立异的那种光线。王碧薇的个子并不高，她长得严格意义上算不上漂亮，但她拥有光线，无限的光彩从她轻盈的身体和愉快的笑声里溢出来，光芒四射，流光溢彩，照得张小庆眼睛生生的疼。他们一起去了广德苑小区，一起去了贵园东里，一起去了星岛嘉园，一路上都是王碧薇在不断的问问题，张小庆不停的回答，他们一起去看了小区公告板上的出租广告，一起去社区服务站问了大妈们有没有出租信息，一起给广告上的电话号码打了电话，一路上都是王碧薇走在前面，张小庆就是个跟屁虫的份。

回公司的路上，王碧薇问了张小庆：小庆，你的英文名字想好了吗？

张小庆说：想好了。

王碧薇说：真可惜，我也帮你想了一个，叫什么？

张小庆说：米歇尔。

王碧薇说：怎么拼的？

张小庆说：M-i-c-h-a-e-l。

等张小庆拼完最后一个字母，王碧薇大声笑起来了，她笑得上气接不上下气，笑得她那双好看的毛毛眼又眯成了一条弯弯的线，她一边笑一边说：米歇尔，笑死我了，哈哈，米歇尔。

张小庆现在不仅仅是涨红脸那么简单了，他感到整个人都肿胀起来，他开始后悔中午喝了两碗酸辣汤，第二碗酸辣汤的后劲上来了，到处都在冒汗，根本堵不住，他甚至感到在他背后已经腾起了一股巨大的水雾，他不知道什么地方出错了，但一定是什么地方出错了。看到张小庆的囧样，王碧薇的眼泪都出来了，她说，小庆，这个单词不念米歇尔，念迈克尔。

张小庆的拼音很差，他从来分不清前鼻音和后鼻音，也分不清卷舌音和翘舌音，这让他的语文成绩一直很烂，一直到小学三年级作文题的出现，这才稍微扭转颓势，到初中，拼音题成功的在语文试卷中被压缩为一道选择题，张小庆窃喜的同时却悲哀的发现：英语出现了。张小庆想了很多方法来对付这个问题：在一次考试中，他将所有与发音有关的选择题全部选了A，结果对了一个；在另外一次考试中，他将所有与发音有关的选择题全部选了B，结果还是只对了一个；接下来，他又分别试了C和D，结果依然并不乐观；最后，他将自己的橡皮擦削成方方正正的正方体，在其中四面用铅笔标上了A、B、C和D，遇到不会的，将正方体抛向空中，接住，看，那面冲上，就填上那面的选项，这种方法至少从概率论的角度成功的将他的命中率提高到了百分之二十五，然而好景不长，到了高中，他惊恐的发现：不定项选择题出现了，这对张小庆来说几乎是一种秒杀级别的题型，选一个就已经非常困难，竟然还有可能选多个，而且他妈的数目还不能确定，这意味着小小的正方体已经容纳不下所有的可能答案，张小庆在心里诅咒了设计这种题型的专家，他想，这个家伙一定也是上学时为选择题而苦恼的家伙，人总是这样，自己吃过的苦一定要让后来人再吃一遍才觉得心理平衡，甚至更加变本加厉。

下午的时候，张小庆问了比尔咱们现在有几个人，比尔回答说目前就咱们两个，公司还在招。张小庆问如何提交代码，比尔回答说本地测试没有问题后将源文件拷贝到共享的项目源文件目录下覆盖即可。张小庆问如果我们俩修改的文件冲突怎么办，比尔说我会划分模块，我们不会同时修改同一个地方。张小庆问我们如何生成可运行的包，比尔说使用Jbuilder直接编译，然后直接拷贝文件夹。张小庆说，好，我知道了。这就是张小庆的第一个正式项目，Jsp加上JavaBean，足够简单，足够好玩，足够让张小庆兴奋一段时间。

公司六点下班，五点五十分的时候，张小庆瞅了比尔，比尔没有下班的意思；五点五十五分的时候，张小庆瞅了比尔，比尔还没有下班的意思；五点五十八分的时候，张小庆瞅了比尔，这次，他发现比尔也在瞅他，比尔说，迈克尔，可以走了。张小庆说，好，你什么时候走？比尔说，马上。这时让张小庆一直担心的事情发生了，旁边正在收拾包的王碧薇说，米歇尔，拜拜。王碧薇是故意的，这让张小庆的头放大了，他不知道回答什么好，回答吧，不是，不回答吧，也不是。正在苦恼的时候，王碧薇又说话了，拜拜，迈克尔。这次是正式的了，张小庆吐出一口气，说，拜拜。

下班后的张小庆先去楼下的联通营业厅办了电话卡，他的电话卡还是来北京前在老家买的，这让他一有电话就要到处寻找公共电话，一如尿急了到处寻找公共厕所。张小庆顺着马路慢慢向回走，在一个十字路口，他看到了小白羊超市，他想起周扬说过的话来：如果看见小白羊超市，那么证明你在郊区；如果看见京客隆，那么证明你在城乡接合部；如果看见美廉美和物美，那么，恭喜你，你已经进城了；如果看见家乐福和沃尔玛，好吧，欢迎来到北京。

顺着早上上班的路，张小庆知道，一旦跨过凉水桥，那将是另外一个世界。傍晚的凉水桥是吵杂的，附近工厂上班的人们下班了，三三两两的往回走，那多是年轻的女孩们，她们叽叽喳喳，说着白天碰到的人和事；菜市场的菜农们买完菜，骑着平板三轮车往回走，脚蹬在车链盘的脚蹬上，链条带动车轱辘咕噜噜的响，有一次，张小庆看见他的房东了，房东是个慢性子，每次并不使劲蹬车，直到车快停下来，这才慢悠悠蹬上一脚，车后的平板上，堆着张小庆熟悉的大蒜们，那里也许就有那么一个是在张小庆的床上睡过的；还有一个个的妇女们，她们或背着或牵着孩子，另外一只手里拎着晚上要做的菜，步伐匆匆的往家赶，为她们的男人做饭，张小庆碰到和他一起同住一个院子的另外一个租户了，那是个年轻的妈妈，牵着她女儿的手往回走，小女儿似乎刚刚被妈妈斥责过，脸上还挂着两行泪痕，很不情愿的被拖着走，走两步总要停一会，两眼汪汪的看着妈妈，想妈妈抱她走，可是妈妈腾不出手，于是母女俩在凉水桥上较着劲。张小庆走上前，打了招呼：回家啊，我帮你提着菜吧。妈妈感激的瞅张小庆一眼，说，孩子他爸回来了，要回去做饭，可这孩子真不听话，硬要抱。于是张小庆帮妈妈提了菜，妈妈抱了孩子，小女儿破涕为笑，三个人一起往回走。聊天中，张小庆知道孩子一家是山东人，孩子爸爸在这边一家工厂开货车，长途，经常十天半月的出车，孩子妈妈在这边带着小女儿在一家杂货店帮忙，小女儿四岁，还未上学，跟着她妈妈在店里玩。妈妈说，吃饭了没？一会儿过来一起吃。张小庆说，没事，吃过了。妈妈说，在哪儿吃的？张小庆说，外边。妈妈说，你可以自己做，这样不仅吃得好还很便宜。张小庆的脸红了，轻声说，不会。妈妈笑起来，说，谁一开始都不会，我教你，还有，房东是卖大蒜的，我们整个院子吃大蒜都不花钱。张小庆也跟着笑起来，他们稍微加快了步伐，桥下，河水依旧不紧不慢的流淌着。

晚饭对张小庆来说始终是个问题，有时候张小庆会到小白羊买个鸡排和两个馒头一共两块五回家吃，但大部分时候张小庆会在鹿圈徘徊，随便找个馆子进去。这边的馆子总是风格一致：一间不大的平房，门上顶着长方形名字各异的招牌：实惠酒家、好再来饭店、东北菜馆，让张小庆奇怪的是，这些招牌竟然都是惊人的一致：除去名字不同，招牌的背景都是同一个光鲜的苗族少女举着某酒露出白花花的细碎牙齿，这是编译好的模板，馆子名字是变量，张小庆想。很少有发光的招牌，于是，这些饭馆的老板们再次行为一致的在门口立上了小灯箱，夜幕降临，各色各样灯箱里橘红色的灯光就依次亮起来，于是，张小庆看到：酸辣土豆丝5元、地三鲜5元、鱼香肉丝8元、木须肉8元、水煮鱼15元。

走进店里，人很少，不到10张桌子，其中一张桌子上还残留着餐具未来得及收拾，前面一桌上有5个中年人正在热烈的喝酒，脸都喝得通红，棉衣都喝得解开了，其中两个人将左脚直接踏在自己的椅子角上，另外一个人正用牙签剔他那粗犷的牙缝，他们一边喝酒一边大声的说话，地上和桌子上都摆满了啤酒瓶，一个人冲站在旁边的服务员小姑娘大声说，再来5瓶啤酒，另外一个人拉住他，说，哥，不行，不能要了，喝完这个吃饭，吃饭，前面那人说，不行，到哥这里，不喝好怎么行，服务员，5瓶啤酒，快点！张小庆找个角落坐下，菜单压在桌子的玻璃下面，透过玻璃看菜单的时候，张小庆发现了桌子上的一团油渍，更远一点，他甚至发现了几粒饭粒，而桌子的里角，则糊满了已经发黑的灰尘，张小庆叫了服务员，可小姑娘根本没有时间理他，他于是自己拿了一次性纸巾将油渍和饭粒小心的拭去。他要了一份西红柿鸡蛋面，4元，等面的空儿，他看了挂在墙角的电视，电视里正在播放超级女声的广告，酸酸甜甜就是我，张小庆觉得这广告词形容他的面条很合适。吃完面，张小庆喊住了正皱着眉头收拾啤酒瓶的小姑娘，说，你们这儿的炒菜能做半份吗？小姑娘看着被踏的全是泥的椅子角，没好气的说，不能。张小庆说，你问一下老板吧，如果可以，我每天晚上都来。小姑娘瞅一眼张小庆，不耐烦的掀起布帘走到后厨去，一会儿，出来，说，不行。张小庆被打击了，走出饭馆，他想，再不来这里了。

饭馆对面是个电话超市，鹿圈的电话超市很多，一到晚上，都人满为患。张小庆等了好一会才轮到他，每个人的电话时间都很长，人们操着各式各样的方言，或热烈或有一搭没一搭的说着话，轮到张小庆，他先给王娓娓打了电话。

张小庆说，娓娓姐，我上班了。

王娓娓说，是吗？太好了，恭喜啊，有时间我去看你。

接下来，他又给余鹏打了电话。

张小庆说，余儿鹏，我上班了。

余鹏说，狗日的，可以啊，请我吃饭。

相比晚饭，张小庆的早饭就要容易的多。正对路口，有一家好吃酒家，每天早上，天还没亮，老板就将火炉旺旺的在门口生起来，先是蒸包子，等到有客人到来，就换上油锅开始炸油条。张小庆每天去的时候，正是人多的时候，没有位置，一地饱含鼻涕和口水的餐巾纸，很多人就站着吃，一有人离开，就有人快速的抢过去，一边坐下一边大声的拍桌子：老板，老板，把桌子收一下。老板这时候人手是不够用的，人们呼喊一声没有反应，就自己将前面吃剩下的碗们盘们推向一边，然后吃饭。这里没有服务员，服务员是你自己，你需要自己去油锅前排队，去抢那油条；你需要自己拿碗，去门外的粥桶前打豆浆和稀粥；你需要自己去取小碟子，咸菜就在刚进门的桌子上躺着；老板在油锅前汗流浃背，你甚至需要自己去算自己吃了多少钱，然后大声的对老板说，老板，钱放这里了，老板说，好的好的，走吧走吧。张小庆的习惯是一碗豆浆两根油条和两碟免费的咸菜，一共一块一毛钱。

吃完早饭，张小庆整理了自己，他看看自己的皮鞋，这双皮鞋昨天刚踩到一坨冻僵的人屎，在桥那面，路上多的是狗屎，在桥这边，路上多的是人屎。张小庆知道，新的一天又开始了，前面，凉水桥向他徐徐走来。

     摘要:   阅读全文

项目上线，有时间总结一下当前的项目，对自己而言，一直是一个学习的过程。本篇总结我们的测试实践。本文分5部分，分别是：项目背景、系统架构与模块划分、我们的测试实践、自动化测试在项目中的价值与对自动化测试的进一步思考。

一、项目背景
所有对项目的介绍一定是从客户开始。
客户：我们的客户是一家全球领先的时尚内容提供商，通过遍布全球的员工，客户每天获取大量关于时装发布、产品设计、街边流行、城市热点等信息，这些信息的绝大部分以图片的形式上传到公司服务器，然后由专职编辑对这些图片进行整理和归类（打标签），最后再由设计人员根据这些信息书写分析报表。
关键内容：分类细致的海量高清图片和具有前瞻性的分析报表。
商业模式：网站，行业内用户订阅-付费。
客户面临的问题：同质化竞争、客户流失。
新系统的关键词：CMS、更精确的内容分类、更好的全文检索、更好的用户体验（更有表现力的内容展现）、更快的内容发布。

二、系统架构与模块划分
1、REST的架构风格
系统采用了Sling作为WEB框架，JCR作为了底层内容存储框架。
系统的特点：
URI唯一标识资源
通过URI能够直接映射到JCR节点，例如http://localhost:80/content/section/news.html能够映射到JCR里的/content/section/news节点

GET/POST/DELETE标准方法对资源进行操作
支持标准方法对资源的直接操作

资源的多重表述
同一资源可以存在多种表述形式，例如http://localhost:80/content/section/news.html展现网页，

http://localhost:80/content/section/news.json展现资源信息的JSON描述，
http://localhost:80/content/section/news.pdf展现网页的PDF。

服务器端的无状态
通过JS获取当前用户信息并缓存在客户端。

2、系统分层
系统分为四层：JS、Servlet、Domain Model和JCR。
因为JCR提供了一套节点模型，所以Domain Model是在节点模型上的行为增强，例如所有对图片节点的操作我们封装在Asset领域模型里。


3、程序划分
程序分为两个大的模块：Migration和Bundles。为什么叫Bundles？因为Sling使用了OSGI框架Felix。
Migration负责导入客户的遗留数据到新系统。之前客户的CMS运行已有10多年的时间，积累有大量数据。主要是各种类型的报表和图片。
Bundles实现系统功能。主要包括了定义报表模板、定义报表各种所见即所得的展现组件、实现对图片的管理、搜索（包括基于图片的可视化搜索）和其他七七八八。

三、测试实践
1、Migration的测试
  自动化测试
对Migration，我们采用了TDD的方式。
输入是客户实际提供的xml文件，输出是JCR里的节点。测试环境的搭建主要是在本地建立起Jackrabbit实例。我们的工作方式是这样：每天早上领到一张migration故事卡，然后先写一个xml到jcr节点的集成测试描述出该类型报表的功能需求，接下来就是让这个测试通过。经过开始阶段的熟悉过程，我们的速度保持在一对Pair一天一种报表类型的导入。

   手工测试
将xml文件内容正常解析并导入JCR只是第一步，第二步我们需要在Bundles里为该类型的报表编写模板使之正常展现。由于涉及到报表样式，这个测试我们采用手工测试，这个工作也是QA工作的重要一部分。
在最开始的开发中，我们没有导入所有报表数据进行测试。这带来了问题，由于客户遗留数据跨越10多年，各种数据形式都可能存在（特别是04年以前数据，给UI带来了很大挑战），而最开始的开发中，我们只是使用了部分数据（09、10年数据）进行测试，这个导致了建立UAT环境时程序的很多返工以及QA的测试压力。

2、Bundles的测试
自动化测试
对领域模型，我们采用了TDD的方式进行单元测试；在本地Jackrabbit实例里建立数据，领域模型封装数据测试行为。
对servlet，我们采用了TDD的方式进行集成测试（同时测试了servlet和领域模型），在测试中对request和response进行mock；
对JS，我们使用数据驱动的selenium功能测试进行覆盖。

我们最后的自动化测试结构：


手工测试
手工测试内容主要是功能测试。
自动化测试价值低的部分我们采用手工测试，这部分内容包括报表模板，相对独立，内容不多，一次测试处处通过；
自动化测试成本高的部分我们采用手工测试，这部分内容包括报表展现组件的编辑功能，因为采用了Ext JS，所以自动化测试困难；
无法自动化的测试：报表在线生成PDF，报表样式，WEBDEV批量上传图片等;

我们与QA的约定：
每完成一个用户故事，我们会与QA、BA一起mini showcase；
QA验收完成后编写功能测试用例；
我们对QA编写的功能测试用例进行自动化，共同维护一个功能测试列表；
对于不能自动化或自动化价值不高的测试用例QA继续使用手工测试。

四、我们感受到的自动化测试价值
1、通过自动化功能测试，我们使得需求对客户可视化；
2、QA的回归测试成本降低，尽管目前频繁的向客户实际使用环境部署，但QA每次部署只需要做一些简单的冒烟测试；
3、测试即需求，这点在TDD的开发过程中感觉非常明显，今天开发的目的就是使这个测试通过，避免了频繁部署到应用中进行测试，最快的电梯不是速度最快的电梯，而是中间停的楼层最少的电梯；
4、与持续集成一起，及时反馈。这点在进行JS代码编写时，心理上都非常依赖于selenium测试，对于没有测试覆盖的地方，没有安全感；
5、足够的单元、集成测试保证了频繁重构，没有人愿意引入BUG，没有足够的测试，没人愿意重构；
6、测试即文档，良好的测试和命名，使得新加入的成员非常容易理解当前代码的功能。

五、思考和讨论
1、自动化功能测试做到多少才合适？
当然是越多越合适，问题在于自动化功能测试成本要大大高于单元测试和集成测试，这些成本反映在测试环境的搭建、数据的准备，需要准备其他很多关联数据例如用户信息和权限信息、自动化功能测试的运行时间长、稳定性（随机成功/失败）、编写等等，需要权衡成本与收益。
个人认为，自动化功能测试需要考虑的着重点包括：页面是否包含大量功能交互性JS（与展现性JS相对）？当前功能是否与其他功能共享一些代码？即独立性，独立性越低越需要着重覆盖（这里又涉及到另外一个问题，即从各个模块里重构出共用代码是否总是合适？）。QA每次冒烟测试时是否需要重复回归（重复回归次数越多，自动化越有价值）？经常失败的测试一定比不失败的测试价值更高？或者从未失败过的测试就没有价值？

2、单元测试？功能单元测试？
TDD的测试粒度多大才合适？从我个人而言，几乎天然的反对mock，为了满足测试覆盖率的追求，强制将两个联系很紧密的类分开，做出各式各样mock，这真让人气馁；stub也不是什么好东西，在一个曾经的spring项目里，在测试目录里，一堆一堆的测试xml配置文件让人有种呕吐的感觉。那就做集成测试吧，两个类关系很好，那么就整体测试它们的输入和输出，看起来很不错，功能实现了，测试也没多写，也不用准备太多其他东西，但是打开实现代码，你就发现那个丑陋，到处是复制和粘贴，是啊，不管黑猫白猫抓住老鼠就是好猫，只关注了当前结果，完全失去了TDD驱动简单设计的好处。

3、测试的重点是测试用例的设计，它反映出对需求的理解
那么结论就很明显，我们如果连需求就没有理解，如何进行实现，所以测试驱动是很自然的。

正如语言是人之间的沟通方式一样，数据是IT系统之间的沟通方式，语言之间的沟通总是最有效的，数据交互却未必，因为IT系统里的数据除了让计算机理解外重要的是还需要人理解。在这篇文章里，我们将讨论工作流系统里的数据，从数据角度分析工作流数据的分类以及不同的应用场景。

 

一、工作流系统的应用场景

在正式开始对工作流数据的讨论之前，首先对工作流系统的应用场景进行讨论是必要的，因为工作流数据脱离不开工作流系统这个大的上下文。目前，工作流系统的应用主要有两种方式：

1、    将工作流系统嵌入到业务系统中使用。此时工作流系统作为内部组件对业务系统进行流程逻辑的横切。试想一个需要多人处理的电力缴费流程，在引入工作流系统之前，我们需要为每个业务表单设置一个状态位，以此来进行业务处理状态的跟踪。如果流程固定，那么这样做并没有什么不好，例如财务软件、海关报关软件等，它们的流程虽然复杂但是不常改变，此时就没有必要引入工作流系统。但是对于另外一些情况，例如制造业的订单处理、库存管理、政府的协同办公等，流程经常需要定制修改，此时如果继续由业务系统自己处理流程逻辑那么成本将会很高。

2、    使用工作流系统进行业务系统的集成。在上规模的企业里，很多流程会涉及到不同的业务功能，例如报价、订单审核、资产核准、绩效评估等，这些流程经常会跨越不同的部门和业务系统。因为不同企业都有自己所采用的业务系统、组织机构以及最佳的业务协作方法，所以这些流程基本上也随企业而异。工作流系统此时扮演的就是集成角色，由其通过定制流程将这些业务系统撮合起来，实现企业内各部门、客户间的信息流动和协作。

在第一种应用场景下，工作流系统作为业务系统的内部横切组件出现，作为横切组件，工作流数据仅仅包括与流程逻辑相关的数据以及其他必需数据，这些数据包括工作流控制数据、工作流相关数据以及需要通过流程传递的业务数据。

在第二种应用场景下，由于不同业务系统之间的数据传递很大程度上依靠工作流系统，所以这些数据被封装为SDO在不同WEB服务间传递，需要注意的是，这些数据并不在工作流系统中存储。

        在下面的工作流数据分类中，我们将详细分类这些工作流数据。

 

二、工作流数据的分类

提到工作流数据，就不得不提业务数据。作为最直接的区分，我们将存储于业务系统中的数据称为业务数据，将存储于工作流系统中的数据称为工作流数据。根据WFMC定义，我们将工作流数据分为工作流控制数据和工作流相关数据。

1、  工作流控制数据。指被工作流系统管理的系统数据，这些数据包括了与流程实例和任务实例相关的执行数据，例如流程实例的状态、执行时间等信息、任务实例的执行者、执行时间、状态、紧急程度等。

2、  工作流相关数据。指与业务流程相关的数据。工作流相关数据又具体分为3种：

·         影响流程实例执行的业务数据。在WFMC中，这个数据被描述为：工作流系统通过该数据来确定流程实例的流转条件，并选择下一个将执行的任务，这些数据可以被业务系统访问并修改。例如报销流程中的“报销金额”，这个数据会决定该流程的审批路径；再例如为任务设置的超时时间，这个数据会触发任务的取消。实质上这些数据就是工作流系统需要依赖于进行流程流转的业务数据。

·         契合业务的关联数据。指工作流系统与业务系统进行关联的数据，例如特定于WEB系统，工作流系统会在每个流程实例里保持有导航至对应业务表单的URL。

·         传递作用的业务数据。当流程跨越多个业务模块时，需要在模块间传递数据，此时会利用工作流系统进行传递，会在工作流系统里暂时存储这些业务数据。

那么，工作流数据有哪些应用场景呢？

 

三、工作流数据与业务上下文

工作流数据最重要的职责之一就是为业务系统的不同应用场景建立起与之对应的业务上下文。

什么是业务上下文？

我们知道，IT系统是对企业现实业务的映射。在一个翻译公司的典型业务场景中，校对人员对翻译人员提交的翻译文档进行审校，此时，校对人员持有翻译人员翻译后的文档，他需要对该文档进行检查，产生新的审校文档并反馈翻译人员的翻译质量。那么，映射到IT系统里，校对人员的任务通常对应于一张需要处理的业务表单，业务表单里会展现他进行当前工作所需要的数据：翻译文档、翻译人员信息、该校对工作的紧急程度等，另外，在这张表单里，他所能进行的操作也根据他此时的职责作出了行为限定：例如他可以上传新的校对后的文档，但是不能删除已有的翻译文档等。如下图1所示，业务表单实质上反映的是此刻我们能获取哪些数据以及能够如何处理这些数据，我们把它称之为业务上下文，可以看到，在IT系统里，业务上下文实质上等于数据加上行为。

企业业务由一系列相互关联的业务场景组成，这些业务场景对应于IT系统里的业务上下文，而业务上下文的本质则是数据加上行为。数据和行为的不同决定了业务上下文的差别。这与现实中的工作相符，人们根据获取/处理信息的不同，担负不同的职责。 

图 1与应用场景对应的业务上下文

工作流数据如何建立业务上下文呢？看一个简单的例子。

在实际应用工作流系统进行开发时，我们经常会碰到这样的问题：同一流程中的不同任务对业务数据拥有不同的权限，如下图6-9所示。

图 6‑9与流程相关的业务数据权限

上图中，在执行请假申请任务时，申请者可以编辑请假人、天数和原因3个字段；而到审批任务时，审批者增加了一个可编辑的审批意见字段，但其余3个字段变化为只读字段。我们将这类问题统称为与流程相关的业务数据权限控制。

产生这类问题的原因是什么呢？原因就在于在一个业务流程里，不同的任务具有不同的业务上下文。如下图6-10所示，不同的任务展现不同的数据，并具有不同的行为。

图 6‑10任务与业务上下文

在IT系统的设计实现中，数据的建模是通过领域模型实现的。在工作流系统的嵌入式应用中，流程实例即是通过与领域模型相关联实现与业务契合的。那么，图6-10可以进一步泛化为图6-11，流程中任务通过获取领域模型不同的部分实现业务上下文的界定。

图 6‑11领域模型与业务上下文

在大部分的业务流程建模中，一个流程模型只与一个领域模型关联。

那么，回到最初的问题上，如何处理此类权限问题呢？答案非常明了：由领域模型实现对业务上下文的切分，工作流系统通过契合业务的关联数据与业务上下文挂接，保持工作流系统的单一职责。

图 6‑12流程相关的业务数据权限控制

如上图6-12所示，我们在业务系统里引入业务权限角色的概念，通过该角色隔离开工作流系统与业务数据权限，即我们认为业务数据权限的管理属于业务系统范围（由业务系统具体实现），更进一步，我们认为其属于领域模型的职责范围。在定义好业务系统的权限角色后，我们通过任务级别的工作流变量将流程中的具体任务与业务权限角色绑定，这样就实现了流程任务与业务数据权限的挂接。

在上面的例子中，我们看到的是利用关联业务的工作流数据界定任务级别的业务上下文，这是一种最简单的工作流数据应用场景。在不同应用中，我们可以看到，工作流数据一个重要的职责就是为业务流程里的任务/流程建立业务上下文，实现数据的聚合。在简单的应用场景里，对一个流程实例而言，这些数据可能只对应于一个领域模型；对流程实例里的一个任务实例而言，这些数据对应于领域模型的一个切面。复杂一些的情况，业务上下文需要跨越多个领域模型甚至多个业务系统，这时我们可以看到，通过工作流系统能够显著降低业务系统建模的复杂性，因为这些数据聚合工作可以有效分派给工作流系统承担。同时，我们需要保持工作流系统的单一职责，工作流系统只保存与业务数据进行关联的关联数据、必需的业务传递数据以及自身的执行数据。

图 6‑29跨系统的业务上下文

 

 

四、工作流数据与数据分析

工作流数据的第2个应用场景是对业务流程执行进行数据分析，这部分的数据主要是工作流控制数据。这一部分正受到越来越多的重视，是未来工作流系统的发展方向。

图 6‑48外部环境从流程实例拉数据进行分析

 

这里有两个典型的应用例子：

例子1在对报销流程进行分析时，我们发现大部分的报销金额都低于500元，然而这些报销流程却都要经过很多环节，在与客户确认后，我们将低于500元的报销限定于部门内部审批即可，这样对个人来说大大加快了报销过程，对公司来说则省下了很多的办公成本。

例子2，在制造流程里，很重要的一点是需要控制流程的节拍时间，即流程里各个任务的完成时间要一致，如果有一项任务的时间多于其他任务，那么很快就会形成瓶颈，造成在制品的大量积压，前续的任务完成很快，中间忙死，后续任务执行者却无事可做，更重要的是，不能对客户进行快速交付。

 

 

五、工作流数据与流程路由

最后一种应用场景非常常见，这部分数据即影响流程实例执行的业务数据，直接上图：

这部分影响路由的一定是业务数据，它们保存到工作流系统里对流程路由产生影响。这种影响不限于任务的选择，还包括的任务的执行条件、任务的完成条件、基于数据的任务触发等。

 

六、工作流数据小结

总结一下，作为区分，我们将存储于业务系统中的数据称为业务数据，将存储于工作流系统中的数据称为工作流数据。

工作流数据分为两种：工作流控制数据和工作流相关数据。其中工作流相关数据又分为3种：影响流程实例执行的业务数据、契合业务的关联数据和传递作用的业务数据。

工作流数据的应用场景：为流程/任务建立业务上下文，这部分数据主要是契合业务的关联数据和传递作用的业务数据，这是工作流数据最重要的职责之一；数据分析，这部分数据主要是工作流控制数据，这是未来工作流的发展方向；影响流程路由，这部分数据人如其名，是影响流程实例执行的业务数据。

实际应用中，我们一定要保持工作流系统的单一职责，例如划分任务权限这个需求，一定需要业务系统自行实现权限的界定，工作流数据仅仅进行挂接。

 

 

PDF噩梦

在之前的一段时间里，只要一提起PDF，我就会头晕，然后是头疼，最后是头大，总之是和头相关。需求很简单：为所有报表提供在线生成PDF版本的功能，这样网站用户在浏览报表时就可以下载离线浏览。对不住了，开源软件，我不得不说，慎用开源软件，慎用！痛苦的查找论坛、痛苦的翻看源码，最后，在支付了200欧后，痛苦消失了，我们购买了商业软件，200欧兼容了更多的网页结构，200欧具有更快的速度，200欧带有一年的技术支持，最最重要的是，200欧，客户出的。

这不是这里的关键，问题是，200欧后，我遇上了新麻烦：报表的PDF版本样式不正确，不正确的原因是图片下方的文字将图片的排列样式弄乱了（图片大小不规则，字数不规则）。在网页中，DOM渲染完毕后，我们使用JavaScript来进行图片与文字高度的重计算，但在PDF中，我们束手无策。

我问BA，可以容忍部分图片排列不整齐否？不出所料。

怀有侥幸，我继续问BA，可以容忍部分文字丢失否？BA说，不可以。意料之中。于是找到徐昊。

徐昊问BA，这些说明文字对客户如此重要吗？

BA说，是的。

徐昊说，为什么？它主要有哪些内容？

BA说，有标题，简单说明以及图片的版权信息，最重要的就是版权信息，一定不能丢失。

徐昊说，能不能这么说，其实对客户最关心的是版权信息。

BA说，是的。

于是问题解决。解决方案是：我们给文字定高，同时将文字缩小以容纳最可能多的字数，这样网站用户在PDF里看到的图片重新恢复了整齐，尽管看不太清图片说明文字，但是用户真正关心的是图片，谁关心哪些无处不在的版权信息呢？你可能会说了，看不清版权信息怎么行？幸好，你问的不是，版权信息有那么重要吗。回答是，这里是PDF，移动你的鼠标到Zoom，点击下拉框，点击150%以上的选项，然后，你会惊讶的发现，那些该死的版权信息到处都是。

BA的职责是帮客户发现的问题，开发人员的职责是解决问题，QA的职责是校验最终的实现是否能够解决客户的问题。具体到一个用户故事上，就是BA编写用户故事，DEV编码开发，QA验收用户故事，这是三个任务，很明显，这三个任务有一个非常重要的共享信息，这个信息就是用户故事所要实现的客户价值（即帮客户解决的问题）。围绕着客户价值，每次迭代开始前，团队都会进行迭代计划会议，所有成员会跟随BA逐一审核各个用户故事；围绕着客户价值，开发人员开发中随时可以和BA进行沟通，就设计问题进行讨论；围绕着客户价值，开发人员每开发完成一个故事，BA、开发人员和QA就会在一起进行一个微型 ShowCase，在期间讨论用户故事的实现是否实现了客户价值，大家对用户故事的理解是否一致。

那么，在相关的任务之间需要能够定义变量，这些变量数据能够在这些任务间共享。

 

描述

一定的任务范围能够定义变量，在一个流程实例里，该范围所包含的任务实例能够使用该变量。

图 6-4任务范围级别的数据可见性

如图6-4所示，我们划定了一个任务范围，该范围包含了任务A、任务B和任务C，同时，我们在该任务范围内定义了一个变量M，那么，在一个流程实例里，只有任务A、B和C的实例在运行期能够使用该变量，任务D和E的实例都不能访问，不可见。

 

可以看到任务范围和块任务在概念上比较相似，都是包含一系列的子任务，它们之间的差别在于：块任务一般具有比较独立的执行上下文和业务语义，而任务范围则是对具有相同执行上下文的任务的一种分组。

在工作流系统里，对流程任务进行分组的好处在于：可以为特定的一组任务绑定数变量、异常处理器和补偿动作。例如在图6-4中，如果任务A、B和C中的任一实例执行失败，那么我们就认为整个任务区域执行失败，将统一执行一个业务补偿行为，同时，这些任务共享一个异常处理器。

实现

在jBPM4里，流程定义模型相比jBPM3最大的变化即是引入了任务嵌套的概念，一个任务能够包含多个其他任务，这里的父任务即可充当任务范围的定义。jBPM4针对这种嵌套的任务建立了一套处理机制，总的来说就是建立任务运行期的嵌套关系，查找变量时首先会在任务级别进行查找，如果找不到，则会依次向上查找父任务实例，直至流程实例级别变量，同时，父任务可以统一绑定异常处理器和事件动作。在后续jBPM4的章节，我们将会详细分析该机制的实现细节。

什么代码才是好代码？这真是个老得能拔掉牙齿的话题。好吧，那让我们再在这刮沙尘暴的无聊时光里重复一次。好的代码要是易读的代码、要做到职责分离、要做到单一职责、要有高的执行效率....

等等，等等，这才抽象了，太书面化了。我只是一个菜鸟，刚写代码几年，也没念过什么书，能不能说得通俗易懂一些？

好吧，我停下来，想，这真是个难缠的家伙。我说，这样吧，我推荐几本书你去看吧，《重构》熊节最近再版了，建议你去买一本。恩，等等，有个省钱的招，去图灵俱乐部讨论组注册下，蹭赠书也很爽，哈哈。

可是，你还没告诉我什么代码才是好代码呢？知道你也没什么好答案，我自己来说好了。

省略掉此时我内心花花的汗水，下面是菜鸟的叙述：

1.一致
我发现自己有轻微的强迫症，当我碰到以下代码时，我就会冲动。
冲动前代码：
def imgName
if(XXX){
   imgName="meigui"
}else{
   imgName=""
}
冲动后代码：
def imgName=XXX?"meigui":""

尽管两段代码功能一致，但一旦我发现出现冲动前代码时，我就会感到不舒服，感到难受，就好像看到阅兵正步走不齐一样。方法名也是一样：
冲动前：
def testXXX(){}
冲动后：
def should_XXX_when_XXX(){}

变量亦是如此:
冲动前：
def imgNode=resouce.adoptTo(Node)
冲动后：
def node=resouce.adoptTo(Node)

总之，我不愿意看到同一个事情有两种实现方式，如果功能类似，那么不管是逻辑还是变量、方法名，我会强迫一致，整齐划一。

关于一致，从调试代码的角度看，零星的不一致比大量的不一致更加糟糕，因为这时大部分地方的一致性会令人麻痹大意。在实现查询分页功能时，我们有这样一行代码：
nodeIterator.size
这行代码的意思是获取查询结果的总数，大部分情况下它工作良好，但是在一种特殊情况下它返回了-1。这对我当时几乎是灾难性的，因为调试过程中我们始终相信这行代码的行为一致，结果是花费了一个下午才找到这个问题。

2.简洁
我喜欢短的代码，对我而言，短的程序总是比更长一些的代码容易理解，小学时学课文就已经这样了，一看到大段的段落我总是会晕过去（特别是文言文，首先我就 对自己理解这段文字失去了信心）。这里要提到注释，即是这些注释明确是为了提高代码的可读性，也会增加我阅读代码的困难，所以我不会在方法里的任何位置添 加注释，撑死在个别方法声明前添加，并且这种情况也尽量避免，如果这个类确实包含了重要的不易理解的算法，我也只会在类声明前添加注释。

关于自然语言，有一个基于经验的结论被称为Zipf定律，即：自然语言中最常用到的单词，其长度会趋于最短。

我写代码的时候，能够简写尽量简写，例如，变量名，imageNode，我一定会写成imgNode；方法名procedureXXX,我一定会写成 procXXX,和讨厌大段代码一样，我非常讨厌命名很长的方法名和变量名，尽管这些名称这么长是为了更好的增加可读性，但可读性不是这样增加的。

在我的第一份代码工作里，我们使用拼音来命名方法和变量（还好，没有包括类名），我讨厌这种命名方式的原因并不是因为我的语文老师不好以至于我前后鼻音不分，而是这种写法根本排除了简写的可能性，甚至，为了避免歧义，有时不得不变得更长。

3.联觉和顺序
关于记忆，人类有两种重要的记忆能力：联觉和顺序记忆。

关于联觉，一个例子是：你总可以一眼记住一个人的脸，比如范冰冰，尽管我到现在也不清楚她到底是单眼皮还是双眼皮，也不清楚她到底是厚嘴唇还是薄嘴唇。

那么，在代码里，这里的表现就是局部，即一个功能的所有相关代码都集中在一个地方。我最讨厌的代码是这样的：最开始我打开一个文件，在阅读的过程中，我发 现一个不清楚的方法，于是我按下ctrl并点击鼠标，于是我跳到另外一个文件；接下来，在阅读另外一个方法里，我再次发现了一个不清楚的方法，于是我再次 按下ctrl并点击鼠标，哇哈，新的文件打开了....如此反复，终于当我打开最后一个文件时，我发现IDE的文件条里已经密密麻麻的排满了好几排文件， 于是，我移动鼠标，右键，弹出一个关闭菜单，我选择了close others，瞬间，哦米拖佛，整个世界清静了，但是，等等，我最初是打算干嘛来着？

所以，请把所有相关联的代码都集中在一个地方，求您了。哦，对了，能不用接口请不要用接口，总会碰到这样的情况，打开好几排的文件，接口文件占了一半，我靠，少几个接口会死啊。对了，这可能是您的一致性心理在作怪，对不起，对不起。

关于局部，一个范例同样与调试有关，在很久之前的一次调试中，我们始终找不到一个变量错误的原因，因为在这段代码里，根本找不到任何错误，很久以后，终于 发现，这个变量竟然是个全局变量，嘿嘿，告诉你吧，这个变量在servlet里，04年的时候，网上很火的一篇文章，标题就是：不要在servlet里使 用全局变量！

关于顺序，最典型的例子出现在高中化学里，我总也不能瞬间说出第12、13个化学元素是什么，我通常会这样记忆：氢氦锂铍硼碳氮氧氟氖钠镁铝硅磷，啊哈，第12个元素是镁，第13个元素时铝，合起来就是--美女！

所以，在代码里，请将互相调用的方法按顺序摆放，方法1先调用了方法2，那么请将方法2紧放在方法1后边。我讨厌这样的配置：打开方法1，发现其调用了方 法2，点击方法2，编辑器里的滚动条瞬间从最上端滚到最下端，紧接着，滚动条又从最下端滚动到中间，再接着，又是最下端，接着，归零到最上端....人生 经不起这样的大起大落，真的，那得要多么大的心脏啊，麦蒂才有过那么一次，13秒....

还有，知道为什么goto为什么那么臭名昭著了吧。

4.自然
使得代码具有轻松的表达方式，同时把错误率降到最低，一种最重要的方法就是代码变得“自然”，即向自然语言靠拢。因为代码并不仅仅是与机器交流的，更重要的是，需要在人之间交流。

机器语言到高级语言，面向过程语言到面向对象语言，jdbc到hibernate，java到动态语言，这些都促使代码变得更加自然。

Ruby里有个不起眼的特性，就是方法调用不用再写括号，这一特性是如此的微不足道但是却被很多人津津乐道，原因就是它更加自然，更加贴近我们的自然语言。于是，我看到，我的同事晓娜，在groovy里，一遍遍的将她力所能及的括号去掉。

此外，程序语言和自然语言是有区别的，除了不能在代码里利用感情词抒发情感之外（我想，如果可以，一定会看到很多的冯特），程序语言没有口语。很少看到程 序员之间这样交流，来吧，我们来说段代码（当然也有，徐昊就可以，哈哈），他们更多的会使用白板和笔或者直接是编辑器。所以，结束招聘时是否需要笔试的争 论吧，我真为那些不经过笔试就直接招人的公司感到羞愧，因为他们根本就不懂程序语言。

此处省略华丽的分割线。

此文谢谢我们项目组WGSN的激烈讨论，谢谢讨论中徐昊的精彩点评。

唐僧与 QA MM

在一个典型的项目团队里，包括了以下几种角色（帽子）： PM（项目经理）、 BA（业务分析师）、 DEV（程序开发者）和 QA（质量保证人员），整个团队的目标是向客户交付价值。

那么，有一天， QA MM来找我，我是开发人员。 MM说，一张图片没有正常显示，我想知道原因，同时想知道你能否修复。我的第一想法是，这不可能，一定是环境的原因。我说，好的，稍等。接下来，我张大嘴巴看到了 MM给我重现的 BUG：本该显示图片的位置一片空白，就像此时我合不上的嘴。这怎么可能呢？我想，这个功能完成的如此之得意，以至于测试用例里的数据都是以我的名字命名的。

几分钟后，或者更长，我叫来 MM，说，找到原因了。

我打开编辑器，光标在源程序的某一行闪烁，我说，最根本的原因在这里。我看到 MM的眼中闪过一丝迷茫。接下来，我却换到另外一个源文件，光标继续闪烁，我说，这里的程序因此受到影响。看得出， MM有点发晕。终于，当我打开第 N个源文件并试图继续讲解时， MM昏过去了。

当 MM苏醒过来时，我在她清澈的双眼中看到了一只清晰的唐僧。

MM肯定感到了不好意思，因为我的讲解中包含了比喻、类推、排比等我力所能及的各种语文知识，看得出，我很努力，我的语文老师也很努力，所以她委婉地说，能不能简单一点？

我想了想，说，测试驱动时测试数据不全导致程序少考虑一种情况。

MM说，能修复吗？

我说，可以。于是故事结束。

就 是这样，当我们执行一项任务时，围绕这项任务必然会产生许许多多的信息，这些信息对于该任务的执行者是必须的，但是对于其他人则不是，有效的沟通往往来自 于简练的表达即只表达对方需要和可以理解的内容，浩瀚的细节只会将真正想表达的内容淹没。其实这里还有这样一层意思：我之所以用这么多的细节信息来淹没 QA，实际上是不太情愿承认程序里有 BUG。 QA想要的结果很简单，是否是程序 BUG，能否修复。而开发人员则往往把自己的程序与自己关联在了一起，认为程序是自己的扩展，程序有 BUG则意味着自己有缺陷。这一关系明显是矛盾的，可是一些团队里开发人员和 QA能够和平相处，而有些团队却势如水火。

那么，对于单个任务而言，需要定义自己的变量，这些变量数据只与该任务相关，只在该任务里可见。典型的工作流应用于任务执行期间的中间数据存储。在文档处理中，一个重要的功能就是需要提供版本管理，在单个任务实例里，办理者能够管理自己处理过的文档版本。

 

描述

任务能够定义变量，在一个流程实例里，该变量只能被其任务实例所使用。

图 6-2任务级别的数据可见性

如图 6-2所示，我们在任务 B上定义了一个变量 M，此时，在一个流程实例里，只有任务 B的实例才能使用该变量。

 

实现

存在两种实现方式，一种是如图 6-1所示的，在任务节点定义中声明变量，运行期初始化任务实例的同时初始化该变量并使用； 另一种是在流程定义级别统一声明变量，但是各个任务实例都独立初始化并存储该变量。第二种实现方式在各个任务都需要使用同一语义的变量时很常见，例如各个任务实例都会有参与者，我们在流程定义时声明一个名为 userid的变量，在流程实际执行时，各个任务实例都会独自保存有自己的 userid数据。

和前面的章节一样，我们先从一个故事开始，这个故事和晚饭有关。在我家，周一至周五，老婆做饭，我洗碗。每天做完 饭，老婆会叫我到厨房，说，看，这个盘要洗一下，另外，灶台脏了，也要擦。如果放在以前，我会说，好，明白了。但是现在，程序员的生活让我意识到，沟通永 远不是一件简单的事情，我说，好，知道了。

等等，这个故事和本章的主题-数 据模式有一毛钱的关系？这只是一个关于沟通的故事。是的，让我们稍微映射一下：这里，晚饭这个流程包含了两个基本的任务，分别是做饭和洗碗，在做饭这个任 务完成时，任务的执行者（老婆）向下一个任务的执行者（我）传递了数据（要洗哪些东西），正如语言是人之间的沟通方式一样，数据是IT系统之间的沟通方式，语言之间的沟通总是最有效的，数据交互却未必，因为IT系统里的数据交互除了让计算机理解外重要的是还需要人理解，IT系统是对现实生活的映射，也正因为如此，现在数据之间的沟通也在向语言靠拢即语义化（REST/语义网）。

好，言归正传。

在 前两章里，我们分别讨论了工作流的控制模式和资源模式，控制模式关注于如何合理调配业务流程里的任务，从而获得理想的执行效率和收益；资源模式则关注于如 何合理调配可用的资源来执行业务流程。本章将介绍工作流系统里的数据模式，从数据的角度分析工作流系统对数据的处理。数据模式共计39种，在下面的介绍中，我们将这些模式分为了四部分，分别是数据可见性、数据交互、数据传输和基于数据的路由。

本章先会概要重复一下与数据模式相关的一些基本概念，例如流程定义、流程实例、原子任务、块任务等。接下来会对具体的39种数据模式进行讨论，讨论的模式按照应用、描述和实现展开，分别对应着实际场景对模式的映射、模式的介绍和工作流系统对该模式的实现支持。最后是小结。

一、基本概念

1、工作流系统里的流程结构

在正式介绍数据模式之前，让我们先简单回顾一下工作流系统里流程的基本结构。

图 6-1 工作流系统里的流程结构

流程定义：对业务流程的建模和描述，其具有足够的细节信息，能够直接被工作流系统所执行。典型的，流程定义由一系列的任务组成，这些任务以图形的形式展现并被连接起来。

流程实例：流程定义的一个执行实例被称为流程实例。一个流程定义可以存在多个同时执行的流程实例。这些流程实例互相独立执行。

任务：一个任务对应着流程定义里的一个单一工作单元。存在四种不同类型的任务：原子任务、块任务、多实例任务和多实例块任务。

原子任务包含简单且独立的任务定义，当其初始化时只会产生一个可执行的任务实例。

块任务是一系列任务的组合，典型的，工作流系统里存在的子流程任务（节点）即是块任务，当一个块任务开始执行时，其将流程控制权传递给与之对应子流程的第一个任务，当子流程完成执行后则将控制权返回给块任务。如图6-1所示，块任务C对应着一个由任务X、任务Y和任务Z组成的子流程，实际执行时，任务C会触发任务X的执行，任务Z执行完毕即子流程执行完成后则会触发任务C执行完成。

多实例任务在实际执行时会产生多个并行执行的任务实例，这些任务实例一般互相独立执行。当一定数量的实例执行完毕后即会触发后续任务的执行。

多实例块任务结合了块任务和多实例任务的定义，其在实际执行时产生多个任务实例，每个任务实例对应着一个子流程实例。

任务实例：任务的一个执行实例。

2、数据相关约定

我们使用def var ${变量名}定义数据元素，同时def var ${变量名}的声明位置决定了变量的作用范围。如图6-1所示，我们在任务C上定义了一个名为M的数据变量，其的作用范围为任务C，任务级别。

我们使用use(${变量名})表明对变量的使用；使用pass(${变量名})表明数据变量的传递。在图6-1里，变量M从任务C传递至任务E。

对于变量的数据类型，典型的有String、integer、float、boolean、date、time等，很多工作流系统使用序列化和反序列化支持存储任意类型的数据类型，如数组、集合、对象。

3、类比的约定

在后续对各个模式的介绍里，我会围绕一个项目团队的故事进行映射，我们如此约定：

流程定义：我们认为所有成熟的软件公司都会建立起其完整并适用的一套软件开发流程，我们将这套流程看作是这里的流程定义。

流程实例：围绕着软件开发流程，我们会使用这套流程来开始我们实际的软件开发项目，我们将所有的软件开发项目都看作是开发流程的执行实例，即流程实例。

任务：项目开发过程中的各项任务。

数据：我们将团队成员之间的信息交流看作是数据交互。

我们从一个最简单的登录例子开始。

最开始我们需要验证在用户名和密码都正确的情况下，能够正常登录系统，我们这样编写测试代码（以下都是伪代码，使用TestNG和Selenium）：



恩，很不错，运行一下，出现红条。为什么呢？原来测试数据库里没有用户名为user1的用户，好吧，写个数据库数据初始化脚本。再运行，OK，绿条！

那么，接下来我们再增加一个测试，需要覆盖密码错误时不能登录系统的情况，很快测试就完成了：


再运行一下测试，绿条。好啦，现在可以看下这段代码，恩，有些重复，重构一下：



重构完成，可以看到，我们的测试方法里现在没有了任何行为，仅仅是数据！这样让我感觉有点怪，不管了，先用TestNG提供的@dataProvider整理一下：



测试方法只剩下了一个！如果要测试不存在的用户不能登录系统呢？很简单，增加数据即可！



在我们的测试方法里，测试数据和测试的行为进行了完全的分离。从系统的功能来说，功能一旦实现，那么就是一个黑盒，我们只要提供数据即可进行测试，这个数据包括两部分：输入和期待的输出。我开始暗自嘀咕：难道我以前那么多的洋洋得意测试方法很多都是不需要的吗？这些方式为什么会存在呢？恩，想起来了，这些方法是为了覆盖功能的各个路径的，是提高测试覆盖率的。那么为什么会产生这么多的测试方法呢？哦，在这些测试方法里，测试数据和测试行为是耦合在一起的！

我伸了个懒腰，突然想，这下好了，我已经封装好了功能行为，QA想增加测试用例只需要自己增加数据就可以了，嘿嘿，爽啊。说曹操，QA到。QA mm说，你的某个功能实现有问题。我瞅了一眼，说，不可能啊（这是dev面对bug的第一反应），俺有测试的，持续集成一直是绿条的。QA mm说，在你的开发环境下测试是没有问题的，但是在QA环境，因为数据库变了，数据变了，应用服务器变了，所以会有些问题。我极不情愿的登录到QA环境，一测试，还真是，郁闷。

怎么办？修复完BUG，第一反应就是自动化测试能不能跑在QA环境呢？一般情况下，这些测试需要干净的测试环境，我们会制造很多的测试数据，可是在QA环境下，QA有她自己的测试数据，这些数据都不存在了哈。恩，看看刚才的测试代码，哈，就用QA的数据也可以啊，心情愉悦的改下：



OK,完成！为了该测试既能在开发测试环境运行又能在QA环境下运行，我们可以引入一个环境变量，将测试数据扔到文件里，通过环境变量来加载不同的测试数据（测试文件）。

好吧，喝点东西（甲流很厉害，喝板蓝根好了），总结一下：

数据驱动测试：测试数据与测试行为分离，通过数据来驱动测试。

好处：在对测试行为封装好的情况下，QA mm能够自己通过数据修改自动化测试；
      自动化测试能够运行在多个环境下（开发环境、QA环境、产品环境）
      测试的可读性
      测试方法大量压缩

适用范围：功能测试（selenium测试）
          通过环境准备测试数据（非测试用例自己准备数据）

可能存在的问题：比一般的测试编写困难，特别是在静态语言里

最后：该文章的思考来自于徐昊在团队内部的相应Session.

本书关注于IT里的流程产品。面对市场上品种繁多的流程产品，很多人的困惑是：这些流程产品究竟能够帮助企业做出哪方面的改进，这些产品背后的理论基础又是什么？同时，很多人对IT产品的宣传也存在着困惑，最多的就是：工作流技术和BPM（业务流程管理）技术究竟存在着什么区别？为什么很多原先的工作流产品现在都改称为BPM产品？本书将对这些问题都进行一定的讨论，一个事实是IT流程系统将在企业的改进方面发挥越来越重要的作用，但是不可否认的是，就目前而言，这些系统还存在着很多的局限，如果一个流程产品的思想是流程自动化，那么很大程度上这个产品是不符合企业发展需要的。

提到流程，第一个问题就是流程的历史。18世纪英国经济家学亚当·斯密在《国民财富的性质和原因的研究》中提出“劳动分工原理”，提出分工有利于提高效率、增加产量，其理由有三：第一，劳动者的技巧因业专而日进；第二，分工可以免除由一种工作转到另一种工作的时间损失；第三，简化劳动和机械的发明使一个人能做许多人的工作。亚当·斯密的分工论蕴涵了最朴素的流程理念。流程产生于一系列的分工。

维基百科里 对业务流程进行了如下定义：业务流程是为特定的对象（客户）创造价值的过程，这一过程由一系列相关联、有组织的活动或任务组成。企业和组织中，业务流程一 般被划分为三种基本类型：管理流程，对企业运行进行管理、协调的流程；运行流程，构成核心业务和创造基本价值的流程，如采购、制造、市场销售等；支持流 程，支撑管理流程和运行流程的流程，如会计、招聘、技术支持等。

接下来我们关注工作流技术的历史。工作流技术发端于1970年代中期办公自动化领域的研究工作，但工作流思想的出现还应该更早，1968年Fritz Nordsieck就已经清楚地表达了利用信息技术实现工作流程自动化的想法。1970年代与工作流有关的研究工作包括：宾夕法尼亚大学沃顿学院的Michael D. Zisman开发的原型系统SCOOP，施乐帕洛阿尔托研究中心的Clarence A. Ellis和Gary J. Nutt等人开发的OfficeTalk系列试验系统，还有Anatol Holt和Paul Cashman开发的ARPANET上的“监控软件故障报告”程序。SCOOP, Officetalk和Anatol Holt开发的系统都采用Petri网的某种变体进行流程建模。其中SCOOP和Officetalk系统，不但标志着工作流技术的开始，而且也是最早的办公自动化系统。

 可以看到，工作流最初出现的思想和要解决的问题即是实现工作流程的自动化。但是这带来了工作流技术应用的局限：第一是在企业里存在着很多关键的业务流程，这 些流程自动化的成本太高，无法自动化；第二是很多流程并不需要自动化，自动化反而会降低这些流程的执行效率，典型的在一个企业里，请假往往需要一定的审 批，在这种情况下，直接面对面的交流往往比通过工作流提交表单更有效率；第三是自动化流程往往意味着流程的柔性降低，比如制造企业都有设备维修业务过程，基本步骤如下：故障维修申请 －> 审批 －> 派工 －> 领料 －> 维修 －> 验收 －> 维修数据记录。这样的一个维修过程如果用工作流实现，工作流引擎会严格按照这样一个顺序执行，但是车间随手换了一个备件，可能只需要5分钟，而从提交申请到维修结束，走这样一个繁琐的过程，恐怕不是信息系统服务于人了，而是人服从信息系统了，再比如，紧急情况下进行的维修，可能直接进行维修、验收、记录维修数据三个步骤，可能连派工都来不及了。此时，自动化流程就会严重影响执行效率。

1970年 代人们对工作流技术充满着强烈乐观情绪，研究者普遍相信新技术可以带来办公效率的巨大改善，这种期望不可避免的落空了。人们观察到这样一种现象，一个成功 的组织往往会在适当的时候创造性的打破标准的办公流程；而工作流技术的引入使得人们只能死板的遵守固定的流程，最终导致办公效率低和人们对技术的反感。1970年代工作流技术失败的技术原因则包括：在办公室使用个人计算机尚未被社会接受，网络技术还不普遍，开发者还不了解群件技术的需求与缺陷。总结一下，工作流应用失败的原因有两点：第一点是自动化流程的柔性低；第二点则是限于当时的技术原因。

进入1990年代后，随着IT技术的发展、个人计算机的普及，工作流技术开始重新进入一个新的热潮，这个热潮完全是技术驱动的，这时候出现了大量的工作流技术应用。需要注意的是，工作流技术不仅仅是指专门的工作流管理系统，同时也指拥有工作流特征的各种应用系统，例如各类企业管理软件（ERP）和协作软件里有具有的相应流程组件。工作流技术的应用使得很多应用软件的开发得到一定程度的简化（同时，可以观察到工作流产品的采购客户往往会是系统集成商）。需要注意的是，此时工作流要解决的问题域依旧是实现工作流程的自动化，由此带来的应用局限并没有发生变化。

与此同时，新的管理革命正在发生。

1990年迈克尔·哈默在《哈佛商业评论》上发表了题为《再造：不是自动化改造而是推倒重来》(Renglneenllg work：don"t automate，obliterate)的文章，文中提出的再造思想开创了一场新的管理革命。1993年迈克尔·哈默和詹姆斯·钱皮在其著作《企业再 造：企业革命的宣言)(Reengineering the Corporation；a Manifesto for Business Revoiution) 一书中，首次提出了业务流程再造(BPR：Business Process Reengineering)概念，并将其定义为：对企业业务流程进行根本性的再思考和彻底性的再设计，以取得企业在成本、质量、服务和速度等衡量企业绩 效的关键指标上取得显著性的进展。该定义包含了四个关键词，即：“流程”、“根本性”、“彻底性”和“显著性”。

以此为标 志，形成了新的业务流程理念，并伴随着对传统企业金字塔式组织理念和管理模式的反思，新的理念强调企业以业务流程为中心进行运作、打破传统的部门隔阂、增 加客户价值和企业效益（降低成本）。以业务流程为中心取代职能分工，成为管理的首要原则，围绕流程建立起来的组织具有更高的敏捷性、效率和效益，呈现出扁 平化、网络化的特征。

新的管理理念催生新的IT产品，BPM产品孕育而生。可以说一个好的IT产 品总是对应有相应的理论基础，那种简单的对现有工作方式的复制化是没有生命力的（一个小的而典型例子是电子印章软件，从布局到排版都很逼真。可是现实中印 章的设计是为进行文件的状态确认，非常直接，但是在电脑上摹仿这种印章，不但用着别扭，看着也十分难过，更重要的是，明明通过工作流的控制已经能够确认文 件的状态，却一定要通过电子印章来生硬模拟。）。很多技术人员以XPDL和BPEL来区分流程产品是工作流还是BPM，认为BPM更为强调软件的系统集成能力。实际上，工作流软件与BPM软件最大的区别不在于技术实现，而是它们解决的问题域发生了变化。

工作流软件解决的问题域是流程的自动化，而BPM软件解决的问题则是业务流程的优化。

因为解决的问题域发生变化，那么BPM软件相比工作流软件在技术上的变化就很清晰了：强调对流程运行的监控、强调对流程运行数据的分析、强调对各种企业应用软件的集成能力、强调快速的开发能力。实际上很多BPM软件的前身即是工作流产品，从技术角度上理解，工作流软件和BPM软件是没有区别的，BPM软件是工作流软件发展的结果，只是开发商出于市场的考虑换上一个不同的标签而已（非常类似于当前的药品市场，同一种成分换个名称就变成新药）。然而从处理问题的角度考虑，区别两者则又是必要的。

但是BPM软件面临的问题依旧存在，因为很多BPM软件解决问题的思路并不正确，很多BPM软件依旧是通过自动化流程来实现业务流程的优化，这再次回到工作流软件所面临的问题：企业很多业务流程很难自动化、自动化流程的柔性很低。对于这些问题，BPM软件试图通过简化编程（快速开发、SOA思想）和系统集成来尽可能自动化多的流程，通过增强流程定量分析能力来尽可能的增加流程柔性。这实际上是在用正确的方式做错误的事，因为解决问题的思路从一开始就决定了这并不是一条正确的路。

相比而言，Nimbus的Control-ES软件则选择了另外一条道路，它并不强调流程的自动化，它是从咨询软件发展而来的，这决定了其解决问题的另外一种方式：强调对现有流程的评估和重构而非自动化。在Control-ES里，流程是作为企业财产保存的，仅仅文档化。这几乎立刻扩大了其对业务流程的描述能力，但是其的咨询背景也决定了它的局限性：无法实时获取业务流程执行的数据（完全依靠咨询人员的工作），于是Control-ES更多是作为咨询人员的工具而存在的。从某种意义上说，流程改进本来就是一项咨询工作，很多IT厂商甚至没有任何业务领域经验，拿出其BPM软件就宣传能够实现客户流程的优化是一件很搞的事情，很多所谓的流程梳理实际仅仅是对现有流程的复制再现，没有任何改进可言。

          一种更好的方式是文档化所有业务流程，然后通过系统集成能力实时获得关键的数据信息，实现以流程为中心的数据撮合，关键的流程执行和改进则交由人去灵活执行。对这种实现思路我们将在本书的最后部分进行讨论。可以看见的是，流程优化从来也不应该是IT系统能够完成的事情，IT系统所要做的是为流程优化撮合必需的数据，做为支撑系统而存在。

          说完BPM软件，最后我们需要关注的一个方向是云计算。越来越多的企业将其工作放置到了网上，典型的如Google提供的各种在线服务，文档、邮件、Excel等，这种趋势触发了新的业务模式，云中的工作流即是其中一种，通过提供在线的工作流程自动化，将各种在线服务通过流程粘合起来。在这方面，Cordys走在了最前面。

我们知道，一个商业目标的实现必定由一系列 的活动组成，这些活动的编排即构成了以目标为导向的业务流程。管理的目标即通过合理有效的编排这些活动以期以最少的成本达到最大的收益。这个编排的过程亦 即进行业务流程建模的过程。在进行业务流程建模时反复出现的活动结构构造即产生了模式。在本章中，我们将讨论工作流的控制模式。控制模式关注业务流程中活 动的编排，一方面强调与实际业务的契合，另一更为重要的方面则是如何合理调配这些活动。

 

本章讨论的控制模式共计43种。需要注意的是，这些模式的出发点是基于对实际业务进行描述的，与具体的工作流系统没有太大的关联。而一个工作流系统对工作流模式的支持程度则直接决定了该系统对业务的建模能力。所以在某种程度上，衡量一个合适的工作流系统时，往往会考虑其对工作流模式的支持程度。

 

本章讨论的控制模式按照描述、应用和实现展开，分别对应着模式的介绍、模式对实际业务的映射和工作流产品对该模式的实现支持。最后是小结。作为约定，我们将业务流程里的活动映射为任务，将对活动的建模描述映射为任务节点。

 

一、       基本控制模式

基本控制模式包括5个模式，是其他控制模式的基础。

 

1、顺序（WCP_01: Sequence）

描述

在同一个流程实例里，任务会在前续任务完成后顺序触发。

图 4-1

如图4-1所示，任务A执行完毕后会顺序触发任务B的执行，任务B执行完毕后会顺序触发任务C的执行。

 

同义词

顺序执行、串行路由。

 

应用

顺序模式是工作流建模的基础，是流程定义里最基本的构建块，用以描述连续串行的一系列任务，这些任务之间的触发是无条件的。

顺序模式也是实际的业务中应用最多的模式， 当实现一个业务价值需要执行多个任务时，最自然的方式就是排序并顺序完成这些任务，典型的如流水线作业。当企业人数不多，业务模式简单（不需要过多的任务 或任务之间存在很强的线性依赖关系），管理成本很低时，顺序模式是最自然的选择。

 

2、并发分裂（WCP_02: Parallel Split）

描述

分支分裂为两个或多个后续分支，当分支执行完毕后触发后续并发分支的同时执行。并发的分支有可能在后续合并为一个分支，也可能不合并。

图 4-2

如图4-2所示，任务A完成后将同时触发任务B和任务C的执行，任务B和任务C的执行不存在前后关系。

 

同义词

AND-split、Fork、并行路由、并行分裂。

 

应用

在传统的软件开发里，开发过程被典型的分为了5个阶段，如下图所示：

图 4-3

这5个 阶段是顺序执行关系，典型的当需求分析完毕后会有一个需求冻结状态，在这种状态下才开始正式的软件设计和实现。该模式最大的弊端在于在需求分析阶段不可能 捕获用户所有可能的需求，而且客户的需求是变化的，开发阶段由于需求冻结对于客户完全黑盒，导致最后的交付无法实现客户期望的业务价值。

在敏捷开发里，开发过程由多个迭代组成，在每个迭代里，需求分析、架构设计、编码开发、测试和交付都是同时进行的，客户参与到这个过程中，客户能够从不断的交付中提出新的需求，这样软件才能够更好的响应变化，不至于在最终交付时出现业务价值的偏差。

图 4-4

其实从某种角度上看，不同企业的组织管理结构也决定了它所采用的业务流程模式。在图4-3所 示的开发流程里，每个阶段都对应于不同的部门，需求分析有专门的业务部门，开发部门内部分为了架构部门、开发部门和测试部门，交付则又有专门的实施团队， 在这种情况下，从管理的成本考虑，顺序执行无疑是最自然和最便宜的选择（这也是为什么在传统企业里实施敏捷困难的原因之一）。

而在敏捷开发团队里，整个团队则是围绕开发流程建立，减少了内部不必要的协调沟通成本，能够达到相对较高的执行效率。

 

实现

由于后续分支的触发是无条件的，所以在很多工作流产品的实现里省去了AND-split节点，直接由任务节点进行分支分裂，如下图4-5所示：

图 4-5

jBPM使用token记录当前流程实例执行的位置并触发流转，建立起token的父子关系。如下图所示，在AND-split节点每个并发的分支都会产生一个新的子token，当子token到达AND-join节点后即可通过其访问到它的父token，再通过父token遍历其子token即可获得当前并发分支的执行情况并实现合并。

图 4-6

作为约定，我们在后续的说明中，将会采用token来指代当前流程实例所执行的位置。

 

3、同步（WCP_03: Synchronization）

描述

两个或多个分支合并为一个后续分支，当被合并的分支都执行完毕后，后续分支才被触发。

图4-7

如上图所示，当任务A和任务B都完成后，才会触发任务C的执行。

 

同义词

AND-join、汇聚、同步。

 

应用

在实际的应用中，AND-split节点与AND-join节点一般成对出现。

在任何时候，总结总是有必要的，每次迭代开发结束后，我们都会进行迭代小结，写出应该改进的部分、应该保持的部分，以保持整个团队的迭代前进。

实际上，很多情况下AND-split节点和AND-join节点往往隐含着管理意义，上一级的管理者在AND-split节点进行任务的管理和下发，在AND-join节点对任务执行结果进行负责。

 

实现

和AND-split节点一样，在部分工作流产品里，直接采用任务节点进行分支合并，如下图所示：

图 4-7

jBPM里，分支的合并实际是token的合并，子token生命周期终止，父token重新激活。

 

4、排他选择（WCP_04: Exclusive Choice）

描述

分支分裂为两个或多个后续分支，当分支执行完毕后只能选择触发一个后续分支执行，即多选一。

图 4-9

如上图所示，任务A完成后将会选择触发任务B或任务C的执行，任务B和任务C之间只能选择一个执行。

 

同义词

XOR-split、排他OR-split、条件路由。

 

应用

流程里的决策任务。会存在两种决策方式：人为决策和系统决策。由人或一组系统设定条件根据流程执行情况作出后续执行路径的选择。

 

实现

两种实现方式，一种是在XOR-split节点定义路由选择条件（图4-10）、一种是在后续转移线上定义触发条件（图4-11）。

图 4-10

图 4-11

条件的计算有多种方式：工作流变量与相应条件定义值简单匹配、提供接口由具体实现类返回计算结果、规则引擎进行规则匹配计算。同时，当存在多个后续分支和条件判断时，一般会定义一个默认执行分支。

 

5、简单合并（WCP_05: Simple Merge）

描述

两个或多个分支合并为一个后续分支，任何一个分支执行完毕后就会触发后续分支的执行，不需要同步，遵循先进先出的原则。需要注意的是：该模式有个前提条件，即前续分支有且只有一个会执行。

图 4-12

如上图所示，任务A或任务B只要有一个完成都会触发任务C的执行，但是任务A和任务B有且只有一个可以执行。如果任务A和任务B都有可能执行，则变为另外一个模式：多合并模式（WCP_08）。

 

同义词

XOR-join、排他OR-join、merge。

 

应用

在实际的应用中，为保证该模式的前提条件，一般XOR-join节点与XOR-split节点成对使用。

 

实现

和AND-join节点一样，因为不需要任何条件判断，所以在部分工作流产品里，直接采用任务节点进行分支简单合并，但是需要和AND-join做出区别，如下图所示：

图 4-13

6、基本控制模式小结

基本控制模式非常简单，实现起来也没有太大的难度。需要注意的是，对于一种模式往往会存在多种实现方式，笔者的建议是：将条件判断的节点独立出来，由其负责条件计算和路径选择，而任务节点则只关注于实际业务的执行，做到职责分离。例如，AND-split、AND-join、XOR-split和XOR-join节点都会单独存在。

可以看到：除去AND-split和AND-join节 点，顺序、排他选择、简单合并模式组合的流程和我们编写程序的逻辑流程图非常的相似，也就是这三种模式能够对程序的逻辑流程图进行建模。于是一件有意思的 事情出现了：有快速开发平台产品使用流程引擎来编排程序逻辑。他们的做法是将细粒度的代码逻辑封装为运算构件，然后再通过流程的可视化编辑器将这些运算构 件粘合起来。这样，传统方式下采用代码实现业务逻辑的过程变成了画流程图的过程。笔者认为这样的实现存在相当大的弊端，相当不合理。首先，编写代码变得复 杂了，明明几十行代码能够实现的逻辑却需要经过编写构件、绘制程序流程图、部署、运行好多步才能实现，编程效率可以想象；其次是代码的执行效率低，程序的 运行需要经过一次流程定义的解释才能执行；然后是这种实现完全牺牲了语言自身的特性，面向过程，很难提供代码级别的单元测试环境，只能提供有限的调试。该 实现实际上是定义了一种简单的流程语言，通过该流程语言来进行功能函数（运算构件）调用的编排。任务编排没有问题，服务编排也没有问题，但是如果编排细粒 度到功能函数，那么就超出了流程引擎的作用域。提升编程效率的最好途径总是语言而不是工具。

六、自动开始模式

在前面的资源模式里，我们讨论了创建模式、推模式和拉模式，它们实际对应着工作项的一个正常生命周期：创建、提供/指派、资源选取开始执行。在前面的讨论里，工作项的执行都是由资源驱动的（从工作项待办列表里选取执行），而自动开始模式则提供了一种系统驱动工作项执行的方式，系统直接驱动工作项执行往往表明了该工作项的最高优先级，需要马上开始执行。

图 5-42

如图5-42所示，自动开始模式对应着红线标识着的工作项的状态变迁，共有4种模式：创建即执行、指派即执行、成堆执行和链式执行。

 

1、创建即开始执行（WRP_36: Commencement on Creation）

描述

资源能够在工作项一创建完毕就开始执行。

图 5-43

如图5-43所示，任务A工作项一创建就插入员工甲的办理列表，需要员工甲马上开始执行。

 

应用

该模式应用在关键的优先级高的任务里，通过系统推送，强制资源优先执行该任务，省去任务的等待时间。

 

实现

该模式的实现实际是系统同时完成了工作项的创建和推送，系统需要确定具体的执行人，工作项不会分配给角色、岗位等资源组以提供给相应资源进行选择。

 

2、指派即开始执行（WRP_37: Commencement on Allocation）

描述

资源能够在工作项一指派完毕就开始执行。

图 5-44

如图5-44所示，任务A工作项一旦被员工甲从可拾取列表拾取就马上插入员工甲的办理列表，需要员工甲马上开始执行。

 

应用

该模式跳过了工作项的指派状态，实际是对创 建即开始执行模式的扩展，在创建即开始执行模式里，工作项必须预先确定明确的执行人，不能分配给角色、岗位等资源组，而在该模式里除了支持创建即开始执行 模式里的情况，同时也提供了对这种情况的支持，工作项可以提供给多个资源拾取，一旦一个资源拾取则必须马上开始执行（从这个角度看，该模式与资源驱动执行-提供工作项模式是相同的）。

 

 

3、成堆执行（WRP_38: Piled Execution）

描述

资源能够成堆执行相同任务的不同工作项。

图 5-45

如图5-45所示，员工甲有多个任务A的工作项需要执行，这些注意的是，这些工作项并不是由一个任务实例所产生的，它们属于不同的流程实例，是由多个流程实例里的任务A生成的。一旦员工甲开始任务A工作项的执行，那么他将执行所有任务A的工作项，即将任务A相关的工作项全部打包执行。这一功能由系统驱动，系统将与任务A相关的工作项依次推送至资源的办理列表。

 

应用

开发人员甲熟悉持续集成工具，此时同时有多个软件开发项目需要搭建持续集成环境。一旦他为某个项目组搭建了持续集成环境，那么处于执行效率的考虑，最好的方式无疑是他一鼓作气将所有的持续集成环境都搭建完毕。

相同/相似的工作交由同一资源一并执行，这些工作具有完全或大部分相似的执行上下文（相同的知识、能力要求），从这个角度能够达到最高的工作效率。

 

实现

系统需要在进行工作项状态变迁操作时提供相应的钩子，以进行相应的回调操作。

 

4、链式执行（WRP_39: Chained Execution）

描述

在一个流程实例里，当前一个任务的工作项执行完毕后，能够自动开始执行下一个任务的工作项。

图 5-46

如图5-46所示，任务A和任务B是两个连贯的任务，它们都分配给员工甲执行，当员工甲执行完毕任务A的工作项后，任务B生成的工作项将马上被系统发送至员工甲的办理列表，员工甲需要马上办理。

 

应用

该模式实际是将资源胶黏在一个流程实例上，同样是出于执行效率的考虑（两个任务位于同一流程实例里，具有相同的执行上下文）。该模式的应用具有前提条件：流程定义时，连续的任务由相同的资源进行处理。

 

七、可见性模式

可见性模式讨论各种不同资源对工作项的可见 性，不同的资源由于角色、权限的不同，对工作项拥有不同的可见范围。由于涉及到权限，那么根据不同的组织机构设置，必然会出现不同的工作项权限分配，这里 不讨论具体的工作项权限分配，仅从工作项的状态来讨论这些工作项区分可见性的必要性。

可见性模式包括2种：未指派状态工作项的可见性和指派状态工作项的可见性。实际上，工作项处于执行状态或完成状态也存在不同的可见性。

 

1、可配置的未指派工作项的可见性（WRP_40: Configurable Unallocated Work Item Visibility）

描述

能够配置未指派工作项的可见性。

图 5-47

如图5-47所示，可拾取列表里存在3个工作项：任务A工作项、任务B工作项和任务C工作项。员工甲可拾取的工作项包括：任务A和任务B工作项；员工乙可拾取的工作项包括：任务B和任务C工作项，那么由此产生的可见性是：员工甲只能看到任务A和任务B工作项，而员工乙则只能看到任务B和任务C工作项。而作为员工甲和员工乙的部门经理，他需要了解每个属下的工作情况，所以他可以看见所有甲乙可见的工作项。

 

应用

随着企业规模的发展，几乎所有企业的组织模 型都会形成金字塔型的结构，一方面是出于分工的需要，另一方面则是出于管理的需要，每一层级的人员都需要对上一级负责，同时管理下一层级的人员。处于管理 的需要，管理者必然需要了解下属的工作情况，这样权限就自然产生了，具体到工作流的任务里，管理者需要对其所管理下属的工作具有可见性。

其实不仅仅是对于工作项，对于流程实例本身 也具有可见性的分配。对流程负责的人必然具备最大的可见性和权限，流程根据任务分解，如果仅仅只对某一任务负责，那么则只对该任务具有可见性，而如果需要 对多个任务负责，那么就需要对多个任务具有可见性，最直接的负责人就是具体执行该任务的人员，但是引入管理的层级后，职责的承担也会形成层级的关系，从上 至下层层承担，此时担负最大职责的人员往往不再是具体的工作执行人员，而是相应的管理人员。

 

实现

在前面所描述的情况里，支持员工甲乙的可见性是比较简单的，因为每条工作项记录都携带有参与者信息，但是部门经理显然不在这些参与者信息里，所以需要引入与组织权限模型相匹配的工作项查询机制，即不同于工作项列表的查询列表。

 

2、可配置的指派工作项的可见性（WRP_41: Configurable Allocated Work Item Visibility）

描述

能够配置已指派工作项的可见性。

图 5-48

如图5-48所示，待办列表里存在3个工作项：任务A工作项、任务B工作项和任务C工作项。指派给员工甲的工作项包括：任务A和任务B工作项；指派给员工乙的工作项包括：任务C工作项，那么由此产生的可见性是：员工甲只能看到任务A和任务B工作项，而员工乙则只能看到任务C工作项。而作为员工甲和员工乙的部门经理，他需要了解每个属下的工作情况，所以他可以看见所有甲乙可见的工作项。

 

八、多资源模式

到目前为止，我们讨论的工作项都是与某一特定资源一一对应的，即一个工作项只能由一个单一资源执行，或者严格来说，一个工作项在任何时间段都只能由一个单一资源执行（考虑到工作移交的情况）；同时，一个资源在任何一个时间段都只能处理一个工作项。

多资源模式将会讨论两种不同的情况：一个资源同时执行多个工作项、多个资源执行同一个工作项。

 

1、同时执行（WRP_42: Simultaneous Execution）

描述

资源能够同时执行多个工作项。

图 5-49

如图5-49所示，员工甲的办理列表里有三个工作项，他能够同时执行这三个工作项。

 

应用

和计算机一样，虽然在任何时刻都只能处理一项工作，但是通过将多项工作切分成多个线程交替执行，从某个时间段看，人能够同时处理多项工作。

人能够选取相关联的多个工作，同时开始执行，在执行的过程中，合理安排这些工作的执行时机和顺序。

 

实现

几乎所有的工作流系统都不会约束人员往自己的办理列表里增加多个工作项。

 

2、增加资源执行（WRP_43: Additional Resources）

描述

资源能够要求增加资源来处理他正在执行的工作项。

图 5-50

如图5-50所示，员工甲和员工乙同时处理一个工作项。

 

应用

在一些复杂的场景里，一项工作往往需要多个资源共同协作完成。

典型的在一个会签任务里，一个发文需要多人签字通过，同时在会签过程中，经常出现动态加签的情况：需要新的人员加入进行签字。

在敏捷开发里，所有的开发工作都是由两个开发人员共同结对完成。

 

实现

工作项作为工作流系统里最小的工作单元，如果将其分配给多个资源，无疑会增加编程模型的复杂度。最常见的实现方式是增加工作项，一个任务节点对应多个工作项，对于需要增加资源的情况，增加工作项。

 

九、小结

在本章里，我们讨论了工作流的43种资源模式，这些模式分为7类，分别是创建模式、推模式、拉模式、折回模式、自动开始模式、可见性模式和多资源模式。

创建模式在系统创建工作项时生效，其位于工作项生命周期的创建阶段，创建模式作为流程模型的构成部分在流程设计期指定，通常在任务节点的定义里进行定义，与一个任务关联，其用来限定可执行该任务的资源范围。系统根据创建模式限定的资源范围生成工作项。

接下来，系统需要将工作项推送给相关的资源进行执行，这个推送的过程即是推模式所包含的内容。工作流系统通过工作项管理器即不同类型的工作项列表与用户进行交互，这里的推送可以理解为系统将生成的工作项推送至相应资源的工作项列表里。

推模式的主语是系统，由系统将工作项推送至资源的工作项列表，那么，接下来的主动权交由单个资源本身，由其拉动工作项的执行，这是拉模式所包含的内容。

实际工作中，工作的执行状态不可能总是与预想相符的，总会出现各种各样的情况，例如重新分配、重做、挂起等等。折回模式对应着这些情况，折回代表着工作项状态的反复、回退。

自动开始模式提供了一种系统驱动工作项执行的方式，系统直接驱动工作项执行往往表明了该工作项的高优先级，需要马上开始执行。

可见性模式讨论各种不同资源对工作项的可见性，工作项自身作为资源与权限相关。

多资源模式讨论一个资源执行多个工作项和多个资源执行同一个工作项的情况。

从这些模式的讨论可以看出，这些模式更多关 注的是对实际业务执行的场景描述，关注通过合理分配任务和调配工作的执行为组织带来最大的执行效率。从另一个角度看，由于这些模式都以业务作为出发点，这 给工作流系统的实现带来了复杂性，很多模式当前的工作流系统都无法完全支持或直接支持。在很多情况下，模式的支持需要很多的约束，而这种约束往往需要在工 作流实施阶段结合客户具体情况进行限定，这实际强调了工作流实施的重要性，工作流系统的应用是由工作流产品加实施两部分组成，很多时候，实施占据了更大的 比重，这就对工作流产品的可扩展性提出了要求。应用工作流不仅仅是选择工作流产品，更重要的还包括选择合适的实施团队。

在下一章里，我们将讨论另外一种工作流模式-数据模式。

五、折回模式

实际工作中，工作的执行状态不可能总是与预想相符的，总会出现各种各样的情况，例如原本分配给员工甲的任务由于甲要请假不得不重新分配，由于新的紧急任务员工乙当前的工作需要挂起一段时间等等。折回模式则刚好对应着这些情况，折回代表着工作项状态的反复、回退。

图 5-33

如图5-33所示，折回模式对应着红线标识着的工作项的状态变迁。这些状态变迁对应着以下情况：

委派：资源将先前指派给他的工作项委派给他人执行。

系统重新分配：系统将没有完成的工作项重新提供或指派给其他资源执行。

退回指派：资源撤销指派给他的工作项，工作项可以重新指派给其他资源。

工作移交：资源将其已经开始执行的工作项移交给他人执行。

挂起/恢复执行：资源临时挂起当前执行的工作项，并在某一个时候重新恢复执行该工作项。

跳过：资源选择跳过指派给他的工作项的执行，不执行该工作项。

重做：资源重新执行先前已经完成的工作项。

提前执行：资源在流程实际触发该工作前已经开始执行该工作。

折回模式共有9种。

 

1、委派（WRP_27: Delegation）

描述

资源能够将先前指派给他的工作项指派给另外的资源执行。

图 5-34

如图5-34所示，委派对应于红线标识着的工作项状态变迁。

 

应用

委派在平常工作中非常常见，例如员工甲将要请假，他将他要完成的工作委派给同事乙执行；在协同办公里，领导将相关工作委派给下属执行等等。

 

实现

实际应用中，委派按照粒度分为了两种：一种 是工作项的委派，这是一种细粒度的委派，指单一任务实例的委派，与某一特定的任务实例关联；另一种是业务的委派，这是一种粗粒度的委派，例如，员工甲将其 负责的某类业务的工作全部委派给员工乙，这意味着属于这类业务的所有工作都将由员工乙执行。业务的委派通常与权限紧密关联，实际实现时为避免用户权限的混 淆，一般采取分开登录系统的方式进行实现，即员工乙如果想处理员工甲委派给其的工作，则需要用员工甲的账号和其给定的密码重新登录系统，并注销掉自己账号 的使用。

需要注意的一点是：委派意味着原先指派的资源还必须对该工作负责，例如员工甲将某项工作委派给员工乙执行，尽管员工乙实际执行了该工作，但该工作仍然必须由员工甲负责。所以在实现中，员工甲必须能够保持对委派工作项的追踪和控制。

 

2、系统重新分配（WRP_28: Escalation）

描述

系统能够重新分配已经分配的工作项，以加快工作项的执行。

图 5-35

如图5-35所示，工作项原先提供或指派给了一个或多个资源执行，现在由于各种原因，需要优化该工作项的执行，所以将该工作项收回重新分配，提供或指派给其他的资源。

 

应用

工作分配的优化。很多时候，计划跟不上变 化，工作也是这样，分配工作前有许多的考虑因素，例如个人能力、工作经验、技能要求等等，但在实际工作中往往会发现原先的人力分配并不合理，或者有些人承 担了太多的职责，或者有人能力超出其目前担承的职责等等（在敏捷软件开发里，我们通过频繁的交换结对编程以达到部分的平衡），在这种时候就需要对工作进行 灵活的重新分配以到达最高的执行效率。

 

实现

实际实现中非常受限，对流程的优化始终是一 个对人的命题，而不是对机器对工具的命题，工具所能做到的只是尽可能多的提供可供参考的数据模型，例如各种报表、数据分析等等，最后做出决策的还是人。所 以该模式的实现也以提供给流程管理员重新分配工作项的能力为主，同时提供工作项超时的提示为辅。

 

3、退回指派（WRP_29: Deallocation）

描述

资源撤销指派给他的工作项，工作项可以重新分配给其他资源。

图 5-36

如图5-36所示，资源能够退回原先指派给他的工作项，该工作项可以交由系统重新分配给其他资源。

 

应用

同样是工作分配的优化，只不过该模式由资源驱动。

实际工作中，由于各种原因，例如经验不足、当前承担职责过多等等，发现自己并不能很好完成当前的任务时，可以提出不执行该任务。

 

实现

实现的难点在于资源退回工作项后的重新分配，即如何重新分配该工作项。

与提供给多个资源模式对应，该模式的最简单支持是退回重新提供给多个资源。例如工作项分配给开发人员这一角色执行，开发人员甲拾取了该工作项（故事卡），经过一番痛苦和彷徨，最终将该工作项退回，这样所有开发人员又都能拾取该工作项。

 

4、有状态工作移交（WRP_30: Stateful Reallocation）

描述

资源将正在执行的工作项移交给其他资源执行，该工作的状态将得到保存。

图 5-37

如图5-37所示，资源将已开始执行的工作移交给其他资源执行。该模式与委派模式很相似，差别就在于委派模式是将未开始执行的工作进行重新指派执行，而该模式则是将已开始执行的工作进行重新指派执行。委派模式中的委派者仍需要为委派出去的工作负责，而移交则同时意味着责任的移交。

 

应用

工作移交非常常见，最常见的原因包括位置调动、离职、休假等等。

 

实现

在大多数的工作流系统实现里，业务数据与流程数据是相互隔离的，仅仅通过某一字段进行关联（例如业务主键），流程的目标是携带业务数据进行流转。在这种情况下，该模式的实现变成了默认实现，系统不需要做任何回退或清理操作，直接做工作项的转发即可。

 

5、无状态工作移交（WRP_31: Stateless Reallocation）

描述

资源将正在执行的工作项移交给其他资源执行，该工作的状态不会得到保存。

与有状态工作移交对应。

 

应用

工作的无状态移交通常意味着工作的重新执行，并且原有的工作对重启的工作而言没有太大的价值。

 

实现

与有状态工作移交相比，该模式需要处理相应业务数据的回退或清理。直接支持该模式比较困难，需要在实施时根据情况对该任务节点操作业务数据的权限进行限定，并在限定的基础上进行记录和回退。

 

6、挂起/恢复执行（WRP_32: Suspension/Resumption）

描述

资源能够挂起当前执行的工作项，并在某一个时候重新恢复执行该工作项。

图 5-38

应用

资源对分配给其的工作进行优化执行，能够根据自己和当前的实际情况合理的安排工作执行，挂起正在执行的工作，执行当前最重要或效率最高的工作，然后再返回执行该工作。

 

实现

基本的状态变迁。

 

7、跳过（WRP_33: Skip）

描述

资源能够选择跳过指派给他的工作项的执行，不执行该工作项，并将该工作项标识为完成。

图 5-39

 

应用

实际工作中，对于非关键工作，可以选择跳过，以便进行后续更为紧急或重要的工作。

 

实现

对于实现工作项本身的状态变迁来说，支持该模式非常简单，问题在于业务数据的依赖关系，如果后续工作的处理依赖于该节点处理后的业务数据，那么简单的选择跳过该工作项的执行就会产生问题。所以一个好的做法是给一些关键任务节点加上约束，不允许执行跳过操作。

 

8、重做（WRP_34: Redo）

描述

资源能够对先前完成的工作项重新处理，同时，该工作的后续工作项（后续任务所对应的工作项）也将被重新处理。

图 5-40

 

应用

对已完成的工作进行重新处理并不少见，但该 模式最为重要的部分还是在于要求所有后续工作的重新处理。所以该模式一般应用在极其重要的关键任务节点，例如非常重要的决策节点，因为后续的任务严重依赖 于该节点所作出的决策（所产生的数据），一旦决策发生变化，那么相应的后续工作必须都要做出变化。这也是业务敏捷性的一种反映。同时需要注意，该模式也是 一种代价高昂的应用，因为这往往意味着该业务流程实例中的很多工作都需要重新处理，所以如何在业务处理中尽早发现可能的环境变化并及时作出决策的调整并避 免成本高昂的返工才是最为重要的一点。

现在的软件开发越来越强调于拥抱变化，强调 代码的重构和演进，尽管如此，如果软件的基础架构需要根据当前业务变化发生重大变更，那么这依旧是一件成本高昂的事情，因为一旦基础架构发生变化，那么很 多模块实现将不得不重新编写代码。所以尽管越来越多的开发团队开始引入敏捷的开发方法，但是经验丰富的开发人员才是整个敏捷团队的基石（敏捷开发非常重视 人）。

 

实现

从该模式里能够看到资源模式与控制模式的结合，工作项的重做需要后续任务的重新执行，这需要取消当前的执行任务，并将流程实例的控制点重新返回至该工作项所对应的任务。这涉及到两种控制模式，分别是：取消任务模式和任意循环模式（具体可以参考第四章的说明）。

 

9、提前执行（WRP_35: Pre-Do）

描述

在工作项实际提供或指派给资源执行之前，资源已经可以执行该工作项。

图 5-41

如图5-41所示，任务A还在执行，任务B还未激活，但此时员工甲已经可以开始执行任务B的工作项。该模式的实现需要一个前提条件：任务B不能依赖于任务A的执行结果，即不能依赖于前续任务的处理输出。

可以看出，该模式与前面推模式里的提前分配模式非常相似，所不同的是：提前分配强调一种通知机制，强调预先准备；而提前执行则已经可以开始实际的执行工作。

 

应用

和提前分配模式不同，该模式实际提供了一种 流程任务执行的灵活机制，在预先定义的业务流程里，任务的执行是具有一定顺序的，可能在大多数情况下，这种顺序是合理的，但是在某些具体的流程实例里，某 些串行执行的任务节点可以并行的执行以达到最好的执行效率和负载均衡，在这种情况下，就可以应用该模式并行执行部分任务。

需要注意的是，该模式仅仅引入了一种实际执行任务的灵活性，是对业务流程定义固化的补偿，如果在一个业务流程中频繁应用到该模式，则往往意味着流程定义本身需要作出调整。

本书全文连载地址
四、拉模式

与推模式相比，拉模式的区别在于动作的主语发生了变化：推模式的主语是系统，由系统将工作项推送至资源的工作项列表，那么，接下来的主动权交由单个资源本身，由其拉动工作项的执行。

图 5-28

如图5-17所示，拉模式对应着工作项的五种状态变迁：

由提供给一个资源拾取到指派给一个资源负责执行，这意味着该资源拾取了该工作项，其将负责该工作项的执行，并将在未来的某个时候执行该工作项；

由提供给多个资源拾取到指派给一个资源负责执行，这意味着多个资源中的一个资源拾取了该工作项，其将负责该工作项的执行，并将在未来的某个时候执行该工作项，余下的资源将不再有机会执行该工作项；

由提供给一个资源拾取到开始执行，这意味着该资源拾取了该工作项，其将负责该工作项的执行，并立即开始执行该工作项；

由指派给一个资源负责执行到开始执行，这意味着该资源开始执行该工作项；

由提供给多个资源拾取到开始执行，这意味着多个资源中的一个资源拾取了该工作项，其将负责该工作项的执行，并立即开始执行该工作项，余下的资源将不再有机会执行该工作项；

拉模式共有6种，分为两组：前三种模式关注工作项的状态变迁；后三种模式关注工作项显示在资源工作项列表里的顺序以及选择执行的方式。

 

1、资源驱动指派（WRP_21: Resource-Initiated Allocation）

描述

资源能够将工作项指派给自己，负责该工作项的执行，但是不必马上开始执行该工作项。

图 5-29

如图5-29所示，员工甲拾取了可拾取列表里的任务A工作项，该工作项由可拾取列表移至待办列表。可拾取列表通常是一个共享的列表，而待办列表则是某一资源的专属列表。资源拾取工作项，意味着工作项从共享状态进入到专属状态。

该模式实际对应着工作项的两种状态变迁：由提供给一个资源拾取到指派给一个资源负责执行；由提供给多个资源拾取到指派给一个资源负责执行。

 

应用

该模式符合大多数的工作场景，我选择负责执行该工作，但我并不马上开始，我可能还有其他的工作需要处理，等到处理完毕后才处理该工作。

 

实现

分配给角色、部门等资源组的工作项通常都以共享的形式分配给所有的组内成员，一旦有人拾取即进入他的专属待办列表，其他人不再可见。

 

2、资源驱动执行-指派工作项（WRP_22: Resource-Initiated Execution – Allocated Work Item）

描述

资源能够开始执行指派给其的工作项。

图 5-30

如图5-30所示，员工甲开始执行任务A工作项，该工作项由待办列表移至办理列表。

该模式对应着工作项的一种状态变迁：由指派给一个资源负责执行到开始执行。

 

实现

最基本的工作项状态变迁，所有的工作流系统都提供支持。

 

3、资源驱动执行-提供工作项（WRP_23: Resource-Initiated Execution – Offered Work Item）

描述

资源能够选取提供给其的一个工作项，并马上开始执行该工作项。

图 5-31

如图5-29所示，员工甲拾取了可拾取列表里的任务A工作项并立刻开始执行，该工作项由可拾取列表移至办理列表。

该模式对应着工作项的两种状态变迁：由提供给一个资源拾取到开始执行；由提供给多个资源拾取到开始执行。

 

应用

与描述略有不同，实际应用该模式是强制要求资源一旦拾取了共享的工作项就必须马上开始执行，基于两点的考虑：一是工作项能够尽快执行；二是工作项能够指派给当前最为空闲的资源，不会出现该工作项被一繁忙资源卡住，造成等待和阻塞。

在敏捷开发里，我们使用故事卡管理项目的开 发，故事卡足够小（如果大的故事卡则分解为多个任务），每天早上由开发人员挑选移动该卡，一旦该卡由可开发状态移动至开发状态，则必须进行该卡的开发工 作，这样项目的真实进展随时得到显示，同时不允许一个开发人员同时进行多张卡的开发。

 

实现

通过这三个模式我们可以发现，工作流系统实现这些模式只是在不同的工作项列表里移动这些工作项，以反映工作项不同的状态和变迁策略，这对于IT系 统而言这不是很困难，困难在于如何能保证人确实是这么做的，例如说一旦拾取就必须开始执行，工作项的跳转很简单，但无法保证的是拾取该工作项的人一定会按 照要求马上开始执行该工作项，也就是说业务流程项目的实施不仅仅包含技术实施，也包含了一套与之相应的管理实施。那种期望上一套流程系统就能马上提高生产 效率和管理水平显然是不现实的，其中一定包含管理方式的变化和组织机构的变化。

敏捷开发中，早上的站立会议是重要的部分，每个团队成员都会汇报昨天的进展和今天将要进行的工作，这样就保证了工作执行的有效性。

 

4、系统决定工作队列内容（WRP_24: System-Determined Work Queue Content）

描述

工作流系统能够排定资源工作项列表里的工作项顺序和内容。

图 5-32

如图5-32所示，员工甲共享的可拾取列表默认按时间排序工作项。

 

应用

实际应用中工作项的排序条件非常多，其目的就是将最重要或优先级最高的工作项排在最前面，引起资源的注意或优先执行。

 

实现

实际实现时有多种排序策略，通常会有时间排序，例如先进先出、先进后出等，同时也有很多其他的排序元素，例如工作项的预定完成时间、执行该工作项的成本预算、工作项的优先级或重要程度等，系统查询工作项时根据这些影响因素进行默认排序。

 

5、资源决定工作队列内容（WRP_24: Resource-Determined Work Queue Content）

描述

资源能够排定其工作项列表里的工作项顺序和内容。

 

应用

为资源提供一定程度上排定工作项的灵活性。每个人关注的视角和侧重点不同，就会产生不同的排序和内容过滤。

例如，作为老板，我可能更为关注各个工作的成本预算，我需要按成本排定各项工作；而作为秘书，我更为关注老板下发各项工作的重要程度，我需要按老板指定的重要程度排定工作。

 

实现

提供工作项列表的客户端排序，一般情况下列表显示系统给定的顺序，用户可以在客户端进行二次排序，典型的Web系统中，工作流系统提供JavaScript的表格控件，利用Ajax异步请求重新排序或进行工作项的过滤。

 

6、自主选择（WRP_26: Selection Autonomy）

描述

资源能够根据自己个人的情况选择执行工作项。

图 5-32

如图5-32所示，员工甲能够根据自己的情况选择执行任务A、B、C中任意一个工作项。

 

应用

尽管老板要求先实现功能最后再重构，但是我认为当前代码如果不进行一定重构会严重影响后续的开发效率，所以我决定先进行部分重构。

 

实现

几乎所有工作流系统都不会对用户实际选择执行工作项的方式进行限制，也没有办法限制。但是系统一般会把重要的工作项加以高亮显示，让用户优先选择。

三、推模式

在创建阶段，系统根据不同的创建模式为任务 节点产生了一个或多个工作项，每个工作项或分配给单个资源或分配给角色、部门等。那么接下来，系统就需要将这些工作项推送给相关的资源进行执行，这个推送 的过程即是推模式所包含的内容。需要注意的是，推模式讨论的是对单个工作项的推送。

在前面我们已经了解到，工作流系统通过工作项管理器即不同类型的工作项列表与用户进行交互，这里的推送也可以理解为系统将生成的工作项推送至相应资源的工作项列表里。

图 5-17

如图5-17所示，推模式对应着工作项到三种状态的变迁：提供给一个资源拾取执行；提供给多个资源拾取执行（这些资源中只会有一个会实际执行，属于竞争关系）；指派给一个资源负责执行。

推模式共有9种，分为3组， 第一组包括提供给单个资源、提供给多个资源和指派给单个资源，讨论工作项推送的最终分配状态；第二组包括随机指派、循环指派和最短队列指派，关注当工作项 分配给角色、部门等包含多个资源的资源组时，如何从中确定最终的一个资源并进行指派；第三组包括提前分配、即时分配和推后分配，关注将工作项推送给用户的 时间。

1、提供给单个资源（WRP_12: Distribution by Offer - Single Resource）

描述

能够在非绑定的基础上将工作项推送给单个资源。

图 5-18

如图5-18所示，任务A工 作项被系统推送至员工甲的可拾取列表。这意味着员工甲不必为该工作负责，他可以选择执行该工作也可选择忽略或拒绝。如果他选择拒绝或忽略且工作项超时，那 么会导致系统对该工作项的重新分配。如果他选择执行该工作，那么他首先需要拾取该工作项，这会使该工作项进入他的代办列表，意味着其必须对该工作负责。

应用

该模式类似于现实工作中的征求意见，先将工作分配给你，然后找你谈话，征求你对该工作的看法，如果合适那么就由你执行，否则再找他人执行。

实现

参与者对工作项的拒绝会导致系统对工作项的 重新分配，这是实现该模式的难点。如何重新分配该工作项，采取何种重新分配策略，这些都具有很大的复杂性。实际上这些工作流模式单个看起来可能比较清晰明 了，但一旦组合起来，例如该模式与创建模式结合起来，那么就有了多种情况变得复杂起来。对于复杂的问题，最好的解决办法就是留给实施阶段，由用户情况作出 使用限定。这也再次强调了工作流实施在工作流应用中的重要性。

2、提供给多个资源（WRP_13: Distribution by Offer – Multiple Resource）

描述

能够在非绑定的基础上将工作项推送给多个资源。

图 5-19

如图5-19所示，任务A所 生成的工作项被推送给多个员工的可拾取列表。这些员工不必为该工作负责，他们可以选择执行该工作也可选择忽略或拒绝。如果他们都选择拒绝或忽略且工作项超 时，那么会导致系统对该工作项的重新分配。如果有一名员工选择执行该工作，那么该工作项进入他的代办列表，其他员工将不再具有拾取该工作项的机会。

应用

该模式是典型的竞争参与，即多人可以完成该工作，先执行者先得。类似于寻找志愿者。

实现

该模式的实现一般是创建阶段将工作项分配给角色、部门等包含多个资源的分组，在推送阶段，将该工作项送至这些组下所有资源共享的可拾取列表里，工作项的实例只有一个，但是多资源可见。

3、指派给单个资源（WRP_14: Distribution by Allocation – Single Resource）

描述

能够在绑定的基础上将工作项推送给单个资源。

图 5-20

如图5-20所示，任务A工作项被系统推送至员工甲的待办列表。这意味着员工甲必须为该工作负责。

应用

该模式是应用最多的模式，直接指定任务的负责人。

在采用军事化管理的企业里，上级的命令一定要执行，下属没有商量和拒绝的权利。

实现

相比提供，指派实现非常容易，直接将工作项推送至选定资源的待办列表。

4、随机指派（WRP_15: Random Allocation）

描述

当存在多个资源可供选择时，从中随机选择一个资源进行工作项的指派。

图 5-21

如图5-21所示，任务A所生成的工作项在创建阶段分配给了开发人员这一角色，在推送阶段，系统会随机选取一名开发人员负责该工作项的执行。

应用

该模式提供了一种指派资源的非确定性机制。

5、循环指派（WRP_16: Round Robin Allocation）

描述

当存在多个资源可供选择时，循环选择其中一个资源进行工作项的指派。

图 5-22

如图5-22所示，任务A所生成的工作项在创建阶段分配给了开发人员这一角色，在推送阶段，系统会循环轮流选取一名开发人员负责该工作项的执行。

应用

不患贫而患不均，平等的分配工作。

6、最短队列指派（WRP_17: Shortest Queue）

描述

当存在多个资源可供选择时，选择其中一个具有最少待办工作即最短工作队列的资源进行工作项的指派。

图 5-23

如图5-23所示，任务A所生成的工作项在创建阶段分配给了开发人员这一角色，在推送阶段，系统发现员工甲的待办列表里有两条待办工作（任务B和任务C），员工乙的待办列表里没有待办工作，所以系统将任务A工作项指派给员工乙负责该工作项的执行。

应用

该模式的目的在于能够最快开始工作的执行，找出相比而言最为空闲的资源迅速开始工作。但是实际应用中，仅仅依靠工作的数量来判断资源是否空闲是不可靠的，因为工作和工作之间还存在着难易之分。

7、提前分配（WRP_18: Early Distribution）

描述

在工作项实际可以执行之前即将该工作项通知或潜在的分配给资源。

图 5-24

如图5-24所示，任务A还在执行，任务B还未激活，但此时任务B的工作项已经提前分配给员工甲，该工作项的主要职责是通知员工甲将由其来完成任务B并能开始一部分准备工作，而实际的工作则要等到任务B被激活后才能进行。

应用

该模式强调的是预先计划，即管理的计划性。

在我们实际的项目开始之前，项目经理已经通知我们将要进行的开发工作，让我们提前熟悉相关的技术。这样当项目开始时就能提高最初迭代的开发效率。

从某种意义上说，稍微复杂一点的工作都应该做到提前通知、提前准备，即计划的必要性。

实现

让工作流系统直接支持该模式比较困难，因为该模式嵌套在控制模式和不同的工作项创建模式里，找不出一种通用的模式，无法预判工作项的生成和实际的参与者。在一定范围内，可以采用下面的方式变通：

图 5-25

如图5-25所示，在自动节点执行时能确定任务B的参与者的情况下，可以通过自动节点给员工甲发送邮件或消息进行通知，工作流系统并不生成工作项。

8、即时分配（WRP_19: Distribution on Enablement）

描述

在工作项实际可以执行时将该工作项分配给资源。

应用

机器执行的工作，重复单一的审批工作，无计划性的工作，如各种突发情况的处理。

实现

大多数工作流系统的标准实现，满足任务执行条件时先激活任务节点，然后创建工作项、分配工作项。

9、推后分配（WRP_20: Late Distribution）

描述

在工作项实际可以执行后的某个时间才将该工作项分配给资源。

图 5-26

如图5-26所示，任务B已经激活且已生成可以执行工作项，但是系统并没有将其分配至员工甲的工作项列表里。这是因为员工甲正在执行任务A的工作项，直到其执行任务A完毕，系统才会把任务B工作项推送至工作项列表。

应用

保证流程和资源对工作的负载处于一种良好的状态，避免出现下图的情况：

图 5-27

在敏捷开发里，我们强调客户合作，整个的开发过程对用户透明，用户知道当前正在进行的开发工作，也清楚开发团队的开发速度，在这种情况下，一旦有新的需求加入，用户会推迟该需求的实现，或者推迟当前其他需求的实现，从而保证整个团队的开发效率。

实现

该模式的实现依赖于推后的策略，即在什么情况下推后分配，满足什么条件下进行分配。具体实现同样采取推后模式，推后到实施阶段实现。

二、创建模式

创建模式在系统创建工作项时生效，如下图所示，其位于工作项生命周期的创建阶段。

图 5-2

正如上面提到的，工作流系统在执行任务节点时会为其创建相应的工作项，根据情况工作项可以是一个也可以是多个。

创建模式作为流程模型的构成部分在流程设计期指定，通常在任务节点的定义里进行定义，与一个任务关联，其用来限定可执行该任务的资源范围。系统根据创建模式限定的资源范围生成工作项，工作项可以直接分配给人，也可以分配给角色、部门、岗位等。

 

1、直接分配（WRP_01: Direct Distribution）

描述

在设计期直接为任务指定特定的资源，该任务的工作项能够在运行期分配给它。注意，指定的资源可以为多个，如果是多个的话就会生成多个工作项，为每个资源生成一个单独的工作项。该模式实际限制执行该任务的资源范围。

图 5-3

如图5-3所示，任务A在定义时直接指定给员工甲，任务B在定义时直接指定给员工乙，当实际执行任务A和任务B时，将由员工甲和员工乙分别执行。

 

应用

该模式一般应用于流程里的关键路径。同时， 在中小企业里，该模式是应用最多的分配模式，因为人员少，管理扁平，所以每个人的职责都非常清晰。该模式也是执行效率较高的资源模式，因为人和任务直接绑 定，所以不会产生推诿等情况，便于管理也便于追究责任，因为运行情况完全在设计期确定。而随着企业规模的扩大，管理层次的复杂，一个任务往往需要交由特定 的部门、岗位或角色来执行，这样无形中会影响任务执行的效率。

该模式的缺点在于一旦关键人物因为各种原因不能及时处理任务，那么将造成整个流程的挂起等待。

 

实现

最简单的资源模式，设计期确定资源，运行期工作流引擎不需要做额外的工作。

 

2、基于角色的分配（WRP_02: Role-Based Distribution）

描述

在设计期为任务指定一个或多个角色，该任务的工作项能够在运行期分配给这些角色。实际执行该任务时，资源将从属于这些角色的资源中产生。该模式实际限制执行该任务的资源范围。

图 5-4

如图5-4所示，任务A在定义时指定给“开发人员”这一角色，该角色包括了两名员工甲和乙。实际执行任务A时，将由员工甲或乙来执行。

 

应用

企业达到一定规模，就会产生人员的分组，角色是典型的分组方式，将具有相似属性的人员定义为一个特定的角色，这些属性通常与工作的内容相关，例如开发人员、项目经理、总经理等，而角色通常又会与权限产生关联。

将任务分配给角色意味着将会有多个员工可以执行该任务，执行效率相比直接分配会有下降，这也是企业扩大后管理成本增大的一种表现形式。

 

实现

工作流系统内置的组织机构模型需要对角色进行支持。引擎运行期通过角色访问属于该角色的人员。

 

3、延迟分配（WRP_03: Deferred Distribution）

描述

在设计期为任务指定资源的标识，典型的，在工作流系统里，该标识对应于一个数据字段变量，例如userid。即在设计期并不确定资源，资源的确定被延迟至运行期，系统运行期从该数据字段里获取该任务分配的资源。

图 5-5

如图5-5所示，任务B在定义时资源的标识指定为userid，实际执行时，任务A由员工甲执行，其指定了下一任务的执行者为员工乙即设置了userid这一变量为员工乙的id，在任务B实例创建时，它访问userid，发现该变量里是员工乙的id，于是将该任务分配给员工乙。

需要注意的是，根据具体的分配策略，运行期该数据字段不仅可以指定人员，也可以指定角色、部门等。

 

应用

该模式给资源的分配引入了灵活性。资源的确定延迟至运行期，即任务可以根据具体的实际情况再确定执行人。具体实施时，这个指定的数据字段可以通过一系列的规则运算得出。

在国内应用中，该模式被大量应用在人工干预流程中，例如下一任务的执行由上一任务的办理者指定。

 

实现

一般通过工作流变量来包含资源的id。为了区别该id是人员id还是角色id，一般内置特殊变量，例如userid、roleid、groupid等。

 

4、按权限分配（WRP_04: Authorization）

描述

能够指定资源的范围，只有该范围内的资源才具有执行该任务的权限。

图 5-6

如图5-6所示，只有项目经理才有权限对开发人员申请软件的要求进行批准。

 

应用

随着分工的细化，每个人工作内容的不同，必然会产生权限的概念。权限实际代表着对同一件事情，每个人执行工作内容的差别。权限越大能执行的操作越多意味着需要负责的方面越多。

该模式强调通过权限对执行任务的资源加以限定。

 

实现

在大多数的软件系统中，角色不仅仅代表具有相似属性的一组人员，同时其也是最重要的权限概念，人员往往不与权限直接关联，角色将人员与权限两者进行关联。所以，对任务设定权限可以通过指定角色来完成。

 

5、职责分离（WRP_05: Separation of Duties）

描述

在一个流程实例里，能够指定两个任务必须由不同的资源执行。

图 5-7

如图5-7所示，任务A和任务B在设计期被指定不能由相同的资源执行，同时它们都指定分配给经理这个角色。那么在运行期，在一个流程实例里，任务A被分配给了员工甲执行，那么在进行任务B的分配时，尽管员工甲也属于经理，但是将不能由其执行。

 

应用

职责分离，不能既当运动员又当裁判员，不能又当跳水队领队又当全运会裁判长。

典型的报销流程里，一般员工的差旅报销由财务人员核实，但如果某名财务人员需要报销差旅费显然不能由自己审批，需要另外一名具有同样权限的财务人员审核。此时就可以对申请任务和审核任务两个任务节点应用该模式。如下图所示：

图 5-8

 

实现

后续节点进行任务分配时，需要获取与之关联前续节点的分配执行信息。流程定义期，在定义任务节点属性时建立两者的关系。

 

6、流程实例整个处理（WRP_06: Case Handing）

描述

在一个流程实例里，所有的任务都能够分配给同一个资源执行。

图 5-9

如图5-9所示，流程实例中的所有任务都由同一个人执行：任务A、B、C都由员工甲执行。

 

应用

在应用该模式的流程里，通常流程里的任务都 是紧密关联的。流程里的任务往往执行在一个紧密相关的上下文里，如果所有的工作都由一个人执行，那么在其了解该上下文的情况下连贯执行这些任务会具有更高 的效率；而如果执行任务的过程中换人，那么新换的人无疑还需要时间对该流程实例相关的上下文进行熟悉，这样无疑会多付出执行成本。

同一个软件的开发最好由同一拨开发人员完成，如果中途更换开发人员，那么新来的开发人员需要一段时间熟悉该软件，会对开发进度产生影响。同样的道理，在软件上线前增加开发人员不一定会提高开发效率，很多时候甚至作用相反。

 

实现

可以在实现延迟分配模式的情况下实现该模式，即在第一个任务节点初始化设置参与者变量，后续任务全部使用该变量。如下图所示：

图 5-10

 

7、经验获取（WRP_07: Retain Familiar）

描述

在同一个流程实例里，当存在多个资源都能执行某一工作项时，能够将该工作项分配给执行了前某一工作项的同一资源。

图 5-11

如图5-11所示，任务A和任务B在设计期被指定由相同的资源执行，同时它们都指定分配给经理这个角色。那么在运行期，在一个流程实例里，任务A被分配给了员工甲执行，那么在进行任务B的分配时，任务B依旧由员工甲执行。

 

应用

该模式刚好与职责分离模式相反，正如它的名字所暗示的，这些任务之间存在着紧密关联，如果执行了其中一个，那么就会熟悉这些相关联任务的背景上下文，积累一定经验，那么后续任务的执行相对其他人来说会变得容易。提高任务执行的效率。

图 5-12

如图5-12所示，在软件销售的过程中，售前和编写标书是重要的两步，这两个任务最好由同一个人进行处理，因为参与软件售前的人更熟悉客户的实际情况和需求，如果分开由不同的人员执行，那么必然会存在前者与后者的交流成本。

 

实现

后续节点进行任务分配时，需要获取与之关联前续节点的分配执行信息。流程定义期，在定义任务节点属性时建立两者的关系。运行期可以通过参与者变量（工作流变量）建立起运行期关系。

 

8、基于能力的分配（WRP_08: Capability-Based Distribution）

描述

能够基于资源的能力进行工作项的分配，能力作为组织模型的一部分建模为资源的属性。

图 5-13

如图5-13所示，任务A需要交与开发人员执行，同时其对办理该任务的人员能力提出了要求，要求只有熟悉JAVA且工作经验大于2年的开发人员才能执行该任务。这样就缩小了选取资源的范围。

 

应用

人力资源管理中很重要的一点就是要做到人尽 其用，每个人的能力都能得到最大的发挥，其实也就是根据能力将人放置到最合适的工作中去。从这一点看，该模式是对人尽其能的实现。但是如何定义各个人员的 能力，这本身就比较的主观，执行各项工作需要具备的能力也具有主观因素，更何况很多时候能力并不能与表现划上等号，模型是固定的但人是变化的受环境影响 的，所以工具本身就是工具，工具的应用最后还是依赖于人。

 

实现

实现需要两部分：一部分是组织机构对人进行建模时需要包括能力模型；另一部分是流程建模时需要给任务定义执行该任务所需的能力约束，这些约束是一系列的领域特定条件，需要有特定的解析器进行条件的解析。

很多工作流引擎提供有参与者接口，接口返回人员ID列表供给任务分配，从而将这部分工作委派到工作流实施时实现。

 

9、基于历史的分配（WRP_09: History-Based Distribution）

描述

能够基于先前的工作历史决定当前任务的分配。

图 5-14

如图5-14所示，当需要在员工甲和员工乙之间做出选择时，会选择此前执行类似任务时完成最好的员工。需要注意的是，这里的历史不再是限定在同一流程实例的任务执行里，可能是同一流程模型的执行历史，也可能是不同流程模型的执行历史。

考虑历史时，有很多的考虑因素，例如完成类似任务最好的员工、完成类似任务最快的员工、完成类似任务出差错最少的员工等等。这些考虑因素依赖于具体的任务内容和背景。

 

应用

国家篮球队比赛前，主教练会考察各个位置里各个球员的联赛比赛历史情况，其中不仅会考虑出场时间也会考虑各项数据，从而做出选择。

 

实现

同基于能力的分配模式一样，该模式的实现依赖于工作流具体应用的场景，也就是需要到实施阶段结合实际实现。从某一种角度也说明，应用工作流产品时，产品实施阶段也是最重要的步骤，选择工作流产品不仅仅是选择产品也需要考察其背后的实施团队。同时也可见，这些模式在诸如政府OA这些应用中是根本应用不上的。

实现需要两部分：一部分是对用户任务执行历史进行统计分析找出关键的评定因素；另一部分是流程建模时需要给任务定义执行该任务所需的历史因素约束，这些约束同样是一系列的领域特定条件，需要特定的解析器进行解析。

 

10、按组织分配（WRP_10: Organizational Distribution）

描述

能够基于人员在组织机构中的位置以及与其他人员的关系分配工作项。

图 5-15

如图5-15所示，审批任务需要由申请人的部门经理执行，即需要员工甲的部门经理执行。这种情况即基于人员之间的关系分配工作。

基于人员在组织机构中的位置分配即需要在工作流模型里建立起与用户相匹配的组织机构模型，可以将任务分配给部门、角色、临时组、岗位等。

 

应用

应用最为广泛的模式，实际工作中几乎所有的工作都必然和组织机构具有联系。其他模式，如基于历史的分配、基于能力的分配等都是基于该模式之上的扩展，直接分配、基于角色的分配则直接是该模式的简单情况。

 

实现

对该模式的支持实际上是对用户组织机构模型的支持。正如前面所提到的，很难存在一种工作流产品能够支持所有的组织机构模型，但是大部分的产品都会提供一套元模型或扩展机制，需要在实施过程中最大限度的契合客户业务。

 

11、自动执行（WRP_11: Automatic Execution）

描述

任务的执行能够自动完成，不需要人员参与。

图 5-16

如图5-16所示，请假审批后需要将情况通知给申请人，该任务由计算机完成，不需要人的参与，也不会产生工作项。

 

应用

随着自动化水平的提高，越来越多的工作可以交由计算机或相应的机器设备完成。流程中的自动执行节点也会逐渐增加。

 

实现

实际上工作流产品对该模式的支持即是支持各种的企业集成方式，不管是通过Web服务还是消息，工作流需要驱动相应的设备机器或应用系统进行工作并传递给必须的数据。所以也可以看出，随着信息化程度的提高，目前工作流应用越来越趋向于企业集成领域。这也是为什么基于Web服务编排的BPEL会逐渐取代XPDL成为工作流流行标准的原因之一。

在上一章里，我们谈到了工作流的控制模式，控制模式强调的是对业务流程进行建模，业务流程的目标是实现一个商业目标或者管理目标，业务流程的执行往往由一系列的任务所构成，控制模式建模的实质在于合理调配这些任务，以期以最少的成本达到最大的收益。

本章将介绍工作流的资源模式，如果说控制模式更为宏观，强调的是业务流程里各个任务的合理调配的话，那么资源模式则深入细节，将要讨论单个具体任务的执行情况。提到任务的执行，那么谁能执行这些任务呢。答案很直接，是人。不管是在公司企业还是政府里，人都是最重要的资源，除去人之外，还有其他的非人力资源，例如机器、设备、计算机等。探讨这些资源如何执行业务流程中的具体任务，如何调配这些资源即构成了本章的内容，即资源模式。

本章介绍工作流的资源模式，共计43种。提到模式，很多人会想到四人帮，想到他们的设计模式，但是需要与编程里的设计模式区别的是：程序里的设计模式关注的是代码，通过应用设计模式做到代码的职责清晰、不重复、开发人员友好等等；而工作流里的模式关注的是业务价值，通过合理调配任务和资源为组织带来最大的业务价值，工作流模式是对实际业务的直接描述，与具体的工作流产品实现没有直接的关系（后面我们可以看到，很多模式当前的工作流产品很难实现），两者的出发点完全不同。

本章先会讨论与资源模式相关的一些基本概念，例如资源、工作项、组织机构建模等。接下来会对具体的43种资源模式进行讨论，讨论的模式按照描述、应用和实现展开，分别对应着模式的介绍、模式对实际业务的映射和工作流产品对该模式的实现支持。最后是小结。

一、基本概念

1、资源
既然是资源模式，那么什么是资源。在本章的前言里，我们已经提到人是业务流程执行里最为重要的资源，除去人之外，随着自动化水平的提高，还有其他的非人力资源，例如机器、设备、计算机等。资源指的是能够进行工作的实体，通俗一点，就是能够执行业务流程里任务的实体。对于需要盈利的公司而言，就是找到一种可以盈利的模式，然后找寻能够执行这些盈利工作的资源，通过资源的工作达到盈利的目的，通过合理调配这些资源达到利益最大化。

因为人是最为重要的资源，所以在后续对资源模式的讨论中，没有特殊说明，资源指的都是人力资源，大多数的模式也将以人来说明。

典型的，人是某个组织机构里的成员。组织机构对人员进行分组，执行相关的工作以达到共同的目标。例如，企业的目标是盈利，政府的目标是为人民提供更好的公共服务。组织机构对人员的分组具有多种形式，最常见的就是部门、角色和岗位（实际上与角色相比，岗位更多体现的是一种业务职能，而角色更多体现的是管理职能，与权限相关）。对于大的跨地域的组织而言，还有分支机构的划分，此外，还有临时组（典型的如以交付为核心的软件开发公司里的项目组）。在很多情况下，人可能具有多个角色、属于多个部门，这些，增加了管理的复杂性。

对工作流产品而言，要对资源模式进行支持，则必然涉及到对资源分组的支持，在大多情况下，资源分组即组织机构模型。只有支持目标客户的组织机构模型，才能在实施工作流产品时最大限度的契合客户业务。当然，如果产品是某个行业的标准，让客户模型向产品靠拢也是另外一种方式。

2、工作流产品里的组织机构建模
所有的工作流产品都有自己的组织机构模型，其是工作流产品里一个重要的模块。但是一套模型往往很难契合多种业务场景。在大多数的产品实现里，都会提供一套元模型，例如人（Person）和组（Group），然后建立多套与业务相关的模型向元模型适配，例如，角色、部门都是组的一种形式，它们只是拥有不同的业务语义而已。

在工作流产品实施时，很重要的一步就是进行组织机构建模，然后将建立完成的模型与工作流产品内置的模型进行适配，在适配的过程中，妥协是经常出现的。

3、工作项
一个业务流程由一系列相关的任务组成。在工作流产品里，使用图形化的节点代表这些任务，而实际的任务被映射为工作项（work item），任务的调用被映射为工作项的执行。一般情况下，一个任务对应着一个工作项，但是存在一个任务需要多人完成的情况，这个时候一个任务就会对应着多个工作项。工作项可以看作是工作流中最小的工作单元，其代表着一个单一资源对某一任务的执行。

既然在工作流系统里任务的执行被映射为工作项的执行，那么就一定存在着人与工作项这个计算机概念的交互，在工作流系统里，这一交互通过工作项管理器来进行管理。即我们通常所见的工作项列表（任务列表），我们通过这一列表拾取任务、处理任务以及管理任务的状态。

4、工作项的生命周期
工作项有其自己的生命周期。
 
如图5-1所示，当工作流系统执行某一任务节点时就会创建工作项，工作项可以是一个也可以是多个，正如上面已经提到的，工作项代表着一个单一资源对某一任务的执行即一个工作项只能由一个资源来执行，现在我们讨论的是一个工作项的生命周期。

工作项被系统创建完毕后即处于创建状态，接下来系统会选取资源来执行该工作项。有两种状态：一种是提供状态，一种是指派状态，这两者的区别在于一个是可选的一个是必须的。如果系统提供一个工作项给你执行，这意味着你符合执行该工作的条件，但你不必为该工作负责，即你可以选择执行该工作也可以选择拒绝，你只是该工作的合适候选者；而如果系统指派一个工作项给你执行，则意味着你必须为该工作负责，该工作必须由你来执行。因为一个工作项只能由一个资源来执行，所以如果是指派的话，那么只能指定一个资源；而提供，则可以提供给一个资源也可以提供给多个资源来候选。通常工作项管理器会提供两种列表来区分这两种状态，分别是待拾取列表和待办列表，一旦资源对待拾取列表里的工作项进行拾取，工作项即进入到资源的待办列表，状态成为指派状态。

工作项进入指派状态即意味着执行该工作的资源已确定，那么接下来就可以由资源来开始执行该工作，执行的过程中可以将工作暂时挂起中断处理，后续可以再恢复对该工作的执行。如果工作成功完成，则工作项成为完成状态；如果工作因为各种原因没有成功完成，则工作项置为失败状态。
似乎一到年末，就会忙起来。

05年的时候忙着和现在的老婆谈那从来没谈过而导致过分饥渴的恋爱；06年的时候新配置了机器，忙着通关使命召唤和生化危机；07年的时候和张祖良一起翻译AJAX企业级开发，第一次翻译，忙得像黄牛，慢得像蜗牛，在心里祈祷，翻译出来的东西不被骂就好；08年的时候和丁雪峰、总司令又一起翻译Spring攻略，第二次翻译，熟练了一些，但是每一个句子还是要花上很多时间，很多时候还得一个词一个词的确认，翻译对我来说是个苦力活，第一次翻译完我就告诉自己不要再翻译了，但是Spring攻略确实是一本好书，完全是书本身吸引了我，同样在心里祈祷，不要糟蹋了这本书。09年了，和辛鹏一起完成这本《Head First Process-深入浅出流程》，还是祈祷，千万不要写出垃圾，有时候，我常想，有必要这么辛苦吗？我是一个喜欢意淫的人，经常就把思绪抛到了多年之后，在未来里洋洋自得，于是回来时就有了动力。

我负责该书的第一部分，包括了工作流的控制模式、资源模式、数据控制模式与异常处理模式，包括了对三种流程规范的介绍、对开源工作流的介绍、对jBPM4的分析。辛鹏负责该书的后半部分，他对流程应用有着非常丰富的经验，目前他正在杭州实施一个BPM的大项目，其中包括了完整的IBM产品套件，包括了企业集成和ESB。很多人认为工作流只是OA，这其实是一个误区，工作流确实在OA里应用的非常多，但这仅仅只是一个方面。说实话，我对本书也非常的期待，非常期待辛鹏在书中分享他众多的实施经验，他是一个非常勤奋的人，这点让我钦佩不止，常常想，等我到了30多岁，还会不会有一颗勤奋的心。

家住燕郊，上班在东直门，每天在路上四个小时，挤那传说中的930，时常安慰自己：哥挤的不是930，哥挤的是寂寞。谢谢老婆，尽管还还着房贷存在着心理障碍，但是还是为我在东直门租了个房子，下周起就可以走路上班了，这样也会有了更多的时间来完成这本书。

还是那句话：战战兢兢。

十一过完，公司的新项目也开始了，时尚网站。技术栈包括了：OSGI、JCR、REST、渐进式增强。该项目有个巨大的亮点，不是徐昊是我们的技术leader，而是开发人员中一半是女生，这样每天pair的时候就生活在祖国的花园中了。

希望能写些有价值的东西，征得刘江的同意，将会在博客连载部分章节。第一部分连载的将是工作流的资源模式，内容包括前言、基本概念、创建模式、推模式、拉模式、迂回模式、自动开始模式、可见性模式、多资源模式以及最后的小结。限于篇幅，将会分节进行连载。考虑到复制麻烦，将会在开放流程社区连载所有内容，博客会连载概要并提供链接。



一、    代码主要结构
所谓流程设计器者，无怪乎读取xml文件，图形展现，操作图形元素，改变xml文件，回写，如此而已。

既然如此，设计器的流程结构就非常清晰：首先是xml框架解析xml文件为Model模型组件，然后Model模型组件被展现为Component视图组件；用户对Component视图组件进行操作，这些操作被同步的修改到Model模型组件；最后用户保存时，Model模型组件经过xml框架解析回xml文件，该文件被上传到服务器或本地覆盖原有的xml文件。

那么代码结构就很清晰了：xml框架、Model模型组件和Component视图组件。但是等等，Model与Component如何交互呢？这里就需要GEF框架嫁接起两者的联系。同时，一个流程设计器往往要同时编辑多个流程定义，相比具体的流程定义而言，设计器拥有一些全局的对象，这些全局对象包括系统菜单栏、工具条、整个设计器布局框架（ProcessDesigner）、设计器入口（ProcessEditor），还有就是负责保存全局属性和发布/订阅定制事件的TheModel对象。

二、    Component视图组件
很直接，Component视图组件指的是与用户打交道的、与流程定义相关的视图元素。注意这里的一个定语：与流程定义相关的，即不包括系统菜单、工具条这些东东。这些视图元素很简单，包括画图板、各种节点元素和连接线元素。

代码位于org.jbpmside.view.component和org.jbpmside.view.component.node下。主要类SurfaceComponent、NodeComponent和ConnectionComponent。看类名就很清晰这些类分别代表着什么组件：
•    SurfaceComponent代表画图板；
•    NodeComponent代表节点；
•    ConnectionComponent代表连接线；

org.jbpmside.view.component.node下的类就是NodeComponent类的子类，代表具体的单个节点类型了，包括开始节点、结束节点、Fork节点、Join节点等等。

Component视图组件使用了degrafa来渲染表现形式。

目前缺少一个属性弹出框组件，职责展现和修改节点/连接线属性。

三、    Model模型组件
Xml流程定义文件解析为本地Model模型组件，本地建模和jBPM4的PVM建模一致，代码位于org.jbpmside.model下，重要的类：
•    ProcessModel代表流程定义；
•    NodeModel代表节点定义；
•    ConnectionModel代表连接线定义；
剩下的就是具体节点类型的模型类，例如StartNode/EndNode/TaskNode等。

目前模型类还非常简单，因为前段时间主要关注Component视图组件部分，接下来很快会与jPDL规范完全同步，同时ProcessModel/NodeModel/ConnectionModel会进行重构，目标是与jBPM4模型完全一致。

 最新的模型位于org.jbpmside.model.common下，对jpdl4的支持位于org.jbpmside.model.jpdl4下，未来需要将Component与Model的关联迁移至common包下。

四、    GEF框架
GEF框架嫁接Model与Component。

1、    IGraphicalEditor与IEditPart
IGraphicalEditor与IEditPart是GEF框架里最重要的两个接口：
•    IGraphicalEditor代表整个图形编辑器，IGraphicalEditor里最重要的方法：



返回当前的图形视图。在当前的设计里，设计器支持多个TabPane，每个流程定义会拥有一个单独的图形视图（即一个TabPane），这里的图形视图即指当前处于激活（编辑）状态的画图板；很显然IGraphicalEditor是一个全局类。

•    IEditPart代表单个的图形编辑元素，很显然，这些元素是和Component组件一致的，IEditPart里最为重要的方法：

Component组件继承于IEditPart，这样就瞬间将Component组件与Model关联起来。IEditPart重要的实现类包括GraphicViewer与GraphicEditPart。
GraphicViewer被SurfaceComponent继承；
GraphicEditPart被NodeComponent和ConnectionComponent继承。
 
2、    Tool
Flex应用程序是基于事件驱动的，用户对界面的操作即反映到各种鼠标和键盘事件上。在原先的设计里，由Component组件自己来处理各种原生事件，当需要其他组件协作时，通过TheModel发出应用定制事件。在GEF的设计里，Component组件的原生事件处理被委派到Tool类进行处理。Component组件只管理自身的图形渲染和变化。
例如SurfaceComponent处理鼠标点击事件代码：


     
注意this.tool方法，这个方法同样是由GraphicViewer和GraphicEditPart分别  引入的。注意有些时候组件的Tool是需要切换的，例如鼠标点击面板，通常会导致被选中的节点或连接线选中状态消失，但是当工具条选中一个节点时，这个鼠标事件会导致向面板增加相应的节点。这时需要ToolManager来进行Tool却换的管理，针对SurfaceComponent/NodeComponent/ConnectionComponent分别有SurfaceToolsManager/NodeToolsManager/ConnectionToolsManager来管理不同的Tool切换策略。需要注意的是ToolManager和Tool都是无状态的，全局唯一，所有视图组件共用。

3、    Command
视图组件的变化会导致Model组件的变化。Tool处理视图原生事件、调用CommandService执行各个Command具体操作视图组件和Model对象实现视图组件和Model组件的变化。

CommandService与SurfaceComponent进行一对一绑定。CommandService持有CommandStack，实现单个Tab编辑界面内Command的redo和undo。

具体操作视图组件和Model对象必须通过Command。

五、    TheModel全局类的用途
      TheModel全局唯一，职责如下：
•    负责应用所有定制事件的订阅/分发；
•    负责持有工具条和系统菜单属性；
•    负责持有剪贴板，实现各个画板之间的节点拷贝/剪切。

六、    ProcessDesigner与ProcessEditor
ProcessDesigner负责整个应用的布局，目前由三部分组成，系统菜单、工具条和TabNavigator（TabBar管理器），TabBar管理器负责添加和删除Tab，由Tab加载画板，这样实现对多流程定义同时编辑的支持（即多Tab）。

ProcessEditor是应用的入口，它持有ProcessDesigner，实现了IGraphicalEditor接口。目前其对graphicViewer（）方法的实现是返回当前激活状态Tab的画板。

同时，ProcessEditor负责统一监听工具条/键盘事件，并将这些事件处理委派给当前处于激活状态的Tab画板处理。

七、    Xml框架
位于org.jbpmside.xml下，使用E4X，使用binding对各种类型的节点进行解析，不集中在一个文件完成解析和转换，一个节点类型对应一个binding。使用代码如下：


测试代码位于test目录下，是目前唯一可以进行单元测试的部分。

八、    还需要完成的工作
1、    xml框架还需要大量的解析工作完成（以支持jpdl4）
2、    第一个版本为本地应用，需要增加对本地文件操作的支持
3、    模型迁移至org.jbpmside.model.common
4、    工具条使用flexlib重写，新的16位图标,节点属性弹出框
5、    Command目前只实现了对undo的支持，需要实现对redo的支持


     摘要: 使用Selenium测试showModalDialog模态对话框一直是一件困难的事情，本文提出一种hack解决的方法。  阅读全文        现在流行抱大腿，不过对眼光的要求也高。要不就如高也，即使四眼，一样无用。对Java企业开发而言，Spring的腿则是一定要抱的。而所谓抱Spring的腿，无外乎三点：

一是通过Spring暴露出服务，将服务配置到Spring的IOC容器里；
二是在自己的运行环境里访问到Spring的IOC容器，能够轻松使用Spring容器里所配置的服务；
三是对于具有事务管理特性的项目来说，将事务管理与Spring的事务管理进行合并。

        下面分别讨论：

一、    通过Spring暴露服务
还记得在jBPM4的运行期环境里提到的JbpmConfiguration吗？它是整个jBPM4的入口，并且是整个应用独此一份的。通过它可以获取processEngine，并藉此获得工作流引擎所提供的各种服务：


通过Spring暴露这些服务，配置如下：


细心的你会发现，配置时使用了JbpmConfiguration 的子类SpringConfiguration。SpringConfiguration相比JbpmConfiguration有哪些增强呢，下面再讲。总之，现在，就可以使用Spring来获取或注入这些Jbpm4所提供的服务了。

二、在environment里加入SpringContext
jBPM4的environment（运行期环境）提供Engine IOC（process-engine-context）和Transaction IOC（transaction-context）。要想在运行期方便地访问到Spring里所配置的服务，最直接的方法就是在environment里加入Spring IOC（applicationContext）的引用。
SpringConfiguration即是对JbpmConfiguration增强了对Spring IOC的一个引用。
 
SpringConfiguration是如何做到的呢？简单，实现Spring的ApplicationContextAware接口，自动持有applicationContext，然后openEnvironment时将其加入environment。



SpringContext是对applicationContext的简单封装。

那么什么从Engine IOC移民到Spring IOC了呢？是的，最重要的就是Hibernate Session Factory。

在jbpm.cfg.xml的process-engine-context里干掉：


 
相关配置挪动至Spring配置文件。

三、    事务
哪里有数据库操作，哪里就有事务。对于嵌入式工作流而言，最重要的集成就是事务的集成。这里先分析jBPM4的事务实现，然后再介绍集成入Spring的事务实现。

1、    Command模式
jBPM4的逻辑实现采用了Command模式。
 
采用Command模式后，jBPM4对CommandService构造拦截器（Interceptor）链，配置在jbpm.cfg.xml的process-engine-context里：


2、    原有的事务实现
jBPM4原有的事务通过StandardTransactionInterceptor实现，在CommandService执行Command之前打开事务（实际委派Hibernate的事务管理），完成后提交/回滚。
 
jBPM4的事务是基于Command的。

3、    集成入Spring的事务实现
Spring的事务是基于服务调用的。

使jBPM4使用Spring提供的事务：


拦截器换用SpringTransactionInterceptor，SpringTransactionInterceptor从environment 提供的Spring IOC获取PlatformTransactionManager，使用事务模板回调Command，事务传播模式强制加入当前事务。

同时，对hibernate session的配置（jbpm.cfg.xml的transaction-context）强制从当前线程中获取：

并干掉原有的事务实现：

参考文档：
http://www.slideshare.net/guest8d4bce/spring-integration-with-jbpm4


        万物生长靠太阳，儿童的生长离不开土壤、空气和水，当然，也离不开绿坝娘的调教。应用程序也是如此，离不开数据库连接、事务、日志、消息等，这些，共同构成了应用程序的运行期环境。
        理想中的环境是什么样子的哩。好吧，一句话，召之即来，挥之即去，当需要某个服务时，ok，打个响指，该服务就准备好被调用了，调用完毕后也不用费心费力地擦屁股，不必老是提心吊胆有好事者追问：你擦了吗，确定擦了？真的确定擦了？直接丢弃给环境降解处理，自然又环保，还有个好名声叫专注领域逻辑。

一、    运行期环境就是一个餐馆
1、    提供必要的服务
作为一个餐馆，必须有厨师做饭我吃，必须有桌子和椅子。作为运行期环境同样如此，我要发消息，你得提供我发消息的Service，我要获取节点任务，你得扔给我TaskService。

2、    提供获取这些服务的统一方式
好吧，我不会亲自到厨房告诉厨师我想吃什么（因为我担心这样一来我会吃不下去），我也不会亲自到收银台给钱。这些服务有一个统一的获取方式：服务员。我想吃什么和结账，告诉服务员即可。关键是这一方式要统一，要足够简单。Spring最懒，把服务给你全部注入了，当然你也可以握住BeanFactory的纤纤细手，一个一个的get。

3、    提供特定于我线程不安全的服务
我点了一盘鱼香肉丝，隔壁也点了一盘鱼香肉丝，结果服务员让我们吃同一盘鱼香肉丝。我立刻跳起来：靠，你们的服务不是线程安全的吗？！Hibernate的Session正是属于这么一种情况，需要环境进行隔离，我的唯一职责就是吃饭！我的领域逻辑是如何优美的进餐！为此还要不断重构我吃饭的姿势哩。
好不容易吃完饭，付完款，正准备离场。服务员风度翩翩地走到我的身旁，我以为还有打折券供应，结果是：服务员小姐轻启朱唇：先生，麻烦您把吃剩的盘子清洗完毕。
崩溃！
像数据库连接的打开，关闭、事务的打开、提交等都属于运行期环境应该做的事情。

4、    其他的七七八八
杂事不少，例如统一的事件机制、权限拦截等等。

二、    jBPM4的运行期环境
好吧，先来看看如何建立jBPM4的运行期环境：


两个关键的类：EnvironmentFactory和Environment。

EnvironmentFactory是全局的，在整个应用程序中保持一个实例即可。

Environment则是每次方法调用则要new一个。

看看Environment的主要方法：


是的，environment为我们的代码提供所需要的服务类实例。

那么，如何获得environment？
继续看：

static，我喜欢也。方便、快捷，不管是在地上、车上还是房顶上，随处都可调用。

那么，为什么Environment每次调用要new呢？
好吧，当你需要获取数据库Session的时候，是不是每次都要new呢。Environment提供的服务里包括了非线程安全的数据库操作服务。

三、    jBPM4运行期环境的实现

1、JbpmConfiguration
JbpmConfiguration是jBPM4里最重要的类，它是整个应用程序的入口。它实现了EnvironmentFactory接口。

      JbpmConfiguration加载jBPM总的配置文件，还是大概扫一下这个配置文件：


配置文件被分为了两部分，分别是：process-engine-context和transaction-context。
对应于两个IOC容器（WireContext）的配置文件。

作为EnvironmentFactory，JbpmConfiguration持有成品process-engine-context对应的IOC容器（全局的）实例，持有半成品transaction-context的WireDefinition。当调用openEnvironment方法时，JbpmConfiguration会new Environment，然后将process-engine-context IOC填充入environment，同时初始化transaction-context IOC，并将其也填充入environment。这样通过environment就可以获得所有所需要的服务，包括全局的和非线程安全的服务实例。也就是environment透过IOC容器提供了查找各种服务的能力。


 

2、与线程绑定的environment
environment初始化之后,避免参数传递得一塌糊涂的方式就是将environment与线程绑定。看Environment的代码：


是的，在openEnvironment时，有这么一行代码：


这样environment就与线程绑定了，可以通过Environment.getCurrent()任意调用了。

哪里有压迫，哪里就有放抗。
在environment.close()方法里：



OK，结束。


一、目前的情况
目前我们要进行持续集成的对象是一个有着100人左右的开发团队，他们开发着一套很庞大的系统。整个开发团队划分为多个开发小组进行协同开发，每个开发小组负责2-3个模块的开发，实际这里的模块已经相当于一个中小型系统。各模块所有的类都通过eclipse整体编译在一起，直接放置在WEB-INF/classes下。本地是无法启动整个系统的，需要耗费大量的资源。

二、碰到的问题
在了解具体情况之前，我们最初的想法是为整个产品做一个持续集成，但是很快就发现这一想法存在很多的问题：
1、整个产品每次构建的时间会很长，这个时间包括代码的编译、启动Weblogic，完成自动化测试，同时对服务器的硬件要求非常高
2、因为构建时间长，所以如果本地构建通过后再提交会严重影响开发效率，况且本地的硬件条件很可能启动不了
3、如果本地不构建提交，则由于开发人数众多，构建会非常不稳定，会经常处于失败状态。而构建失败会导致后续提交的阻塞。
4、作为一个100人的开发团队，代码提交会引发频繁的服务器构建，服务器无法负担。

同时作为客户，他们有这样一种想法：敏捷开发是好的，但是不适合于大的项目和大的团队。

最重要的问题集中在两个方面：
1、启动整个产品过于重量级（不包括自动化测试的情况下已经如此）
2、如何不影响开发人员的频繁提交

三、我们的想法
我们现在的想法是做多阶段的持续集成（multi-stage CI）

可以参考这里http://www.ddj.com/development-tools/212201506

具体而言：
1、各个开发小组内做小组内的持续集成
2、开发小组间集成做整个产品的持续集成


大概：
1、每个开发小组一个分支，整个产品一条主线
2、在小组分支上搭建持续集成环境，小组内的开发向该分支上提交，各个小组可以并发开发，互不影响
3、小组完成一个完整的功能后，从主线更新合并代码，本地构建通过，提交，触发整个产品的持续集成

为使小组内持续集成构建加快，小组内尽量划分清楚对其他模块的依赖，不必要的模块（这里的模块包括基础模块，例如工作流模块）不必加载。
同时推荐轻量级的web服务器例如Tomcat来完成小组内的测试环境。需要启动weblogic的情况或功能依赖过多的情况下，建议在产品持续集成时进行测试。
同时保留原有的启动单独测试服务器进行手工测试的习惯。
       和Jbpm3一样，Jbpm4实现了自己的IOC容器。以现在的眼光看来，应用程序里一个IOC容器几乎是居家必备的，否则，又要平白多出一坨一坨的工厂类和单态类来。

一、    Jbpm4 IOC容器介绍
IOC容器的目的是管理组件和实现组件之间的解耦。和Spring里的BeanFactory对应，Jbpm4里的接口是Context，具体实现则是WireContext。Context实际在Jbpm4里有更多的含义，它与Environment一起，共同构成了代码运行的运行期环境。在这个环境里可以获取系统的组件，更为重要的是提供了数据库连接（session）和事务（这个稍后会讲）。

先来看看Context接口的核心方法：


很明显，提供两种从容器里获取组件的方法，一种是通过name，一种是通过type。

对于IOC容器来说，一般情况下都会提供一种加载的方式，比如从xml文件进行加载、从资源文件进行加载。Jbpm4透过WireParser具备从xml加载的能力。

此外，WireContext通过一个Map缓存初始化后的组件。

二、    Jbpm4 IOC容器实现
容器的实现有五个关键类和接口，分别是：WireParser、Binding、Descriptor、WireDefinition和WireContext。
 

WireParser读取xml文件，同时WireParser会加载一系列的Binding(默认从jbpm.wire.bindins.xml文件读取加载)。

Binding负责根据xml里元素的tag将xml元素转换为对应的Descriptor。

Descriptor负责初始化对象。它们被添加到WireDefinition。

WireDefinition被WireParser返回给WireContext。WireContext创建对象时会访问WireDefinition里的Descriptor，同时将初始化对象的任务委托给Descriptor自身。

需要注意的是：Jbpm4在初始化对象时有着四种策略，分别是：延迟创建和初始化、延迟创建和立刻初始化、立刻创建和延迟初始化、立刻创建和立刻初始化。

立刻创建：在WireContext创建完毕后对象就已经创建。
延迟创建：调用WireContext的get方法获取该对象时才创建该对象。
初始化：一般完成对象属性的注入等操作。

三、    Jbpm4 IOC容器在Jbpm4里的应用
IOC容器在Jbpm4里最重要的作用就是加载Jbpm的总的配置文件（默认是jbpm.cfg.xml），这也是整个Jbpm应用的起点。大概扫一下这个配置文件：



可以看到配置文件被分为了两部分，分别是：process-engine-context和transaction-context。在实际应用中，它们分别对应着两个不同的WireContext:ProcessEngineContext和TransactionConext。ProcessEngineContext覆盖了jbpm4里最重要的服务类，这些类是全局唯一的，当然，ProcessEngineContext也是独此一份。本是同根生，命运各不同。TransactionConext则是在每次openEnvironment时重新创建，因为其包含了数据库连接和事务。

贯穿于整个Jbpm4中，这两个Context被压到Environment里（Environment和线程绑定），在任何需要的地方都能提供一条龙的服务。于是，在很多领域类里，利用这些服务实现充血模型就是很顺理成章的一件事了。

总结: ProcessEngineContext给引擎领域模型提供全局的组件查找；TransactionConext提供数据库相关服务。


公司团体票，参加了QCon北京大会第二天的内容。感觉大多数技术网站都有水化和后继乏力的感觉，原因很简单，简单地依靠用户产生内容是有问题的，专业作者和专职编辑团体才是高质量内容的保障。在这方面，个人觉得INFOQ非常不错。

说说自己的一些大会感想。

关于话题

第二天的话题是关于网站架构，虽说一直做企业开发，但对网站一直有很高的兴趣。网站的访问量、用户量是企业应用所无法比拟的。早上赶到已经是九点半，Rod的演讲已经开始，非常多的听众，走道上全是人。第一次见到真人，但session确实没给人留下太多的影响，主要还是对springsource当前产品的介绍，其中也提到了ruby企业应用的局限性，明显是在推grovy。

第二个session是来自eBay的教训，提到了好几个原则：水平扩展、垂直扩展、异步、记录所有错误日志、实时性与可用性的取舍等等。非常不错，都是实战的总结，但是觉得现场的同声翻译有些问题，将可用性翻译为了可及性。来的晚了，坐最后一排，PPT的字有些多看不清楚，希望INFOQ能尽快提供下载。听力不好，另外有些概念没太理解，旁边的Tin给我讲解，其实听过Tin关于网站结构的一个session，非常好。同时，我在想，关于大会session，我不知道INFOQ是如何确定的，能否和投稿一样运作呢。

上午最后一个是Agile+CMMi，口音听起来比较吃力，刚好李默同学招呼吃饭，为下午的session占座，于是一帮人先去吃饭。

下午的话题可以说是非常精彩。先是支付宝程立带来的SOA治理。我对SOA这个话题一直是不感冒的，我认为仅仅把SOA认为是一种技术架构或实现是很BT的。程立的话题亦由它们产品采用SOA架构展开，这让我很瞌睡，我认为这个就是程序良好的功能划分、交互的约定、统一的查找/注册。不过很快就有了惊喜，话题接着讲到了公司架构、组织架构、业务架构、应用架构，以及如何协调这些架构已达到企业的运营目标。这和我的理解比较一致：SOA治理其实并不是采购所谓SOA产品来达到的，它之于公司运营过程类似于敏捷之于软件开发过程，是一套方法或者说是一套实践，而BPM管理企业流程则类似于Mingle管理开发流程。话题非常好，也很有作者自己的理解，可惜的是到后面由于时间原因都没有展开。另外，我觉得前面和后面的内容有些冲突让人犯晕，如果分开成两个话题就更好了。程立拿上帝创造世界的7天做比较，后来我提问时也提到：你们支付宝真累啊，一周要工作6天，我们都是双休日：）

豆瓣和优酷的话题我认为是全天最精彩的话题了。豆瓣按发展历程依次介绍了豆瓣架构的整个变化过程，优酷则着重强调了架构的简单性原则，邱丹在演讲时不停地强调这一原则，他们的架构是典型的LAMP，感觉是实用性至上。豆瓣则更技术性一些，开发了自己的DoubanDB和DoubanFS,有意思的是它们给每台服务器都起有一个指环王里的人物名字，这其实也是公司文化的体现。

有道的话题是关于日志分析，介绍的比较简单，主要是一些对系统概念的介绍，没有展开。后面提到了他们分析的一些有意思的结果，但是也是很快带过了，感觉可以再多一些，我们有时候挺需要八卦。

个人觉得对一个好的技术会议来说，话题应该是最最重要的，今天的话题就让人觉得很值。下一次的规模是否可以更大一些呢，涉及更多的话题，各种同一领域的实现技术都可以在一起PK，这样更加有意思。

其他

广告
我认为这个其实还有很多地方可以发掘，最明显的就是中午吃完饭回来，大厅在放维多利亚的秘密，这是一个多么好的广告时段啊，却维多利亚了。演讲的空隙都可以播放广告。

同声翻译的不太好。可能不是技术人员出身吧。

食品
主会场只有一个饮水机，拥堵。小面包不错，一连吃了四个。

晚上的沙龙本来是非常好的交流机会，由于住得太远，只有眼馋的份了。
     摘要: 在周末的openparty上，分享了关于JbpmSide介绍的session。主要介绍了这个项目的目标、功能规划、开发计划以及当前的进度。下面是可供下载的ppt。

JbpmSide仍然定位于一个完整的工作流解决方案。  阅读全文 汇报一下设计器当前进度以及下一阶段主要的开发目标。
当前进度主要集中在图像处理方面：
    1、采用Riawave，完成了整个设计器图形处理的架构
    2、工作流节点的图形建模
    3、节点的拖拽以及连线
    4、节点、连线的剪贴、复制、删除操作，支持快捷键
    5、画板的缩放和Grid显示与否
采用的图形类库是Degrafa。
下一阶段（2-3周）会实现以下的功能：
    1、目前的连线是通过点击两个节点出现的，将支持单独的连线增加（两种形式：直线、曲线）
    2、增加不同节点对连线的约束，即开始节点只能出、任务节点单进单出等。
    3、采用flexlib实现新的设计器菜单（Tabpane形式），同时将图形模型工具条移到左侧垂直放置
    4、do/undo功能，将所有对画板的操作重构为Command模式
余下的功能包括：导出图片、打印等。
近阶段的主要任务是实现设计器的图形功能，不考虑XML的转换和建模。其中包括根据大家的反馈改变部分的现实细节。源代码将尽快放出。请关注JbpmSide。

目标： jBPM-side ProcessDesigner是一个独立的设计器，基于 Flex技术。其目的在于既使得程序开发人员能够基于其进行业务流程的建模，同时业务人员也能够基于其进行简单的建模和修改，例如修改节点的顺序、参与者等操作。此外， jBPM-side ProcessDesigner具有很高的可配置性，在流程定义 scheme变化的情况下，能够很快的做出适配。即其与具体的流程定义语言无关，可以对 jPDL、 XPDL、 BPEL都进行建模。 jBPM-side ProcessDesigner的数据核心是 xml。

功能规划：

一、 图形建模

支持流程模型与图形元素的一一对应，支持通过图形元素来进行流程的建模。流程模型与图形元素之间通过 xml进行互相转换。图形建模方面，支持图形元素的拖拽、定位、复制、粘贴，支持快捷键操作，例如 do/undo、 delete。

二、 流程参与者的适配导入

支持在进行流程建模时，适配导入流程参与者。在进行人工参与节点定义时，选择参与者。进行人员 /部门 /角色的本地建模，提供最简单的必需属性。

三、 图形展现与 xml编辑的互相切换

支持流程图形与 xml编辑的切换，支持 xml定义的本地导入和导出。

四、 流程的分包与版本管理

支持流程定义的分包和版本管理，需要服务器端的支持。

五、 与服务器端的远程调用

在支持服务器端的远程调用之前， jBPM-side ProcessDesigner仅仅是本地 xml的导入导出建模。采用 restful-ws，基于 xml在服务器与设计器之间传递数据。

六、 与业务适配的 DSL

七、 流程的权限管理

支持对流程定义的分类权限管理，不同业务部门对属于自己的流程定义有各自的管理权限。此功能独立与 jBPM-side ProcessDesigner，但是需要通过契约使得 jBPM-side ProcessDesigner对流程定义的展现进行过滤。

      Jbpmside要使用Flex开发流程设计器以及管理器，刚好公司的一个内部项目也应用到Flex，大概花了一个礼拜来熟悉和了解Flex。其中发现Flex开发和AJAX开发的很多相通之处，这里把自己对Flex的一些学习心得总结一下。分为三部分，分别是对Riawave框架的介绍、参照Riawave，对自己先前采用的AJAX开发框架的介绍、以及对AJAX前景的一些自己看法。

一、Flex框架Riawave的定制应用

Flex有很多开发框架，最有名的是Cairngorm。但是Cairngorm太复杂了，职责的细粒度分离带来的是过多的类和代码，不太适合中小项目。这里我们采用了Riawave，准确的说Riawave并不是一个框架，它只是一个通讯录管理的简单代码示例，它包含了很多的最佳实践。这里想说一点，就是很多时候采用某种技术起决定因素的往往不是技术本身是否先进，而是看该技术的使用者是否众多。

 

Riawave将应用程序拆分成三部分，分别是Views、ModelLocator、DAO。

 

Views指的是应用里的页面组件，例如表格、表单、菜单等。它的职责：1、组成整个应用的界面；2、对组件内部的原生事件进行处理，这些事件指发生在该组件里的鼠标事件和键盘事件；3、当需要其他组件进行协作时，发布定制事件；4、对其所关联的数据进行操作；5、监听其他组件发布的与之相关的定制事件，并做出展现形式上的改变。

 

ModelLocator是整个应用的核心。它的职责：1、集中存储应用的所有数据；2、给页面组件提供统一的定制事件监听器接口，即所有的页面组件要对其他组件的定制事件监听则必须通过ModelLocator来进行订阅；3、唯一的定制事件发布接口，即任何页面组件要发布自己的定制事件都必须通过ModelLocator发布；4、集中维护所有定制事件的类型。ModelLocator是单态的，通过ModelLocator，应用程序所有的定制事件都被统一管理。

 

DAO负责操作应用的数据。它的职责：1、改变应用的数据，提供应用数据修改的统一接口，即用户操作页面组件改变数据时，实际上是由页面组件转发给DAO处理；2、远程访问服务端，Flex通常作为应用程序的前端展现出现，和AJAX一样，数据的操作要和服务器端进行交互；3、服务器端返回正确的操作结果后，改变ModelLocator里的数据，发布定制事件，触发相应页面组件改变。

 

可以看到，整个Flex应用完全是由事件驱动的。其他需要了解的部分：1、Flex的Data Binding机制，这个机制实际也是由事件发布/订阅机制实现的，它可以省去自己编写重复的定制事件发布/订阅代码，实现组件展现数据与ModelLocator的数据同步；2、VO，本地的数据建模、用途：发布定制事件时，通过VO携带组件数据，VO被包含在事件里；传递数据到DAO。

 

二、自己采用的自制AJAX框架介绍

与Flex一样，AJAX也是事件驱动的。在自己以前的AJAX开发中，也自制过与Riawave类似的开发框架，应用的效果也不错。在这个框架中，采用了Mootools。

 

使用过一些js库，包括prototype、Mootools、Jquery和Ext。说说自己的看法：prototype更像是底层库，封装了DOM查找和操作、XMLHttpRequest异步访问以及简单的js类继承体系，方便小巧；Mootools的特点是非常面向对象，另外对事件进行了统一的管理，这两个特点决定了Mootools非常适合用以编写自己的AJAX组件；Jquery在项目中使用过一部分，丰富的插件让人印象非常深刻；Ext则是一个完整的解决方案，代码非常有参考价值，提供了众多的组件，但是只是适合企业应用，另外，效果有些让人审美疲劳。

 

应用程序分为三部分，分别是View、ModelLocator、DataHandler。

 

View同样是应用里的页面组件，例如表格、表单、菜单。它的职责：1、组成整个应用的界面；2、对组件内部的原生事件进行处理，这些事件指发生在该组件里的鼠标事件和键盘事件；3、当需要其他组件进行协作时，发布定制事件；4、调用DataHandler对其所关联的数据进行操作；5、如果存在子组件，监听子组件发布的定制事件，调用其他子组件协作，或者继续向上发布定制事件。

 

ModelLocator负责维护整个应用的数据。ModelLocator是单态的。

 

DataHandler负责操作应用的数据。它的职责：1、改变应用的数据，提供应用数据修改的统一接口2、远程访问服务端；3、服务器端返回正确的操作结果后，改变ModelLocator里的数据，回调调用View里的方法，View会改变DOM元素、发布定制事件，触发其他页面组件重新渲染；4、应用程序的入口，由一个服务器访问开始，使用返回数据构造View Container。

 

与Flex相比，事件的订阅/发布机制发生了变化，改为由View组件向父View组件依次冒泡传递，直到找到可完全处理该事件的组件为止。

在AJAX开发里，由于没有统一的View组件，所以组件之间的关系通常是一种容器-子组件的关系，是一种层级关系。第二层的子组件可能充当第三层组件的容器。

 

容器的职责：1.保存对所有子组件的引用；2.订阅子组件的定制事件；3.调用其所管理的子组件协作；4.渲染时调用子组件依次渲染；5.销毁时，依次调用子组件的销毁方法；6.当对子组件发布的定制事件无法完全处理时，继续向自己的上一层的容器发布事件。

三、对AJAX的看法

很多人将AJAX与Flex相比，认为AJAX只是一种过渡的技术。我不这么认为，我认为Flex适合企业应用，而网站还是会广泛应用AJAX。另外，个人认为AJAX需要进一步提高的地方：1、统一标准的组件库，现在的组件库没有标准，嵌入到网页里应用没有问题，但是当需要这些组件进行协作时会比较困难，需要大量的编码；2、更快的JS解析引擎，这个没什么好说的；3、更强大的运行环境。

                                                   

       大概花了三天的时间读完这本书，书本身也不厚，读起来很快。这本书出版于2001年，所以对它也没有抱有很大的期望，但是还不错，特别是前三章，很有些惊喜。后面关于工作流仿真的描述也很到位。但是关于技术实现，则大都略过了。

        总结一下里面个人觉得不错的部分。

        第一章很不错，强调为什么需要工作流管理系统。

        企业经营环境的变化：过去企业市场竞争主要围绕着如何提高生产率进行，现在则是围绕新产品的竞争而展开。新产品的价格总是高于其价值，通过竞争，价格才逐渐接近价值，产品失去独占期，同时也意味着产品生命周期的结束。与产品生命周期缩短所对应的，是客户定制产品数量的增加。

        在这种情况下，传统串行的产品研制会延长产品的上市时间，同时串行过程也是在企业以功能为核心划分组织机构下的必然产物。

        敏捷制造提出的背景：用户需求多样化、个性化，所有企业都将处于一种连续改变、不可预见的市场环境中，此时问题的核心在于是否抓住机遇、快速响应市场、开发新产品。敏捷制造的基本思想是，企业能够对持续变化、不可预测的市场需求做出快速反应，强调面向市场的敏捷性。实现敏捷制造的关键是对企业进行敏捷化改造和重组。其中企业组织结构发生重大的变化，传统的企业组织结构是功能部门制，即按照不同的功能和职能设立不同的部门，上下级之间形成一个树型的结构。这种结构的缺点在于：每个单元都由上一级的功能单元进行管理，出现问题时，每一级都会把责任推到上一级，这样会造成部门职责不清。柔性底，一个生产流程往往跨越多个部门，部门之间的协调成本很高，扯皮。需要建立起面向流程的组织机构，按照企业要实现的主要业务流程来配置组织机构，以项目来组织人员，减少内部不必要的沟通协调成本，提高对市场的响应速度。

        由此，需要工作流系统来对企业的流程进行分析和梳理。然后围绕这些流程来进行企业的业务重组和改造。

        第二章的亮点在于如何实施工作流系统。

        工作流的实施不同于普通的业务处理系统，它首先需要在战略层次上对企业的业务目标进行分析，确定企业的战略目标和组织要求，然后再进入到具体的实施阶段，分为三个阶段：模型建立阶段、模型实例化阶段和模型执行阶段。实施工作流的目的在于提高企业的柔性，能够根据市场的变化不断改进其业务流程。其中作者强调了工作流的两个重要职责：集成和仿真。工作流系统本身是一个完成流程建模和流程管理的软件系统，但是为了在企业的实际业务中得到有效的应用，它必须和企业已有的或购买的其他业务系统实现集成，通过集成来提高整个企业 的应用水平和应用效率。

        第三章分析工作流系统的组成以及WFMC定义的五个接口。很清晰。

        第四章到第八章描述具体商业产品的大概技术实现、XPDL规范和分布式的工作流，由于现在已经是B/S软件的天下，所以里面的分布式在这里显得理所当然。这部分可以跳过。

        第九章讲述作者实现的一个工作流系统CIMFlow。亮点在于分布式工作流机的设计方案。

        核心思想是：多个工作流机分配给多个部门，与这个部门相关的流程或流程节点就由这个部门专属的工作流机执行，部门可以各自独立修改这些流程或流程节点。另外为了集中管理，再设置一个主控工作流机，集中管理这些部门工作流机。这样可以提高流程的柔性。很赞的思想，但是实现无疑复杂了。

        第十章讲如何在企业流程重组中应用工作流。偶觉得，这本书一旦上升到企业运营的层次讲解工作流，马上就很赞了，O(∩_∩)O~。其中关于流程仿真部分很是好看，颠覆了自己对流程仿真的观点。以前认为是流程仿真是确保流程建模的逻辑正确，属于软件测试的范畴。这里的仿真却是为企业决策提供数据。需要注意的是对资源的定义。资源包括了人、业务系统、运营成本等等，很广义的概念。

        最后一章再次强调工作流集成能力的重要意义。不禁让我想起了BPEL。

        合上书，我想，这是在讲工作流吗，( ⊙o⊙ )?，咋和我印象中的工作流不一样哩。我想，作者更强调的应该是一种高端的业务流程管理，它既不是现有的工作流、也不是BPM软件，然而又不是BPG，因为它管理的流程是可以马上执行的。只能这么想，作为7年前作者对工作流的理解，期望太多。

        如果有电子版，值得一读，如果买纸版，就没有必要了。

在温暖的办公室里写下这些字的时候，外边的天气很好，目光从明亮的窗户扔出去刚好能够触到西直门，所以这应该算是北京的好天气。回想起去年的这个时候，也是坐在办公室里，在上地，不远处的信息环岛，运通105在缓缓挪动。我很喜欢运通105，尽管有很多车可以选择，但是运通的司机总是很生猛，他能够骂骂咧咧地迅速变线超车，也能够抢在绿灯的最后一秒秒穿过路口，上他的车你需要确实坐稳扶好。下雨的时候会去坐车，平时则是骑车，那辆自行车几乎每个月都要修理一次，最近一次是刹车时用力过大结果闸应声而断了。11月换了份工作，坐城铁上班，自行车开始生锈，每天上班时经过车棚，看见布满灰尘的自行车，突然就有一种极不真实的感觉，我认识它吗，为什么它会显得如此之陌生，生活，似乎在一瞬间就完成了转换。

我是一个怀旧的人，经常会沉浸在过去的某种情绪里不能自拔。今年又似乎过得太快，我还没来得及回忆，已悄然流逝。过完年就考虑着要不要换一份工作，公司的效益不好，产品的BUG太多，似乎也看不见前景。然而三月份岳母的生病打断了这一想法，请假回家了一个礼拜，先是手术，然后化验，结果出来，是癌症，然后就是化疗。每月发完工资，我和老婆都会去邮局，给她家里汇钱，然后打电话安慰她的母亲，在电话那头，岳母总是带有愧疚，觉得她拖累了我们。我喜欢她的母亲，和我妈妈一样，都是很朴实的农村人。过年去她家，还没起床，岳母已经把早饭端到床头，糖水煮鸡蛋，一个压着一个，八个，尽管尽了最大的努力，但终究还是没有吃完。

四月份公司策略发生变化，停止业务平台的开发，以维护为主，同时重新开发工作流，我一直认为单独的工作流产品是有前途的，平台则不然，市场上这类产品已经非常的多，并且都没有什么亮点，如果说解决某一业务类型的问题尚还合适，那么夸大到通用的地步就只能是市场忽悠罢了。至于技术性的平台，我想，在国内，只能是叫好不叫座。再说说工作流，作为很多系统的基础设施，我觉得是越来越普及，同时，也会越来越廉价。

那是快乐的一段时光，功能调研、TDD、制定开发计划，每天都很充实。但是第一个版本迟迟不能发布，终于等到八月，开发被迫终止。原因是人员的流失非常严重，到最后只剩我一人在支撑。作为小公司，如何留住开发人员，这是个很大的问题。其实，我想，有时候不仅仅只是薪水的问题，还有很多因素，例如代码的封闭、人员之间的交流等等。给我印象很深，一次讨论实现时，我坚持了hibernate xml映射的形式，同事想引入注解，我反对，理由是会给团队带来新的技术学习成本，而我们的重点应该是快速实现引擎本身。后来，同事离职，老板找我谈话时提到了这件事情。这让我汗了很长时间。还有很多沟通的方式需要学习。

开始招人，始终找不到合适的人。有人给我的博客留言想面试，是一个四川的小伙子，汶川地震当了一个月志愿者回来没有多久，身上似乎还有沙子、混凝土的味道。一下子就喜欢上他，很勤奋、积极，虽然工作经验不多、也只是大专，但是给人的感觉很向上。有时，真的，觉得工作经验并不是很重要（行业经验除外），但是一定要有精神。离开公司时，我想，这也算是我给公司做出的贡献。

汶川地震时，坐在办公室里，3楼，没有任何感觉，就看到楼下突然聚集了越来越多的人们。QQ同学群发来消息：地震了！哪儿地震了？通州？四川？不，是心里！接下来几天里，看着电视里的不间断报道，眼泪就下来了。我是坚持要对政府批评的那部分人，我认为虽然有进步，但是还不够，一直到今天，政府失职的地方实在是太多。其实，政府一直缺少的就不是赞美，而是批评。我厌恶专家，他们在08年集体华丽地转身，变成砖家。一直在关注冉云飞的博客，每周，他都会有四川掮客周刊，然而，最近，他也被和谐了。

8月份在北京受孕，工作流开发停止，刚好看看书，也从公司的角度思考一下发展。小公司，生存是第一位的，工作流开发需要投入，暂时没有产出，中断可以理解。但是，作为一个技术性公司，如果没有技术那就失去了竞争力，长远的发展是个问题。真是矛盾。中小公司，99%的成败取决于老板。大公司靠财务，小公司靠销售。我觉得公司的销售和市场有些问题：好吧，就算是产品功能不强大，那售前那么少，怎么解释。是客户在没了解你的产品前，就把你的产品给cut了？或者，他们根本就不知道有这么一个产品？你是仅仅提供一个产品，还是提供一整套的解决方案？解决方案仅仅基于自己的产品？有那么多的工作流应用经验，这个能不能以服务的方式提供收益？盈利模式是什么？技术、编码，这些此时都不重要了。

去年的这个时候为自己写下了08年的展望。第一是结婚，10月份的时候实现了。第二个是开发一个基于js的工作流设计器，没有完成，也不打算去做了。第三个是工作上是否有新的挑战，是的，11月终于换了工作，去了自己一直想去的公司，但是要是原公司能够有足够的成本支持工作流的开发，也许现在还在那里，毕竟是自己负责的第一个产品，有很多的想法在里面，并且已经完成了第一个版本目标的80%，有这么个说法，很多产品倒在最后一里路上，我的体会很深。第四是多看看非技术书、善待家人，这点做得还不够，年底和朋友一起翻译了《Spring Recipes》，每天晚上都翻到12点，经常忘记给家里打电话。有次父亲给我打过来，说，吃饭了没。我看看表，11点了，说，都11点了怎么会还没吃饭？父亲用很惊讶的语气说，哦，我还以为你忙得连饭都没空吃呢，原来还是不忙啊。父亲是在怪我没给他打电话呢。

有过很多矛盾，年底前最终还是决定开发一个工作流的开源系统，想法是前公司的老大提出的，基于jbpm，实际我并不是很喜欢jbpm的一些实现，我想自己实现引擎，但是考虑到用户，这无疑是最好的选择。明年的愿望就是：把这个开源的工作流系统做下去，发布出来。

再就是，要锻炼身体，又胖了。

当面对一个完整的工作流系统时，你可能会被它众多的功能所困惑：流程流转模式、时间服务、组织适配、表单权限等等。但是如果我们转换一种思路，首先从用户使用的角度来进行分析，工作流系统的组成就会变得异常清晰。实际在现实开发中，整个系统也是由用户的业务需求一步步迭代而来。

 

一、        从用户的角度分析工作流系统的组成

这里的用户分为两类：一类是应用系统开发人员（以后简称开发人员），一类是应用系统的最终用户（以后简称最终用户）。对于最终用户而言，工作流系统往往是不能直接使用的，它需要由IT部门的开发人员嵌入到应用系统中。开发人员才是工作流系统的直接使用者，这造成了问题：工作流系统更多关注于开发人员的需求，例如如何快速开发、如何更好的嵌入业务逻辑等等，而最终用户的需求被或多或少的忽略了。

这里从最终用户的角度进行分析。

 

1、                    面向开发人员的流程设计器

最终用户通过流程设计器对业务流程进行描述，实际是一个流程建模的过程。理论上，业务分析师完成这个业务流程建模的过程，并且业务分析师往往被假定为非技术人员。对于业务分析而言，流程建模通常是抽象的，一定程度上是模糊的，建模的目的在于通过图形的形式向其他人解释一个业务的过程，图形只是一种方式，采用它只是它更易于理解和易于沟通，实际类似于DSL。实际上企业的规章制度、文字描述的执行流程都是对业务流程具体的描述方式。

 

对于工作流而言，这个建模所产生的流程是需要被引擎执行的。这就要求流程中每一个节点的定义都是要有明确含义的，它需要被计算机明确而准确的解释。同时，出于集成业务系统的需要，流程模型定义往往带有很多额外的属性。

 

所以现实中的流程设计器往往属性配置繁多。导致最终用户在打开设计器后根本无从修改和建模，他需要关注很多与业务无关的配置，无意中的修改往往产生流程无法运行的后果。

 

2、                    工作项列表

即任务列表。工作流系统通过工作项列表进行人工任务的分配。最终用户通过该列表签收、处理每天的工作，工作以工作项的形式展现。对于工作项，用户有着多种业务操作：签收、完成提交、收回、回退等等。对于分配给他人的工作项，也存在着多种业务操作：催办、提醒、时间限定等等。

 

3、                    流程追踪

用户在处理工作项时，对该工作在流程中所处的位置进行查看，了解当前流程的状态和执行情况。一般情况下，流程追踪以图形化的方式展现。用户通过不同的图标和标示来区分流程中各个节点的状态和参与者信息。

 

4、                    流程实例管理

包括流程实例、节点实例、工作项实例的管理。改变状态，包括了挂起、重新启动、终止、跳转等等。主要目的在于对流程人为执行错误进行人工干预以及对流程信息的监控。

 

二、        系统架构

从用户的角度分析完工作流系统的组成，这里从开发人员的角度分析工作流系统的架构。系统架构里的每一部分是如何与用户使用的部分进行对应，以及每一部分在实现时需要注意的事项。

 

1、                    整体构成

如图，各模块分层组织，位于上层的模块依赖于底层的模块。正如你所看到的，流程定义模型位于整个工作流系统的最低层，因为它是整个工作流系统的基础。

 

流程定义模型：定义对流程进行描述的所有对象。因为对流程进行描述的本质就是利用这些模型进行建模，所以这些模型对象的实现直接决定着工作流系统对流程的描述能力。

 

组织结构适配器：工作流系统在与业务系统进行集成时，需要进行组织适配，通过这一过程将业务系统里的组织机构导入到工作流系统里。具体实现时，工作流系统需要建立起自己的组织机构模型（包含在流程定义模型里），要适应多种业务系统，往往需要建立多套模型，根据具体情况进行切换。有多种方式完成这个适配，最简单的方式是利用SQL配置读取数据进行语义转换。

 

流程设计器：供用户使用的可视化图形工具。每种图形都对应着一种流程定义模型。具体的实现有Swing、SWT，但是基于AJAX的WEB设计器无疑会提供更好的可用性。

 

流程执行引擎：将流程定义模型解释为流程实例模型。利用这些流程实例模型完成流程的调度和执行。在工作流系统里，执行引擎是整个系统的核心。实现时不仅需要考虑各种流程调度的实现，还要考虑执行的效率、缓存、日志等等。

 

工作项引擎：解析参与者定义模型和工作项定义模型，生成相应的工作项。对用户对工作项的操作作出响应。

 

WEB应用：工作流系统的WEB展现。包括了工作项列表、流程追踪以及流程实例管理的操作和显示。

 

流程仿真：对建立好的流程模型进行运行仿真，模拟流程模型的执行过程。目的在于发现流程建模过程中的疏漏，发现由此导致的流程不能运行。

 

时间服务：提供对整个流程实例执行时间和任务执行时间的控制，根据规则触发相应的时间事件，例如任务超时、任务预警等等。根据规则自动触发启动新的流程实例。

 

业务集成：提供工作流系统与业务系统的契合方式。典型的实现包括通过注册事件监听器和提供接口抽象类调用业务系统代码、提供API给业务系统调用、工作项驱动业务表单和脚本引擎执行业务逻辑脚本等等。特定于工作项驱动业务表单，为方便开发，绝大多数的工作流厂商都提供了电子表单的实现。

 

2、                    基于事件的流程执行引擎

流程执行引擎的主要职责就是负责流程的调度和执行。

 

首先需要将流程定义模型解释为流程实例模型，在定义模型和实例模型之间建立起对应关系。一个简单的对应关系如下图所示：

 

执行引擎将流程定义模型的属性读取到相应的实例模型里，由实例模型完成流程的调度和执行。当然，上图只是一个简单的描述，实际情况要复杂的多，特别是节点定义（ActivityDefinition），根据实际应用，往往存在着多种类型，典型的有开始节点（StartDefinition）、任务节点（TaskDefinition）、自动节点（AutoDefinition）、分裂节点（SplitDefinition）、汇聚节点（JoinDefinition）、结束节点（EndDefinition）等等。这些节点的实例根据类型的不同执行不同的逻辑。其中，分裂节点实例和汇聚节点实例负责流程的调度，它们决定流程的流向，通常情况下，它们会调用一个脚本引擎执行一段脚本来决定流程的流向，同时，也会提供对外暴露的接口，由业务系统实现，接口返回的结果决定流程的流向。任务节点实例和自动节点实例则负责流程的执行，为保证流程执行引擎职责的清晰以及对外围设施的松耦合，它们只是发布相关的事件，通过事件发布/订阅机制来触发具体的逻辑执行。

 

典型的事件有流程启动事件、流程结束事件、进入节点事件、离开节点事件、时间事件等。例如，任务节点实例的进入节点事件将会触发工作项引擎生成工作项（Workitem），并触发时间服务器开始计时。

 

3、                    基于充血模型的工作项引擎

对最终用户而言，大部分的业务操作都集中在对工作项的操作上。常见的包括工作项的提交、收回、委派、追加和退回。这些操作从系统设计的角度不仅涉及到工作项（Workitem）对象内部状态的变化，而且影响到流程执行引擎的调度以及相关的其他工作项对象状态。

 

工作项引擎的职责包括两部分。第一，监听任务节点实例的进入事件，生成工作项实例。第二，处理上面提到的各种工作项操作。

 

实现时，工作项生成器根据任务参与者的执行模式典型的分为四种情况：

 

竞争参与，当有多个参与者参与该任务时，产生竞争，谁先开始这项工作，就由谁负责完成该工作。此时，工作项生成器生成多个工作项实例，在某个工作项完成时会终止其余工作项。

顺序参与，多个参与者按照指定的顺序完成该工作。A完成之后由B完成，B完成之后再交给C完成。此时，工作项生成器生成多个工作项实例，根据顺序依次激活各个工作项。

共同参与，多个参与者同时对工作进行处理。此时，工作项生成器生成多个工作项实例并全部激活。

智能决策，存在多个参与者的情况下，工作项生成器能够根据一定的指标（由数据分析，例如人员的处理效率，工作负载等等）和规则来决定该节点的参与者并为其生成相应工作项。这里涉及到算法。

 

对于工作流系统而言，各种流程实例对象都是充血模型。特定于各种工作项操作的处理，此时的工作项对象亦设计为充血模型，将业务逻辑封装到领域模型里，简化领域模型之间的交互，省去频繁的get/set。由领域模型再委派到具体的处理类里。

Client->(Business Facade)->Domain Model->service->Data Access(DAO)

 

4、                    工作项驱动业务表单的业务集成方式

最终用户对任务的处理，必然由工作项对应着某一业务表单。用户在工作项列表里选择自己需要办理的工作项，由工作项导航到业务表单。

 

特定于WEB系统，业务表单的导航由url完成。在流程定义模型设计时，将url设置入节点属性，生成工作项时将此url保存在工作项对象属性里。点击工作项详细信息时即打开该url，完成到业务表单的导航。业务表单页面通常需要引入处理工作项逻辑的父页面或者导入定制的js库，这些父页面或js库由工作流产品提供。这样，对于业务表单编写，工作流逻辑是透明的。

系统要集群，使用SNA方案。
一、 缓存的处理
缓存要使用统一的缓存服务器，集中式缓存。
原先的实现采用ehcache。
在spring里的配置，以资源缓存为例：

cacheManager负责对ehcache进行管理，初始化、启动、停止。
resourceCacheBackend负责实际执行缓存操作，put 、get、remove。
resourceCache实现具有业务语义的业务应用层面的缓存操作，内部调用resourceCacheBackend操作。

现在采用memcached。
关于客户端，采用文初封装的客户端，地址在http://code.google.com/p/memcache-client-forjava/。
使用spring的FactoryBean进行二次封装。同理：
memcachedManager负责对memcached进行管理，初始化、启动、停止。
代码：

 

配置：

 

resourceCacheBackend负责实际执行缓存操作，put 、get、remove。
代码：

配置：

  resourceCache同上，替换新的实现类MemcachedBasedResourceCache即可。

二、 Session失效的处理
采用memcached作为httpsession的存储，并不直接保存httpsession对象，自定义SessionMap，SessionMap直接继承HashMap，保存SessionMap。

会话胶粘：未失败转发的情况下没必要在memcached保存的SessionMap和httpsession之间复制来复制去，眉来眼去。

利用memcached计数器保存在线人数。

系统权限采用了acegi，在acegi的拦截器链里配置snaFilter

注意需要配置在第一个。
snaFilter的职责：
1、 没有HttpSession时，创建HttpSession;
2、 创建Cookie保存HttpSession id;
3、 如果Cookie保存的HttpSession id与当前HttpSession id一致，说明是正常请求；
4、 如果Cookie保存的HttpSession id与当前HttpSession id不一致，说明是失败转发；失败转发的处理：
     4.1、根据Cookie保存的HttpSession id从memcached获取SessionMap；
     4.2、SessionMap属性复制到当前HttpSession；
     4.3、memcached删除SessionMap。
5、 判断当前请求url是否是登出url，是则删除SessionMap，在线人数减1.

代码：

利用HttpSessionAttributeListener监听httpsession的属性变化,同步到memecached中的sessionmap。

  利用HttpSessionListener，sessionDestroyed事件时根据sessionid删除memcached里的sessionMap（如果存在）。不再担心httpsession的过期问题。
  三、 文件保存的处理

和缓存类似，采用集中式的文件服务。对于linux，采用nfs。参考文档http://linux.vbird.org/linux_server/0330nfs.php#What_NFS_perm。关键在于对权限的分配。
应用程序本身不用修改。

在集群部署的情况下，应用程序需要做出调整，主要集中在四个方面：对httpsession的处理、对缓存的处理、共享的文件系统、synchronized关键字的失效。

对httpsession的处理

对httpsession的处理最为重要，因为对WEB程序而言，httpsession无疑是最重要的全局资源，它需要被多个web服务器所共享。

无共享的集群架构（SNA），在这样的集群中，每个节点具备完全相同的功能，并且不需要知道其他节点存在与否。每个节点JVM进程不保持全局状态，才能够保证n个JVM节点的幂等性，那些所有涉及到全局状态的，必须放在JVM进程之外，例如用户ID可以使用cookie，session可以放入数据库（这并不是一个好的选择），文件可以放在共享存储系统中。

也就是说httpsession的信息需要被保存在JVM进程之外，例如分布式缓存、数据库。

这里是方案：

1、使用会话cookie保存web服务器产生的sessionid
   为什么是sessionid而不是userid，原因在于谁也不知道除去登录外其他人会在httpsession里干些什么

2、自定义SessionMap<String,Serializable>同步保存httpsession内的信息
   自定义SessionMap同步httpsession，在操作httpsession时不用改变调用接口，不用东张西望

3、使用分布式缓存memcached保存自定义SessionMap<String,Serializable>

4、会话胶粘
   未失败转发的情况下没必要在memcached和httpsession之间复制来复制去，眉来眼去

5、使用SnaFilter处理失败转发

6、使用HttpSessionListener实现SessionMap<String,Serializable>的过期
   利用容器session 机制的好处,httpsession过期的时候干掉memecached里的SessionMap

下面根据web请求的过程分情况讨论该方案：

A、登录

根据请求的url判断是否是登录请求

在线人数保存在memcached里

B、 正常请求

C、 失败转发

D、登出

根据请求的url判断是否是登出请求

E、HttpSession过期

不hack memcached，使用HttpSessionListener，sessionDestroyed事件时根据sessionid删除memcached里的sessionMap（如果存在）

关于在线人数的统计：在线人数存储在memcached里，将在线人数与sessionMap绑定，往memcached里增加sessionMap时在线人数+1，删除时-1.

项目情况：是一个大型公司的内部办公系统，该系统有两个和一般企业应用不太一样的特点：一是用户量非常多，人员数达到2W左右，另一个是采用分级管理的形式，各个分公司数据分开管理。

我们的定位：我们是作为业务平台的提供商参与这个项目的，我们提供底层的开发平台，系统集成商在此基础上进行二次开发。

在项目从开发到部署的过程中遇到了很多的问题，也反映出很多问题。

一、怎么回事，跑得比猫还慢
项目开发完毕后部署在Ibm aix 小型机上，32G内存，16个cpu。应用服务器采用的是weblogic9.2，数据库是oracle10.0.2。上线后发现系统运行的非常缓慢，甚 至比开发环境下的tomcat还要慢。于是开始排查原因，最开始是对SQL进行监控，优先考虑是数据库访问性能产生瓶颈。通过监控，发现很多业务需要执行 大量的SQL语句，查看客户编写的相关代码，发现在查询数据时循环执行了大量SQL。主要原因在于他们在代码中循环调用了我们相关API，一个最典型的例 子是通过用户ID查找用户NAME，他们在业务表格里没有保存用户name，而是在查询的时候通过用户ID查找用户name填充到页面，几乎每一个查询都 是n+1。
 
另外由于平台使用了hibernate，使得oo编程得非常爽快，导致开发人员完全忽略了相应的数据库操作所带来的压力。很多业务逻辑直接通过PO叠加完成，把一些可以通过很少SQL完成的逻辑全部分散放置到PO里，导致了大量PO的交互和SQL语句。

开始优化SQL，优化的同时增加大量业务缓存。但优化完毕后运行缓慢的现象依旧存在，性能有了一定的提升但是不是非常明显。继续优化，其中考虑过 多频繁访问的数据使用内存数据库的方式。但是优化过后在tomcat上效果明显，部署到生产环境就问题依旧。于是考虑weblogic的配置问题，作为开 发平台提供商，我们只是提供系统开发相关方面的支持，对于应用服务器和数据库服务器只是做基本的配置系统可运行即可。但是在这个问题上系统集成商咬定是我 们平台的问题不放，并且存在一个很严重的问题：他们使用的是盗版的weblogic，这样根本就没有相应的技术支持。

问题的解决：最后是找了一个BEA曾经的开发人员，问题实际非常的简单，现场部署的weblogic默认是运行在32位机器上，与64位机器存 在一定的不兼容。通过替换相应的jar包，问题得到了解决，主要是IO方面。替换完毕后，速度提升了进30% 。该开发人员说，如果没有lisence，根本就不会得到这些替换的jar包。

二、内存耗尽了
访问速度的问题解决了，系统的使用量很快上来，马上遇到新的问题：内存耗尽了。严重到几乎每天都要out of memory一次。这种问题在客户现场频繁出现。

本地测试，tomcat，sun jdk 通过Jprofiler监测内存使用情况。在并发访问门户的情况下，内存确实存在暴涨的情况，100并发，内存使用立刻上升了150m左右，继续并发 100，再增长150m。但是很快在抵达高峰时会有一次gc发生，内存使用稳定在200m，内存里大量char[]数组对象。疲劳测试，内存使用曲线并没 有出现逐渐上升泄露的情况。换weblogic和jrocket测试，gc发生的更加频繁，内存使用稳定。
 
但是现场依旧频繁当机，内存根本释放不了，一直逐渐增长，典型的内存泄露。对系统缓存、单态对象包括spring管理的对象、IO流进行了统一 排查，依旧没有找到内存泄露的原因。使用IBM 工具分析heapdump文件，结果还是大量的char[]数组对象占据内存，查找应用，找不到相关业务对象引用。
 
问题解决：问题解决是一篇偶尔搜到的oracle论坛的帖子，这里http://forums.oracle.com/forums/message.jspa?messageID=1040570 。原因在于oracle10的数据库驱动对statement最后执行的结果集有着引用，并且不会释放，目的在于通过内存而换取更好的性能。数据库连接采 用的是weblogic的连接池，关于connection有个相关的statement cache设定，设定一个connection能够被缓存的statement个数，最大是1024，而现场就被设定为了1024！connection pool的connection个数被设置为了500 。真是个恐怖的设置。在将1024改为10后，内存使用量轰然倒地，稳定在1g左右。这个设置是在前面系统访问速度存在问题时由系统集成商的开发人员设置 上去的，他们将所有和优化相关的参数全部开到了最大。这个问题要是用户购买的是正版的weblogic和oracle的话，相信也会很快得到解决。

三、线程阻塞
内存泄露的问题解决后，线程阻塞的问题浮出水面。系统集成商报告是线程死锁，通过分析工具其实是线程阻塞，主要问题在于系统用到了 synchronized关键字，对工作流相关API全部使用了synchronized，原因在这里：http: //ronghao.javaeye.com/blog/205731 。分析发现一个工作项提交的操作在连接数据库时被挂起了20分钟！造成了大量线程的排队阻塞。被挂起的原因有很多种。我们采用的方法是将接口拆分和设置事 务timeout时间。但是这显然不是一个好方法。最后是去掉所有的synchronized关键字，将同步的问题交由数据库解决，问题解决。

四、反思
1、系统集成商为什么不购买正版？
2、开发平台提供商究竟在项目开发中处于一种什么样的位置？开发平台是否对所有软件开发问题都要负责？
3、开发平台是越封装越快乐吗？还是越封装越丑陋？

更具体的细节在这里：

 AIX+weblogic性能诊断记录

从事工作流以及相关开发已经三年。提到工作流，很多人都会想到BPM，想到业务流程。对于业务流程，我的理解经过了一个过程，从最开始对工作流抱有的不切实际的期望，到对BPM的一些看法，再到目前的趋于实际。有一些感触，也有一些理解。对于业务流程管理而言，我想说的是：BPM向左，工作流向右，都不靠谱，或者说它们实际所能描述的流程和这里的业务流程根本就风牛马不相及，不是一个概念，唯一的相同点是只不过都叫流程而已。

一、什么是业务流程

业务流程是一个技术术语，它具有准确的定义：有组织的活动，相互联系，为客户创造价值。

这句话很好理解。甚至可以说任何企业的活动都是以业务为主线，以流程为线索串联起来的。企业的规章制度、操作手册等都与业务流程有着契合点。

二、业务流程对于企业的意义

业务流程对于企业的意义不仅仅在于对企业关键业务的一种描述，更在于对企业的业务运营有着指导意义，这种意义体现在对资源的优化、对企业组织机构的优化以及对管理制度的一系列改变。这种优化的目的实际也是企业所追求的目标：降低企业的运营成本，提高对市场需求的响应速度，争取企业利润的最大化。

三、业务流程也是一个体系

业务流程通常的表现形式是流程图（不是唯一形式），毕竟图形是最易于理解的一种形式，但似乎我们太关注于流程图本身而忽略了其他。除了流程图之外，业务流程还应该包括目标和指导方针，这才是一个完整的业务流程。在梳理业务使用业务流程描述时首先要想到的是该流程所要达到的目标，能为客户创造什么价值，脱离开业务目标或者说纯粹为描述业务而描述业务是没有意义的。同时在制定业务流程时也要考虑到该业务流程的指导方针，同一个业务可能有很多种业务流程的描述形式，具体哪一种是最合适的，这里就必须有一个指导方针来进行约束。

四、业务流程的特征

1、层次性、逐层抽象

业务流程是有层次性的，这种层次体现在由上至下、由整体到部分、由宏观到微观、由抽象到具体的逻辑关系。

这样一个层次关系符合人们的思维习惯，有利于企业业务模型的建立。一般来说，我们可以先建立主要业务流程的总体运行过程（其中包括了整个企业的大的战略），然后对其中的每项活动进行细化，落实到各个部门的业务过程，建立相对独立的子业务流程以及为其服务的辅助业务流程。

业务流程之间的层次关系一定程度上也反映了企业部门之间的层次关系。不同层级的部门有着对业务流程不同的分级管理权限。决策层、管理者、使用者可以清晰的查看到下属和下属部门的业务流程。

为使得所建立的业务流程能够更顺畅的运行，业务流程的改进与企业组织结构的优化是一个相互制约、相互促进的过程。

2、以人为本

组织中最重要的部分是人员的工作方式以及构成他们每日操作的工作流程。

人是业务流程的驱动者，组织中的每一个人都会在业务流程中充当一个角色。通过良好的业务流程，每一个人都会有自己清晰的职责，要求具有良好的沟通协作意识和团队意识，明确自己在一个个业务流程中所担当的角色。

同时对于参与其中的业务流程，每个人员都要有自己的反馈。

首先，每个人员都能查看到这些业务流程，他们需要充分理解这些业务流程、流程的业务意义和目的，这些业务流程通过切合他们理解能力的方式（切合业务的图形、说明文字、相应的制度、规范、标准等等）得以展现。

其次，对于流程运行中存在的问题或瓶颈，每个人员都要积极反馈（提出修改的建议，或者在权限范围内直接修改）以促进流程的持续改进，业务流程的管理和变动不仅仅是业务分析人员或管理人员的职责，每一个员工都要参与其中，否则只有失败。管理人员和决策层更重要的职责是制定出业务流程的规则和约束，在这个规则和约束范围内，员工可以根据变化的商业环境对业务流程做出迅速修改，这样不必等到领导了解情况后再做出决策从而失去机会。

3、对流程运行效益的分析

从企业投资者的角度来讲，好的业务流程设计必然是能够为企业带来最高利润的设计。因此，对业务流程的效益分析是评价业务流程的一个重要方面。财务数据是最关键的数据，但这种分析不一定完全是由数据支撑的，有些是不能量化的，比如人员效率等等。

五、业务流程管理

良好的业务流程管理是保证企业灵活运营的关键（业务流程管理又何尝不是一种业务流程？）。

1、业务分析

实际这也是业务流程管理最重要的部分。它需要对企业业务有着强大的分析能力，因为业务分析对企业的运营有着重大的指导意义，只有具备了这样的业务分析能力，才能把握住企业运转的真实流程，而且这种分析能力往往带有对整个行业的深刻理解和前瞻性。没有异议，业务分析在于人，与IT无关。

2、业务流程的持续改进

不仅仅是流程管理人员（管理决策层）根据运行效益的分析和商业环境的分析对流程进行重整。还包括每个员工对其参与的流程的持续反馈和持续改进。柔性的业务流程。

3、IT系统与业务流程的关系

IT系统与业务流程并没有直接的关系。正如06z在SOA帖子里表达的：soa95%以上的工作是在做业务流程的分析解构和重整，技术层面的支持只占5%不到。在落实到技术层面，你觉得一个soa产品究竟应该包括些什么内容呢？这些内容又能有多少是能够辅助大家对业务流程进行分析和测试，对业务元素进行重整和再分配？如果你们真的有这个能力，你们觉得是在这里继续开发软件过苦日子，还是去开拓商业咨询呢？我的观点是：SOA很美好，但是一落地就变成了小丑。所谓的业务流程管理软件同理。

可以这样理解：业务流程管理是一个很大的命题，IT系统通过信息化对它的子集进行支撑，这里的IT系统包括的范围很广泛，包括了所有的企业应用软件（所有的企业应用软件都可以看作是对企业某部分的业务流程进行的描述）。业务流程管理的核心在于业务流程的分析解构和重整，这点是所有软件都不可企及的，关键在于人。至于BPM还是工作流，它们本来就有它们自己的适用范围，硬要把它提升到业务流程管理的高度来宣传，那就真的和小丑一样，滑稽而可笑。

关注下篇：BPM是干什么的

用js编写自己的组件，测试一直是个头疼的问题。最开始大量使用alert，firebug出现后天突然蓝了。但人的欲望总是没有止境的，在面对越来越多的后台数据交互以及特定于不同业务数据不同的展现形式时，仿佛一夜回到解放前。

说说我现在的困境：

目前要做的是工作流的提交页面，也就是对当前办理工作的用户展现后续任务，根据不同的情况由用户选择或是引擎自动计算。这是最简单的情况，后续包括参与者的选择计算、时间服务设定以及Comment等等。
现在根据业务逻辑分为了四种情况：
1、串行
2、分支选择
3、M选N选择
4、复杂的分支组合
四种情况需要准备不同的业务测试数据，同时页面展现也是不同的。我采用的方式如下图：


针对每种情况都建立相应的测试文件夹，在各自文件夹下准备各自的业务测试数据以及测试页面。并且一个testcase往往需要很多的业务测试数据（和通用组件还是不太一样）。清晰还是清晰，但是问题在于这种测试还是人肉，做不到自动化测试，同时为了业务数据能够顺利插入不得不hack一些代码。当增加或改动部分代码后就要人肉返测一次，预计代码还会大量膨胀，相应的测试文件还会增加。真是苦海无边，无心睡眠。想想cc和junit真是幸福的像花一样。

我佛慈悲，不知道大家有什么好的方法没有？

收回

收回是工作流参与者对自己“已办任务”（对已完成的工作项）的一种操作，即参与者主动对已办理过的工作项进行重新办理。

为什么要收回？

参与者完成任务后，发现自己办理有错误等情况后，需要将此任务收回重新办理。

工作项的参与方式

目前有四种方式：共同参与、竞争参与、顺序参与、基于角色的共同参与。

下面会针对这四种方式进行讨论。

工作项收回模式

1、未触发下一节点的工作项的收回

即当前任务节点并未完成，依旧处于执行状态

1.1共同参与

如图：在节点A未结束之前，workitem1、workitem2和workitem3正常完成后可以任意收回。在只产生一个workitem的情况下，不存在未触发下一节点的收回情况。

1.2顺序参与

如图：workitem1、workitem2和workitem3顺序完成，workitem1在workitem2签收（包括挂起和手工终止）前可以收回，同样，workitem2在workitem3签收（包括挂起和手工终止）前也可以收回。在只产生一个workitem的情况下，不存在未触发下一节点的收回情况。

1.3竞争参与

因为只会产生一个workitem，该workitem完成后会立刻触发下一节点，所以不存在未触发下一节点的收回情况。

1.4基于角色的共同参与

与1.1相同。

2、已触发下一节点的工作项的收回

 

2.1共同参与

问题1：多个工作项时谁可以执行收回操作？

workitem1、workitem2和workitem3都可以执行收回操作。第一个工作项的收回将会导致节点B实例的删除，同时节点A重新恢复执行状态。

问题2：节点B处于什么状态节点A的工作项可以执行收回操作？

由A触发的节点B处于正在执行的状态，节点B所产生的工作项：

a共同参与   工作项均未签收、挂起或手工终止

b顺序参与    第一个工作项未签收、挂起或手工终止

c 竞争参与   工作项均未签收、挂起或手工终止

d角色        同共同参与

问题3：工作项收回产生的影响？

节点A重新执行，收回的工作项重新执行。节点B重新恢复未触发状态，B所产生的工作项全部删除。

2.2顺序参与

问题1：多个工作项时谁可以执行收回操作？

workitem1、workitem2和workitem3根据顺序可以依次执行收回操作。

2.3竞争参与

情况简单，只有一个工作项，所以可以直接收回。

2.4基于角色的共同参与

同2.1

工作流收回模式

后续触发节点只能是人工节点（可以是多个，至少一个），否则不支持收回。目前不支持父子流程之间的收回。

一个典型的同步汇聚情况：

节点1首先执行完毕，但是因为是同步汇聚，所以它不会触发实际的流转；而节点2的完成则会触发节点3的执行。在这种情况下，节点2的工作项可以执行收回操作，而节点1的工作项因为后续没有触发节点而不能收回。

关于Domain Model的讨论已经非常多了，炒炒冷饭，这里是自己的一些做法。
以Workitem（工作流里的工作项）作为例子

最开始的做法：
一个实体类叫做Workitem，指的是一个工作项或者称为任务项
一个DAO类叫做WorkitemDao
一个业务逻辑类叫做WorkitemManager(或者叫做WorkitemService)

主要看看WorkitemManager，因为主要逻辑集中在这里



Workitem类里有一些状态转换的逻辑，这样避免直接调用get/set属性方法



接下来的做法：
三个类不变，将WorkitemManager打平，将逻辑移动到Workitem


实际上此时WorkitemManager的功能非常有限，仅仅是事务边界和获取workitem对象，甚至在一些情况下可以省略。

通过一个Container类将spring的applicationContext进行封装，然后通过getBean()的静态方法即可访问被spring所管理的bean。实际是将workItemDAO隐式注入了Workitem。



这样带来的好处是业务逻辑全部被封装到Domain Model，Domain Model之间的交互变得非常的简单，没有频繁的set/get，直接调用有业务语义的Domain Model的方法即可。问题在于单元测试时脱离不了spring的容器，workItemDAO需要stub。我觉得这个问题不大，问题是Domain Model开始变得臃肿，在业务逻辑复杂时代码行急剧膨胀。

现在的做法
以上三个类保持不变，增加一个类WorkitemExecutor，将业务逻辑移步。


将业务逻辑拆分成两部分，一部分在Workitem，另一部分委托给WorkitemExecutor。实际上是Domain Model将复杂逻辑的情况重新外包出去。调用的时候，面向的接口还是Domain Model的方法。注意到WorkitemExecutor和WorkitemManager的API是非常相似的。实际可以这样认为，传统的方式
Client->(Business Facade)->service(Business Logic 部分依赖Domain Model)->Data Access(DAO)。
现在的方式
Client->(Business Facade)->Domain Model->service->Data Access(DAO)。

另外，在返回client端的查询的时候还是倾向于直接调用DAO，而不是通过Domain Model。

改进：
注意到代码中有这么一行

确实是一个bad smell.当代码中大量出现后，这种造型是很恐怖的。所以采取了一种处理方式：给所有Domain Model继承一个父类，在父类里集中管理所有Domain Model所依赖的services，在父类里进行造型。

回退（Rollback WorkItem）

回退是工作流参与者对自己“待办任务”（实际是对工作项）的一种操作，即参与者主动回退待办任务列表中的任务到已经执行过的人工节点。

为什么要回退？

参与者接受任务后，发现不应由自己办理此任务或以前的执行者办理有错误等情况后，需要将此接受的任务回退给以前某个节点的执行者重新办理。

回退模式

回退的情况实际上是非常复杂的，其中包括了参与者的重新选择以及回退的条件判断等等。这里先列出常见的回退模式（其实也是我们支持的模式）。

串行

   

这种情况最为简单，后续节点可以回退到前续任意人工节点。回退后，节点重走。

分支

   

这种情况也相对简单，实际执行的分支上的节点可以回退到前续任意人工节点（不区分主支和分支）。同样，主支上的节点也可以回退到任意实际执行的分支上的节点。

可能的问题：多次回退后的回退节点选择。例如：第一次流程经过节点2、节点3到达节点5，节点5可以回退到节点1、节点2和节点3的任意一个，此时节点5回退到节点1，节点1重走，这一次流程改为经过节点4到达节点5，节点5回退时如何选择回退节点？此时的策略是以最近实际执行的分支为准，即节点5只允许回退到节点4和节点1，不允许回退到节点2和节点3。（抹去记忆）

并发

   

对于并发的情况，分支节点只允许在分支的节点间回退。

同理，主支节点也只允许在主支的节点间回退。

多实例汇聚

   

在这种情况下，节点5会产生2个实例，实际相当于继续并发。节点5根据具体哪个节点触发的它而产生回退节点。同时不允许回退到节点1以及前续的节点去。

子流程

   

支持子流程到父流程的回退，也支持父流程到子流程节点的回退。需要注意的是子流程节点有可能产生多个子流程实例，在这种情况下不支持父子流程之间的相互回退。

回退节点的参与者选择

默认策略是由原先节点的实际参与者重新处理，比如节点2回退到节点1，则节点1的实际参与者重新处理该节点任务。这也符合大多数实际的业务场景。

在节点任务竞争参与的情况下，提供另一种策略，即让人员重新竞争。

回退的条件判断

对于多人（或者多部门，用户）参与的工作项，提供不同的回退策略

任意人回退即回退，剩余工作项手工终止

最后提交人回退才回退

   流程定义期定义该策略。

   另外流程定义时提供节点可回退列表，由用户在定义期对可回退的节点进行限制。

关于业务补偿

业务补偿是一个很重要的概念，在回退的情况下需要相应的回退部分业务操作。这里由引擎提供统一的接口，返回回退路径，由客户自定义代码进行匹配处理。

 

关于实现

很多工作流引擎通过流程定义时绘出回退线来显式的支持回退，这种实现在业务复杂的情况下会造成流程图的异常烦琐，但是比较清晰，实现比较容易。隐式实现相比而言优点更多。

收到这本书已经好久，甚至读完这本书都已经好久，一直想着写个书评，却一直被这事那事拖着，直到今天。我只想说，这是一本好书。

关于Hibernate似乎不必说太多。和朋友聊天，朋友说，你对Hibernate熟吗？我说，还好，用了两年了。朋友说，如果10分是满 分，你给自己打几分？我认真想了想，6分吧。说实话还真没有底气，会用而已。在此之前，我就看过一本Hibernate的书籍，《深入浅出 Hibernate》，然后就是满江红翻译的Hibernate中文手册。我想，也许没有必要再买一本Hibernate的书了，有问题查查 Hibernate中文手册就好了。

问题在于，我收到了这本书。

花了两个礼拜大概看过这本书。看的快是因为一些内容本来就很熟悉，还因为把jpa这部分全部略过了。一口气读完的。原谅自己曾经的浅薄吧，看 完这本书才发现自己对Hibernate的了解其实少的可怜，知道如何映射实体对象，知道对象的3种状态，知道save和 saveorupdate，get和load的区别，知道级联和关系控制反转。。。。知道这些就够了吗，实际差得还很远呢。这本书把以前许多零散的知识点 全部系统的串联起来，很多时候，看得我暗自流汗，哎，原来是这样的啊。

实际这本书不仅仅局限于Hibernate，我更认为是对java持久化的一个完整介绍和总结。我想，像without ejb一样，是应该人手一本的。

关于翻译，这本书被人诟病的厉害，原因是认为翻译的很差。我的感觉是，确实存在问题，但是也不至于差到网上说得那种地步。至少我读过一遍，基 本上没有碰到读不过去的地方，相反，还是比较流畅的。但是不是说没有问题，一些句子是根据上下文很快得出意思的。我想，对于刚使用Hibernate不久 的人来说，这种理解很可能就显得比较困难，会显得无所适从。另外，单纯从英文版来说，这本书也不适合作为Hibernate的入门书。另外，这本书的定价 太高，我想，这也是读者反应很激烈的一个原因。很高的期望，很贵的价格，结果不是很满意，自然谩骂的厉害。我想，出版社的读者定位、市场策略包括定价都是 存在问题的。

最后说说翻译，翻译确实不是一件轻松的事情，这点我有很深的体会。去年翻译《Enterprise AJAX》时，每天的进度只有两三页，有时一个句子要反复揣摩好长时间，真是痛苦的一个过程（但是却是收获良多）。

最后，一本好书。 测试在sqlserver2000上进行，对工作流操作的相关方法在单元测试里进行多线程并发。测试发现sqlserver出现死锁的情况相当多，一些典型的情况：

1、对同一张表先insert再update是很快会引起死锁的，不管操作的是否是同一记录
解决方法：对于同一记录，需要调整hibernate的映射策略，使得一次insert完成操作。对于不同的记录需要在代码中手动flush，使得update先于insert。

2、对两张表进行多次update操作时，两张表交替update也会很快引起死锁
解决方法：在代码中手动flush，保证对两张表的update不会出现交替的情况。

3、部分大范围扫描的select和update混合也会导致死锁
解决方法：优化sql，尽量减少sql语句，通过给po增加持久化字段的方式减少关联查询

经过优化，大部分情况下数据库死锁的情况得以避免，另外奇怪的是通过事件探查器在死锁时并未发现锁升级的事件。但是在一些特殊情况下（例如多个并发汇聚的直接联合），死锁依旧发生。最后不得不对方法进行synchronized关键字同步，这个通过synchronized flush完成。业务方法不必同步，最后批量操作数据库时进行同步。

换oracle进行测试，在未synchronized的情况下，未发生死锁情况。由此可见sqlserver与oracle锁实现机制存在很大的差别。对sqlserver鄙视之。另，同事说，sqlserver2005后性能和机制发生了很大的变化，未测试。

补充一下我的一个最简单情况下的测试用例：
PO：

映射文件 hibernate3：

被测试方法（都配置有事务）：

测试用例：

测试结果：不论是hibernate还是jdbc，并发情况下都很快就会引起sqlserver2000的死锁，换用两种数据库驱动jtds和jturbo死锁的情况没有变化。

结论：sqlserver2000数据库的lock配置策略，不支持，或者数据库本身，就不支持对不同的行做同时操作（或者支持不完善），所谓的行锁支持很不完善，死锁情况非常容易发生。

补充：我对数据库的一些实现机制也并不是很了解，所以这里也只能列出现象而不能解释死锁的根本原因。另外感谢Alex的讨论。
今天用hsqldb做单元测试时碰到这么个异常
failed batch; nested exception is java.sql.BatchUpdateException: failed batch
经过检查发现是HSQLDB的问题
The bug is in HSQLDB - a well known one (any Google search for HSQLDB and that "failed batch"
message would have told you it).
https://sourceforge.net/tracker/?func=detail&atid=378131&aid=1407528&group_id=23316
解决方法 : turn off batching with HSQLDB it doesnt work.
设置<prop key="hibernate.jdbc.batch_size">0</prop>即可

这是我们（东方易维）工作流产品设计过程中采取的设计：

一、流程实例的状态

   状态分为5种：实例化、执行中、挂起、手工结束、正常结束。

   状态的变迁如下图：

二、节点实例的状态

状态分为5种：实例化、执行中、挂起、手工结束、正常结束。

状态的变迁如下图：

三、具体节点的状态

   细分：

A、人工节点、等待节点

这两个节点被触发后存在一个执行等待的过程，所以可以被用户直接挂起和手工结束。人工节点的挂起意味着所有未完成工作项的挂起，同时相应时间服务的时间计算的挂起。手工结束会使流程跳过该节点（所有工作项手工结束），继续往后流转。

B、开始节点、结束节点、分支节点、自动节点

这些节点的特点在于被触发后立刻执行和流转，所以不会存在挂起和手工结束的状态。

C、并发节点、汇聚节点

并发节点和汇聚节点不存在挂起的状态，同时不能被用户直接手工结束，它们的状态受流程实例状态和相关节点实例状态的影响。

并发节点和汇聚节点的情况复杂一些，分模式讨论

图1

1、同步汇聚（图1）

根据情况触发节点0、节点1、节点2中的一个或多个，汇聚节点等待所有实际触发的节点完成后再执行流转。中间汇聚节点只会产生一个实例。

1.1、正常流转时的处理策略

当汇聚节点未被触发时（即节点0、节点1、节点2都未执行结束），并发节点处于执行状态，一旦汇聚节点被触发（即节点0、节点1、节点2有一个执行结束），并发节点正常结束并且汇聚节点处于执行状态，所有并发出的节点实例执行结束后，汇聚节点正常结束，流程继续流转。

1.2、用户挂起、手工结束相关节点的处理策略

1.2.1、汇聚节点未激活时

节点0、节点1、节点2的挂起和恢复执行不会影响并发节点的状态（依旧处于执行状态）；节点0、节点1、节点2的任一手工结束都会触发汇聚节点，使并发节点正常结束，如果所有并发的节点实例都结束（包括手工结束和正常结束），汇聚节点正常结束，触发流程流转。

1.2.2、汇聚节点已激活时

节点0、节点1、节点2的挂起和恢复执行不会影响汇聚节点的状态（依旧处于执行状态）；节点0、节点1、节点2的手工结束会影响汇聚节点的状态，每个节点实例的手工结束会引起汇聚节点的判断，如果所有并发的节点实例（包括正常结束和手工结束）都结束，汇聚节点正常结束，触发流程流转。

1.3、用户挂起、手工结束流程的处理策略

1.3.1、汇聚节点未激活时

流程的挂起和恢复执行不会影响并发节点的状态（依旧处于执行状态），节点0、节点1、节点2会被全部挂起或恢复；流程的手工结束会引起所有节点的手工结束。

1.3.2、汇聚节点已激活时

流程的挂起和恢复执行不会影响汇聚节点的状态（依旧处于执行状态），节点0、节点1、节点2未执行结束的实例会被全部挂起或恢复；流程的手工结束会引起所有节点的手工结束。

2、nOutOfM汇聚（图1）

根据情况触发节点0、节点1、节点2中的一个或多个，汇聚节点等待N个实际触发的节点完成后即执行流转（N>0且N<M，M为实际触发的节点个数），在N<=0和N>=M的情况下即为同步汇聚。中间汇聚节点只会产生一个实例。

2.1、正常流转时的处理策略

当汇聚节点未被触发时（即节点0、节点1、节点2都未执行结束），并发节点处于执行状态，一旦汇聚节点被触发（即节点0、节点1、节点2有一个执行结束），并发节点正常结束并且汇聚节点处于执行状态，N个并发出的节点实例执行结束后，汇聚节点正常结束，流程继续流转，M-N的节点实例被手工结束。

2.2、用户挂起、手工结束相关节点的处理策略

2.2.1、汇聚节点未激活时

节点0、节点1、节点2的挂起和恢复执行不会影响并发节点的状态（依旧处于执行状态）；节点0、节点1、节点2的任一手工结束都会触发汇聚节点，使并发节点正常结束，如果N个并发的节点实例都手工结束，并发节点正常结束，触发汇聚节点，汇聚节点正常结束，触发流程流转，M-N的节点实例被手工结束。

2.2.2、汇聚节点已激活时

节点0、节点1、节点2的挂起和恢复执行不会影响汇聚节点的状态（依旧处于执行状态）；节点0、节点1、节点2的手工结束会影响汇聚节点的状态，每个节点实例的手工结束会引起汇聚节点的判断，如果N个并发的节点实例（包括正常结束和手工结束）都结束，汇聚节点正常结束，触发流程流转，M-N的节点实例被手工结束。

2.3、用户挂起、手工结束流程的处理策略

2.3.1、汇聚节点未激活时

流程的挂起和恢复执行不会影响并发节点的状态（依旧处于执行状态），节点0、节点1、节点2会被全部挂起或恢复；流程的手工结束会引起所有节点的手工结束。

2.3.2、汇聚节点已激活时

流程的挂起和恢复执行不会影响汇聚节点的状态（依旧处于执行状态），节点0、节点1、节点2未执行结束的实例会被全部挂起或恢复；流程的手工结束会引起所有节点的手工结束。

3、辨别汇聚（图1）

是nOutOfM汇聚的特例，N=1

4、多实例汇聚（图2）

图2

根据情况触发节点0、节点1中的一个或多个，节点0和节点1任意一个执行结束后都会触发汇聚节点产生一个新的实例，汇聚节点实例紧接着触发节点2，节点2也会产生多个实例。

4.1、正常流转时的处理策略

当汇聚节点未被触发时（即节点0、节点1都未执行结束），并发节点处于执行状态，一旦汇聚节点被触发（即节点0、节点1有一个执行结束），汇聚节点会紧接着触发节点2，汇聚节点正常结束。所有并发出的节点实例执行结束后，并发节点正常结束。

4.2、用户挂起、手工结束相关节点的处理策略

节点0、节点1的挂起和恢复执行不会影响并发节点的状态（依旧处于执行状态）；节点0、节点1的手工结束会影响并发节点和汇聚节点的状态，每个节点实例的手工结束会引起汇聚节点产生新的实例并触发节点2，同时会引起并发节点的判断，如果所有并发的节点实例都手工结束，并发节点正常结束。

4.3、用户挂起、手工结束流程的处理策略

流程的挂起和恢复执行不会影响并发节点的状态（依旧处于执行状态），节点0、节点1、节点2会被全部挂起或恢复；流程的手工结束会引起所有未结束节点的手工结束。

5、隐式结束，没有汇聚节点与并发节点对应（图3）

图3

所有节点结束时（正常结束或手工结束），并发节点正常结束。流程的手工结束会引起所有未结束节点的手工结束。

四、流程实例状态变化对节点实例状态造成的影响

1、流程实例的挂起

   A类节点挂起，B、C类节点不受影响。同时在流程实例恢复执行之前，A类节点不允许用户直接恢复执行。

2、流程实例的手工结束

   所有节点全部手工结束。

五、节点实例状态变化对流程实例状态造成的影响

隐式结束的情况下，节点的手工结束或正常结束都会触发流程的判断，如果所有的节点都已结束则流程结束。

用户的需求大概分为两部分：一部分是整个项目完全基于工作流来搭建开发，这也是很多工作流厂商患有“平台压迫症”的原因；另一部分是将工作流作为业务组件加入已有的项目中，推动业务的“审批”流转。

前者的要求显然更高，但也意味着有更多的利润。其实这一部分的用户又可以进一步的细分：一是技术能力比较差的公司，他们通过层层外包接到项目，而又没有实力自己开发，于是想通过采购工作流加上几个刚入门的程序员来完成整个项目的开发（这类用户往往也是业务平台最大的客户群），他们想着是一整套的开发解决方案，甚至包括业务分析；二是对业务编程的需求，他们需要流程引擎能够侵入业务编程的内部，对业务的状态和生命周期进行灵活的管理，从而最大程度的简化开发或者说满足一些复杂业务编程的需要。

后者的需求则比较简单，多是某一行业的项目公司，突然碰到有审批的需求了，采用工作流多是满足人工“审批”的需要，以及部分的统计分析。

需要承认，工作流其实与最终用户还差得很远，也就是说在众多厂商的网页上，那副著名的业务流程生命周期其实是一句空话。一句话说，就是那个什么流程设计器是给程序员用的，至于用户，哪凉快哪去。也就是说现在的工作流还不能给最终用户提供价值。OK，既然工作流的价值是提供给集成商的，集成商就会考虑成本，于是工作流能否提供一个完整的开发解决方案就成了最重要的考量。

最后说说市场。工作流其实有着很大的市场，只不过这个市场被开源工作流和平台瓜分掉了。因为目前的工作流不能给最终用户提供价值，所以集成商在遇到审批的需求时，首先想到的会是开源的工作流引擎，从jbpm、osworkflow的流行也可以看出这一点，并且知识的积累确实比购买工作流来的划算，同时很多公司通过积累也会有自己的流程组件，这并没有太大的难度。难度留给技术能力一般的公司，他们首先想到的会是一整套解决方案而不仅仅止于流程服务，于是平台出现了，平台说：“灰壳显灵，银弹来了。”

关于平台，有一个很时髦的流行词汇，叫“业务应用基础平台”，稍候待续。 py工作流是国内比较好的工作流之一。大概看过它的一些文档，分析一下。
1、路由模型
 py支持的工作流模式其实并不多，只是支持1到7七种模式而已，其中比较重要的是模式6和模式7，即M选N分支和M选N聚合，看过它的实现，利用转移线条件来触发转移线，从而触发后续的节点。这样做比较简单，但是同时也存在很多问题，例如在路由非常复杂的情况下，例如多个分支节点的串联，以及并发路由存在多个节点时，这种做法实现起来就非常困难。另外，并发路由的工作流变量会存在相互冲突的情况，也包括业务数据的冲突。可以说py的路由模型还是很简单的，支持简单的业务可能没有问题，对于复杂的业务可能需要很多其他额外的办法。当然，很多国内的工作流甚至连模式6和模式7都支持不了，同时工作流的应用目前还具有很浓的“审批”的影子（貌似有人很讨厌审批这个说法），所以目前的路由模型应该满足需求了。
2、任意路由和回退
 没有看到任意路由和回退的复杂示例。关于任意路由，产品说明中说到可以在整个流程范围内任意自由路由，我觉得这个说法本来就是有问题的，并发路由的情况下，并发支线往主线上跳转，这种情况会有很多问题存在，其他并行的支线如何处理？或者说根本就没有考虑到这些复杂的情况？回退也是一样的道理，至于业务补偿的提出还是不错的，不过推给了用户自己设置回退动作。
3、关于WFMC和BPEL规范
 看看流程定义文件就知道了，它不支持任何规范。敢说国内工作流的流程定义就没有遵循规范的。
4、参与者的指定
 提供了组织机构、角色、个人这三种常见的参与者设置模式，还提供了流程启动者、活动执行者、从相关数据或从规则逻辑中获取参与者的模式。
5、工作的代理和代办
6、时间服务
 提供了四种时限。活动提醒、活动执行、流程提醒、流程执行。
7、业务开发
 感觉这是非常出彩的地方，在一个简单的示例中几乎不需要任何编码，比如一个简单的请假管理。看看它的流程定义文件，它几乎将整个业务表单都嵌入到流程定义里去了。这样做是否合适？我个人倾向于引擎与业务完全分开，通过反射或者某种映射将两者关联到一起。如果是用户自己开发已有的复杂业务，如何将工作流嵌入？至于studio也是非常出色的，具有开发调试的功能。调用接口非常的清晰。
总结一下：py工作流还是一个不错的工作流引擎，抛开它的宣传，感觉引擎的实现还是有些简单，或者说只是满足了目前的一些常见需求，至于所说的SOA和服务编排，我觉得目前还不现实。它的优势在于与其平台的完全融合，能够利用很多既有设施，可是这又何尝不是把双刃剑？另外，强大的市场宣传和良好的服务团队也是选择工作流时的重要考虑。 委办是什么？即分发给A的工作项可以委派给B代为进行处理。委办只针对个人。委派给组织或岗位似乎没有意义。
一、委办的分类
 1、用户单一工作项的委办以及收回委办
 2、用户所有工作项的委办，全权委办
 3、用户按流程划分工作项的委办，基于模板的全权委办，也可以理解为基于业务的委办
二、委办的触发与终止
 1、对于单一工作项的委办，在待签收和待办工作项列表需要出现委办的功能按钮，由用户选择其他用户代为办理。工作项委办后进入委办工作项列表，用户可以收回委办，同时用户和被委办人都可以对该工作项进行办理，用户自己处理则工作项自动被收回委办。
 2、对于全权委办以及基于模板的全权委办，需要委办申请单。用户通过填写委办申请单，将某段时期内工作项列表的处理工作委派给他人。消息通知：当用户将工作委派给指定的被委办人时，被委办人可以收到提醒消息。
 3、委办的自动终止以及手动结束：当委托的时间到期时，委办功能自动终止，委办申请记录将只读。用户也可以手动结束委托，逻辑删除或对委办申请记录进行修改。维护委办申请列表。
三、委办工作项列表
 1、用户可以在委办列表里对委办的工作项状态进行跟踪，对于还未被被委办人签收的工作项可以收回或直接办理
 2、被委办的工作项进入委办人的委办列表
 3、被委办的工作项按状态进入被委办人的待签、待办和办结列表，注明是被委办即可
 4、委办工作项的再委办，工作项增加委办的说明字段，委办工作项的依次状态影响
四、其他
 1、提交工作项页面，选择用户出现委办人时，名字红现，括弧注明其将被委办的被委办人
 2、提交工作项页面，选择部门或角色包含委办人时，不做处理。引擎生成工作项时做出处理，对工作项做出委托说明
 3、流程跟踪列表，增加委办说明字段 既然是与用户相关的权限，那么权限的表现则一定与UI紧密相连。工作流管理系统里，用户与工作流的交互界面有四种：
1、流程设计器
    流程设计器的功能比较单一：定义或更新流程定义。里面涉及到包、模板和版本的概念。资源即流程模板（例如发文模板、收文模板），权限可以细分为：维护、只读以及不可见。
2、流程管理控制台
  对流程实例（包括活动实例和工作项实例）进行管理。这里对资源的划分有两种方式：操作和数据。从操作来分比较琐碎，例如：流程实例的挂起、终止、恢复、跳转，活动实例的挂起、终止、恢复等等，当然可以做一种集合，例如：对流程实例的管理、对活动实例的管理、对工作项实例的管理、时间服务的管理等等。从数据划分则很好理解，例如：发文的流程实例、收文的活动实例等等。两种方式的组合构成最终的权限。
3、工作项列表
    这个似乎没什么好说的，工作项直接分配到用户、部门和岗位。
4、与流程相关的业务数据
    用户对业务自身的权限以及不同流程节点对业务的权限。看问题的两种方式。业务数据处于流程中时由流程决定权限，例如拟稿时可以操作哪些字段，审批时是否可以上传附件等等。流程结束后，业务数据归档，此时的权限由业务权限+流程权限组合。简单的一个例子：普通用户A可以在发文模块里看到自己参与过的所有发文文件，发文管理员B则可以看到发文模块里所有的发文文件。
    
结合具体的业务需求：
1、主控岗位的提出。例如发文管理，存在主控岗位，可以对所有的发文流程进行管理，催办、督办等等。
2、大集中模式下对数据的再划分。还是以发文管理为例，北京公司的发文管理员对北京的发文数据进行管理，上海公司的发文管理员则只能对上海的发文数据进行管理。

最终的权限分类：
1、流程设计器里流程模板的可见与不可见。可见即可维护。
2、流程管理按操作来分显得没有实际的意义，用户关注的是业务数据即操作的范围。流程实例（活动实例）的可见与不可见。可见即可操作。更进一步说，用户甚至根本都不会登录到流程管理控制台，他会倾向于在业务菜单里有自己相应的流程管理功能，例如在发文管理里增加发文催办、督办等等。
3、不用
4、往业务权限表里增加流程参与者的权限信息。

总结：总是感觉工作流管理部分的权限不是那么的必要，流程定义的复杂度让最终用户很难直接使用，流程实例的管理更多的是契合到业务中去，而这种契合表现则是流程数据按业务进行划分后的管理。
DOM事件标准定义了两种事件流，这两种事件流有着显著的不同并且可能对你的应用有着相当大的影响。这两种事件流分别是捕获和冒泡。和许多Web技术一样，在它们成为标准之前，Netscape和微软各自不同地实现了它们。Netscape选择实现了捕获事件流，微软则实现了冒泡事件流。幸运的是，W3C决定组合使用这两种方法,并且大多数新浏览器都遵循这两种事件流方式。

默认情况下，事件使用冒泡事件流，不使用捕获事件流。然而，在Firefox和Safari里，你可以显式的指定使用捕获事件流，方法是在注册事件时传入useCapture参数，将这个参数设为true。下面用个例子分别来测试这两种事件流。

1、冒泡事件流
当事件在某一DOM元素被触发时，例如用户在客户名字节点上点击鼠标，事件将跟随着该节点继承自的各个父节点冒泡穿过整个的DOM节点层次，直到它遇到依附有该事件类型处理器的节点，此时，该事件是onclick事件。在冒泡过程中的任何时候都可以终止事件的冒泡，在遵从W3C标准的浏览器里可以通过调用事件对象上的stopPropagation()方法，在Internet Explorer里可以通过设置事件对象的cancelBubble属性为true。如果不停止事件的传播，事件将一直通过DOM冒泡直至到达文档根。

测试的HTML文件，其中用到了mootools-release-1.11.js，对mootools的代码进行了改动：
     
给addListener方法里增加了setCapture参数，用于测试捕获事件流。

效果：

js:


测试结果ie和ff下效果一致：单击item2,会依次触发fn2、fn1、fn;单击item1,会依次触发fn1、fn;单击Container,只会触发fn;当在任何一个事件处理器里调用e.stopPropagation();都会阻止事件的冒泡。

2、捕获事件流
事件的处理将从DOM层次的根开始，而不是从触发事件的目标元素开始，事件被从目标元素的所有祖先元素依次往下传递。在这个过程中，事件会被从文档根到事件目标元素之间各个继承派生的元素所捕获，如果事件监听器在被注册时设置了useCapture属性为true,那么它们可以被分派给这期间的任何元素以对事件做出处理；否则，事件会被接着传递给派生元素路径上的下一元素，直至目标元素。事件到达目标元素后，它会接着通过DOM节点再进行冒泡。

这里ie与ff存在着很大的差异，甚至ie6与ie7的表现也各不相同，所以分开测试。

a、ff
事件从从DOM层次的根开始往下传递时，会被useCapture属性为true的事件监听器所捕获，而到达目标元素再从目标元素冒泡时，则会被useCapture属性为false的事件监听器所捕获。当在任何一个事件处理器里调用e.stopPropagation();都会阻止事件的传播。

b、ie6
用事实说话：

第一种情况：

单击浏览器的任何位置，都只是触发fn；

第二种情况：

单击浏览器的任何位置，会依次触发fn1、fn;

第三种情况：

单击浏览器的任何位置，会依次触发fn2、fn1、fn;

结论：如果HTML元素捕获了通过该元素的setCapture()方法对这个元素的设置，依附于该元素的处理器将会被事件触发，即使setCapture()方法
被调用的这个元素不在目标元素的祖先路径中。事实上你甚至单击浏览器的非页面部分都会触发事件处理器。并且事件一旦被捕获就不会继续再
往下传播（即使该元素在目标元素的祖先路径中），而是立刻冒泡。e.stopPropagation();会阻止事件的冒泡。
 
c、ie7
测试效果与冒泡事件流一致。将对捕获事件流的支持干掉了？
 
结论：正如mootools所做的，避免捕获事件流。


工作流现在已经应用的非常广泛了，审批OA等等自然不必多说，许多业务系统里也有大量的应用。前两天的
一个项目就是使用工作流将整个项目管理的过程进行整合，包括了前期预算、项目进度管理、合同管理等等。
可供选择的工作流也很多，商业的、开源的。那么你是如何评价一个工作流产品的好坏的呢？你的标准是什么？
当然，用户也经常会问我这个问题，我的回答是：根据你实际的业务。是的，不管是什么样的工作流，都是
为了满足业务的需要，你把你的需求提出来，我们看看是否满足，不能直接满足，最合适的间接方式又是什么。你说，我要有催办。是的，我们有。你说，我要有任意回退和任意流。是的，我们有。你说，我想对流程实例进行分级管理。oh,没有也，重要吗？让我们想想其他办法。你说，你们符合BPEL标准吗？这个。。。你说，你们采用了petri网模型吗？汗。。。你说，你们是SOA架构吗？。。。
我的衡量标准是这样的：
1、流转功能
  包括了基本的工作流模式实现，串行、并发、分支、汇聚、循环等等。这个是最基本的。其实打开流程设计器拖拖拽拽很快就能知道这个产品到底实现了哪些流转模型。实际这个的实现也是引擎的核心。有多种模型可以选择。petri 模型应该是最灵活的了，也有很大的实现难度。但是流程模型做这么灵活，到底实际能用上多少……就我个人的经验来说，大部分的复杂性都是由流程的分支并发（m/n）引起的，最坏的办法是强制要求客户将这些并发的任务改成 step by step 的执行。这样牺牲一点效率，还是可以把项目做成的。
2、业务的内在支持
  比如说催办、时间服务、收回等等。我觉得这个与实际业务挂钩，反而是最为主要的考虑。因为采用间接的方式必然会产生编程，而很显然会耗费成本。
3、与业务的契合方式
  流程维护流转。业务还是自己实现。如何将这两者很好的衔接起来。同时这个过程还存在权限的限定，每个运行节点对业务的权限肯定存在差别，是否有一套完整的解决方案？当然这其中也包括了组织机构的适配，对各种组织模型的支持。
4、定义良好的API
  通常会存在工作流无法直接满足的业务场景，那么肯定需要程序直接调用工作流的API，清晰且简洁的API。
5、流程的仿真
  这种仿真比较简单，目的在于检验所定义的流程是否正确。出错要有明确的提示信息。普元的单点调试？
6、电子表单
  我始终觉得电子表单目前实际应用并不理想，它仅仅只能处理简单的业务。但是销售的经验告诉我，这是一个巨大的闪光点。用户喜欢自己动手。流程定义实际最终用户很难实际操作。我在想：简化版本的流程设计器+电子表单也许会有很好的售前效果。
7、良好的售后
8、良好的最终用户体验
9、性能
10、最好能够和标准扯上关系，可是谁知道我是否真的有关系呢？
这是一个完全基于js的应用程序，区别于一般的web应用，它是oaop。大概需要一些什么样的工作呢？

大概的概念：

1、容器
 是的，需要容器。容器的两个目的：布局和管理组件。组件之间的相互通信以及影响都需要容器来协调。管理组件之间的状态，组件需要向容器进行注册。对组件传播过来的事件，容器需要做出处理，调用相关其他组件的方法或者忽略或者继续向上一级容器传播。

2、组件
 组件的目的是完全屏蔽对dom编程的依赖，同时屏蔽底层的浏览器事件，例如鼠标单击、双击等等，对这些事件进行完全的封装。组件有着自己的生命周期：初始化、渲染、重画、销毁等等。由组件完成页面的渲染工作，例如节点、画板、连线等等。

3、模型
 在页面进行建模是必要的，例如活动节点、流程等等，这些模型与组件衔接，它们之间的状态互相影响，比如节点组件名称的改变实际影响的是所对于节点模型的属性。画板节点的增加实际也会给响应的流程定义模型新增一个活动节点。

4、与服务器交互
 与服务器的交互完全基于xml。流程定义模型有着自己的xml方法，由xml解析为模型，由模型解析为xml，双向的过程。本地存储。很自然的选择。
 
可能的难点：
最大的难点就是组件的实现，事件的处理以及传播机制。

开发的过程：

1、底层库的选择
 面向对象的开发方式，底层库需要完成的工作：继承、接口实现、事件的统一处理接口、element DOM编程的封装。

2、基本组件的开发
 画板、图形组件、连线组件、弹出面板、简单表格组件、树等等。封装基本的事件。可以定制事件。

3、容器的开发，管理组件
 组件实际也是容器的实现，比如画板的概念。画板中节点之间的互相影响。

4、加入模型的支持

5、xml与模型之间的js解析

参考：
ext是一个不错的参考，但是太笨重，功能越多越缓慢，轻量实现。主要参考其中容器以及组件的概念。
draw2d 实现太简单，基本就是一个图形库，考虑其中对图形组件的实现。

内容

序
致谢
关于作者

第1章 AJAX和富互联网应用

    转变中的Web
       传统Web应用的痛处
       AJAX止痛药
    企业中的AJAX
    采用AJAX的驱动因素
       可用性
       网络利用率
       以数据为中心
       递增的技巧、工具和技术升级
       服务器不可知论
    关于应用
       AJAX技术
       编程模式
    AJAX的替换技术
       XUL
       XAML
       Java Applets 和Web Start
       Adobe Flash，Flex和Apollo
       OpenLaszlo
    小结
    资源

第2章 AJAX组成技术(AJAX Building block)

    JavaScript
       JavaScript类型
       闭包
       面向对象的JavaScript
       Prototype属性
       面向对象编程(OOP)和继承(Inheritance)
       易变性(Mutability)
       线程(Threading)
       错误处理(Error Handling)
       命名空间(Namespacing)
    文档对象模型(Document Object Model)
       基本原理
       操作DOM
    层叠样式表
       继承和层叠(Inheritance and the Cascade)
       内联样式
       样式表
       动态样式
    事件
       事件流
       事件绑定
       跨浏览器事件
       事件对象
    客户端通信(Client-Side Messageing)
       XMLHttpRequest基础
       处理数据
    小结
    资源

第3章 Web浏览器中的AJAX

        增量的AJAX
        对服务器影响
    HTML标准
       文档类型定义(Document Type Definitions)
       盒子模型
    启动加载AJAX组件
       onload事件
       浏览器编码技巧
    模型-视图-控制器
       视图
       控制器
       模型
    AJAX MVC
       AJAX模型
       AJAX视图
       AJAX控制器
       面向方面的JavaScript
    小结
    资源

第4章 AJAX组件

    命令式组件
    声明式组件
       服务器端声明式编程
       声明式Google地图
       替代方法

    自定义声明式组件
       行为式组件
       声明式组件
       关于声明
    构建组件
       基本功能
       连接到服务器
       最终版本
    小结
    资源

第5章 从设计到部署

    设计
        为AJAX建模
        应用模型-视图-控制器模式
        优先考虑性能问题
    设计原型
       线框绘制
       验证设计决议
    测试
       测试驱动开发
       调试
    部署
       JavaScript压缩
       图片合并
       保护知识产权
       文档
    小结
    资源

第6章 AJAX架构

    多层架构：从单层到多层
    异步消息
    轮询
    服务器推送
       Comet
    跟踪请求
    缓存：处理数据
    基本缓存
    在组件中缓存
    在浏览器中缓存
    在服务器中缓存
    在数据库中缓存
       MySQL
       MS SQL Server
       Oracle
    更新服务器端模型：并发
       悲观锁定
       只读锁定
       乐观锁定
       冲突鉴定
       冲突解决
       自动化的冲突解决
    流量控制(Throttling)
       客户端
       服务端
    可伸缩性
       负载平衡和群集
       AJAX可伸缩性问题
    离线AJAX
    Firefox离线存储
    Internet Explorer userData离线存储
    使用Flash客户端存储
    离线AJAX和并发
    小结
    资源

第7章 Web服务和安全性

    Web服务
    Web服务协议
       表象状态传输
       XML远程过程调用
       Web服务
       选择合适的工具
    客户端的SOAP
       IBM Web服务JavaScript库
       Firefox
       Internet Explorer
    跨域Web服务
       服务器代理
       URL片段标识符
       Flash跨域XML
       脚本注入
    安全性
    AJAX的安全性考虑
    跨域漏洞
       跨站脚本
       跨站伪造请求
       JavaScipt劫持
   SQL注入
       预处理语句
       存储过程
       XPath注入
    数据加密和隐私
    防火墙
    小结
    资源

第8章 AJAX可用性

    常见问题
       后退按钮和书签
       页面大小
       自动提交
    可访问性
       识别用户的可访问性需求
       JavaScript和Web可访问性
       屏幕阅读器和可访问性
       兼容JAWS的AJAX交互
       键盘可访问性
    可用性测试
    迅速而又随性的测试
       招募参与者
       设计和运行测试
    软件断言测试
       用于测试可用性的工具
       对软件辅助测试的一般忠告
    小结
    资源

第9章 用户界面模式

    显示模式
       动画模式
    交互模式
       基本交互模式
    小结
    资源
       拖拽资源
       进度栏资源
       活动指示器资源
       颜色淡出资源
       即时编辑资源
       向下钻取资源
       即时搜索资源
       即时表单资源

第10章 风险和最佳实践

      
       风险来源
          技术风险
          文化和政治风险
          市场风险
       技术风险
          范围
          浏览器能力
          可维护性
          向前兼容
          第三工具支持和代码过时
       文化和政治风险
          终端用户的期待
          可培训性
          合法性
       市场风险
          搜索引擎的可访问性
          范围
          货币化
       风险评估和最佳实践
          采用特定的AJAX框架或者组件
          渐进增强和不唐突的JavaScript
          Google 网站地图
          可视化的提示
          避免镀金式设计
          采用一种收益模型
          把培训作为应用的一部分
       小结
       资源
          搜索引擎优化
          统计
          网站地图
          屏幕截取工具

第11章 案例研究

    基于Web2.0 重新武装美国国防部
       背景
       挑战
       解决方案
       采用技术
       成果
    Agrium公司整合AJAX技术到业务
       背景
       挑战
       解决方案
       采用技术
       成果
    AJAX助力国际运输和物流公司
       背景
       挑战
       解决方案
       采用技术
       成果
    小结
    资源

附录A OpenAjax Hub

    主要特性：发布/注册管理器
       范例
       未来对OpernAjax Hub支持的工具包

索引

时间真快，一晃08年都过了半个月。一直很忙，也不知道在忙些什么东西。领导催着要份年终总结，于是就有了这个东西。还是分成两个部分：工作和生活。

工作：
1、年初的时候继续业务平台的开发，主要是修改BUG和书写使用文档，公司开始增加测试的岗位，平台也开始有订单，于是BUG像雨后春笋般的茁壮成长出来。实际一直到现在，那份长长的BUG单依旧存在，改不完的BUG。现在有很深的体会：一个好的产品，并不在于采用了多么先进的技术，重要的是要成熟，要贴近业务，而这需要的是时间和大量的项目经验。所以，要是想节约成本采购一个业务平台，首先需要考虑的是这个平台存在几年了？都被哪些实际项目采用过？它面对的业务是什么，是否符合我项目大部分的需求？对于号称采用很多新技术和通用性非常强且刚开发出来的所谓平台一定要慎用，很可能你就成了实验品。

2、业务平台的价值。其实业务平台是有很大的存在价值的。这个价值就是业务。我们公司产品的口号是：释放你的技术，专注你的业务。我认为这个口号相当不妥，正确的应该是：发挥你的技术，我们替你思考业务。业务平台还有生存的意义，至于意义单一的所谓开发平台，我看还是洗洗睡吧。

3、5月份开始进入工作流的开发，一直到现在。对工作流有了很多新的认识。工作流应该算是公司最核心的产品了。代码很臃肿，没有测试，但是分层还是非常的清晰。期间开始增加测试并增加功能，对引擎部分做了部分的重构。中间也陆续做过工作流的售前和售后工作。工作流，感觉是越来越普及了。但是感觉市场却没有想象的那么好，单独的工作流引擎有没有前景？其实可以这样分析：很多行业都有他们自己针对的行业软件公司，这些公司都有自己的业务平台和流程组件，虽然不是独立对外卖的；另外就是中小型企业和客户采用开源的工作流引擎了，这样积累的使用经验可以成为公司的财富，只要把核心人员留住，就不用每个项目都去购买一个商业工作流了，节约成本；可不可以这么认为：商业工作流的市场本来就很小呢？

4、12月到新疆出了趟差，然后就是全力开发新疆的项目了。这是一个大集中的项目，也就是一套系统，所有分公司一起使用，最 紧迫的问题就是组织结构、权限以及数据（包括流程）的分级管理了。现在是业务需求基本都满足，但是可以想象未来性能的压力，工作还会有很多。

个人技术：
1、上半年看过一些敏捷和UML的书籍。敏捷感觉已经是一个被用滥的词语，人人头上都顶着一个敏捷的帽子，就像言必称 spring"hibernate一样，有些恶心了。看过这些书，其实体会最深的还是如何开发出一个大家都能读懂的代码，如何与他人交流，能让别人看懂的代码就是好代码。至于UML，好像也能画上和看懂几个了。

2、最后一个季度和朋友一起翻译了《Enterprise AJAX》这本书，重新对ajax有了兴趣，翻译确实是一件辛苦的事情，但是现在回忆起来却很是觉得有意义。最直接的就是翻译水平有了很大长进，然后就是ajax有了一些新的认识。现在看Ext的代码，想着能否有扩展为类swing框架的可能性。期间参与了满江红组织的seam翻译工作，自己做的工作很少，纯属充数，算是了解了一把seam。

3、我和老婆说，怎么今年就感觉进步没有去年那么明显呢？老婆说，因为你去年起点太低！于是释然。

生活：
1、年初买了房子了，注明一下：是在老婆强烈要求下买的。地点在燕郊。
2、关注了厦门PX、上海磁悬浮，除去工作，开始关注很多东西，也开始看历史。

08的展望：
1、结婚
2、开发一个基于js的工作流设计器，能否完成？
3、做了3年的开发工作了，工作上能否有新的挑战？
4、多看点非技术书，多出去转转，善待自己和亲人。 事件无疑是AJAX应用中最重要的部分，EXT将事件分为了两种：自定义事件与浏览器事件。

自定义事件
按字面意思就是用户自己定义的事件，这个事件通常与组件相关。并且需要用户根据组件的状态自己触发。相关的类Ext.util.Observable 、Ext.util.Event（Observable.js）。Ext.util.Observable是所有组件（component）的父类，它使得所有的组件都可以任意的添加自定义事件，它的events属性对事件进行维护，这些事件实际都是Ext.util.Event对象，Ext.util.Event对象里的listeners属性对与该事件相关的处理器进行维护。Observable给所有的子类提供了一个统一的接口来发布事件以及管理事件，这一特性对于组件来说是至关重要的。

浏览器事件
即传统意义上的鼠标单击、移动等等事件，这些事件是由浏览器根据用户的动作自己触发的，与页面元素紧密关联。相关的类Ext.Element 、Ext.EventManager、Ext.EventObject、Ext.lib.Event 。Element包含了常见的DOM方法和属性，提供一个快捷的、统一的、跨浏览器的接口，内置了常用的DOM节点的动作，并且是跨浏览器的定位的位置、大小、动画、拖放等等。对事件的处理，Element实际将这一处理委托给了EventManager，由EventManager对页面所有的浏览器事件进行管理，例如增加事件处理器、移除事件处理器等等，另外EventManager还定义了几个很重要的方法：onDocumentReady、onWindowResize、onTextResize。其中onDocumentReady尤为重要，通常在页面需要通过它来启动我们的AJAX程序，它会在页面document渲染完毕而图片等还未下载时调用我们的启动函数。至于EventObject，它则是对原始的浏览器事件进行了封装，提供给事件处理器一个统一一致的事件接口。Ext.lib.Event呢？EventManager的很多功能其实是调用它完成的，它的listeners、unloadListeners维护着所有的事件处理器。 正在翻译《Enterprise AJAX》，附录里介绍到OPENAJAX HUB，google相应的中文资料很少，所以就把译文贴出来：）

OpenAjax Hub（“Hub”）主要用来处理Web应用开发者需要在同一个应用中同时使用多个AJAX运行库的情况。它提供标准的JavaScript，当被包含在AJAX驱动的Web应用里时，它使得多个AJAX工具包能够在同一个页面里一起协同工作。

AJAX应用开发者在开发中的需求往往存在着巨大的差异，这导致了如今市场上存在超过200个各种各样的AJAX产品，同时这些产品的架构和特性也存在巨大的差异。对一些开发者来说，他们认为开发中最重要的因素是找到一个能提供与后端服务器强大集成能力的AJAX工具包。

而对其他一些开发者来说，最重要的因素则是能否应用特殊的客户端组件（例如，富数据网格组件或交互式的图表组件）。结果，AJAX生态系统发展到现在，开发者在大部分时间里都能找到满足他们每个特殊需求的AJAX工具包，但是也存在问题，他们往往必须在同一个Web应用里混合和匹配使用多个AJAX工具包才能满足所有的需求。 

Hub应用的一个重要场合是门户和内容糅合，这里，应用开发者创建一个页面，页面里松散组装预先包装好的应用组件。Hub实际上是保证这些AJAX驱动的应用组件能够使用多个不同的AJAX工具包创建。

主要特性：Hub 的发布/订阅管理器

Hub的主要特性是它的发布/订阅管理器（“pub/sub管理器”）。 pub/sub管理器允许内容糅合的一个部分能够传播其他应用组件所订阅的事件。例如，假设存在一个日历组件，该组件允许用户能够选取一个特定的日期。内容糅合里可能存在多个UI组件，这些组件都需要根据新选择的日历日期而更新它们的视觉外观。在这种情况下，日历组件将发布一个“新日历日期”的事件，而其他可视化组件将订阅这个事件。因此，pub/sub管理器的通用消息的优点是给由不同AJAX工具包所构建的组件之间提供了一个关键的集成机制。

Hub的pub/sub管理器提供各种各样的先进特性，例如对事件名称通配符的强大支持，在下面的例子里并没有展示这个特性。

范例

让我们假设现在有这样一个商务智能应用，该应用使用下面的AJAX运行库：

■ UTILS.js, 对浏览器的JavaScript环境提供非常有用的扩展，例如XMLHttpRequest的APIs。

■ CALENDAR.js,提供一个日历组件

■ CHARTS.js, 提供一个图表组件

■     DATAGRID.js,提供一个交互式的数据网格组件

该应用有一个唯一的日历组件，用户可以以图表组件的形式（例如，每日情形、每周情形、每月情形和每年情形的柱状图）和数据网格组件的形式（例如，地方数据与全国数据，两种数据都以用户选择的感兴趣的列展示）选择其中的一些数据视图当一个新的日期在日历组件里被选择时，各个用户指定的可视化组件（例如，图表和/或数据网格组件）都需要被更新。

实现该应用的一个方法是在加载其他AJAX库之前加载OpenAjax Hub的JavaScript。例如：

 

一些AJAX运行库包含OpenAjax Hub，将Hub作为它们标准发布的一部分，在这种情况下，只要特定的AJAX运行期的JavaScript（译注：这里特定的JavaScript指的就是包含OpenAjax Hub的AJAX运行库的代码）在其他兼容OpenAjax的运行库之前被加载，那么则没有必要为OpenAjax.js使用一个单独的<script>元素。

要使应用工作，开发者需要注册一个回调函数，当用户在日历组件里选择一个新的日期时调用该函数。这个回调函数接着使用OpenAjax Hub的publish()函数传播这个新日期事件：

 

接着开发者需要开发这样一些代码：所有的图表组件和数据网格组件都要订阅这个新日期事件，并要提供一个回调函数。各个回调函数将相应地更新特定的可视化组件：

未来支持OpenAjax Hub的工具包

OpenAjax联盟正与工业界一起合作，达到对OpenAjax Hub的广泛支持。一个特殊的AJAX工具包可以像下面这样支持OpenAjax Hub：

■ AJAX工具包可以包含Hub（最好的方式）。Hub可以被小于3K的JavaScript实现，所以一些AJAX工具包简单地捆绑Hub，将它作为它们工具包的一个标准组件。

■ 如果Hub在运行环境里可用则使用它。其他一些AJAX工具包可能决定在它们的发布中并不包含Hub，它们会检查Hub是否早先已经被加载了，如果已经加载，它们则直接使用Hub的服务。 

■第三方的开发者可以开发适配器。对大多数工具包来说，它们可能允许第三方的开发者编写少量的JavaScript使得自己能够支持Hub。

当AJAX工具包包含内置对Hub的支持时，应用开发者的工作将更加容易，但是通过查找或编写适配器的方式，Hub依然可以被那些并未实现支持Hub的工具包所使用。

其实本没打算看这部电影来着，其实是等着德甲来着，然而，德甲还没有开始，百无聊赖地那么一按，就看到了《火柴人》，其实如果不是尼古拉斯·凯奇我也早继续换台来着。

“一二三，开门”，习惯性随着短促咳嗽而来的眨动的左眼，洁癖的让人抓狂的种种，呵，真是个烦躁的男人。

故事开始，诈骗亦开始，中间向体育频道换过好几次频道，温吞的故事，毫无新意的诈骗过程，让人没有欲望。哪有什么所谓的大片好看，几次爆炸，追车、美女，眼球已经被牢牢抓住。情况在罗伊第一次去见他的女儿时发生变化，烦躁的罗伊不停地在车里吸着烟，颤抖的夹着烟卷的手，布满烟雾的车厢，一根接着一根的烟卷，飘忽不定找不到落脚点的眼神，看到女儿要走下定决心的追赶，立刻没有犹豫地喜欢上这个犹豫的男人。心想，这肯定是一部充满温情的电影了，一定就是了。因为女儿，他的生活即将打乱，充满生气？抑或是杂乱？不管那种，都得改变。

生活中存在着这样或那样的不安，所以我总是以最大的善意来揣度电影。剧情也在向我希望的方向发展。小女孩让父亲教她去行骗，第一次行骗成功。女孩拿着骗来的300美元开心地关上车门：我们成功了！父亲和她庆祝后却让她把钱还回去：如果不这么做，我算得上是一个父亲吗？呵，温暖。

随后一次更大的诈骗开始，父亲也决定完成这最后一次诈骗重新开始。情节发展再次让我大跌眼镜：这也太easy了吧，虽然被骗的胖男人没有像他们想象的那样在飞机中才发现钱被调了包，而是一路追赶出来，收费站找零钱一节也确实让心里小小激灵了一把，但整个过程非常顺利，顺利得让我觉得索然无味。这应该是一个多么充满惊险和刺激的过程啊，枪战、追逐、飞车、心里悬疑，可惜，没有，没有，还是没有，什么都没有。应该是这样一个激烈的过程，然后是美妙的结局：父亲和女儿美满的在一起，成功隐退，快乐的生活，然后是终场的字幕打起。应该是这样的呵！

女儿枪响的一刹那，我的心咯噔一下：完了，导演该如何结尾呢？我再也想像不到一种合乎逻辑而又符合我心理的结局。悲剧？感人的悲剧？父女情深的悲剧？无论是哪一种，我都不愿意看到。切到体育频道：斯图加特3比0领先拜仁。切回来，被捕、审讯、医生、密码、接头地点…这一切都意味着父亲在劫难逃。作为父亲，能做到就这么多了；然而，作为电影，它显然可以做到更好-一切在打开那扇门的一刹那霍然开朗，谜底像沙子那样刺入人的双眼，让人心疼，原来一切都是假的，一切都是骗局，他们欺骗了罗伊，导演欺骗了我。心里空荡荡的再无着落，像无人的秋千，空在那里荡漾，像突然的人去楼空，只剩满心的空旷。半天回味回来：哦，这是电影，并且是好莱坞的电影呢。

一年后再见，女儿离开，转身说：“I'll see you, dad”。是的，到此为止，over。

却还是温暖。我更愿相信最初故事的情节是这样的：父亲诈骗，女儿到来，最初的混乱，亲情，融合，改变，生活一起。可是，可是，如何处理这位父亲的过去，抹不去的过去，而这个过去最直接的代表莫过于他诈骗所得来的钱财了。捐掉？这不很搞吗？自首？你以为是中国电影？于是导演以一场更大的骗局将这些钱将父亲的过去轻松的抹去了。原来是这样。原来是这样呵！女儿还是女儿，父亲还是父亲。“I'll see you, dad”。是的，没有复仇，没有怨恨。

好久没有看过如此温暖的电影了。再补充一下：很喜欢罗伊的眼睛，非常喜欢，焦虑、关爱、犹豫、彷徨、绝望、温情。

Solr 是一个可供企业使用的、基于 Lucene 的开箱即用的搜索服务器。对Lucene不熟？那么建议先看看下面两篇文档：

实战Lucene，第 1 部分: 初识 Lucene：http://www.ibm.com/developerworks/cn/java/j-lo-lucene1/

用Lucene加速Web搜索应用程序的开发：http://www.ibm.com/developerworks/cn/web/wa-lucene2/

一、 solr介绍

solr是基于Lucene Java搜索库的企业级全文搜索引擎，目前是apache的一个项目。它的官方网址在http://lucene.apache.org/solr/ 。solr需要运行在一个servlet 容器里，例如tomcat5.5。solr在lucene的上层提供了一个基于HTTP/XML的Web Services，我们的应用需要通过这个服务与solr进行交互。

二、 solr安装和配置

关于solr的安装和配置，这里也有两篇非常好的文档，作者同时也是 Lucene Java 项目的提交人和发言人：

使用Apache Solr实现更加灵巧的搜索：http://www.ibm.com/developerworks/cn/java/j-solr1/index.html

http://www.ibm.com/developerworks/cn/java/j-solr2/index.html

下面主要说说需要注意的地方。

Solr的安装非常简单，下载solr的zip包后解压缩将dist目录下的war文件改名为solr.war直接复制到tomcat5.5的webapps目录即可。注意一定要设置solr的主位置。有三种方法。我采用的是在tomcat里配置java:comp/env/solr/home的一个JNDI指向solr的主目录（example目录下），建立/tomcat55/conf/Catalina/localhost/solr.xml文件。

     观察这个指定的solr主位置，里面存在两个文件夹：conf和data。其中conf里存放了对solr而言最为重要的两个配置文件schema.xml和solrconfig.xml。data则用于存放索引文件。

     schema.xml主要包括types、fields和其他的一些缺省设置。

solrconfig.xml用来配置Solr的一些系统属性，例如与索引和查询处理有关的一些常见的配置选项，以及缓存、扩展等等。

上面的文档对这两个文件有比较详细的说明，非常容易上手。注意到schema.xml里有一个

的配置，这里将url字段作为索引文档的唯一标识符，非常重要。

三、 加入中文分词

对全文检索而言，中文分词非常的重要，这里采用了qieqie庖丁分词（非常不错：））。集成非常的容易，我下载的是2.0.4-alpha2版本，其中它支持最多切分和按最大切分。创建自己的一个中文TokenizerFactory继承自solr的BaseTokenizerFactory。

在schema.xml的字段text配置里加入该分词器。

    完成后重启tomcat，即可在http://localhost:8080/solr/admin/analysis.jsp

体验到庖丁的中文分词。注意要将paoding-analysis.jar复制到solr的lib下，注意修改jar包里字典的home。

四、 与自己应用进行集成

Solr安装完毕，现在可以将自己的应用与solr集成。其实过程非常的简单，应用增加数据-->根据配置的字段构建add的xml文档-->post至solr/update。

应用删除数据à根据配置的索引文档唯一标识符构建delete的xml文档-->post至solr/update。

检索数据à构建查询xml—>get至/solr/select/-->对solr返回的xml进行处理-->页面展现。

具体的xml格式可以在solr网站找到。另外就是solr支持高亮显示，非常方便。

关于中文，solr内核支持UTF-8编码，所以在tomcat里的server.xml需要进行配置

另外，向solr Post请求的时候需要转为utf-8编码。对solr 返回的查询结果也需要进行一次utf-8的转码。检索数据时对查询的关键字也需要转码，然后用“+”连接。

也许是流程做多了的缘故，所以看起程序开发来一切都是流程或者说都包含流程。个人认为大多数的企业应用（不包括特殊应用，例如文档库、信息资源库、BBS等等）不过是对数据以一定的样式展现（表单），以一定的逻辑对数据进行操作（业务规则），以及把这些处理数据的过程以一定的流程进行管理（流程）。上面三个方面分别对应着表单、业务规则和流程。程序开发中则对应于表单引擎、规则引擎和工作流引擎。而这些方面又可以统一到一个更大范畴的流程上来，所以这里有对流程驱动开发的设想。

先来看看具体的应用场景。

单表增删改查

这是最简单的情形，也没有流程，对这个情形不加讨论。但是这里会提到表单引擎，VB里的数据控件非常的易用，没有PO，没有DAO，也没有Service，直接与数据库字段进行绑定。我们的表单引擎也可以采用这种方式。

支持表单控件（输入框、文本框、下拉框等）的拖拽，将整个表单与数据库表绑定。

表单控件与数据库字段的绑定。

单表业务+流程

比上面的情况稍微复杂一点点，也就是要在业务里引入流程，其实这也是现在工作流引擎应用最多的地方，比如说政府OA里的收文、发文。

这里只需要将表单与流程进行绑定，表单引擎的处理方式不变，依然是直接与数据库表进行绑定。表单负责对数据库里的业务数据进行展现，工作流则负责推动这些数据在业务意义上状态的转换，互不影响，并在需要的时候在自动节点上对这些数据进行相应的业务处理。

关于表单权限。这个也是表单与工作流进行绑定时所必须考虑到的问题。其实只是需要在表单引擎里引入权限角色的概念，每个角色对应于一种权限，这种权限具体说来就是表单里每个字段的可见、可编辑等等。然后在人工节点定义时指定表单权限角色即可。这样也实现了流程与表单权限一定程度上的解耦。

其实还有一种更方便的方式，将表单直接与人工节点进行绑定，每个人工节点对应于不同的表单。

复杂一点，多表关联的情况

复杂一点的情况是业务往往是多表的关联。这需要对表单引擎做出扩展，让它可以根据关联字段对关联表做出查询，得到关联表的设计结构，继续映射。这让我想起了ORM，这里很有FRM的意思在里面。其实对于常用的关联查询往往有通用的组件可用，例如根据userid渲染出用户名，根据数据字典的id关联渲染出相应的值，oa里的正文、附件、印章等等。

流程跨越多个业务

流程需要跨越多个业务，一个典型的流程如下：

会议审批会涉及到两张业务表：会议室使用表，会议记录表。在会议申请和领导审批节点，最终用户打开的都是会议申请的表单，对应于会议记录表，对该表进行操作。但是流程运行到会议室管理员安排会议室的节点，该节点最终用户不仅需要看到会议申请的表单同时还要看到会议室使用情况的表单，如果有空闲的会议室，用户登记操作会议室使用表，然后通知申请者；如果没有空闲的会议室，则不用登记直接通知申请者。这个过程中跨越了两个业务，分别是会议室管理和会议管理。表单在各个节点也是不同的。

这其实对工作流引擎提出了比较高的要求。例如如果流程已经结束，会议得到批准，但申请者突然有事要改变会议时间怎么办？回退。这里的回退无疑就需要有业务的补偿，例如要删除会议室的相关记录。

应用集成

一个流程不仅会跨越多个业务，也会跨越多个系统。这里的应用场景很多，重要的是要去其他系统抓取数据和操作数据，仅仅靠数据库表对表单的映射满足不了需求。

对工作流引擎做出改进，与前面相比，需要由引擎来完成对其他系统服务的调用。这里一个很重要的载体就是XML。首先要定义交换数据所用的XML scheme，然后将这个XML scheme再与表单引擎做出映射。实际执行时，工作流的自动节点会在人工节点前调用其他系统的服务，按照XML scheme将数据转换为符合定义的XML，在紧接着的人工节点送给表单引擎，表单引擎渲染。修改数据也是同样的过程，表单引擎将处理后的数据以XML返回，工作流再次做出转换，调用服务的修改功能。

上面五种都是比较常见的应用场景，理想的情况下，开发方式应该是这样的：画出应用流程à定义流程表单à表单与数据库进行映射à对流程进行业务仿真à完成开发。问题是这样的：你的表单引擎是否足够强大？表单与后台是直接用SQL进行交互的，也就是Transaction Script模式，没有业务对象，对于复杂业务逻辑如何处理？如何使用规则引擎来解决业务逻辑的问题？权限如何以一种AOP的方式对数据操作进行横切？

呵呵，纯属个人YY。

 

原文地址：http://www.blogjava.net/RongHao/archive/2007/10/30/157009.html

对于当前的工作流应用来说，人工节点无疑扮演着一个非常重要的角色。因为无论是传统的协同办公系统还是越来越多的企业应用，都需要有人参与到具体的流程中来。这篇文章着重分析工作流应用中人工节点所涉及到的参与者模式以及与此关联的工作项模式，最后会提供部分的解决方案作为参考。

先简单说说什么是人工节点。

人工节点的概念是与自动节点相对的。顾名思义，人工节点就是需要有人参与的节点，在实际流程中，它体现在产生由人完成的工作项以及由人决定一些决策变量，这些决策变量会对流程的运行产生影响（例如分支的选择等等）。自动节点则是由工作流引擎自己调用完成，不需要人的参与，通常是执行定制的业务操作。相比较而言，人工节点更多的应用在管理流程里，而自动节点更多的则是应用在企业业务流程里。

人工节点的职责有三个：第一是决定该节点的参与者；第二是根据参与者生成需要人来处理的工作项；最后是当工作项被参与者处理完毕时，它将继续触发流程的流转。参与者处理工作项时可以处理相应的业务和设置流程决策变量。

下面我们就按照这三个职责分别对人工节点所涉及到的参与者模式和工作项模式进行分析。

1、  决定参与者模式

换句话说就是决定该节点的参与者，这里有两种模式：引擎自动获取和最终用户指定。
 

1．1引擎自动获取

所谓引擎自动获取就是由引擎在运行期计算实际的节点参与者，不需要最终用户的参与。这个计算基于流程定义时对该节点参与者的定义。

（1）    直接指定人员、部门或角色

这种情况最简单，也最直接，用户定义节点时直接在组织用户树里选定人员、部门或角色，然后在运行期根据定义执行与或者是或的运算。大多数的工作流引擎都支持这种模式。但很明显它也存在着很大的局限性，它是静态的，一旦流程定义完毕参与者也就跟着固定下来，运行期的任何变化都不会对参与者造成影响，一个很简单的需求，请假流程，节点的参与者需要是当前申请者的部门领导，因为申请者在定义期是不确定的，所以根本无法指定节点的参与者，所以这种模式远远满足不了用户稍微复杂一点的需求。

（2）    调用用户定制的计算参与者代码

这种情况通常是由引擎提供一个接口或是父类，用户需要实现或是继承这个接口或父类，然后实现相应的方法。这个方法通常会传递进一个执行上下文的参数，用户代码通过这个上下文可以访问到当前流程实例的信息，例如当前节点状态，工作流变量等等，然后用户可以根据实际业务和当前流程实例信息进行逻辑计算，最后返回一个参与者的ID集合。对于上一个模式里提到的计算当前申请者部门领导的例子，这个模式实现起来非常简单，首先获得当前申请者ID，然后在根据这个ID找出该申请者部门再找出该部门领导即可。

实际流程运行到该节点就会调用用户自己定制的计算参与者的代码，方法返回的参与者ID即作为该节点的实际参与者。

这种模式对于工作流引擎的实现而言最为简单，因为它把最大的复杂性都抛给了用户，由用户代码来计算实际的参与者。实际上很多开源的工作流引擎采用的都是这种方式，例如JBPM。但是这种方式给用户带来最大灵活性的同时也带来了复杂和烦琐。特别是当面对一个数量巨大的流程需求时，为每一个流程的每一个人工节点都定义一个参与者计算类是让人头疼的。再加上现在强调业务的敏捷，业务里的改变要迅速反馈到流程的定义里，让最终用户来编写或修改这个参与者计算类不现实也不可能。补充一下，这也是用户在考虑采用开源的工作流引擎还是商业工作流引擎时需要着重考虑的一个方面。

（3）    指定前续节点的参与者

实际上是用户在节点定义时指定参与者为前续某个节点的参与者，当流程运行到该节点，引擎会自动获取所指定的前续节点的参与者作为该节点的实际参与者。

这个模式实现起来并不困难，大多数商业工作流引擎都对该模式进行了支持。它能够满足用户的部分特定需求。

（4）    更为复杂的情况

用户的需求永远是复杂的，引擎所要做得就是尽量降低这种复杂性，流程的变化要能够迅速跟上业务的变化。考虑下面两种稍微复杂一点但是又很常见的需求。需求一：参与者为当前申请者的部门领导且职位为副总；需求二：参与者需要是测试部的所有女同事。这两种需求模式1、3都不能满足，2可以，但是正如提到的那样，模式2可能会非常的烦琐，不能适应业务的敏捷。其实这里的复杂性主要体现在：1、这里的参与者可能是运行期决定的；2、参与者的限制条件可能非常多，而这些条件不是简单的部门、角色或职位所能描述的。

对于一般的工作流引擎而言，它们都会选择模式2的实现，让用户自己实现逻辑。实际在后面的部分解决方案里，我们会看到更为好一点的实现方式。

 

1.2最终用户指定

   运行期由最终用户来决定节点的参与者。这也是中国国情所独有的特色。这种模式最为常见的就是用户提交工作项时的提交页面，用户在该页面上选定下一节点（多数分支用户选定时）和下一节点的参与者。这种模式本身并不困难，问题在于在提交页面需要给用户提供一个参与者的选择范围，让用户进行选择。而关于这个选择范围，则又回到前面所提到的引擎自动获取的模式，这个范围同样是需要引擎计算的。于是又回到了刚刚讨论过的四种模式。

 

2、参与者执行模式

   现在，已经获得了节点的参与者。引擎下一步将会根据这个参与者生成工作项，注意，这里的参与者可能是一个人，也可能会是一个人员范围（即多个人）。于是就产生了参与者的执行模式，也可以理解为工作项的生成模式。

2.1竞争参与

当有多个参与者参与这个节点时就会产生竞争参与这个模式。同样一个工作，A可以完成，B也可以完成，于是就产生竞争，谁先开始这项工作，就由谁负责完成该工作。

2.2顺序参与

   多个参与者按照指定的顺序完成该工作项。A完成之后由B完成，B完成之后再交给C完成。

2.3同时参与

   多个参与者同时对工作进行处理，所有参与者均完成后，流程继续向后流转。这个模式其实比较复杂，因为这里同时涉及到一个完成规则：是所有参与者均完成工作项后流程流转，还是有其他规则？例如完成2个工作项即可流转，完成80%的工作项即可流转。稍候会讨论到。

2.4负载均衡

   这也是一个常见的需求。这项工作A和B都可以完成，但是A目前有10个待办工作项，B只有2个待办工作项。于是用户期望该工作交由B来完成。这里需要实现一个简单的负载均衡。其实这种情况只是智能决策的一种最简单的情况，所谓智能决策是指系统能够根据一定的指标（由数据分析，例如人员的处理效率，工作负载等等）和规则来决定该节点的参与者。

3、工作项完成模式

这个模式在参与者执行模式为同时参与时有效。在说到这个模式之前，先简单说说工作项可能存在的几种特殊状态，这些状态包括挂起、人工终止和委派。挂起就是工作项暂时停止执行，挂起会影响到流程的流转，会导致流程的挂起。人工终止则是人工手动改变该工作项的状态，使该工作项终止执行，这个人通常会是管理员。人工终止也会对流程流转产生影响，当除去该工作项之外的所有工作项都完成时，人工终止该工作项会触发流程的流转。委派就是将该工作项委派给他人完成，同时该工作项也就结束了。人工终止和委派是工作项结束的特殊状态。
 

3.1全部完成

当所有工作项都结束时触发节点的结束和流程的流转。

3.2完成规定的个数

节点定义时指定工作项必须完成的个数，当完成的工作项达到这个指定的个数时触发节点的结束和流程的流转。 

3.3完成规定的百分比

节点定义时指定工作项必须完成的百分比，当完成的工作项占所有工作项的比例达到这个指定的百分比时触发节点的结束和流程的流转。
 

其实这里很明显的可以看出不管是所谓的参与者执行模式还是工作项完成模式不过都是一定的规则，既然是一定的规则那必然就限定了应用的灵活性，用户能否自定义规则？根据业务灵活地修改规则？规则引擎+DSL应该是一个不错的选择。

周末参加了清华大学信息系统与工程研究所组织的一次工作流研讨会。
会上清华大学的研究人员介绍了他们对工作流研究的一些成果。其中主要关注了数据挖掘和分析。
关于数据挖掘，有两个方面。第一个方面是当企业没有应用工作流时，对企业日常数据进行挖掘，分析数据
之间的关联和逻辑，得出一套基本的企业应用业务流程，为将来应用工作流做出准备；第二个方面是当企业
已有工作流应用时，对相关流程数据进行挖掘，根据数据描绘出正在运行的流程，很显然，这个方面与流程
仿真有关。
关于数据分析，则主要是对流程数据进行分析，这个涉及的内容就比较多，包括流程的运行效率，人员效率
分析，统计等等。其中有一个非常有趣的例子：贪官A试图逃跑，逃跑前是有一定前兆的，比如向国外转移
账款，给小蜜频繁打电话，工作效率降低等等。于是数据分析就可以起作用，对A最近的所有数据进行分析，
得出他将要逃跑的结论。而来自有生博大的赵斌，谈论到他们已经实施的项目中，涉及到对一些电子公文
流程中的办文统计，并依据“指标”进行工作量和效率的分析。
这其实也反映出我们工作流软件中缺失的部分：数据分析-数据统计-优化流程。而这也正是BPM的重要功能之一。也是未来发展的趋势。功能缺失最重要的原因在于实际上我们的软件没有研发只有开发。具体他们略微谈到了他们一些实现的方式，非常的理论，涉及到算法，数据结构等等。我们软件开发最主要的是满足用户的各种业务需求，比如说回退、收回、会签等等，这也是现实情况所决定的，开发团队的人员通常都不是很多，并且这种分析挖掘需要的人员无疑需要很高的理论水准，这个本科往往是达不到的(不得不承认研究生和博士就是比本科要优秀)，博士硕士的研发团队的开发成本会非常的高，并且实际产生的利润很难评价，对于不大的公司来讲这个是很难接受的。于是就造成了这种状况：软件研发缺失掉了。
依托高校是个不错的想法，但是依托高校不等于说你把办公地点搬到清华大学门口就是依托高校了，也有这种依托，那是买煎饼的。
问题背景：我们是一家工作流公司，客户采购我们的产品后，将其嵌入其项目中。我们的工作流采用的是   spring+hibernate的方式，客户项目则是jdbc直接进行数据库操作。
问题：客户在其数据库操作过程中需要调用我们的工作流接口，这样就需要将我们的工作流操作与他们的业  务操作置于同一个事务中。我们的服务采用的都是spring的声明式事务，而客户采用的是对         connection进行事务处理。如何保证事务的一致性？
想到的解决方案一：使用jta事务，用tomcat+jotm提供事务管理器。为什么一开始就想到要使用jta事务？？实际上我们和客户都是使用的同一个数据库，为了方便，各自使用了不同的数据库连接方式，使用jta的话确实有bt的意思在里面。但是事实上是我们的第一反应都是jta。最后没有采用该方法的原因也很简单：我没有将jotm配置成功！汗一个。
想到的解决方案二：将客户的这些特定代码用spring管理起来。因为要修改客户部分代码，这个方案遭到了客户的强烈反对。于是放弃。
想到的解决方案三：客户数据库操作与我们的服务使用同一个数据库连接。然后编程处理事务。存在两种方式：一种是把客户的连接传给我们，另一种则是把我们的连接传给客户。第一种方式对我们的影响太大，所以最后决定采用后一种方式：从hibernate session中获取connection然后传递给客户。接下来查看一下HibernateTemplate的execute()方法，思路就很简单了：获取定义的sessionFactory-->创建一个新的session并打开-->将session与当前线程绑定-->给客户代码返回connection-->打开事务-->客户使用我们传递的connection进行数据库操作-->我们不带声明事务的服务操作-->提交事务-->解除绑定。
实际要注意的地方是：1、将session与当前线程绑定使用的TransactionSynchronizationManager.bindResource()方法，这样在HibernateTemplate里才能找到session；
                    2、我们的服务一定要把声明式事务彻底干掉，否则会有commit;
                    3、我们服务调用完毕后一定要flush session，否则客户代码不会感知数据库里的数据变化。
最终解决：使用了spring里常用的模板和回调。代码如下：

调用伪代码：


基于职责设计对象
最关键的软件开发工具是受过良好设计原则训练的思维，而不是UML或其他任何技术。

RDD是思考OO软件设计的一般性隐喻。把软件对象想象成具有某种职责的人，他要与其他人协作以完成工作。RDD使我们把OO设计看作是有职责对象进行协作的共同体。

分配职责的基本模式是GRASP。

创建者模式
  问题：谁创建类A的实例？
  建议：如果以下条件为真时（越多越好），将创建类A实例的职责分配给类B：
        1、B“包含”或组成聚集了A。
        2、B记录A。
        3、B紧密的使用A。
        4、B具有A的初始化数据。
        首选聚集或包含A的类B。
  注意：A和B指的都是软件对象而不是领域模型对象。
  禁忌：对象的创建常常具有相当的复杂性。在一些情况下，更适合使用工厂。

信息专家模式
  问题：给对象分配职责的基本原则是什么？
  建议：把职责分配给具有完成该职责所需信息的那个类。把职责和数据置于一处，把服务与其属性置于一处。
  禁忌：相比较而言系统关注更为重要，设计要分离主要的系统关注。例如：领域对象加入持久化逻辑成为充血模型，这就把应用逻辑与数据库逻辑混合起来了（不良设计）。

低耦合模式
  问题：如何减少因变化产生的影响？（高耦合并不是问题所在，问题是与某些方面不稳定的元素之间的高耦合）
  建议：分配职责以使（不必要的）耦合保持在较低的水平。（信息专家模式支持低耦合）

控制器模式
  问题：在UI层之上首先接受和协调系统操作的对象是什么？
  建议：把职责分配给能代表下列选择之一的对象：
        1、代表全部“系统”、“根对象”、运行软件的设备或主要的子系统（外观控制器的变体）。
        2、代表发送系统操作的用例场景（用例或会话控制器）。

高内聚模式
  问题：怎样使对象保持有内聚、可理解和可管理，同时具有支持低耦合的附加作用？
  建议：职责分配应保持高内聚。委派职责。内聚性低的类通常表示大粒度的抽象，或承担了本该委托给其他对象的职责。

多态模式
  问题：如何处理基于类型的选择？如何创建可插拔的软件构件？
  建议：当相关选择或行为随类型（类）有所不同时，使用多态为变化的行为类型分配职责。不要测试对象的类型，也不要使用条件逻辑来执行基于类型的不同选择。
  经验：如果有一个具有抽象超类C1的类层次结构，可以考虑对应于C1中的公共方法特征标记来定义接口I1，然后声明C1来实现接口I1。

纯虚构模式
  问题：当并不想违背高内聚和低耦合或其他目标，但基于专家模式的方案又不合适时，哪些对象应承担这一职责？
  建议：人为制造类，由该类来承担一组高内聚的职责。该类并不代表问题领域的概念-是虚构的事物。例如DAO
  纯虚构通常基于相关的功能性进行划分，因此这是一种以功能为中心的对象。

间接性模式
  问题：为了避免两个或多个事物之间的直接耦合，应该如何分配职责？
  建议：将职责分配给中介对象。例如，Adapter
  间接性的动机通常是为了低耦合，并且大多数间接性中介都是纯虚构的。

防止变异模式
  问题：如何设计对象、子系统和系统，使其内部的变化或不稳定性不会对其他元素产生不良影响？
  建议：创建稳定的接口。
  不要和陌生人讲话：约束了应该在方法里给哪些对象发送消息。它要求在方法里，只应给以下对象发送消息：
  1、this对象（自身）
  2、方法的参数
  3、this的属性
  4、作为this属性的集合中的元素
  5、在方法中创建的对象
  典型违反该原则的例子： F f=foo.getA().getB().getC().getD().getE().getF();

命令-查询分离原则：
  执行动作（更新、调整，等等）的命令方法，这种方法通常具有改变对象状态等副作用，并且是void的（没有返回值）。
  向调用者返回数据的查询，这种方法没有副作用，不会永久性地改变任何对象的状态。
关键在于：一个方法不应该同时属于以上两种类型。
 
在绘制交互图时考虑和决定职责分配。然后在类图的方法分栏里概括职责分配结果，方法是职责的具体实现。
在迭代开发中，我们并非一次就实现所有需求。

在多个迭代里对同一用例进行增量式开发。

细化阶段：构建核心架构，解决高风险元素，定义大部分需求，以及预计总体进度和资源。（包括了三到四次的细化迭代）
关键思想和最佳实践：
 实行短时间定量、风险驱动的迭代
 及早开始编程
 对架构的核心和风险部分进行适应性设计、实现和测试
 尽早、频繁、实际的测试
 基于来自测试、用户、开发者的反馈进行调整
 通过一系列讨论会，详细编写大部分用例和其他需求，每个细化迭代进行一次
制品：领域模型、设计模型、软件架构文档、数据模型、用例、用户界面原型。

领域模型
领域模型是对领域内的概念类或现实世界中对象的可视化表示。
应用UML表示法，领域模型被描述为一组没有定义操作的类图，反映属性和关联。（一定注意，它不是软件对象！是概念对象！）
准则：
  使用领域术语
  认真汲取领域专家所使用的核心词汇和概念
  如果某概念类不是现实世界中的数字或文本，那么她可能是概念类而不是属性
  需要描述类：1、需要有关商品或服务的描述，独立于任何商品或服务的现有实例；2、减少冗余或重复信                 息
  避免加入大量关联，添加关联是为了突出对重要关系的大致理解，而非记录对象或数据的结构
  通过关联而不是属性来表示概念类之间的关系，领域模型中属性的类型应该是数据类型（基本类型）
  对数量和单位建模
每次迭代的领域建模不超过几个小时。

系统顺序图
系统顺序图（SSD）是为阐述与所讨论系统相关的输入和输出事件而快速、简单地创建的制品。是操作契约和对象设计的输入。
SSD展示了直接与系统交互的外部参与者、系统（作为黑盒）以及由参与者发起的系统事件。这些事件是通过用例文本总结出来的。
应为每一个用例的主成功场景，以及频繁发生的或者复杂的替代场景绘制SSD。
基本上软件系统要对三种事件进行响应：来自于参与者的外部事件，时间事件，错误和异常（通常源于外部）。
系统事件应该在意图的抽象级别而非物理的输入设备级别来表达。

操作契约
操作契约使用前置和后置条件的形式，描述领域模型里对象的详细变化。其中的关键元素是后置条件。
为系统操作定义操作契约。系统操作在绘制SSD草图时确定。
后置条件描述了领域模型内对象状态的变化。可分为三种类型：创建或删除实例，属性值的变化，形成和消除关联。注意，它描述的是所需的变化，而不是这些变化是如何完成的。以说明性的、被动式的过去时态编写后置条件。（例如，创建了xx，而不是创建xx）

逻辑架构和UML包图
逻辑架构是软件类的宏观组织结构，它将软件类组织为包（或命名空间）、子系统和层等。
UML包图常用于描述系统的逻辑架构--层、子系统、包等。
将系统的大型逻辑结构组织为独立的、职责相关的离散层，具有清晰、内聚的关注分离。
协作和耦合是从较高层到较低层进行的，要避免从较低层到较高层的耦合。较低层包含可复用功能。
可以将应用逻辑层更准确地称为架构的领域层，即包含领域对象（注意领域模型与领域对象是不同的两个概念），处理应用逻辑的层。
领域层是软件的一部分，领域模型是概念角度分析的一部分。
从UI层发送到领域层的消息将是SSD中所描述的消息。

轻量级绘图然后编码。
在OO开发中，至关重要的能力是熟练地为软件对象分配职责。

在面向对象分析中（OOA），强调的是在问题领域内发现和描述对象。OOA关注从对象的角度创建领域描述，OOA的结果可以表示为领域模型。需要注意的是，领域模型并不是对软件对象的描述（区别于软件中的对象类），它是真实世界领域中的概念和想象可视化。

在面向对象设计（OOD）中，强调的是定义软件对象及它们如何协作以实现需求。（类图与顺序图）

迭代开发是OOA/D成为最佳实践的核心。建议迭代的时间在2-6周之间，小步骤、快速反馈和调整。迭代的一个关键思想是时间定量，或时长固定。
1、在第一次迭代之前，召开第一个时间定量的需求工作会议（两天）。业务和开发人员需要出席。
   a、高阶需求分析。仅仅确定用例和特性的名称，以及关键的非功能性需求（性能，可伸缩性等等）。
   b、通过架构师和业务人员，从高阶列表选择10%列表项（例如，30个用例名中的10%，3个）。这3个用例      需要具备：具有重要的架构意义；具有高业务价值；具有高风险（例如，可处理500个并发交易）。标      识这3个用例：UC2，UC11和UC14。
   c、剩下的一天半对这3个用例的功能和非功能性需求进行详细的分析。
2、在第一次迭代之前，召开迭代计划会议，选择UC2，UC11和UC14的子集，在特定的时间内（例如，四周）    进行设计、构造和测试。要注意，并不是在第一次迭代中就要构造全部的3个用例，可以将其分解为一系   列更为详细的迭代任务。
3、在三到四周内完成第一次迭代（严格遵守时间）
   a、在开始的两天内，开发者在架构师指导下分组进行建模和设计工作。白板，UML草图，界面、讨论。
   b、编程。注意UML草图只是参考
   c、测试
   d、结束前一周，检查是否能够完成初始迭代目标，如果不能，缩小迭代范围。
   e、最后一周的周二，冻结代码，集成和测试所有代码，建立迭代的基线。
   f、周三上午，演示此局部系统，展示早期可视进展，要求反馈。
4、在第一次迭代即将结束时（最后一周的周三周四），召开第二次需求会议，对上次会议的所有资料进行复   查和精化。然后选择具有重要架构意义和高业务价值的另外10%到15%的用例，一到两天详细分析。这项工   作完成后，大约20-25%的用例得到了详细记录。
5、周五上午，举行下一迭代的迭代计划会议。
6、相同步骤2次迭代。
7、反复四次迭代和五次需求会议，这样在第四次迭代结束后，可能已经详细记录了80-90%的需求，但系统只   实现了10%。
8、大概推进了整个项目过程的20%。up里，属于细化阶段。此时，可以估计整个项目的工作量和时间。
9、一般不再需要需求会议，需求已经稳定了。接下来是一系列为期三周的迭代，在最后一个周五召开的迭代   计划会上选择适宜的下一步工作。
  
早期的迭代要致力于核心架构的构造，应该首先处理困难的和具有风险的事物。

建模（构建UML草图）的主要目的是为了理解，而非文档。只需对设计中不常见、困难和棘手的一小部分问题建模和应用UML。不要单独建模，而是结对（或三个人）在白板上建模。并行的创建模型（例如，类图和顺序图交替开始）。UML细节是否精准不重要，重要的是人员能够互相理解。坚持用最简单、常用的UML元素。开发者应该为自己进行OO设计建模，而不是创建模型图后交给其他人实现。

UP的核心思想是：短时间定量迭代、进化和可适应性开发。

初始阶段是建立项目共同设想和基本范围的比较简短的起始步骤。包括确定大部分用例名称，对10%的用例进行分析，关键的非功能需求的分析，业务案例创建和开发环境的准备。包含第一次需求研讨会，并为第一次迭代制定计划。要解决的主要问题：涉众是否就项目设想基本达成一致，项目是否值得继续进行认真研究。

用例是文本形式的情节描述，特别注意，用例是文本不是图形！用例建模主要是编写文本的活动，而非制图。用例名称应使用动词开头。
参与者的三种类型：主要参与者，协助参与者，幕后参与者。
用例的三种常用形式：摘要，非正式，详述（在第一次需求会中，详细的编写其中少量（例如10%）的具有重要架构意义和高价值的用例）。用例应该包含所有涉众关注点的事物。
准则：
以无用户界面的本质风格编写用例；排除用户界面而关注参与者的意图。
编写简洁的用例。
编写黑盒用例，不对系统内部工作、构件或设计进行描述。而是通过职责来描述系统。
采用参与者和参与者目标的视点。
这些天主要在做一些翻译的事情。周日的时候抽了半天时间给一本书做了一章的试译。似乎并不是太意外，编辑今天告诉我试译没有通过，与他们的要求还有一定的差距。然后他把他批注过的试译发给了我。看得出编辑是一个非常负责任的人，几乎所有的句子都被他详细的review过。总结了一下原因：
1.没有经验。这是我第一次翻译书，犯了很多常识性错误。例如少用被字句，章号用阿拉伯数字，图题和图中需  要翻译的英文应该对应，我、你、你的这些代词，能不翻译尽量不要翻译等等。
2.对专业知识不熟悉。这本书是关于swing,java2d\3d的，而自己在这方面没有什么经验，只是使用过Swing，这  样就使一些专业术语翻译很不到位。对英文的理解会存在问题。
3.自己翻译的理解问题。一些句子不通顺，不好理解，措辞的不当。其实这个问题我认为主要是匆忙不负责任引  起的。
尽管被cut了，但我认为自己还是学到了很多东西的：一些常用的翻译技巧和注意事项，对相关知识不熟悉时不要随便翻译，遇到难度的句子要做批注，翻译完毕后一定要review等等。感谢华章图书的编辑，他让我懂得许多。也让我长长出了口气：不用再去网上找java2d/3d方面的文档和书籍，不用狂补相关的知识。另外要感谢的是阿敏总司令，是他介绍给我这个机会，但是我没有把握住。
翻译，并不是一件简单的事情。
UML有三种使用方式：用作草图绘制，用于蓝图绘制，用于程序编制。
倾向于将UML用于草图绘制，绘制草图的实质是选择，重点是进行交流，常用的介质是白板。
草图是故意不完备的，要突出重要的信息。草图是探究性的，蓝图是定义性的。草图用于正向工程（设计阶段），蓝图用于逆向工程（根据已有的代码导出）。详细文档应该根据代码生成。

UML最重要的是类图和顺序图。

瀑布风格和迭代风格
瀑布风格是基于活动来分解项目的，迭代风格根据功能子集来分解项目。
迭代的一种常用技术是时间框定法，迫使各次迭代的时间长度固定。通过定时搁置功能，使人们能够在搁置日期和搁置功能之间进行明智的选择。

敏捷过程是强适应性的过程。敏捷方法强调项目成功最重要的因素是人的素质以及人之间的良好协同，敏捷方法倾向使用时间框定的短小迭代。每一次迭代结束时要进行一次迭代回顾。

RUP本质上是一个迭代过程，分为四个阶段：初始，细化，构造，移交。
需求分析最重要的是与用户及客户的交流。

类图
类图表述系统中各个对象的类型以及其间存在的各种静态关系。
对不重要的事（如日期或布尔值，一般说，值类型）使用属性，对较为重要的类使用关联。
非常反感那些除了一组域及其get/set方法没有行为的类。如果你在利用get方法重复调用数据，这预示着某一行为应该移往具有数据的对象。
依赖应该单向，依赖越少越好，特别谨慎循环依赖，尤其反对包间的循环依赖。对类使用依赖最常见的情形是阐明瞬间关系，比如，把一个对象作为参数传递到另一个对象时。
不要试图使用对你可用的所有图示法，保持图示简单，集中考虑关键方面。绘制类图时总以使用某种形式的行为技术为宜。

顺序图
尽量省去回送。
单一职责，提倡分布式控制（把处理分散到多个对象里去）。
减少过程式编程，如if/else，改用多态解决类似问题。
把顺序图看作各个对象如何交互的形象化表示而不是一种对控制基理的建模方法。顺序图擅长示明对象间的协作，不擅长于示明行为的精确定义。

CRC卡
CRC的一个重要部分是认识职责。任意一个类都可以用少量职责对其概括。对具有三项以上职责的卡片提出质问，是否应该把类分解，或把职责合并成一个更高层次
的概述。
工作流开发已经有一段时间了，这里把自己的一些想法小结一下。仅仅就工作流引擎来说，不包括一些外围的实现，例如流程定义器，管理控制，工作项列表等。
工作流引擎其实就是一个状态机，只不过在状态变化的过程中加入了其他一些工作。我把工作流引擎的职责理解为以下四个方面：
1、对工作流模式的支持。
   这无疑是最重要的部分，状态的变迁往往取决于不同模式的选择。支持的模式越多则客户的开发代码会越少。衡量一个工作流引擎的技术水准很大程度取决于引擎支持模式的多少。
2、工作流变量的传递和转换。
   工作流引擎通过工作流变量与外部应用交互，工作流变量在各个活动节点以及父流程与子流程之间传递。变量除基本类型（String,int等）以外，也需要支持一些复杂的数据类型（例如对象，以一种配置映射的方式）。这里还涉及到一个上下文的问题。
3、任务项的分配。
   任务项的分配往往和工作流组织权限联系起来，其实工作流组织权限存在的目的就是决定任务项分配，决定由谁来完成这个工作项。工作项涉及到的内容也比较多，比如工作项的回退，撤回等等。
4、调用外部应用。
   单纯的表单推动已经不再适用，活动节点本身需要支持许多的业务操作，而这些操作与引擎本身是无关的，与外部的应用有关，所以就需要引擎提供一种调用外部应用的机制。外部应用可以是javabean,webservice,rcp等等形式。
除去上述四方面还有一些外围的工作：例如时间服务，节点的事件机制等等。
对客户而言，他们需要的仅仅只有两个接口：任务项管理接口（比如提交任务项，委派任务项等等）和流程状态管理接口（比如启动一个新的流程实例，推动流程流转等等）。在理想的情况下，给用户提供一个封装完全的提交页面和父类Action也是很好的一种方法。
今天终于有空看看了Fielding的rest论文，没有看完，很多文字确实难懂，但有些还是很有感触的，做个记号。
一个软件架构是一个软件系统在其操作的某个阶段的运行时元素的抽象。
架构元素：组件，连接器，数据，配置。
架构风格：一组协作的架构约束。
一种特定的架构可以由多种架构风格组成。
关键关注点的架构属性
性能
最佳的应用性能是通过不使用网络而获得的。这意味着对于一个基于网络的应用，最高效的架构风格是在可能的情况下能够将对于网络使用减少到最少的架构风格。
可伸缩性
表示在一个主动的配置中，架构支持大量的组件或大量的组件之间交互的能力。
简单性
对组件之间的功能分配应用分离关注点原则。使得单个的组件足够简单，更容易被理解和实现。
可修改性
基于网络的系统的一个特殊的关注点是动态的可修改性，它要求在对一个已部署的应用做出修改时，无需停止和重启整个系统。包括：可进化性，可扩展性，可定制性，可配置性，可重用性。
可见性
能够通过限制必须使用通用性的接口，或者提供访问监视功能的方法，来影响基于网络的应用中交互的可见性。在这种情况下，可见性是指一个组件对于其他两个组件之间的交互进行监视或仲裁的能力。
可移植性
能够在不同的环境下运行。
可靠性
当在组件、连接器或数据之中出现部分故障时，一个架构容易受到系统层面故障影响的程度。
  整体来说实现的非常清晰：
  1、引擎解析流程定义xml时，给相应的事件挂接上create-timer 和 cancel-timer动作
  2、流程实例实际运转时，create-timer动作在相应事件触发时执行
  3、create-timer在job表里插入相应时间job记录，给该job记录附上计算完毕的执行时间
  4、JobExecutorServlet在后台启动一到多个JobExecutorThread线程
  5、JobExecutorThread线程不停的每隔一段时间对job表扫描一次，找出需要执行的job记录，执行之
  6、只执行一次的job记录，执行完毕后删除之；重复执行的job记录，写入新的执行时间，更新之
  7、相应事件触发cancel-timer动作，将对应job记录从job表里删除
  下面具体用代码来说话（挂接到node节点）：
  1、引擎解析流程定义xml 

  可以看到，引擎把xml中timer节点解析成了两个ACTION：CreateTimerAction和CancelTimerAction
  CreateTimerAction会在进入该节点时触发，而CancelTimerAction会在令牌离开该节点时触发。
  2、看看CreateTimerAction和CancelTimerAction究竟在做些什么

  很明显，是通过一个职责集中的schedulerService向job表中插入了一条job记录，注意到这个方法：

  这里利用JBPM提供的工作时间计算组件计算了job的执行时间。
  CancelTimerAction就很简单了，删除相应的job记录。

  3、JobExecutorServlet是干什么的
  启动线程

  4、线程是如何工作

  看看实际执行的方法

  5、着重关注Time对象
  在上面我们看到实际执行的代码是job.execute(jbpmContext);
  Time 是Job的子类，看看它的实现：


JBPM时间服务的使用主要体现在对timer节点的使用。timer节点有两种使用方式：一种是挂接到node节点下，在进入node节点时触发，在离开node节点时终止；另外一种是挂接到task节点下，在任务创建时触发，默认在任务完成后终止。下面举例说明：
  一、挂接到node节点  

  解释：timer将会在流程令牌进入节点catch crooks时触发，延迟3 business hours开始执行动作，每10 business minutes重复执行一次，直到令牌离开catch crooks节点。
  对time节点来说 name、repeat、transition都是可选属性。对一个流程定义来说，每一个time节点的name必须唯一，如果你不定义name属性，引擎会默认把node节点的name赋给timer。在上面这个例子里，如果你不定义timer节点的name，则它的name就会是catch crooks。说说repeat属性，如果你不定义它，则timer就会只执行一次动作不会重复执行。transition属性，如果定义了这个属性，流程令牌会在timer执行动作完毕后，顺着这个路径离开node节点。所以在上面这个例子里，尽管定义了repeat属性，action还是会只执行一次。
  action节点，可选，即timer节点在时间到时执行的动作，可以是任意action类型，包括script。注意与时间有关的两种action类型：create-timer 和 cancel-timer。其实一个timer节点在被引擎解释时就是被分解为create-timer 和 cancel-timer两个action，create-timer挂接到node-enter事件中，cancel-timer挂接到node-leave事件中。action节点最多只可以挂一个。
  说说整个过程：
  1、令牌进入节点catch crooks
  2、timer被触发（实际这时是在执行create-timer动作）
  3、3 business hours后 timer 事件触发
  4、定义的action被执行
  5、令牌顺着time-out-transition路径离开catch crooks节点
  6、cancel-timer动作被执行即timer终止（没有给repeat的机会）
  二、挂接到task节点

  与挂接到node 的区别是：这里可以定义一个属性cancel-event，可以指定那些事件可以终止timer的执行，默认是task-end。可以指定多个事件，以','分割，任一事件触发timer即终止。
  可以看到jbpm对任务实例和节点执行时的时间服务还是支持的很好，可以做出很多的扩展，但是它没有对整个流程实例本身提供更多的服务，比如说定时的流程启动和整个流程的时间控制等等。以及对精确时间点的支持还不够。