2013下半年总结——该拿什么来拯救-CSDN博客

本文链接：https://blog.csdn.net/jianxin1009/article/details/19765251

13年的8月底，对我的的13年前半年进行了一个小结（2013，我平凡却又不平凡的一年），再次查看，恍如昨日。

那么这半年来，我又做了些什么呢？又有哪些让人心窄的事呢？

中间件

在这里，接触到了SOA，接触了EJB，接触了CORBA，接触了ESB。

那么什么是中间件：中间件是一个独立的软件或服务，和你所做的系统是相对独立的。

那SOA呢？这个提到的一个概念是面向服务编程，对于SOA看了一本书(SOA实践指南)，不在于懂了多少，在于真的看完了……

EJB我接触过2.0，3.0，但真正编过码的只有3.0。不得不说，3.0比2.0简单的不是一点半点。

CORBA就算用应该也是遗留系统了，但CORBA中的封装组件的概念还是很好的。

ESB，心窄的看了看JBossESB，更心窄的是项目中用的不是这个JBossESB，而是一个叫做MuleESB的东西。后面说经验教训的时候会说到这个。

后来就开始了我们的高校云平台的搭建工作。

云平台

之所以叫云平台，有一部分原因就是云这个字比较火。

下面一一列出搭建这个开发环境用到的技术：

dwz，一个中国人自己的前端框架，用起来真心感觉挺好用的，目前为止，我们项目中的界面需求都可以满足。而且学习成本也不高，上手快。不过在第一次加载页面的时候把所有的js和css一次性加载这个也导致了我们项目中集成的一个难题。

struts2，这个不用多说了吧，MVC中的C。

Hibernate（EntityBean的实质），我们项目中的完全用面向对象的形式进行持久化，导致了项目初期很不适应。而且Hibernate性能优化相对来说比较麻烦，一个很简单的页面，往往要发很多语句。由于是分布式，关于Session关闭的问题到最后也没有解决，采取的解决方案是所有数据都进行手动查询。

EJB，业务逻辑层用的是无状态的会话Bean，消息驱动Bean现在还没有用到，但随着项目的进展，一定会用到这个的。而消息中间件，我们会采用ActiveMQ（apache开源项目）。

事务，关于EJB的事务，我们采用的是容器自管理的事务。但这种事务是二阶段提交事务，这种事务在一个系统内用还行，但如果是分布式，这个肯定就不够用的，而是要用补偿性事务，精力原因？也因为这种需求暂时没有那么大，所以这个暂时没有考虑……

spring，这个就不多说了吧……

项目管理：到目前为止用的都是禅道，源于贾总以前对其的研究，很快就上手用了。但这次迭代完成后（我们采取的开发方式是Scrum），会以我们项目小组作为试点，开始使用JIRA，通过学习人家的软件，不得不说，真的很牛！！！

Maven，一个jar包管理工具，这个东西的使用其实很简单。但是提前约定很重要，这也应了Maven的设计初衷，约定优于配置。在这里还进行了nexus的搭建（私服）。

Jenkins，这个是一个自动构建的工具，但是目前还没有真正投入使用，原因其实就是没有写好单元测试。而对于EJB的单元测试，真心有点蒙，不过最近看了一篇博客，有一个叫做EasyMock的测试框架，后面打算看下这个东西。不过最后一次坤哥开会，说要强制将自动构建用上，不论单元测试是否有，都进行自动构建。

eclipse，说到约定优于配置，那么我们也对eclipse进行了统一。通过一个人对eclipse进行配置（注释、样式、编码、插件），这样的好处也是不言而喻的。

dwr，ajax框架，在我最初提出要使用这个的时候，其他组员对其兼容性提出了很大的质疑，现在dwr最新的版本是3.0，我用3.0对目前主流的浏览器进行了测试，发现3.0对于主流浏览器都可以完美的兼容，如果你没有很高的性能需求，就别再去比较它与其它的区别了，直接用这个吧，简单，易用，兼容性好~~~PS，我觉得dwr得给我发点钱了，哈哈

shiro，一个权限框架，可以让你很方便的实现控制到页面按钮。

sso，单点登录，也是我们最近碰到的一个问题，目前正在攻克中，静待佳音吧~~~

confluence，一个wiki管理工具，不得不说外国人的设计真的很牛，你可以不用这个工具，但这个软件的你必须得看看人家的设计。

Java本身

除了上面说的这些，还对Java的语言本身的东西有了进一步的了解（因为要给其他人封装工具类）：

...，在方法的参数后面加三个点，就是说可以传入任意多个这个类型的参数。

容器，要封装，如果没有容器，那你就应该自己写个容器了，没有真不行。

泛型，有了它，让你封装起来得心应手，用好了，泛型真的是个宝。

虚拟机，虽然还没有系统的看一本书（计划中），但是现在在给别人解释的时候，总是会说类似它们不在同一个虚拟机内这样的话。

ClassLoader，调用方法在传递class的时候，会改变ClassLoader（自己猜测）。

Java中的传值、传址，虽然说这只是一句话的事，问谁谁可能一度娘就给你回答了，但是真正遇到问题，你真的会考虑是因为远程而将本来应该传址变成了传值了么？

这个环节，就是一个又一个小的知识点，但就是这一个又一个小的知识点，让我对Java有了一个深层次的了解与理解。

经验教训

如果要我说这个项目我学到的最重要的是什么？那么我会说是学习方法，这也利益于和贾总一起搭伙。

如果要我说这个项目我最心窄的事是什么？那么我会说是JBossESB，最后用了个轻量的Mule……

如果要我说这个项目我最骄傲的事是什么？那么我会说是真正体会到了开发一个分布式要付出更多的努力，要遇到更多蛋疼的问题，这也就是为什么有人曾说过，能不分布，千万别分布……

现在来对上面的进行一下解释：

因为之前看的东西，都是有视频可看的，我们也习惯了看视频去学习。猛的没有了视频，让自己找资料去学习，难免会在学习方法上有些偏差。我的偏差在于对于一个新事务的学习，首先是去百度直接搜索，可是后来我发现，贾总不是这样的。

对于一个全新的事务，他是大致在网上搜一下，然后就是去官网上面开始看了，后来我弄的几个东西（dwr，jira，greenhopper等）就是按照这个思路去做的，发现其实我们去看那些纯英文的网站的学习效率，要比我们看那些我们能看懂的度娘出来的不靠谱的网页快多了。

之所以JBossESB流产，源于我太懒，省事，没有对目前流行的所有ESB进行一个对比。其实这个也源于我们的应用服务器用JBoss，用JBossESB的话可以直接就用一个应用服务器了。因为JBossESB是基于消息的，而基于消息就对实时性要求的不是那么高，其实在看到一半的时候，就向贾总提出过换，但没有换成。而且在例子方面，做的也不是很好，只是一直在对它给的例子进行修改，没有真正放到Eclipse中进行运行过，种种原因，致使JBossESB即没有被应用，还用了那么长的时间，如果一开始就看的是Mule，那么肯定用不了那么长时间。

所以前期调研很重要。

因为分布，所以原本起作用的lazy（hibernate中的）却总是发生Session关闭的问题。因为分布，原本起作用的级联操作也出现了各种各样的不起作用。因为分布，我们不得不解决一个SSO的问题（就是不分布也得解决）。因为分布，出现了页面的样式丢失问题。因为分布，我们不得不去了解什么是补偿性事务。因为分布，原本的传址，却意外的变成了传值。

但庆幸我们一一解决或正在解决。