实现的方法很简单，在窗体添加一个 WebBrowser 组件，然后执行以下代码：

　　但随之而来出现了一个问题：WebBrowser 组件在未载入 HTML 之前是无边框的，当载入 HTML 之后，WebBrowser 四周出现了一个三维边框，和程序本身的风格极不协调，查看了 WebBrowser 的所有属性，没有属性可以改变这一设置。

　　经过测试以后发现，该边框并不是 WebBrowser 产生的，而是 WebBrowser 中载入的 HTML 产生的，如果是这样的话，那问题就好解决了，真接用 CSS 去掉边框：

　　当你高兴地设置以上 CSS 后，却发现 WebBrowser 的边框却依然存在，是 CSS 错了吗？NO，是你的 DOCTYPE 出了问题，以上的 CSS 在 XHTML 下是无效果的，将 DOCTYPE 设为 HTML4 即可：

　　闲话表过，再表闲话。

　　话说Mitch Kapor以数十亿美金高价把一手创建的Lotus公司卖给IBM后，做了一段投资人，又回归技术界，创立一家开源基金会。为了实现心目中“最好的PIM软件（个人信息管理，类似Outlook那样的）”，投入百万美元，聘请了一群最NB的程序员（包括Netscape元老级程序员、Macintosh操作系统核心程序员、微软资深开发工程师……），动手开干。有近乎奢侈的资源（财力、人力、时间），照说项目应该顺利进行吧。其实不然。这个名为Chandler的项目，从2000年开始立项，开发过程中软件功能列表一再缩减，直至今日尚未推出1.0正式版本。测试版本在我的Windows 2003操作系统上，仍然无法运行。

　　看过上面两桩闲话，读者大概知道我想说什么了。雄伟的愿景往往流于空想，做软件难，第一难就在于蓝图太宏大。常有朋友找我帮他们做顾问，看看他们的软件/网站项目。通常的过程会是这样——

 　　（演示、讲解项目目标、功能等等）
　　我：请问，这是你们真正想要的东西吗？
　　对方：是，我们想做最好的xxx。
　　我：请问，你们打算花多长时间来做这个项目呢？
　　对方：三个月。
　　我：坦率地说，你们不可能做得到。我的建议是，把刚才说的功能先砍掉一半，再砍掉三分之二，剩下的部分，大概就是三个月之内你们能完成的部分了。
　　对方：……

 　　产品设计者往往会想得太多，把所有可能路径都设想在内。而开发者则往往会低估项目难度，做出太过乐观的判断。这样的结果就是，以为可以在过短时间内完成过于庞杂的功能。危害有二：其一，项目无限期延误；其二，功能不断缩减。六个月甚至一年之后，大褂没做成，千疮百孔内裤倒是有一条。与其如此，不如一开始就以内裤为目标好了。

　　昨天有人问我，为什么是“先砍一半再砍三分之二”而不是“砍掉六分之五”。我说的“砍”，不是简单按字母顺序嚓嚓嚓，而是一个讨论、思考的过程。第一步去除一半，第二步去除一半的三分之二。起初设想出那么多功能，肯定花了不少心血。现在要砍，每一项都显得那么宝贵而舍不得丢弃。反复斟酌、流泪放弃，最后剩下的，是软件/网站项目最最核心和关键的功能，也是以目前资源所能完成的工作。以后，再视运营情况加以增补。

　　我想，做其它事，或许也可以采用类似的方法吧。大褂还是内裤，这是一个难题。以我之愚鲁，大褂不敢妄想，甚至没准内裤也做不出来，那就踏踏实实、裁剪缝制一个真有用的口罩吧。

　　我想这种场景在我们的项目实施过程中会经常出现，那么接下来该做些什么呢？是技术人员该就此技术方案找出N+1条拒绝的理由还是产品经理继续讲述第N+1遍方案细节呢？当然都不是，腾讯搜索产品中心副总经理邢宏宇认为：讨论一致性的目标才是最应该做的。

　　腾讯搜索产品中心副总经理邢宏宇是一位技术团队“老练的”的领路人。他认为，在项目实施的过程中，技术和需求之间会产生矛盾这是一个普遍的现象。这些矛盾的存在带来的负面影响可谓是大小不一，大到会使整个项目停滞或者流 产，小到员工之间不和睦闹矛盾。当然，我们也看到了很多成功合作的案例，他们是如何解决这些矛盾的呢？

　　在上面的故事中，其实产品经理做了B技术方案是为了实现产品功能A，那么他只需要把他要实现的功能A清楚的描述给技术人员就可以了。最后技术人员用了更好的技术方案C轻松的实现了产品功能A。因此，在现代项目实施过程中，产品经理和技术人员之间需要学会“沟通、信任、支持”。

　　软件产品特别是互联网产品的多样性、多变性的特征使得它的诞生必然要伴随着成千上万次的沟通。 邢宏宇表示，“沟通更深层次的也代表着你主动参与意识的强弱，而不仅仅是被动的去完成一项任务，参与程度越高它所能给你带来的乐趣也越大。”

　　沟通也需要技巧，正如我们之前的故事里所讲，如果产品经理一直和技术人员沟通B技术方案，但技术人员却并不知道是为了实现功能A，这样的沟通只会浪费时间。所以，沟通也要“各司其职”。越线的沟通就会埋下问题的种子，这也是为什么沟通之后需要信任。

　　产品经理擅长的是功能描述、技术人员擅长的是技术方案的制定。邢宏宇说：“我们都要相信对方的专业素质，技术人员要相信产品经理提出的功能一定是经过专业思考的，而产品经理也一定要相信针对这样的功能技术人员肯定能拿出最优的技术解决方案。”只有这样，技术人员才不会说产品的某一个功能是“垃圾”，而产品经理也不会越俎代庖的帮技术人员想好技术方案。团队之间表现在，技术人员帮助产品经理提建议和想办法，思考自己在技术实现的过程中出现的问题，可不可以做技术上的优化；而产品经理在帮助技术人员建议方案同时也要反思一下自己提出的功能是否真的合理。

　　邢宏宇总结说：“任何一个软件产品都是一个高度集中的集体智慧，这其中团队内部、团队之间你来我往的协作过程中，包含了更多的艺术和技巧。”

　　上面是对Apache的配置，Tomcat也是需要调整的，修改tomcat目录/conf/web.xml文件，如下，将listings改为true：

            <servlet>
              <servlet-name>default</servlet-name>
              <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
              <init-param>
                <param-name>debug</param-name>
                <param-value>0</param-value>
              </init-param>
              <init-param>
                <param-name>listings</param-name>
                <param-value>false</param-value>
              </init-param>
              <load-on-startup>1</load-on-startup>
            </servlet>


　　特此记录下来，供大家参考。
 

整理：枫远雅客 http://www.fyyk.com   点击下载PDF文件 
转载自http://blog.csdn.net/esoftwind
翻译自TSS的文章。-- Uncover the hood of J2EE Clustering
原文：http://www.theserverside.com/tt/articles/article.tss?l=J2EEClustering

    越来越多的关键应用运行在J2EE（Java 2, Enterprise Edition）中，这些诸如银行系统和账单处理系统需要高的可用性（High Availability, HA），同时像Google和Yahoo这种大系统需要大的伸缩性。高可用性和伸缩性在今天高速增长的互连接的世界的重要性已经证实了。eBay于1999年6月停机22小时的事故，中断了约230万的拍卖，使eBay的股票下降了9.2个百分点。

    J2EE集群是用来提供高可用性和伸缩性服务，同时支持容错处理的一种流行的技术。但是，由于J2EE规范缺乏对集群的支持，J2EE供应商实现集群的方法也各异。这给J2EE架构师和开发人员带来了很多困难。以下是几个常见的问题：
     >为什么带集群功能的商业J2EE服务器产品如此昂贵？（10倍于不带集群功能的产品）
     >为什么基于单服务器环境构建的应用不能在集群中运行？
     >为什么应用在集群环境中运行得很慢，但在非集群环境中却快得多？
     >为什么集群的应用移植到其他服务器中失败？

理解这些限制和要素的最佳方法是学习他们的实现方式。