每次写年度总结，也就是更新自己简历的时候。把有意义的项目加在简历后面，把自己新学到的技术加在后面。在感叹岁月流逝的同时，总想抓住点什么，留住点儿什么。这时候，需要做的就是做总结。不总结就是竹篮打水，就是狗熊版棒子。总结下来才会沉淀下来。书阅读越薄，就是这个道理。
Maven的学习，是从一套Maven视频开始的，视频看完之后还是云里雾里的，什么中央仓库啊，私服库啊，已经依赖关系啊，都没有一个清晰的理解。不过在项目中应用，这些已经足够了。就是很多东西，不是很理解。
然后在GCT入学那几天，以及回来的几天，我研究仔细了一下《maven权威指南》，由于在项目中已经有了应用，再次理解很多概念，就容易了很多。此外，Maven的中文资料也很多，比如争光师兄的博客，就有对Maven的详细讲解；那期间，经常去他那里偷学现成的。还是吃现成的舒服啊！他已经总结好了革命果实，我们直接窃取就好了。
有了Maven，Jar包的管理就方便多了。不用拷过来拷过去，还担心着Jar包冲突的问题。
已经有了几年数据库开发的经验，但是在TKY项目中，我同时负责后台服务接口。各种各样的需求要求，需要我们了解Oracle很多特性的东西。尽管我们不会去做DBA，多了解一些还是好的。
比如之前，我们系统测试中，发现备份的数据库，还原后总是缺失一些表，由于是远程调试，我们找了好久才发现，原来是数据的问题（表都没有了，去哪找数据去？）。学习了Oracle我才知道，原来是数据库备份的时候，需要清空Oracle的回收站，这是Oracle的删除机制，回收站有东西，备份的时候就会导致一些相关表无法正常复制。
Oracle的学习也是通过一个视频。由于数据库的内容大部分内容都是相似的，对比MySql和Sql Server，大部分都是学过的东西，过一遍就好了，我们只需要着重关注一下新的知识，也就是Oracle特性的东西。
(技术这东西，就好像这片竹林，盲目的乱窜很容易迷失方向。要掌握学习的方法)
最开始认识到Ejb，是在最开始接触JavaEE规范的时候。那时认识到的是Ejb2.0，感觉就是：繁琐。要想实现一个最简单的Ejb应用：业务类需要继承SessionBean，业务接口继承EjbObject，Home需要继承Ejb的Home接口。这些繁琐的操作，内部逻辑是非常复杂的。而我们想使用Ejb2.0实现自己的业务逻辑，我们就必须委曲求全，默许它的侵入性。
人们对Ejb2.0的怨声载道，给了SSH一个大好机会。而SSH的易学易用，轻量级弱侵入性的特点，非常适合中小级web项目的研发。不过，大和小都是相对的。SSH的缺点还是因为Spring在分布式上的缺陷。
不过，随着Ejb3.0的出现，它极大的改进了Ejb2.0。Ejb3.0重量级，弱侵入性，几行注解就能配出Ejb应用。Spring为了抢占市场，在分布式上做了很多工作。现在，可以说Ejb能够完成的事，Spring也同样能够完成。
我们继续来说Ejb。对于这门技术，我还是选择了Ejb3.0，来进行深入研究。因为它基于自身特点，并借鉴Spring的长处，开发出来的产品。它集成了Ejb2.0的所有功能，却比Ejb2.0更加易用。
为了从宏观上了解分布式开发，我找了一本《JavaEE高级开发》翻了翻，因为书中用到的绝大多数东西，都是GXPT项目中用到的技术和工具，所以，学起来很快，同时它能更使用你用到的那些知识更加系统化。此外为了更加深入的学习Ejb3.0，我又找了一本《Ejb3.0 In Action》，这本将近八百页的英文文章，耗费了我两个月左右的时间。尽管看完了，但是书中好多东西，还是不太懂。只是对于应用过的东西，理解更加深刻了。
尤其是对Ejb的发布订阅模式，有了更加深刻的理解。这对我后来研究Shuttle ESB，很有帮助，这是后话。
现在，我深刻的体会到了一点：我们搞技术的，一定要懂英语。一些比较前沿的技术，只有我们阅读官方网站的官方文档，或者一些技术的英文原著，你才会真正懂得作者的意图，你才会感觉到什么是地道。按照官网上的去做，不敢说一定是最正确的，但肯定是最权威的。
同时，你看官网的资料多了，你都不太想看中文的。因为人家讲的更加系统，很有规律。不像中文资料，杂七杂八。
然而，看官网当然没有搜中文资料来的快捷。如果项目紧任务中，你当然是要以解决问题为首要的，下班之后再自己去逛官网。
现如今，流程管理，几乎在任何一个大型项目中，都必不可少。我选用Jbpm的原因很简单：API比较完整，资料也比较健全，还有一套守宏师兄录制的视频。最开始接触Jbpm，是在OA项目中，项目中使用的Jbpm3.2版本。完成了一套比较简单的公文审批流程。
Jbpm3已经是一个很成功的产品。一方面它支持嵌入式，降低了工作流的门槛；另一方面，对开发人员友好，它有易读的jPDL、流程可测试性和节点行为的可扩展性。我们能够很容易的在流程运行中加入自己定制的行为。Jbpm3面向开发人员，解决了程序的自动化问题。
然而，Jbpm3的作者Tom Baeyens，对该产品的定位就是工作流系统，所以Jbpm3并没有实现BPMS特性。另外就是Jbpm3不支持流程语言规范，它采用了自定义的jPDL。节点的运行期间行为与jPDL里面的定义的节点类型一一绑定，造成了流程引擎与特定流程语言绑定，难以再支持其他流程语言。
所以，我有学习了Jbpm4.3，也就是《jBPM4工作流应用开发指南》这本书。Jbpm4在Jbpm3的基础上，进行了质的改变。为了实现流程引擎与流程语言的解耦合，Jbpm4引入了PVM（流程虚拟机）的概念。解决了Jbpm3中流程引擎与特定流程语言绑定的问题。
此外，Jbpm4还增强了BPMS特性，支持了BPMN流程建模标准。并且，引入了SignavioWeb建模器。
现如今，Jbpm5，和Jbpm6都已经出来了，这些只是了解过一些相关，没有进行深入研究。据说Jbpm5又完全抛弃了Jbpm4的代码，这些还没有时间研究，等项目中需要在深入研究。
ESB是面向服务架构中，必不可少的一部分。GXPT项目中，使用Mule ESB完成了系统间的交互。不过，由于自己没有参与到这一块儿的开发，对Mule没有一个实战的经验。此外，GXPT项目中，只是比较单纯的使用了Mule，并没有使用到它比较复杂的功能，所以我对Mule的理解，比较肤浅。不过，跟着官网，做一些Demo，实现一些实例，基本上也就够用了，接下来的就是在具体项目设计时，应用的问题了。
Shuttle ESB是最近一个项目中使用到的ESB产品。正好我负责这一块儿的研发。项目中把Shuttle ESB作为一个消息路由器使用，用到了Shuttle的全部核心内容，让我对ESB又有了更深入的理解。具体细节我就不介绍了，我会在我的系列博客中继续介绍：Shuttle ESB系列博客。
可喜可贺的是，现如今，Shuttle已经能够正常在系统中运行了。
又是SSH？？ 呵呵，没错！在Java Web开发中，SSH是最基础的。所以我们不仅要会用，还要做到精通！所以我们需要深入研究。因为之前做的项目大部分都是基于SSH的，自己也是应用比较多，理论比较少。鉴于这种情况，我选择了看书的方式。由于一直觉得XX In Action系列不错，所以我就选择：《Struts2 In Action》、《Spring3 In Action》和《Hibernate In Action》三本书。根据王鹏师哥讲解的SSH，结合这三本书进行研究。
由于一直是下班时间进行研究。每天也就只有两个小时的学习时间。导致占线拖得很长。《Struts2 In Action》没有什么特殊的东西，基本上就是MVC那一套流程，Struts2内部很多功能，都是扩展拦截链完成的。我们可以自定义拦截器，完成面向方面的编程。
《Spring3 In Action》全面介绍了Spring的注入方式，以及AOP的应用。当然，还介绍了一些Spring很多扩展的功能。我觉得这本书中介绍的东西还是偏实现，想要更加深入学习的话，需要结合官网，看Spring的源代码。说白了，内部也就是配置文件+反射+几个设计模式的应用，没有什么更新鲜的。
《Hibernate In Action》目前正在看，主要介绍的内容也就是Hibernate的各种关系映射、Hibernate的缓存、延迟加载和性能优化等。
从技术架构上讲，OA系统是以SSH为基础，主要包含两大块：ACL权限管理和Jbpm工作流引擎。
无论多么复杂的权限管理，无论采用什么技术实现，无非就包括两大部分：授权和认证。本项目中直接基于位运算进行操作。使用ACL能够控制的更加细粒度，可以对角色进行控制，也可以对单个用户进行控制。
另外，这里不采用框架，而是直接使用位运算也有很大的好处：快速、直接和一劳永逸。无需框架那些乱七八糟的配置，直接使用位运算进行控制，速度很快。对于很多相同的东西，你都可以抽象成模板，然后根据需要，直接改造使用就好了。
对于授权，必须由系统提供授权界面，对系统各个模块的访问权限，进行权限设置。而认证就更简单了，包括登陆时的认证和即时认证。登录认证就是登陆时，判断哪些模块儿有权限，需要加载哪些模块儿；即时认证，比如，系统中某一界面的权限认证，就属于即时认证。
对于权限系统，有多种类型的权限，你需要根据具体需求，选择更加合适的模式。同时，你可以使用权限框架，如Shiro。
OA中工作流部分，是使用Jbpm3.2进行实现。完成的主要功能是一个公文审批的流程。无论是版本几，使用起来也就是那么个基本流程：定义流程、部署流程、启动流程实例以及相关操作。这一部分由于业务流程比较简单，没有什么更深入需要介绍的。虽说工作流产品每一个版本，都是基本上推翻原来的设计，从新架构设计。但是它们都是为了解决实际项目中的工作流程而设计实现的，不同点在于内部设计的理念和实现。对外使用的基本步骤是不变的。
（光说不练假把式，实践才是检验真理的唯一标准）
这个项目是我带队从需求部分开始做的。我前前后后翻了好多遍那本《Jbpm4.3工作流开发指南》，研究了工作流的前端设计器，并且用Maven搭建了Jbpm的开发环境，并且跟工作流大牛守宏师兄沟通了开发疑惑。
我定的开发计划是这样的：我们现在众多工作流需求中，选取一条经典的。然后设计出一套流程。整个项目组共同实现这个流程。完成之后，再在此基础上进行扩展，再把工作流做的独立，通用。此外，我们还想实现JIRA中工作流的效果。将工作流嵌入到项目业务中，具体流程由用户自己定制。……
可是，还是自己的原因吧！因为Jbpm工作流开发要求较高，组内成员花费了比较长的学习时间。再到后来，项目还是以失败告终。现在，已经将项目交给九期了，希望他们继续把项目做好吧。我们的遗恨，就交给九期去创造奇迹吧！
这是我第一次参与分布式开发，分布式的开发让我受益匪浅。
如今，是拥抱高并发、大数据的互联网时代。诸多传统行业的转型也是顺应时事，以至于很多人说：纯粹的传统行业已经是穷途末路。按照这样的逻辑，对我们程序猿来说，Hadoop、分布式、集群、多线程等等这些技术，已经是我们的基础技能了。如果你还在公司，天天干着枯燥、重复的工作，那我只能说：您真需要给自己充充电了。
写着写着就又有点跑远了，我们来继续谈项目体会。GXPT项目一共包括六个子系统：权限系统（集成单点登录）、jc系统、pj系统、ks系统、Jbpm工作流系统和日志系统。权限系统采用shiro框架。在权限系统中，将每个子系统均看做是一个组织，一个组织中又包含多个资源（多个业务）。每个访问系统的用户都配有自己的角色，角色绑定资源、操作，以做到对按钮级别的控制。
jc系统为pj系统和ks业务系统提供基础信息和基础服务，jc系统和ks系统为不同需求下的不同业务系统，而工作流系统为整个系统提供流程支持。
由于系统要实现分布式，后台服务使用Ejb提供服务支持，Jboss作为应用服务器，分布式事务没有做更加严格的要求，采用JTA声明式事务交给Ejb容器管理。后台的Ejb服务以业务为单位，作为一个细粒度颗粒jar。每一个颗粒都做到相对独立，以冗余为代价，增加系统的灵活性。
前台使用DWZ+Struts2+Spring架构，使用DWZ是因为它是一个比较成形的国产jquery框架，文档当然都是中文的，学习成本低，上手快；使用Spring框架，只使用到了IOC功能。Spring的主要功能包括两个功能：1、struts2中的action的创建交给Spring管理，这个很常用；2、Spring管理Ejb Bean。将Spring应用程序（也就是war包）部署在Jboss中，Spring通过配置<jee:jndi-lookup>元素标签，它能根据Ejb jar部署在服务器的部署地址，查找上来所需的ejb Bean，进而使用ejb服务。
对于系统间交互的部分，将jc系统的对外服务，分发布称Webservice，中间通过ESB进行通信，完成系统间的通信。
因为系统由细粒度颗粒组成，大量的jar包会泛滥成灾，我们使用进行Maven管理jar包，配置私服，设置远程仓库。添加第三方jar包时，只需要在pom中引用即可。Maven会自动在本地查找，如果没有话，自动从私服上下载。
另外，由于我们采用的是敏捷开发模式，要充分发挥工具的作用。我们还使用了Jenkins进行持续构件，一天中Jenkins能够集成多次，从SVN上下载最新的jar包，部署到Jboss应用服务器中，如果集成失败，发生错误，它会通知Hmail服务器，邮件服务器会给对应的开发人员发送邮件。
另外，为了保证系统的查询效率，还是用了缓存。这里无非就是使用了Hibernate的一级缓存、二级缓存以及查询缓存。二级缓存的实现采用第三方的框架Encache。同时，使用Ejb的JMS保证了缓存的同步。比如：系统间的互操作用到了缓存，当jc系统数据发生变化时，pj系统这边的缓存就成了脏数据，这时候，就可以在pj端起一个MDB Bean，监听jc系统的消息，当有数据变化，它就会监听到消息，然后它会清除缓存，重新从数据库查询数据。
本次开发没有采用传统的瀑布是开发，而是采用另一种开发模式：Scrum敏捷开发。敏捷风已经在国内喊了好几年了，但是落实到企业中，国内企业真正使用敏捷开发的公司，却是少之又少。
刚开始接触敏捷开发，我就觉得这种模式很棒。它主张以工具代替写文档，实现快速开发，这点很让我们兴奋，不用花大量时间写文档。传统开发中，说实话，那后来补的几千页的详细设计文档，你真的回头看过吗？当然，敏捷开发并不是不写文档。敏捷开发主张的是只写有用的文档。
这次开发中，也遇到了一些未解决的技术问题：
1、用Webservice进行传输，返回PageModel类型的方法，无法传输成功。WSDL里面的定义都是正确的，猜测与分布式事务有关系；
2、跨域访问的问题；
……
这个项目，我是最为一个研发人员，中途加进来的。业务流程在之前的博客中有所介绍，这里再重新整理一下：
首先，一些硬件设备检测到各种数据信息，用C程序进行接收，然后将这些数据发送给C++端。C++端接收到数据后，按照一定的规则，对数据进行分类、加工、处理。处理后，C++端会将一些特定的数据，以windows消息的形式发送给ESB服务。ESB在本系统中，作为消息中间件使用，对消息进行转发。ESB服务端接收到消息后，它会以Pub/Sub的形式，将消息发送给每个客户端，而每个客户端，都会有多个终端显示器。由于是消息是Pub/Sub的方式发送的，而不是Command的方式。所有的终端显示器在启动后都会接收到消息。
终端显示器接收到消息后，它会根据消息，进行一定的处理。处理完后，它需要通知其他所有的终端显示器，它处理完了。如何实现呢？很简单，只需要让处理完的终端显示器给ESB Server再发送一个消息，然后ESB Server再通知一遍所有的终端显示器。
在参与到这个项目之前，老师就告诉我们：这个阶段，对我们来说，最重要的是给自己一个职业定位。不错，就这几个月的开发来说，变化最大的就是自己的心态。
对大多数程序员来说，看着自己写的软件能够按期交付，并且正常运行起来，才是最满足的事情；对于大多数经理，满足领导的各种灭绝人性的要求应该是第一位的，其次才是协调下面的人好好干活；而对于经理的领导（如XX主任）来说，他要做的就是保持系统的领先性。不管系统现在进展如何，他都会对所有相关人员介绍说，我们的系统绝对是国内的领先标准，我们的开发团队都是从XX来的精英组成。……
有一次，我们在给吉林那边的客户演示的时候，公司的董事跟人家是这么说的:我们的系统马上就会实现全国联网，所有局的系统将实现系统共享；我们使用到了全世界最领先的技术。中间使用ESB消息中间件，实现了系统的灵活性。……
我的想法是：你有多大胆，地有多大产。为什么楚云飞能当师长？因为他并没有仅仅把眼光放在自己的358团，而是放在了中国的国防力量上。而我们程序员呢，比较一头扎到代码里，所以容易坐井观天。所以说，要给自己一个积极的职业定位。
项目中，我负责的主要是ESB这一块儿的研发。我在开发中，遇到的一些比较难对付的问题有：
1、ESB源码研究的少，网上资料也少，结果就是ESB在集成时，报的很多乱七八糟的异常，我只能去按照自己的想法，进行尝试。这个摸着石头过河的过程，比较熬人；
2、大家也看出来了，ESB的研发属于中间层开发。我与两头同时进行开发，一旦有人上传上来有问题的代码，我就得启动一堆服务和工具，一点点调试问题出在哪。有时候寻找问题在哪，就会花费大半天时间；
3、ESB消息中间件的研发，不能按照传统开发的思路进行。你需要转变一些思路。懂Ejb发布订阅模式的，可能会更好理解一点。比如说：服务总线实例启动了之后，他才能发送消息，同时，它才能监听消息队列中的消息。这里，它是如何传输消息的，你要寻思明白；
4、启动一个ESB服务总线实例，是需要很多资源的。所以也很花费时间。其实这儿最好放在容器中启动，或者是放在windows服务中才好。可是系统要求在启动的时候，完成服务总线实例的启动。目前的是在登录中启动实例，缺点显而易见：耗费时间，降低用户体验。这一块儿的思路是采用多线程实现。系统启动时，另启动一个线程去偷偷启动服务总线实例，它不影响系统的启动。这就好像是完成Ajax的内部实现。现在还没做这个工作。
现在，自己已经是正儿八经计算机系的学生了（毕业证已经发下来喽）。参加自学考试，多学了十几门课程，在宏观上多软件开发又加深了一层认知。同时，更重要的是，锻炼了自己快速阅读的能力，学会了读书的方法。“读烂前几章，后几张烂读”的方式是要不得的，不然读了半天，只能是：不识庐山真面目，只缘身在此山中。读书必须先宏观再微观。它是一个不断丰富思维导图的过程。图的关系画清楚了，理清楚了，你也就会读懂了。
另一件喜事就是自己已经是研究生了。入学时，尽管惹的袁老师很不高兴，还是挡不住我们对GCT的热爱。看着自己选的课程列表，正是自己比较薄弱的一些课程。一定要抓住这个机会，好好补习一下。
写到最后了，也来谈谈程序员的感情生活。我要感谢生命中有她的出现。她不是一个事业型的女孩，她崇尚自由。我很爱她，也很感谢她。我要感谢她这么爱我。我相信，我们的爱，会是一个死循环，永远的循环下去。
8真是一个神奇的数字。大家的好消息一个接一个，真是为大家感到高兴，四年的努力真的没有白费。真心希望大家都能够突破自己，再创新高。同时也希望自己能够一鸣惊人。另外，我也接到了阿娟姐好消息。你别以为不告诉我们，我们就永远不知道。这是继海燕姐之后，我们八期的另一大喜讯。值得我们为你庆祝、为你祝福。
原文地址：http://blog.csdn.net/liu765023051/article/details/39251985
