gic根本没有CORBA构造，而缺省使用t3协议。
WebSphere和Visual Age衔接紧密，而WebLogic是IDE无关的，实际上，你几乎可以使用任何的开发工具。
由此可见，差异还是相当多。如果你是一种应用服务器的专家，并不意味着你就是所有应用服务器的专家。这种区别体现在IDE，debugger，build工具，配置管理等等方面。具备某提供商的某项特殊工具的使用经验，可以在评估该提供商的竞争对手产品时具有一些便利。但是，不要奢望在不同产品之间进行无缝的转移或衔接。因此，你不得不花费足够多的时间在熟练掌握这些工具上。
风险7: 设计中没有充分考虑到可伸缩性和产品性能
项目阶段：
设计
受影响的项目阶段:
开发、负载测试及成熟化
对系统的影响:
可伸缩性、性能、可维护性
症状:
无法忍受的速度缓慢
系统给服务器端增加的沉重负担，而无法利用到一些聚簇技术。
规避方案:
把精力集中于性能和可伸缩性方面的需求，明确开发中要达到的性能指标。如果你需要每秒50个事务，而你的EJB设计只能提供40个，那么你就需要考虑替代方案，诸如存储过程，批处理，或者重新考虑OLTP的设计。
尽可能让你的提供商加入进来，他们应该非常清楚其产品的强项和弱处在哪里，然后给你提供最直接的帮助。
备注:
本风险与风险2 (over-engineering)似乎有些冲突。实际上，两者相互影响。 我对风险2给出的解决方案是，只在绝对必要的情况下才进行构建。而对与性能和可伸缩性，你要预先划分好什么是必须要做的。
如果你实现就识别出系统需要非常强的可伸缩性，并把它作为一个比较关键的需求，那么你首先需要选择一个带有很强的簇支持及事务型缓存的应用服务器。另外，你应把业务对象设计为EJB，从而可以充分利用服务器架构的优势。 XP也没有问题，你仍然是只做绝对必要的工作。
我把这样的观点看作是一种检查和平衡的方法。我们只需要最简单可能性的系统，该系统只提供客户所需要的功能与行为即可。
风险8: 陈旧的开发过程
项目阶段：
开发
影响阶段:
稳定化，成熟化
对系统的影响:
可维护性、代码质量
症状:
项目计划看上去似乎类似于瀑布模型: “首先草构设计，然后在一个很长的周期里进行开发。”
由于不存在构建（build）过程，每次构建都象是噩梦
构建的日期等于损失开发的日期，因为什么也没有做成
在集成以前组件没有分别被充分地测试过，而集成测试意味着将2个不稳定的组件放在一起，然后查看堆栈里的跟踪结果。
规避方案:
好的软件方法学将提高你的软件生命期。此前我已经提到XP方法，你可以在网上找到很多这方面的资料。
备注:
JUnit可以用来进行单元测试，Ant工具可以进行编译与构建，这2种工具都对XP方法有很好的支持。
风险9: 没有好的架构方式
项目阶段：
开发
影响阶段:
开发、稳定化、成熟期
对系统的影响：
可维护性、可伸缩性、代码质量
症状:
在代码中使用了很多次的核心库中发现Bug。
没有建立日志标准 -- 于是系统的输出很难读取或者解析。
不良的不一致的异常处理。在有些站点中我们甚至可以看到，出错信息直接暴露给了最终用户，例如在用户在他的购物车核帐时发送一条SQLException堆栈跟踪信息，用户接着会怎么做？打电话给数据库管理员要求对primary ke