工作五年，一晃已年过三十了。读研时，独立做项目，毕业头三年，主要在大公司工作，后来，也就是08年，半创业。具体点，合伙人吧，自己负责IT部门，到现在6人，公司总共20来人，旅游业。这两年严酷的创业经历，让我越发觉得管理(做事)，以及领导(带人、待人，不是管人)的重要性。因为，随着组织的扩大，混乱度无形中就会增大，管理和领导，就是让这种混乱重归有序，重归单人作战那种意图和行动的高度统一。

    说得功利点吧，一个人的财富和其影响力是成正比的。影响力本质上就是对他人的价值。比如，郎_xian_评的出场费一天超过15万。作为技术人员，如果我们只能影响周边几个人，那么我们凭什么拿那么高的报酬，除非我们做的事情影响了很多人，比如杨勃的豆瓣网。所以，我还是觉得，技术人员往高处发展，逐渐应该有管理意识、培养自己的管理能力。技术从书本上可以学到很多，管理还真得实践，书上看到的，你觉得很弱智的问题，比如盲目扩张，自己亲身经历时，一样会犯，也许是行为习惯在起作用，看书不足以改变行为。

    回到正题上。
    也许是自己曾经在较大公司或团队的做事习惯和视野，刚创业时，用在这种小团队的商业项目开发上，几乎惨败。
    先说项目开发这块吧。
    大家知道，项目管理和过程管理是两码事，前者关注目标和进度，成本和收益；后者关注做事流程、方法。
    项目管理，体会最深的，就是目标和任务分解、进度控制，以及沟通。

    项目管理软件
    从大公司出来的人，我想最喜欢玩的，就是借助于项目管理软件(核心是甘特图)。市面上的大多数知名的项目管理软件，无论是桌面版还是网页版的，我都试过。当然最后也选择了一款：ConceptDraw Project，用了一年多，也多少有些用。但最后还是发现，它其实对项目进度和质量关系并不大。也许，一个Excel表格更实用。
     项目管理软件，本质上是解决一种沟通和职责分配的问题。比如，一个项目，折叠成一个三层树形结构，老板只关心第一层，也就是整体进度；中间是项目经理关注的功能层，最后一层，也就是具体的任务，是开发人员关注的。想想，如果没有这玩意，你怎么告诉其它项目干系人进度？但又引出几个问题：
    靠文档来沟通，还是靠信任? 太在乎文档，往往导致每天去关注文档如何漂亮、有说服力，并为此花大量时间，而不是项目如何漂亮。另外，是否有文档就可以防止扯皮、兑现承诺？我们是关于项目目标，还是关注彼此的博弈？

    进度偏差 创业型项目，往往都是以前没有接触过，其进度评估往往有很大误差，比如业务需求的挖掘和变化，技术难点，开发人员素质。我们是关注进度，还是关注项目本身的质量？两者都要，但如何兼顾？虽然有方法学，比如砍掉优先级低的，但你怎么让老板相信某个核心功能就得四天时间。
    在我们的进度设计不合理情况下，是否开发人员完成甘特图(WBS)下的任务就ok？远远不够，任务分得太细，往往限制了开发人员的创造性和自我评估能力，如果提前两天完成呢？
    我们现在是以项目管理软件为辅，任务的下达主要以邮件传达，每周一上午的周例会会白板宣布。我发现白板比投影仪PPT好用。

   关于规范
   这也是大公司特别喜欢玩的。
   也许我们前期会制定一个的架构、设计文档，代码规范，这有一个规范建立的时间成本以及规范本书的合理性，再说如果一个开发人员，特别是高手，如果不认同你的设计和规范，你要强推，他要么走人要么怠工。规范的本质是为了协作和后期可维护，如果只有两个人或一个人写某个模块，你觉得有这个必要吗？规范整洁的代码，在项目初期，对用户的价值关系很小，你会关心豆瓣网的js代码写得很漂亮吗？我们应该关注代码的健壮性而不是可维护性，我们不是在开发Windows。

    人适应项目，还是项目适应人
    大公司，往往是来了一个项目，赶快招人，人来适应项目。小公司呢，我现在的看法是，项目适应人。小公司，往往一个项目做砸，公司就面临解散。所以，我认为，最好还是按照开发人员的擅长，保证功能质量，最快的速度上线。另外，为了达成进度，可以在上线初期砍掉不太重要的栏目或功能。
    我在这个上面栽过跟头的。比如开发人员的擅长，如果他擅长jsp开发模式，而不是Hibernate+Spring的分层开发，就让他按自己的意思做吧。因为，创业型项目都不会太大；即使技术实现你感觉完美了，用户可能感觉不爽；再说，项目开发，涉及到业务调研、需求分析、原型界面、架构、开发、部署、推广。开发，也就是代码实现，占去项目时间，也许不到30%。项目如果证实有商业前景，代码重新实现一遍，花不了多少时间。
    但我也深深地意识到我们项目管理的级别，就如同CMM1到CMM4。但我还是觉得目前是最好的选择。
    如果最低层次的用户需求目标都达不到，直接考虑代码怎么有可扩展性、可维护性，对于小公司就是找死。
    另外，尊重和信任、支持开发人员的技术选择，往往是一种激励、增强团队凝聚力的方式。万众一心，比什么目标、进度更有效、实际。
    我们应该培养一种团队成员的内部创业心态，而不只是敬业。

    在进度把控上，我现在更倾向于强调我们的项目目标和紧迫性，而不是他们的任务。因为我希望大家的关注点是项目，而不是他的上级，他应该对项目负责，而不只是对上级负责。

    说说沟通
    项目管理中最难处理好的，就是沟通。以前，我比较关注于工具，如邮件、文档、ppt讲稿会议，逐渐我关注效率和效能，特别是态度。沟通最基础的就是态度。如果网站上线后，订单提交出现一个核心bug，你是直接找开发人员问责；还是告诉他哪儿出了问题，这个问题的严重，并且自己反省，比如测试流程出了问题。出现这种事情，也许需要负责人举重若轻的气度。但更深层次的，如果负责人能够培养其员工质量意识，危机意识，才是治本。因为一个有强烈质量意识的团队，他自然会去对代码健壮性、功能易用性精益求精，自然会去配合测试流程。
   刚才那个沟通问题，对开发人员的态度，前者是负面，后者是中立。那么前者，开发人员的反应是如何不让领导下次责怪自己，比如只做领导安排的事情；后者的反应是怎么去改进，不让这样的事情发生。
   如果你认可创新就可能出错，如果你认可开发人员都是想做好的。那么所有的事情，朝正向发展迈出了最决定性的第一步。

   沟通:命令式还是征询式
   在沟通，特别是下达任务或做决策这类事情上。应该说中国绝大多少管理者都是用命令式。我过去经常在用，但一直在试图改正，改用建议式和征询式。管理者最需要、最难开口的一句话是：Do you think so？命令的方式，经常出现下级不能理解上级的意图，严重的出现抵触。每个人，其实都喜欢别人按自己的想法做事，但你怎么知道自己的想法或决策是对或不是偏颇的，怎么让团队愿意去执行？去征询团队其他成员的意见，让他们参与，往往能够培养其主人翁意识、责任感、向心力，还能够完善自己的想法。但要将员工参与意识，转化为一种习惯，太难。
    当大家都没有主见时，需要领导者的果断、魄力和强势，但这种机会并不多，而且这种情况，需要团队成员对领导者的信任。
   
    遵守制度，还是建立信任
     在大公司，往往是告诉你怎么去遵守公司制度。在小公司，我认为最基础、最核心的一件事，就是建立信任，让团队信任你的人品(说到做到)，信任你的能力(能够把大家带到一个新的高度)。建立了信任后，下一步的核心工作，怎么将你的个人目标，也就是团队目标，转化为每个成员的个人目标。
    有了信任这个基础，才会有了团队建设的第二个核心：激励。
    是激励，而不是约束、监督，让团队有战斗力。但大公司往往喜欢后者。也许，大公司都是职业经理人，反正是打工，太关注于事。如果说有个所谓的中国式领导，我觉得就是以人为本，对人的尊重。人的关系处理好了，事情就好做。
    加班、考勤、上网监控，这类对信任、激励极具破坏力的行为，也许是工业型社会对我们这个思考性创造性行业的侵蚀。知识型劳动者，需要一种与体力型劳动者完全不同的管理模式，这种模式也许需要一个从萌芽、生长到成熟期。现在在目前的中国，还只是刚走出萌芽期。
   
    以前完整看过余世维的11套视频，还看过几遍。他那种人本理念我还是很认同，只是，他在大公司、规范公司的做事情方法和风格，完全照搬拿到小公司，非常危险。你能够拿幼儿园那种教育方法来教育成年人吗？小公司不具备大公司那种职业化的环境，也不具备大公司在行业中的市场地位及资金实力。
    如果说大公司讲究做事方法、流程，如SWOT分析法、BCG矩阵，小公司更看重灵活性、市场适应性。小公司应该适当短视、急功近利，否则在你实施一个三年计划时，第二年还不赚钱可能就撑不下去。
    所以我觉得，在跨国大企业呆惯了，出来创业很危险。一个是做事方法不适应，另外一个就是没有平台。如果要出来创业，以前那种大企业的经历可能更是一种劣势。 也许有一种情况，你是大公司的高官，拿到一笔很大的风险投资，然后出来创业。
    
    人事招聘
     薪水  如果公司给得起，并且应聘者能力差不多。 就不要太在乎那200、300。虽然说至少要不低于行业平均值（IT人员是IT行业平均值，而不是本公司所在的行业平均值），但最重要的，还是不要低于当事人的期望值，因为最核心的是满意度，而满意度决定于期望值和实际值的差距。对于小公司，往往一个人技术人员的成本和收益，和其工资差距非常大，有可能10倍。所以，我们的关注点，应该是怎么一开始留住这位人才。然后，怎么让其充分发挥潜力。小公司往往不是因为节省那几千几万的工资成本死掉的，而是充分利用这位人才才活下去了。

     另外，不要以为有多少人才选择的机会，小公司往往不受高级人才的青睐。太高级的人才，可能养不起，而且往往太有个性，很难合作愉快，除非在来公司前有很长时间的了解。
     招聘到合适人才后，应该让其忘掉薪水，专注于工作，寻找工作本身的乐趣。当然，要做到让其在薪水上有优越感，也许是项目很盈利的那一天，开始时很难。

     人才标准 如果其能力和你预期相差不大的话，更应该考虑其态度、做事风格，甚至是价值观。因为其能力的发挥，和这个环境，特别是他的直接利益相关者，也就是上司，关系太大。如果配合得好，一个人可以顶三个。否则，那种内耗导致的进度延期，由此引起的市场机会丧失，公司财力无法支撑，往往是致命的。因为一个几人的IT团队，每一个人的职责就如同那木桶的一块板，缺了那块都存不了水。
     比如关于质量，更确切说是内容质量，我们目前做旅游电子商务，我认为内容质量很核心。但你招进来的同事，始终认为先要量，什么都可以抄，而我强调质，原创、半原创，可以少而精，而不能多而乱。除开项目进度，怎么去沟通？最好两个人一开始都认同原创的力量。

     提升一个人的技能不难，但改变一个人的态度比较难，改变一个人的价值观几乎不现实。所以先找志同道合的人吧。    
     别期望人才是可替代的。我们不是大公司，我们缺了谁，那一块就不转。
     大家都知道，松耦合要付出代价，比如SOAP协议的低性能，AMF私有协议的高性能。创业期，不要太多考虑人才替换，而是关注怎么发挥人的潜力，留住人，尽快高质量完成项目。人才替换的一个假设，可能是你对自己管理的不自信，因为你不相信自己能够留住人。
    
     这次就写这么多吧。
     我似乎有这种体会，考大学、四六级这类资格、证书类考试最好混，因为只要勤奋就可以，再加点方法就可以出类拔萃了。  上班也比较好混，说找工作吧，像我搞技术的，本身对技术很狂热，根本就不愁找不到工作，因为面试时我觉得那家伙应该比我牛，正好可以切磋切磋，没想太多所以没啥怯场或不自信。工作吧，如果是技术类，特别是商业软件，技术难度都不大，按上司意思来，很容易搞定。创业呢，自己要做商业判断、业务决策，还要协调若干人的工作(协调的本质是协调利益)。做事和管事，完全是两码事，有些难。不过，创业还是很有意思，因为你可以按自己的意愿去工作去生活，当然也是受限环境的自由。


我将我的一个回复放在这个地方，特示警醒：
原文地址：http://www.javaeye.com/topic/646406      摘要: 开发和架构的界限难以捉摸。有些人告诉你它根本不存在，架构只是开发者们所做的设计过程的简单扩展。 另外一些人认为这是一个鸿沟，它只能由那些做到高度抽象，而且不会陷入实现细节的开发者才能跨越。通常，在这两个极端的观点中间某处有个可操作的平衡点；不论如何，怎么从开发转换为架构师都是个有趣的问题。

经常被用来区分软件架构和软件设计开发的关键几点包括 伸缩性和抽象程度的增加以及作出正确设计决策意义的增强。软件架构是通过一个全局的观点，宏观的视角来理解软件系统作为一个整体如何工作。

即使这能够帮助区分软件开发和架构，它并不能帮助理解某人如何从开发提升到架构。 并且，它也不能帮助识别谁能够成为一个好的软件架构师，如果你想雇人的话你如何去寻找他们以及你是否是一个软件架构师。
  阅读全文      摘要: Flashback 技术是以Undo segment中的内容为基础的， 因此受限于UNDO_RETENTON参数。要使用flashback 的特性，必须启用自动撤销管理表空间。
在Oracle 10g中， Flash back家族分为以下成员： Flashback Database， Flashback Drop，Flashback Query(分Flashback Query,Flashback Version Query， Flashback Transaction Query 三种) 和Flashback Table。  阅读全文      摘要: 代码检查是白盒测试的一种静态测试方法，是众多软件测试方法中发现软件缺陷最有效的方法之一。本文结合国内外学者在相关领域的研究情况，介绍代码检查相关的基本概念、过程和分析方法。  阅读全文      摘要: 为什么需要对参数进行编码？相信有过开发的经验的广大程序员都知道，在Web中，若是直接在Url地址上传递参数值，若是中文，或者+等什么的就会出现乱码现象，若是数字或者英文的好象没有什么问题，简言之，传递过来的参数是需要进行编码的。 在这里，也许有人会说，为什么不直接用Server.UrlDecode和Server.UrlEncode这两个来进行编码和解码的操作呢？ 的确，这两个服务器端对象很...  阅读全文      摘要: Spring Framework最得以出名的是与Hibernate的无缝链接，基本上用Spring，就会用Hibernate。可惜的是Spring提供的 HibernateTemplate功能显得不够，使用起来也不是很方便。我们编程序时，一般先写BusinessService，由 BusinessService调DAO来执行存储，在这方面Spring没有很好的例子，造成真正想用好它，并不容易。  阅读全文      摘要: Spring Framework从诞生之日起，受到了越来越多的关注。最近，新的开源项目大多支持Spring Framework。国内目前也有专门的网站（http://spring.jactiongroup.net/）。那它为什么如此受欢迎呢？

我想最重要的是，EJB让每个人都痛恨。要编写一个EJB，需要写LocalHome, RemoteHome, Bean, LocalInterface, RemoteInterface，需要一个标准描述符，一个特殊厂商描述符（Weblogic、WebSphere都不一样），如果是Entity Bean，还需要Mapping文件。如此之多，实在麻烦。但EJB最重要的是解决Transaction问题，没有Spring之前，没有其他方法能够描述式的解决它。每个人、每个公司为了解决Transaction的问题，编程的写法都不一样，百花齐放。于是，在最需要它的时候，Spring出现了。  阅读全文      摘要: Spring Framework  【Java开源 J2EE框架】 Spring 是一个解决了许多在J2EE开发中常见的问题的强大框架。 Spring提供了管理业务对象的一致方法并且鼓励了注入对接口编程而不是对类编程的良好习惯。Spring的架构基础是基于使用JavaBean属性的 Inversion of Control容器。然而，这仅仅是完整图景中的一部...  阅读全文

 

Chasing an OSGi vision

OSGi技术的研究和讨论

     摘要: 金山软件事业部的技术总监许式伟常常称自己是一个计算机的狂热爱好者。对于他深厚的软件开发经历，他只简单的分成了桌面开发阶段、服务器开发阶段。但我想这每一个阶段中都蕴涵了很多关于他奋斗故事。  阅读全文      摘要: 中国人大都喜欢用武侠小说来比较软件开发，但是在实战武功中，只有葵花宝典才是最厉害的，也只有掌握了葵花宝典，才能称为"不败"。

……

让你的思维快起来，你就会区别于那些反应迟钝的人。如果你不能让人生的道路变长，就让它变宽。这世界变化快，需要你变得比它快才行。

这样加快并不会让你短命，相反，你有更多的时间来享受生活和锻炼身体。你的生活将更有品质，更丰富，更有意义。面对变化，你将立于不败之地。我们都是和自己赛跑的人，需要跑得比昨天的自己更快。  阅读全文      摘要: OpenCore纯插件体系结构中的核心概念包括：微内核、插件与服务。  阅读全文      摘要: IDG全球高级副总裁兼亚洲区总裁熊晓鸽曾在一篇文章中建议Web 2.0的创业者们“不要把融钱当成最重要的事”，并且给出了IDG选择互联网公司的标准：“首先看创业者，它要能创造一些服务和技术，而且这些服务和技术要能取代现有常规产业，或促进其达到巅峰；第二，不管提供产品还是服务，有终端消费者都是最重要的。”如何才能达到这样的标准呢？这就要求我们把目光从美元转到用户、甚至是转到自己身上。想想看，广大的用户在日常生活中，遇到什么样的具体问题？或者是涌现出哪些新的需求？而且这些问题和需求是可以借助Internet来解决的？有时候，找对要开的锁比找对钥匙更为重要。当然，锁找对了，还是要能够想出开锁的办法。接下来的“指导篇”，就是告诉您怎么样去找到合适的锁，又怎么样打造开锁的金钥匙。  阅读全文      摘要: 当前web2.0革命风起云涌，web2.0强调服务，而服务最基本的要求是速度快和稳定，离开这两个谈功能强大和易用性都没有任何意义。本文介绍一些关于笔者运营一个web2.0网站的优化心得和经验，希望能够和大家共同探讨。

Web2.0网站不同于以往以静态信息为主的网站架构，以往的结构大体分为2层，一个是客户端浏览器，一个就是web服务器；而web2.0以动态和交互为主，一般是3层或者4层，在静态信息网站的结构上的web服务器后端会增加应用服务器和数据库。一般会把浏览器和web服务器归为最上一层即为web层，应用服务器为中间一层，数据库为最底层。从优化角度来讲，越上层优化获得益处越大，优化也是从上自下而来。
  阅读全文      摘要: Google架构
Amazon的体系结构
eBay的架构
YouTube网站架构
Facebook 详解  阅读全文      摘要: Web2.0的最大特征就是信息生产的革命，大大促进了网络内容的个体生产，从而引发了微内容的海量产生。

从方军的《网络大图景:人、物与讨论》汲取到的分类思路，微内容可以分为三大分类。

围绕人的。也就是人与人之间的连接、关系，这也是SNS网站所产生的微内容。

围绕物的。这是最通常的微内容方向。“物，是一种与人相对的泛指，新闻资讯是物，blog是物，图书是物，音乐是物，电影是物，旅行过的地方也是物，网摘是物，餐馆是物”。譬如豆瓣的对书、电影、音乐的评论、打分、收藏，抓虾的对blog item的收藏、推荐、分享等。

交互的。泛指人与人之间的虚拟的或真实的讨论。比如因为一个新闻引发的网络地震，就既包含了小范围内的真实讨论，也包含了大范围内虚拟的对话。
  阅读全文      摘要: Blog——博客、blog
Podcast——播客
RSS
Tag——标签
Wiki
Digg

  阅读全文      摘要: 1、在你开始之前，先定一个简单的目标。
2、链接是最基础的思想。
3、数据应该属于创建它的人。
4、数据优先，体验与功能其次。
5、做好积极分享一切的准备。
6、Web是一个平台；要让它成长。
7、理解与信奉“阶梯性”。
8、任何东西都是可编辑的。
9、Web上的身份是神圣的。
10、了解流行的标准并且使用他们。
11、遵循无意使用的规律。
12、粒化你的数据与服务。
13、提供用户能够单独受益的数据和服务。
14、让用户组织并过滤信息。
15、提供丰富的用户体验。
16、信奉并支持快速改进和反馈。
  阅读全文      摘要: 普通的系统，在编译发布之后，系统就不允许进行更改或扩充了，如果要进行某个功能的扩充，则必须要修改代码重新编译发布。使用插件可以很好地解决这个问题。  阅读全文 第一篇：IIS安装
Quote:

第一篇我们就不说了，怎么安装IIS网上到处都是，我们直接开始第二篇吧。

第二篇：PHP安装
Quote:

1、程序下载：
建议到PHP官方网站
网址：http://cn2.php.net/get/php-5.2.0-Win32.zip/from/a/mirror


2、程序安装：



解压或者未解压后，能看到php-5.2.0-win32-installer.msi文件时，双击文件，弹出下列对话框，我们再单击Next（下一步）：




在这一步，他会要你同意一个协议，不同意是没法继续安装的。同意就同意呗，反正这个东西是开源的，（应该是的吧）呵呵：




在这一步选择安装文件夹，如果要更改，单击Browse（浏鉴）。这里，我建议不要改更。第一，PHP文件不大；第二，由于这个本来不是Windows下的文件，更改不知道会不会有什么不能用的地方。：




选择你的WEB服务程序，建议选择IIS/PWS 3。这个选项在XP的IIS下，也就是IIS5.5下测试通过。：




程序安装组界面，别急点点下一步，看清楚下面的说明：




在上图中显示的Extensions（扩展）前面的“+”号点开，然后拖动滚动条，一直到下图位置。在GD2上右击，然后选择安装此功能（选择中的第一个或者二个）。
其实，第一个跟第二个的区别在这个地方不大。如果有下属选项时，选第一个，只会安装一些默认的功能，而第二个是完全安装。懂英语的朋友就不要笑话我了，呵呵  




同理，拖到mysql那一项，与前面一样的操作。如果你的mysql版本比较高，建议把mysqlli也装上，就是在mysql下面的那一个。  




需要的人还可以到下面这个地方，按照上面两步的方法安装PHP帮助文档与PEAR。然后单击Next（下一步）



单击Install（安装），开始正式安装PHP




安装过程，等待



安装完成，单击Finish（完成）结束安装





到这里，我们的PHP算是装完了。休息一下，我们马上开始讲第三篇，PHP与IIS整合

第三篇：PHP与IIS整合
Quote:

说起来，这一点应该是PHP安装最重要的一个环节了，如果这一步没有成功，其他的都白搞了，呵呵。



打开IIS，然后在你要支持PHP的网站名称上右击，选择“属性”。当然，如果你要所有的网站都支持PHP，也可以在“网站”上面右击，选择属性。




这是弹出来的网站属性对话框，我们要选择的是“主目录”选项卡。   




选择“主目录”选项卡后，再点击这个选项卡下面的“配置”




弹出应该程序配置选项卡，这里时候，我们要选择“添加”   




这步比较关键，这个是点击添加后弹出来的。
在“可执行文件”后面，我们选择“php-cgi.exe”，前面的路径是你的PHP安装路径。
而这个，在很多以前的参考上，都是一个DLL文件，而这个版本是php-cgi.exe。
“扩展名”填“.php”，别把那个点“.”丢了。
后面就是一直“确定”到最后了。呵呵





最后，我们来写一个测试程序“test.php”，然后打开测试。如果你看到了跟我图片中类似的内容，那么恭喜你，PHP安装成功了！
test.php内容：

Copy code

<?php
     phpinfo();
?>

 

     摘要: 作者 : Stephen Covey


It will change your life (at least the way you react to situations).

它將改變你的一生（最低限度，它將改變你對不同情況的反應）。


What is this principle? 10% of life is made up of what happens to you. 90% of life is
decided by how you react.

90/10 的定律是什麼？生命的 10% 是由你的際遇所組成，餘下的 90% 則由你的反應
而決定。
  阅读全文      摘要: 在很多企业应用中有时需要在特定的时间运行一段代码，比如银行需要在晚上系统相对空闲的时间内进行日结的对帐，到了规定时间系统需要触发对帐服务，运行对帐程序，通过WebSphere Application Server和EJB定时器服务能解决这个问题。

  阅读全文      摘要: 当您需要强大而灵活的可扩展 J2EE 应用程序时，可以利用 WebSphere® 集群环境。本文描述了在 WebSphere Application Server 集群环境中设计基于 Web 的应用程序时需要考虑的事项，包括应用程序文件更新和同步、会话对象的序列化和动态缓存。  阅读全文      摘要: 中间件厂商对分布式网络环境的定义和理解并非完全相同，因此不同的中间件产品实现集群时所使用的概念和方式也有所不同。本文基于较为普遍应用的中间件产品 IBM WAS ND v6.1 讲述集群及分布式网络环境的相关概念，并且使用一个实例来演示集群环境的完整实现过程。  阅读全文      摘要: 本文通过两个实际场景，介绍如何从头搭建一个WAS ND水平集群环境以及如何将一个已有的单节点（或三节点）Web环境扩展成五节点的集群环境。  阅读全文      摘要: J2EE集群的本质  阅读全文      摘要: 本文目的在于分析Jetspeed支持集群的现状。首先介绍了集群计算的背景知识，然后使用tomcat作为例子配置了一个集群，接着分析了 jetspeed对集群的支持现状，提出了解决这些问题的办法，最后详细解释了jetspeed保存sesson数据的操作，这将对jetspeed的改造有帮助。  阅读全文      摘要: 本文对Spring框架中所包含的AOP思想以及事务管理进行了分析，并通过对一个业务对象实现加锁/解锁的操作
  阅读全文

设计目标：

 

1.       开发效率

2.       性能、预算

3.       符合OO设计

4.       避免复杂性

5.       可维护性、可扩展性，可重用性

 

 

分布式应用

 

不足：

1．  增加了应用的复杂性

2．  对性能会造成一定的影响

3．  给OO Design带来一定的困难

优点：

1．  能满足多类型客户端的需求（applet, swing）

2．  能同时将组件部署到不同的应用服务器

采用前提：

1．  客户端需要使用J2EE技术，比如Swing

2．  为了与已有的分布式应用集成， 需要将J2EE组件部署到多个应用服务器

3．  实现对多应用组件部署进行控制，提高系统灵活性、可靠性

 

 

可选技术：

可通过集群和负载平衡（remote interface调用单服务器应用）来实现分布式应用的健壮性、灵活性

 

 

EJB技术

 

缺点：

1．  测试困难

2．  部署麻烦（classloader复杂、部署描述符复杂、开发－部署－测试周期长）

3．  采用remote interface的EJB不符合OO Design

4．  技术复杂，可能将简单需求变得复杂开发

5．  减少了应用服务器的选择

优点：

1．  能远程访问组件

2．  能将应用组件部署到不同服务器（分布式应用）

3．  支持多客户端访问

4．  使用到异步消息模式的时候可以采用message driven bean

5．  能实现复杂的事务管理

 

 

采用前提：

1、  对EJB底层比较熟悉

2、  需要使用EJB的角色安全访问

3、  需要使用EJB的事务管理

4、  需要使用EJB的线程安全管理

5、  需要使用基于RMI/IIOP的分布式架构

 

 

4种J2EE基本框架

 

一．非分布式框架

 

1、(Web UI tier + Business Logic tier) + implement tier + DBMS

 

实现简单、能满足大部分需求，是中小型J2EE项目中采用最多的框架，虽然没有使用EJB，但是层次清晰。

优点：

1．简单

2．速度快

3．符合OO设计

4．容易测试

缺点：

1．仅仅适用于Web UI

2．自己管理事务

3．无法实现高并发处理

4．无法使用entity bean

5．不支持多JVM应用

2、Web UI + local EJB + DBMS

 

稍微复杂，能使用EJB容器的事务，线程管理，没有采用分布式特性，性能比远程调用稍好

优点：

1．降低了EJB的复杂度

2．不会对基础框架造成影响

3．本地调用对性能有一定优势

4．可以使用EJB容器的事务和线程管理

5．可以使用entity bean

缺点：

1．比纯web应用复杂

2．单JVM运行

3．单客户端（web）支持

4．测试困难

 

 

二．分布式框架

 

1．基于远程调用的分布式

 

架构最复杂，对有远程访问客户端的需求是理想选择，健壮、灵活，但是不容易维护、测试、实现困难

优点：

1．  多客户端支持

2．  可将应用组件部署到多台服务器（JVM）

缺点：

1．增加了复杂度

2．影响性能

3．调试困难

4．必须在EJB容器中运行

5．异常处理复杂

6．OO设计困难

2．基于Web Service的分布式

 

对非J2EE客户端调用适用性好，无分布式调用，往往作为第一、第二架构的变体。

优点：

1．  通用标准，能支持更多客户端类型

2．  提供的Web service接口比RMI接口更好

3．  Web service传输协议比RMI更友好

缺点：

1．  性能差

2．  需要作object与xml之间的转换

3．  相对于java client来说，性能也不好

 

 

UI框架部分

 

选择UI的几个决定性因素：

1．  用户的实际需求

2．  项目的性能要求

3．  当前开发人员技术水平

 

 

 

 

J2EE框架设计几个需要强调的观点

 

简单

可维护性

性能

开发效率

 

 

J2EE框架设计通用法则

1．  使用J2EE，而不是让J2EE牵着鼻子走（因需而用，而不是因有而用）

2．  万不得已不要使用EJB（谬论：把EJB视为J2EE核心）

3．  万不得已不要采用分布式架构

4．  企业应用不要仅仅局限于J2EE技术（业务知识，.NET技术）

5．  J2EE不仅仅是一个规范

6．  谨慎处理数据库通用性，数据比J2EE应用的寿命更长

7．  利用好JDBC(SQL)技术

8．  不要忽略数据库的能力

9．  简单即是美

10．有时候使用EJB的好处可能来自于无状态Bean

11．在项目启动初期就应该考虑到性能问题

12．在设计的时候考虑应用在集群环境下运行的可能性

13．好的J2EE设计来自于好的OO设计

14．使用辅助类来隐藏底层API实现

15．在web UI层采用MVC框架

 

 

J2EE框架设计成则

1．  底层设计必须着眼当前可用规范而不是未来新规范

2．  没有针对实际需求的简单例程参考价值有限

3．  对框架进行详尽的测试

4．  对代码进行详尽注释

5．  尽可能早的对风险加以解决

6．  项目启动时就确定所采用的服务器

7．  在项目早期实现自动测试和构建

8．  在项目启动时雇佣J2EE设计专家

9．  避免重复发明轮子

10．统一设计和编码风格 

     摘要: 大量的负载均衡相关文档链接，在这里收集起来，以备后用  阅读全文